On Fri, 11 Sep 2026 18:56:58 GMT, Artur Barashev <[email protected]> wrote:

>> In certificate selection path, after X509Authentication.createPossession() 
>> returns a cert/key, this is to verify that it can actually produce a valid 
>> CertificateVerify signer for the peer requested signature schemes (make sure 
>> parameter set check after cert selection).
>> 
>> This change is validated by the new tests: MLDSACertSelection.java for 
>> test.case=fail44, and MLDSAClientAuthMismatch.java for test 
>> case=test.case=failClientAuthMismatch.  Mach5 tier1-tier3 tests also passed.
>
> I have a few concerns about this change:
> 
> 1. First, could you clarify why this broader preflight validation is 
> necessary for JDK-8381641?
> I understand its connection to ML-DSA: the key manager selects a credential 
> using the general ML-DSA key family and can therefore return a key whose 
> parameter set does not match any signature scheme offered by the peer. 
> However, getSignerOfPreferableAlgorithm() is already called when producing 
> CertificateVerify.
> 
> 2. Basically instead of failing at CertificateVerify step we fail in the 
> preceding CertificateMessage step, but there is a performance impact - during 
> successful TLS 1.3 authentication, JSSE now calls 
> getSignerOfPreferableAlgorithm() twice. Each call repeats:
> 
>     - Iteration over peer signature schemes
>     - Algorithm-constraint and key-parameter checks
>     - Signature.getInstance(algorithm)
>     - Signature.initSign(...)
>     
> `initSign()` can involve provider selection, key validation, native calls, or 
> HSM/PKCS#11 resource acquisition.     The impact will probably be small for 
> in-memory JDK providers but could be more noticeable for hardware-backed or 
> remote keys.
> 
> I think we should choose one of the following:
>  - If early validation is not required, remove this check and retain the 
> existing validation during CertificateVerify.
>  - Save `schemeAndSigner:possession` pair returned in CertificateMessage step 
> in HandshakeContext and then reuse it in CertificateVerify step (right now we 
> only save `handshakePossessions`). This way we would avoid the redundancy and 
> the performance impact.

Preflight validation in `CertificateMessage` is not needed and removed, and 
continue with original validation in `CertificateVerify`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/32529#discussion_r4023894781

Reply via email to