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 😊 --- 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 <[email protected]<mailto:[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<https://urldefense.com/v3/__https:/www.ietf.org/archive/id/draft-yusef-tls-pqt-dual-certs-00.txt__;!!FJ-Y8qCqXTj2!ef5d2u1f8gSH8JtOTp-0P-NE3Bntgv5X-VLuXyRX9oUjUSVLMCpl_wutw5Kqi_6M36W1LG-N7twfzlFc8L8r14B_Ag$> Status: https://datatracker.ietf.org/doc/draft-yusef-tls-pqt-dual-certs/<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-yusef-tls-pqt-dual-certs/__;!!FJ-Y8qCqXTj2!ef5d2u1f8gSH8JtOTp-0P-NE3Bntgv5X-VLuXyRX9oUjUSVLMCpl_wutw5Kqi_6M36W1LG-N7twfzlFc8L8B4VkCPA$> HTML: https://www.ietf.org/archive/id/draft-yusef-tls-pqt-dual-certs-00.html<https://urldefense.com/v3/__https:/www.ietf.org/archive/id/draft-yusef-tls-pqt-dual-certs-00.html__;!!FJ-Y8qCqXTj2!ef5d2u1f8gSH8JtOTp-0P-NE3Bntgv5X-VLuXyRX9oUjUSVLMCpl_wutw5Kqi_6M36W1LG-N7twfzlFc8L90w7e2IQ$> HTMLized: https://datatracker.ietf.org/doc/html/draft-yusef-tls-pqt-dual-certs<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-yusef-tls-pqt-dual-certs__;!!FJ-Y8qCqXTj2!ef5d2u1f8gSH8JtOTp-0P-NE3Bntgv5X-VLuXyRX9oUjUSVLMCpl_wutw5Kqi_6M36W1LG-N7twfzlFc8L_-8UGfpw$> 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]<mailto:[email protected]> To unsubscribe send an email to [email protected]<mailto:[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.
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
