One of the key use cases is to simplify PKI architectures for closed environments that will have to deal with a mix of clients.
Transition from RSA to ECDSA required two end-entity certificates and did not have to touch the rest of the certificate chain. Organisations did not have to create and maintain a separate PKI to produce ECDSA end-entity certificates. Worth noting that to this day many have to maintain both end-entity certificates to interoperate with legacy clients. Meaningful PQ signatures transition will require maintaining multiple certificate chains. Environments that deal with a mix of clients will need to support - Classic PKI - Composite PKI - and potentially pure PQ PKI On top of that, agility within PQ/T components may be needed depending on specific technological or regulatory requirements. It might be easier to produce required combinations from available building blocks instead of maintaining multiple separate composites prepared upfront. Best Regards, Yaroslav On Thu, Jun 19, 2025 at 12:44 AM Blumenthal, Uri - 0553 - MITLL < [email protected]> wrote: > Agree with Watson here. Don’t see a use case, or a threat - within TLS > context - that this would help with. > — > Regards, > Uri > > Secure Resilient Systems and Technologies > MIT Lincoln Laboratory > > > On Jun 18, 2025, at 18:41, Watson Ladd <[email protected]> wrote: > > > > !-------------------------------------------------------------------| > > This Message Is From an External Sender > > This message came from outside the Laboratory. > > |-------------------------------------------------------------------! > > > >> On Wed, Jun 18, 2025 at 3:33 PM Mike Ounsworth > >> <[email protected]> wrote: > >> > >> Watson, > >> > >> > >> > >> There is currently no way to request that a server produce a > CertificateVerify containing two signatures. This draft is adding a > mechanism for 2 certificates -> 1 CertificateVerify. > >> > >> > >> > >> Basically, since draft-reddy-tls-composite-mldsa is on the table, we > also wanted to write down the other obvious way of doing hybrid signatures > so that we can have a complete discussion on the topic. Whether or not this > is “needed” is exactly the discussion to have at 123 😊 > > > > It's much easier to make complex arguments over email than in a few > > minutes of time at the mic line. > > > > More specifically, it's not clear to me why these are desirable > > mechanisms. Unlike confidentiality mechanisms, authentication > > mechanisms cannot be broken retrospectively. We already have a > > mechanism for negotiation that has functioned to enable transition > > from RSA to ECDSA, largely seamlessly. The scope in the document and > > justification of a smooth transition is already demonstrably met with > > no real change to libraries to implement this. I don't see anything > > in the introduction of the draft that makes the case here, unlike the > > one you cite as an alternative. > > > > Sincerely, > > Watson > >> > >> > >> > >> --- > >> > >> Mike Ounsworth > >> > >> > >> > >> From: Watson Ladd <[email protected]> > >> Sent: Wednesday, June 18, 2025 5:29 PM > >> To: Yaroslav Rosomakho <[email protected]> > >> Cc: <[email protected]> <[email protected]>; Hannes Tschofenig < > [email protected]>; Mike Ounsworth <[email protected]> > >> Subject: [EXTERNAL] Re: [TLS] Dual certificates in TLS proposal > >> > >> > >> > >> On Wed, Jun 18, 2025, 3: 19 PM Yaroslav Rosomakho > <yrosomakho=40zscaler. com@ dmarc. ietf. org> wrote: Dear TLS WG, We have > just submitted a new proposal, draft-yusef-tls-dual-certs-00, that extends > TLS 1. 3 to support authentication using two > >> > >> > >> > >> > >> > >> On Wed, Jun 18, 2025, 3:19 PM Yaroslav Rosomakho <yrosomakho= > [email protected]> wrote: > >> > >> Dear TLS WG, > >> > >> We have just submitted a new proposal, draft-yusef-tls-dual-certs-00, > that extends TLS 1.3 to support authentication using two certificate > chains: one using traditional algorithms and one using post-quantum (PQ) > algorithms. This approach, aimed at closed environments and staged > post-quantum migration, enables stronger session authentication by > requiring both signatures to validate. > >> > >> The proposal builds on existing TLS 1.3 mechanisms with minimal > protocol changes. It introduces a dual signature algorithm extension and > defines how dual certificate chains and signatures are structured, while > preserving compatibility with Exported Authenticators. > >> > >> This mechanism complements existing proposals such as composite > certificates (e.g., draft-reddy-tls-composite-mldsa), offering greater > deployment flexibility, especially for systems that require support for > independently validated classical and PQ credentials. It also helps with > phased migration strategies where TLS endpoints have to deal with a mix of > opinionated peers while limiting the need to create a zoo of PKI > hierarchies to satisfy classic, pure PQ as well as all possible > compositions of algorithms. > >> > >> We welcome your feedback and discussion on the proposal and the design > specifics. > >> > >> > >> > >> Why is this needed given the existing signalling of client support for > certificate signature algorithms? > >> > >> > >> > >> > >> Best Regards, > >> Hannes, Mike, Rifaat, Tiru, Yaron and Yaroslav > >> > >> > >> > >> > >> > >> ---------- Forwarded message --------- > >> > >> A new version of Internet-Draft draft-yusef-tls-pqt-dual-certs-00.txt > has been > >> successfully submitted by Yaroslav Rosomakho and posted to the > >> IETF repository. > >> > >> Name: draft-yusef-tls-pqt-dual-certs > >> Revision: 00 > >> Title: Post-Quantum Traditional (PQ/T) Hybrid Authentication with > Dual Certificates in TLS 1.3 > >> Date: 2025-06-18 > >> Group: Individual Submission > >> Pages: 27 > >> URL: > https://www.ietf.org/archive/id/draft-yusef-tls-pqt-dual-certs-00.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-00.html > >> HTMLized: > https://datatracker.ietf.org/doc/html/draft-yusef-tls-pqt-dual-certs > >> > >> > >> Abstract: > >> > >> This document extends the TLS 1.3 authentication mechanism to allow > >> the negotiation and use of two signature algorithms to enable dual- > >> algorithm hybrid authentication, ensuring that an attacker would need > >> to break both algorithms to compromise the session. The two > >> signature algorithms come from two independent certificates that > >> together produce a single Certificate and CertificateVerify message. > >> > >> > >> > >> The IETF Secretariat > >> > >> > >> > >> > >> > >> This communication (including any attachments) is intended for the sole > use of the intended recipient and may contain confidential, non-public, > and/or privileged material. Use, distribution, or reproduction of this > communication by unintended recipients is not authorized. If you received > this communication in error, please immediately notify the sender and then > delete all copies of this communication from your > system._______________________________________________ > >> TLS mailing list -- [email protected] > >> To unsubscribe send an email to [email protected] > >> > >> Any email and files/attachments transmitted with it are intended solely > for the use of the individual or entity to whom they are addressed. If this > message has been sent to you in error, you must not copy, distribute or > disclose of the information it contains. Please notify Entrust immediately > and delete the message from your system. > >> > > > > > > -- > > Astra mortemque praestare gradatim > > > > _______________________________________________ > > 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] > -- This communication (including any attachments) is intended for the sole use of the intended recipient and may contain confidential, non-public, and/or privileged material. Use, distribution, or reproduction of this communication by unintended recipients is not authorized. If you received this communication in error, please immediately notify the sender and then delete all copies of this communication from your system.
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
