JDK-8350902 : Add mechanism to disable signature schemes based on their TLS scope
  • Type: CSR
  • Component: security-libs
  • Sub-Component: javax.net.ssl
  • Priority: P2
  • Status: Closed
  • Resolution: Approved
  • Fix Versions: 8-pool,11-pool,17-pool,21-pool,23-pool,24-pool,25
  • Submitted: 2025-02-27
  • Updated: 2025-03-24
  • Resolved: 2025-03-24
Related Reports
CSR :  
JDK-8349583 - Add mechanism to disable signature schemes based on their TLS scope
Relates :  
JDK-8352277 - java.security documentation: incorrect regex syntax describing "usage" algorithm constraint
Description
Summary
-------
Currently when a signature scheme constraint is specified with "jdk.tls.disabledAlgorithms" property we don't differentiate between signatures used to sign a TLS handshake exchange and the signatures used in TLS certificates:
https://datatracker.ietf.org/doc/html/rfc8446#section-4.2.3
We need to implement a mechanism to disable signature schemes based on their TLS scope.

Problem
-------
The current syntax of the jdk.tls.disabledAlgorithms security property doesn't allow to disable algorithms based on their TLS scope, i.e. their application inside the TLS protocol. For example, if you add "rsa_pkcs1_sha1" to the jdk.tls.disabledAlgorithms security property, it disables specified signature scheme to be used for both: handshake signing and certificate signing.

Solution
--------

Implement a mechanism to disable signature schemes based on their TLS scope.

Specification
-------------
The definition of the `jdk.tls.disabledAlgorithms` security property in the `java.security` file will be updated to describe new functionality. The following text will be added to the definition:

     - TLS protocol specific usage constraints are supported by this property:

       UsageConstraint:
           usage UsageType { UsageType }

       UsageType:
           ([HandshakeSignature] | [CertificateSignature])

       HandshakeSignature restricts the use of the algorithm in TLS handshake
       signatures. CertificateSignature restricts the use of the algorithm in
       certificate signatures. An algorithm with this constraint cannot include
       other usage types defined in the jdk.certpath.disabledAlgorithms
       property. The usage type follows the keyword and more than one usage type
       can be specified with a whitespace delimiter.
       Example: "rsa_pkcs1_sha1 usage HandshakeSignature"
Comments
Moving to Approved. [~abarashev], if additional constraints should be added here -- along the lines of the discussion in https://bugs.openjdk.org/browse/JDK-8352288?focusedId=14763512&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14763512 -- please update this CSR and re-Finalized it so it can be re-Approved.
24-03-2025
Additional CSR to fix existing regular expression syntax: https://bugs.openjdk.org/browse/JDK-8352288
18-03-2025
[~abarashev], at your option, a separate bug can be filed to fix the other regular expressions.
18-03-2025
[~darcy] Thanks for the explanation. Initially I assumed that existing documentation in java.security can't be modified, but that doesn't seem to be the case for this particular matter of incorrect syntax. I updated this CSR with the correct proposed syntax. The syntax also to be updated in 2 other places in java.security where we describe "usage" constraint.
18-03-2025
[~ascarpino]; right the regex/grammar should include the semantic constraints on the set of strings to be recognized. For example, if the constraint is "the string "`usage`" must be followed by exactly one of [HandshakeSignature] and [CertificateSignature]" then the regex for that is something like usage ([HandshakeSignature] | [CertificateSignature] ) Thanks and HTH
18-03-2025
I believe I understand what Joe is saying. Both UsageConstraints require at least one value to follow the `usage` keyword. The change associated with this CSR should be: usage ([HandshakeSignature] | [CertificateSignature]) The existing certpath example also should be: usage ([TLSServer] | [TLSClient] | [SignedJAR])
18-03-2025
Hi [~darcy]! Could you please elaborate on your last comment? I'm following the established pattern. I also include the sentence with the explanations of the syntax: "The usage type follows the keyword and more than one usage type can be specified with a whitespace delimiter."
17-03-2025
Moving back to Provisional, not Approved. [~abarashev], the section of the java.security file you cite supports my earlier claim that the regex proposed in this CSR does not capture the desired semantics: # # UsageConstraint: # usage [TLSServer] [TLSClient] [SignedJAR] # This constraint prohibits the specified algorithm for # a specified usage. This should be used when disabling an algorithm # for all usages is not practical. 'TLSServer' restricts the algorithm # in TLS server certificate chains when server authentication is # performed. 'TLSClient' restricts the algorithm in TLS client # certificate chains when client authentication is performed. # 'SignedJAR' constrains use of certificates in signed jar files. # The usage type follows the keyword and more than one usage type can # be specified with a whitespace delimiter. # Example: "SHA1 usage TLSServer TLSClient" # Please update the CSR with a regex grammar that reflects the desired constraints.
17-03-2025
[~abarashev], please Finalize the CSR to indicate it is ready for the second phase of review. Thanks.
12-03-2025
Hi [~darcy]! I have updated the text in java.security file to address your concerns. Also, this CSR has been reviewed by [~mullan]. Please let me know if you have any other questions/concerns.
12-03-2025
It must be followed by one or more usage types. About the syntax: I'm using the existing convention in "java.security" file: https://github.com/openjdk/jdk/blob/99fb350bf65f9469c8097ddebcc6742255435a88/src/java.base/share/conf/security/java.security#L601
03-03-2025
The typical regex-ish interpretation of usage [HANDSHAKE] [CERTIFICATE] is that the string "usage" can be optionally followed by "handshake" or optionally followed by "certificate". There is no constraint from the grammar as given that either "handshake" or "certificate" is required. That semantics would be given by something like: usage ([HANDSHAKE] | [CERTIFICATE])
03-03-2025
"rsa_pkcs1_sha1 usage" would be invalid syntax. Whatever is not specified in jdk.tls.disabledAlgorithms security property should be allowed.
03-03-2025
Hi [~darcy]! I've added the usage example. And we'll have another CSR when we are actually going to use that mechanism to disable SHA-1 in TLS/DTLS 1.2 handshake signatures (JDK-8340321). I'll ask another engineer from our team to review it.
03-03-2025
So, by the grammar rsa_pkcs1_sha1 usage certificate handshake would be rejected while rsa_pkcs1_sha1 usage would be accepted.
03-03-2025
Moving to Provisional, not Approved. [~abarashev], please have one or more other engineers in the security area review this CSR before it is re-Finalized. Also, please give more context about the grammatical changes. Are uses of this mechanism intended to be described in another CSR?
03-03-2025