Hi Erwin, TPMs are out of scope for this document, because this deals with what goes "on the wire".
Can you elaborate on what you have in mind about TPMs in this case? Regards, Rifaat On Wed, Jul 15, 2026 at 8:17 AM Erwin Hoffmann <[email protected]> wrote: > 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 > _______________________________________________ > 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]
