On Sun, Mar 15, 2026 at 10:06:23PM -0700, Eric Rescorla wrote: > On Sun, Mar 15, 2026 at 10:01 PM Viktor Dukhovni <[email protected]> > wrote: > > > On Sun, Mar 15, 2026 at 08:51:02PM -0700, Eric Rescorla wrote: > > > > > - If TLS 1.2 is negotiated, servers MUST NOT send > > > certificates which are signed by or contain keys using > > > these algorithms. > > > > This would I think be undesirable. The details of which trust-anchors a > > TLS client or server supports, and which algorithms are accepted when > > verifying X.509 certificate chains are practically out of scope for TLS. > > > > That's now that RFC 5246 (which controls TLS 1.2 says): > > If the client provided a "signature_algorithms" extension, then all > certificates provided by the server MUST be signed by a > hash/signature algorithm pair that appears in that extension. > > This bullet is merely the logical consequence of that combined with > this code point not being meaningful for TLS 1.2.
Signature_algorithms_cert supercedes that requirement in TLS 1.2. While ML-DSA (or SLH-DSA) not having either certificate type (yes, there are two) in TLS 1.2 prevents those from appearing as signature algorithms, the algorithms can still appear in certificate signatures. And while interop is not great, it is still optimal (because if it does not work, nothing would have worked anyway). -Ilari _______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
