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. > > I am well aware of section 4.2.3 of RFC8446, the signature_algorithms" > extension and the implicitly subsumed by it "signature_algorithms_cert". > And yet, in practice, at least some TLS implementations treat the > certificate chain as an opaque bag of bits to pass to the X.509 layer. > They don't know or care what algorithms are employed there. Only the EE > key that signs CertificateVerity is directly examined by the TLS layer. > Those implementations are already potentially nonconformant. -Ekr
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
