Hi Songbo, Thanks for the detailed review. Both points are addressed in PR #43 ( https://github.com/hannestschofenig/tls-dual-certs/pull/43), CertificateVerify now uses your Option A (single transcript). For now we kept a single alert and deferred the stricter encoding rules to a future revision.
Cheers, -Tiru On Thu, 25 Jun 2026 at 14:21, Songbo Bu <[email protected]> wrote: > 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] >
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
