Clients using TLSv1.2 shall include the signature_algorithm extension with at least the
combination of {SHA-1, RSA; SHA-256, RSA; SHA-256, ECDSA} in the ClientHello
message. The combination SHA-1 and RSA is for backward compatibility only (see also below)
and depends on an organization’s security policy (see also 7.4.3). Other combinations may be
supported.
However, there is another footnote further in the document: NOTE The German BSI recommends using RSA (IANA values 0x0401, 0x0501,
0x0601) only until 2025 as problems with the padding in the utilized PKCS#1 are
known.
If BSI recommends only using RSA (PKCS1) until 2025, then why should the TLS 1.2 Client still include RSA as a signature value in the supported_algorithms extension?
Proposal
The standard should be updated to mandate that the TLS 1.2 Client should only send "SHA-256, ECDSA" in its supported_algorithms extension, or the TLS 1.2 Client should "look ahead" to RFC 8446 (TLS 1.3) list of supported_algorithms and use those instead.
Discussion
Created
Status
Decision to reject based on the exisiting explanations in IEC 62351-3 in clause 7.5.4
08 Jan 25
Approval (N/A)
Now it is more clear.
I agree, we should reject the proposal.
27 Aug 24
Discussion (red)
The proposal with falsely marked as "future improvement" but was actually targeting (N/A).
Here the clarified proposal with more details:
Proposal to reject = Accept (N/A) due to the following:
- Clause 7.5.4 already states that the combination of {SHA1, RSA} is intended for backward compatibility only. It is also stated that the usage depends on an operator's security policy. Moreover, security event handling is defined, when detecting a combination of {SHA1, RSA}. These statements seem sufficient.
- The German BSI statement in Table 6, relates to RSA with padding utilizing PKCS#1. This does not rule out RSA usage as such. There are other RSA signature algorithms stated in Table 6 (like rsa_pss_rsae_sha256), which can be used beyond 2025.
27 Aug 24
Discussion (red)
So, what is the real proposal now?
27 Aug 24
Discussion (red)
Proposal for Approval (Future Improvement)
26 Aug 24
Discussion (red)
I agree with the comments of Steffen Fries.
27 Jun 24
Accepted
As stated in the text, the support is only intended for backward compatibility to allow interworking with legacy equipment.
As SHA-1 is deprecated in IEC 62351-3:2023 it would be consequent to not propose it per default and only provide a statement that if backward compatibility is required and the organization's security policy allows it, it may be offered.