On Thu, 10 Sep 2026 22:13:13 GMT, Hai-May Chao <[email protected]> wrote:
>> src/java.base/share/classes/sun/security/ssl/CertificateMessage.java line
>> 1041:
>>
>>> 1039: SSLLogger.warning("No available authentication
>>> scheme");
>>> 1040: }
>>> 1041: } else if (pos instanceof X509Possession x509Possession &&
>>
>> Why we fail earlier here now? How is it related to ML-DSA signature scheme?
>
> 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.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/32529#discussion_r3992461896
