RFR: 8272875: Change the default key manager to PKIX [v3]

[Artur Barashev]

On Mon, 5 May 2025 08:50:07 GMT, Daniel Jeliński <djelinski at openjdk.org> wrote:

> Well, technically the current 1ms takes into account both the client side and the server side of the handshake. Last time I checked, they were more or less evenly split. The 1ms slowdown will happen entirely on the server side, so it's more of a 3x slowdown.

Yes, good point, thanks!

> 
> Most of the time an extra millisecond doesn't matter, but it can be a factor in the server startup time on a busy server. We currently invalidate all session resumption tickets during server restart.

I see. But at the same time my understanding is that PKIX KeyManager's boot-up should be faster because it doesn't cache the whole KeyStore.

> 
> Re your point 3: what's the observable difference? If the certificate we can offer doesn't meet the peer's expectations, will we fail the handshake on the server side instead of failing on the client side, or is it something else?

Yes, we fail on the server side if we can't offer a certificate passing peer-supported algorithms in "signature_algorithms_cert" extension.

I put together a prototype of yet another KeyManager which can be a compromise solution: it's basically a `SunX509` with algorithm constraints: #25016

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

PR Comment: https://git.openjdk.org/jdk/pull/24756#issuecomment-2851050257