Hi Rifaat, thanks for sharing the draft.
What makes me wonder is the fact, that TPMs (unlike HSMs) are not taken into consideration. Thus, what we gonne do with the composite/PQ cert? Or is this out-of-scope here; and if, why? Extensions to existing TPMs (ie. adding Keccak hashes) seem to be quite unpopular (a Master student of me tried it once). Regards. --eh. Am Dienstag, dem 14.07.2026 um 08:10 -0400 schrieb Rifaat Shekh-Yusef: > Hi Ekr, > > Thanks for the detailed review and comments. > See a few comments inline. > > Regards, > Rifaat > > > On Thu, Jun 25, 2026 at 12:52 PM Eric Rescorla <[email protected]> wrote: > > 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. > > > > > Can you elaborate on what you mean by "superior" in this case? > > There are pros and cons to each approach. > Take a look at the following document that has a comparison between > these two approaches: > https://www.ietf.org/archive/id/draft-reddy-pquip-pqc-signature-migration-01.html > > > > 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. > > > > > > > Note that the use cases we are trying to address are enterprise use > cases, not Web. > > Composite - requires 3 PKIs: the existing traditional, composite, and > pure pqc. > Dual - requires 2 PKIs: traditional and pure pqc. > > The transition from one mode to another in the dual case is much > simpler and smoother than the composite, relying on changing some > configuration to drop the traditional certificate when the time > comes. > Dual provides a better backward compatibility with legacy products > making it simpler for organizations to gradually transition their > systems. > The decoupling of the PKIs allows for a lifecycle independence with > different validity periods, renewals, revocation, etc. > Dual utilizes existing standards PKI infrastructure and standalone > certificates allows for easier future replacement of algorithms > without waiting for a new composite specification to define how to > combine the signatures of these algorithms. > From an operational perspective, you need to update your TLS library > whether using composite or dual. Because of that composite has no > advantage over dual. > > > > 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. > > > > > We agree that this adds complexity to TLS. > Because of that we are looking for more parties that might be > interested in such a mechanism to help with the analysis. > > > > 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? > > > > > I am not sure I understand this comment. Can elaborate on this? > > Regards, > Rifaat > > > > 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]> > > 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-0 > > > 2.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-du > > > al-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] > _______________________________________________ > TLS mailing list -- [email protected] > To unsubscribe send an email to [email protected] -- Dr. Erwin Hoffmann | www.fehcom.de PGP key-id: 36553F7F9C58D1CC PGP key-fingerprint: 950B 5555 0B08 5A2A 1C00 9594 3655 3F7F 9C58 D1CC
signature.asc
Description: This is a digitally signed message part
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
