On Mon, 12 May 2025 20:05:18 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 sure the exception happens during KeyManager's algorithm check It is nice to refactor the common code for algorithm constraints checking into a new class, `X509KeyManagerConstraints.java`, used by both `SunX509KeyManagerImpl` and `X509KeyManagerImpl`. However, it looks like a new system property, "jdk.tls.keymanager.disableConstraintsChecking", is introduced, and it will affect both `SunX509KeyManagerImpl` and `X509KeyManagerImpl`. When setting this property to true, it will disable the existing RFC compliant algorithm constraints checking even in `X509KeyManagerImpl`, and we’d want to avoid that. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25016#issuecomment-2874984309
