Good idea. Option (f) could be an erratum that calls out EdDSA and ML-DSA as examples of "built-in digest signatures" in X.509 that fall under the non MD-5/SHA-1 hash bullet of RFC 5929.
-----Original Message----- From: Watson Ladd <[email protected]> Sent: Wednesday, October 29, 2025 11:45 AM To: Kampanakis, Panos <[email protected]> Cc: Nico Williams <[email protected]>; [email protected] Subject: RE: [EXTERNAL] [TLS] Re: tls-server-end-point channel binding for ML-DSA CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe. On Wed, Oct 29, 2025 at 8:3 AM Kampanakis, Panos <[email protected]> wrote: > > Hi Nico, > > Interesting. Indeed, it seems that currently ML-DSA server certs would appear > to fall under the "undefined hash subcase" because they don't have an obvious > digest. > > 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). > 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 😉 Would everyone come to that same conclusion though? Might be an errata or a short doc clarifying is needed. > > _______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
