Hi Tiru, Thanks for the update. I like the simplification of not adding a new extension and negotiating this through the existing signature_algorithms path.
One point from a first pass: Section 5.3 may need tightening around the CertificateVerify input. The draft says the TLS structure is unchanged, but then defines: first-hash = Transcript-Hash(Handshake Context, Certificate1) second-hash = Transcript-Hash(Handshake Context, Certificate2) In TLS 1.3, CertificateVerify signs Transcript-Hash(Handshake Context, Certificate), where Certificate is the handshake message as sent. If Certificate1 and Certificate2 are intended to be derived virtual Certificate messages, I think the draft should say that explicitly and define their exact serialization, including whether the handshake header and certificate_request_context are included. Otherwise implementers may assume the ordinary running transcript hash and then find that it cannot directly produce the two per-chain inputs. If the intent is to keep the TLS transcript completely unchanged, another option may be simpler: have both signatures cover the same RFC 8446 CertificateVerify input, and rely on the negotiated dual SignatureScheme plus the certificate-chain order to bind each signature to its corresponding key. If per-chain signing is required for non-separability, then the draft probably needs to call that out as a deliberate change to the signing input rather than just an encoding detail. Small related parsing point: because the first signature length is explicit but the second signature takes the remaining bytes, it may be useful to say that receivers reject zero-length, overlong, or trailing-byte encodings before signature verification, and to distinguish malformed encoding from failed signature validation. Best, Songbo On Thu, 25 Jun 2026 11:53:29 +0530, tirumal reddy <[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]> > 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]>, Hannes Tschofenig > <[email protected]>, Hannes Tschofenig <[email protected]>, > Mike Ounsworth <[email protected]>, Rifaat Shekh-Yusef > <[email protected]>, Yaroslav Rosomakho <[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] To unsubscribe send an email to [email protected]
