On Wed, Oct 29, 2025 at 03:35:13PM +0000, Kampanakis, Panos wrote: > But strictly speaking, ML-DSA X.509 certs > (draft-ietf-lamps-dilithium-certificates) have a built-in hashing > which SHAKE256 hashes the public key tr and the message (TBScert).
Oh. I see. Thanks! So maybe OpenSSL needs to implement the missing metadata in their APIs so that PG can use this? When the original poster referred to ML-DSA certificates, were they effectively referring to OpenSSL's implementation of draft-ietf-lamps-dilithium-certificates? Or are there competing bindings of ML-DSA to PKIX? (Interesting note about why not HashML-DSA in the I-D. Well done!) > This produces the mu value used in the ML-DSA Sign algorithm that > produces the cert signature. So, I would argue that (f) ML-DSA certs > fall under the second bullet which prescribes reusing the cert > signature hash, and that hash is SHAKE256. Case closed, no more work > required 😉 I would too then, though I have one question above that needs answering before I bless that answer. Also, there is still the question of whether we should be more explicit in associating a digest function with _every_ signature algorithm that can be used for certificates, and where we might record such associations. This is really a failure in RFC 5929 (for which I'm obviously partly to blame). Fifteen years ago it was pretty obvious what hash function was associated with what signature algorithms, and less obvious that it would not always be so obvious. That's all changed now. So I think that while we might have a useful answer for ML-DSA we might still also need to update RFC 5929. I'm now leaning towards creating an IANA registry of signature algo -> digest algo for TSEP CB. Nico -- _______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
