On Tue, 13 May 2025 14:01:10 GMT, Artur Barashev <abaras...@openjdk.org> wrote:
> > 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`. Should the property be a switch for SunX509 > > KeyManager, not a general toggle for all KeyManager? Avoiding its misuse > > for `X509KeyManagerImpl` that may lead to disable the existing RFC > > compliant algorithm constraints checking? It might be preferable to keep > > the property logic in `SunX509KeyManagerImpl` (not in the common code). > > @haimaychao Thanks for looking into it! Yes, it will disable constraints > checking for both key managers and I did it this way on purpose. I think it > will be simpler and less confusing to the end users. This system property is > off by default and my assumption is that if end users want to disable KM > algorithm constraints checking they would expect it to be disabled > system-wide. Making this toggle SunX509-specific is a trivial change if we > have a consensus on this. > > @seanjmullan What do you think? Need to think about it some more, but I am kind of leaning towards it only affecting SunX509. The main benefit of the property is to workaround any compatibility issues where current code is not ready for the change. Any application already using the PKIX TrustManager already has this checking enabled/enforced. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25016#issuecomment-2884859280
