JDK-8365955 : Do not send signature_algorithms_cert extension if not required
  • Type: Enhancement
  • Component: security-libs
  • Sub-Component: javax.net.ssl
  • Priority: P4
  • Status: Closed
  • Resolution: Won't Fix
  • Submitted: 2025-08-21
  • Updated: 2025-10-21
  • Resolved: 2025-10-20
Related Reports
Relates :  
JDK-8365820 - Apply certificate scope constraints to algorithms in "signature_algorithms" extension when "signature_algorithms_cert" extension is not being sent
Description
The TLS 1.3 spec says that the signature_algorithms_cert defaults to the algorithms configured in signature_algorithms; we could could send signature_algorithms alone unless we're configured to permit different algorithms in both cases.

As one specific example, currently for TLS 1.3 handshakes we remove the RSA_PKCS1 signature schemes from signature_algorithms and only send them in signature_algorithms_cert. However, the spec permits sending RSA_PKCS1 algorithms in signature_algorithms, and some existing TLS implementations do that to avoid sending both extensions.
Comments
"signature_algorithms_cert" extension can be disabled with `jdk.tls.client.disableExtensions` and `jdk.tls.server.disableExtensions` system properties. Also, the client sends RSA_PKCS1 signature schemes in "signature_algorithms" extension when "signature_algorithms_cert" extension is disabled, and when both TLSv1.3 and TLSv1.2 protocols are supported (e.g. SSLContext.getInstance("TLS")). This is per RFC 8446: RSASSA-PKCS1-v1_5 algorithms: Indicates a signature algorithm using RSASSA-PKCS1-v1_5 [RFC8017] with the corresponding hash algorithm as defined in [SHS]. These values refer solely to signatures which appear in certificates (see Section 4.4.2.2) and are not defined for use in signed TLS handshake messages, although they MAY appear in "signature_algorithms" and "signature_algorithms_cert" for backward compatibility with TLS 1.2. If we send RSA_PKCS1 signature schemes in "signature_algorithms" extension when TLSv1.3 is the only enabled protocol, that would be not an RFC-compliant behavior. We can make a special case for QUIC if needed, but QUIC standard doesn't mention any different treatment for "signature_algorithms" extension.
21-10-2025