On Wed, 14 May 2025 18:16:13 GMT, Artur Barashev <abaras...@openjdk.org> wrote:
>> When the deafult SunX509KeyManagerImpl is being used we are in violation of >> TLSv1.3 RFC spec because we ignore peer supported certificate signatures >> sent to us in "signature_algorithms"/"signature_algorithms_cert" extensions: >> https://datatracker.ietf.org/doc/html/rfc8446#section-4.4.2.2 >> https://datatracker.ietf.org/doc/html/rfc8446#section-4.4.2.3 >> >> X509KeyManagerImpl on the other hand includes the algorithms sent by the >> peer in "signature_algorithms_cert" extension (or in "signature_algorithms" >> extension when "signature_algorithms_cert" extension isn't present) in the >> algorithm constraints being checked. > > Artur Barashev has updated the pull request incrementally with one additional > commit since the last revision: > > Make the test run on TLSv1.3 test/jdk/sun/net/www/protocol/https/HttpsClient/ServerIdentityTest.java line 1: > 1: /* Are these changes relevant to this issue? It doesn't use a SunX509 TrustManager AFAICT. test/jdk/sun/security/ssl/X509KeyManager/PeerConstraintsCheck.java line 1: > 1: /* I am trying to figure out when the algorithm constraints are enabled, why the key isn't being selected. I don't see anywhere that you are setting the algorithm constraints property. Please add some more comments explaining how the exception case occurs. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25016#discussion_r2129881920 PR Review Comment: https://git.openjdk.org/jdk/pull/25016#discussion_r2130018039
