RFR: 8349583: Add mechanism to disable signature schemes based on their TLS scope [v12]

Sean Mullan mullan at openjdk.org
Thu Mar 6 20:08:07 UTC 2025


On Wed, 5 Mar 2025 01:14:40 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> 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
>> 
>> Also fixing JDK-8350807 on the server side just as a side-effect, not a dedicated fix for that issue.
>
> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update documentation and unit tests to signal TLS scope case-insensitivity

src/java.base/share/conf/security/java.security line 747:

> 745: #
> 746: #     HANDSHAKE restricts algorithm to be used for signing TLS handshake.
> 747: #     CERTIFICATE restricts algorithm to be used for signatures in certificates.

s/HANDSHAKE/'Handshake'/
s/CERTIFICATE/'Certificate'/

Suggest slight rewording: "Handshake restricts the use of the algorithm in TLS handshake signatures." and "Certificate restricts the use of the algorithm in certificate signatures."

src/java.base/share/conf/security/java.security line 748:

> 746: #     HANDSHAKE restricts algorithm to be used for signing TLS handshake.
> 747: #     CERTIFICATE restricts algorithm to be used for signatures in certificates.
> 748: #     These constraints can't be mixed with any other usage constraints for the

s/can't/cannot/ (sounds more formal).

The word "any" seems redundant, suggest removing.

src/java.base/share/conf/security/java.security line 752:

> 750: #     ampersand '&'.
> 751: #     See https://datatracker.ietf.org/doc/html/rfc8446#section-4.2.3 for more
> 752: #     information on signatures used in TLS handshake and in certificates.

I suggest we don't include a reference to the TLS 1.3 RFC. Something like this might be fine for the developer's guide though.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23681#discussion_r1983972328
PR Review Comment: https://git.openjdk.org/jdk/pull/23681#discussion_r1983974557
PR Review Comment: https://git.openjdk.org/jdk/pull/23681#discussion_r1983981814


More information about the security-dev mailing list