On Sun, Mar 15, 2026 at 10:06:23PM -0700, Eric Rescorla wrote:
> > 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 know, but it is my impression that this is rarely enforced, for the
simple reason that most servers have but one chain to offer, and so
offer that in the hope that the client will cope, regardless of what
some (perhaps needlessly strict) text in the specifications was trying
to suggest.
> > 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.
The text in question is I believe broardly ignored, and the same would
likely be fate of similar text here. If a TLS stack is capable of
choosing the most likely compatible chain out of multile chains
configured, it should do so regardless of any text encouraging it to do
that. But proscribing going ahead with all that the server or client has
available does not seem logical to me.
Are we trying to punish implementations for being liberal in what they
accept? Why does prohibiting PQC CA signatures in a TLS 1.2 X.509 chain
warrant a MUST (NOT)? Configuring such a chain would, for obvious
reasons, dramatically limit interoperability, but precluding its use
seems overkill.
--
Viktor. 🇺🇦 Слава Україні!
_______________________________________________
TLS mailing list -- [email protected]
To unsubscribe send an email to [email protected]
