* Overall, if we are to support the simultaneous use of PQ and traditional signatures in TLS, I think that composites are a superior approach.
Composite certs indeed seem to be a superior approach. Among other benefits: no major API changes for TLS stacks, fits in the protocol nicely. * As far as I can tell, the only real benefit of this design is that it allows you to perform a transition of the form traditional -> simultaneous PQ/T -> pure PQ while avoiding the need to issue separate composite certificates. The main difficulties in these transitions are probably around distributing (and negotiating) new roots, and dual certs still require new roots. Cheers, Andrei From: Eric Rescorla <[email protected]> Sent: Thursday, June 25, 2026 9:50 AM To: tirumal reddy <[email protected]> Cc: <[email protected]> <[email protected]> Subject: [EXTERNAL] [TLS] Re: Fwd: New Version Notification for draft-yusef-tls-pqt-dual-certs-02.txt Document: draft-yusef-tls-pqt-dual-certs-02.txt Overall, if we are to support the simultaneous use of PQ and traditional signatures in TLS, I think that composites are a superior approach. As far as I can tell, the only real benefit of this design is that it allows you to perform a transition of the form traditional -> simultaneous PQ/T -> pure PQ while avoiding the need to issue separate composite certificates. The cost of this savings is quite a bit of additional complexity in TLS. I'd like to see some analysis that shows that cost is worth paying. Given modern automation (ACME) and shortened certificate lifetimes, it's hard to believe just issuing the certificates is a big deal, though perhaps technically being able to make the composites is? In any case, I'd like to see much stronger arguments than have been advanced here before we absorb this complexity. With that said, even on its own terms I think this draft is trying to get too clever. Specifically by: - Overloading the signature scheme code points to indicate that you are sending multiple certificate chains. - Only signing a partial transcript. At a high level, it's not clear to me that this encodes the right semantics. As covered in quite a bit of detail in Chrome's roadmap [0], we have to distinguish between the algorithm encoded in the EE's certificate and the algorithms used to sign that certificate and other certificates in the chain, and there are benefits to requiring a PQ PKI even if you don't have PQ keys (stage 3 in Google's roadmap). # Signature schemes You state in S 4.1. Dual code points are advertised and negotiated using the existing signature_algorithms extension defined in Section 4.2.3 of [TLS], exactly as for any other SignatureScheme. A client that supports dual authentication includes the relevant dual code points in its signature_algorithms list. The server selects one code point from the client's list, just as in standard TLS 1.3 negotiation. The message in which the server's choice is conveyed is in CertificateVerify, but the client needs to parse the Certificate prior to seeing CertificateVerify, which means that it doesn't know whether a dual code point is in in use or not at the time it processes the Certificate. Instead, it must parse either version and then fail if (for instance) the server sent two certificate chains but then signs with a single algorithm. This is possible but kind of unfortunate, especially because of the way you handle the transcript. Second, these code points have narrower semantics than ordinary signature schemes, because (for instance) you cannot use them to sign the certificate. The result of both of these design choices is a bunch of special case state keeping associated with these special signature schemes. Finally, it's not clear to me what the semantics of this extension actually are. Suppose that I advertise the following signature algorithms: [ ecdsa_secp256r1, sha256_mldsa44 ] This allows the server to supply me with a P-256 certificate signed with an MLDSA key (or vice versa). Now if I add ecdsa_secp256r1_sha256_mldsa44, what does this say about the certificate in the PQ chain. Can it be signed by a P-256 key? If not, what text forbids this and what is the general rule? I recognize that it's tricky to actually design something with the right semantics here, but I don't think this is quite there and overloading this extension seems to make the problem harder. # Only Signing a Partial Transcript Instead of signing the whole transcript, as everything else in TLS does, each algorithm just signs the transcript corresponding to its own certificates. As I understand it, you are doing this for domain separation reasons, but the consequence is that we are in uncharted territory about the security of TLS, and in particular that neither signature is endorsing the other's certificates. Do you have any analysis for what this does to the security of TLS? In addition, it's an implementation problem because it means that the RP needs to maintain two transcripts rather than just hashing in the Certificate message as received. Incidentally, the way you have specified this seems to remove the Certificate message's headers, which would otherwise be in the transcript, as per S 4.4.1 of RFC 8446. It seems like there ought to be some other way to provide domain separation. -Ekr [0] https://www.chromium.org/Home/chromium-security/post-quantum-auth-roadmap/ On Wed, Jun 24, 2026 at 11:24 PM tirumal reddy <[email protected]<mailto:[email protected]>> wrote: Hi all, The draft https://datatracker.ietf.org/doc/draft-yusef-tls-pqt-dual-certs/ has been revised to address the comments received from the WG during the presentation at IETF-123. The draft no longer defines any new TLS extension. Dual authentication is signaled entirely through new SignatureScheme code points, negotiated with the existing signature_algorithms extension; the negotiated code point determines how the existing Certificate and CertificateVerify messages carry the two chains and two signatures. Further comments and suggestions are welcome. Regards, -Tiru ---------- Forwarded message --------- From: <[email protected]<mailto:[email protected]>> Date: Wed, 24 Jun 2026 at 13:59 Subject: New Version Notification for draft-yusef-tls-pqt-dual-certs-02.txt To: Tirumaleswar Reddy.K <[email protected]<mailto:[email protected]>>, Hannes Tschofenig <[email protected]<mailto:[email protected]>>, Hannes Tschofenig <[email protected]<mailto:[email protected]>>, Mike Ounsworth <[email protected]<mailto:[email protected]>>, Rifaat Shekh-Yusef <[email protected]<mailto:[email protected]>>, Yaroslav Rosomakho <[email protected]<mailto:[email protected]>> A new version of Internet-Draft draft-yusef-tls-pqt-dual-certs-02.txt has been successfully submitted by Tirumaleswar Reddy and posted to the IETF repository. Name: draft-yusef-tls-pqt-dual-certs Revision: 02 Title: Post-Quantum Traditional (PQ/T) Hybrid Authentication with Dual Certificates in TLS 1.3 Date: 2026-06-24 Group: Individual Submission Pages: 20 URL: https://www.ietf.org/archive/id/draft-yusef-tls-pqt-dual-certs-02.txt Status: https://datatracker.ietf.org/doc/draft-yusef-tls-pqt-dual-certs/ HTML: https://www.ietf.org/archive/id/draft-yusef-tls-pqt-dual-certs-02.html HTMLized: https://datatracker.ietf.org/doc/html/draft-yusef-tls-pqt-dual-certs Diff: https://author-tools.ietf.org/iddiff?url2=draft-yusef-tls-pqt-dual-certs-02 Abstract: The anticipated emergence of cryptographically relevant quantum computers (CRQCs) poses a threat to the authentication mechanisms used in TLS 1.3. This document defines a hybrid authentication mechanism that uses two independent certificates, one traditional and one post-quantum, ensuring that an attacker must break both algorithms to compromise a TLS connection. The two certificate chains are carried in a single Certificate message and two independent signatures are encoded in the CertificateVerify message. The IETF Secretariat _______________________________________________ TLS mailing list -- [email protected]<mailto:[email protected]> To unsubscribe send an email to [email protected]<mailto:[email protected]>
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
