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.
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.
While it may well be imprudent for a TLS 1.2 server to send a chain with
a classical EE key that is ultimately signed by a PQC trust-anchor,
because many/most clients may not be able to verify it, I see no reason
to prohibit this, nothing about presenting such a chain looks to me like
adding features to the frozen TLS 1.2 protocol. The choice of chain to
configure is up to the server operator.
If a particular server knows that its clients support PQC in X.509, and
yet for some reason TLS 1.2 is still required, what is the compelling
reason to preclude this?
--
Viktor. 🇺🇦 Слава Україні!
_______________________________________________
TLS mailing list -- [email protected]
To unsubscribe send an email to [email protected]
