On Wed, Jun 18, 2025, 4:30 PM Yaroslav Rosomakho <[email protected]> wrote:
> 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. > Why does this draft make that simpler? It envisions two separate chains. Same as with using the existing negotiating mechanisms. 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]
