On Mon, 5 May 2025 08:50:07 GMT, Daniel Jeliński <djelin...@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
