| Internet-Draft | Dual Certs in TLS | June 2025 |
| Shekh-Yusef, et al. | Expires 17 December 2025 | [Page] |
This document extends the TLS 1.3 authentication mechanism to allow the use of two certificates to enable dual-algorithm authentication, ensuring that an attacker would need to break both algorithms to compromise the session.¶
This note is to be removed before publishing as an RFC.¶
Discussion of this document takes place on the Transport Layer Security mailing list (tls@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/tls/.¶
Source for this draft and an issue tracker can be found at https://github.com/hannestschofenig/tls-dual-certs.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 17 December 2025.¶
Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
There are several potential mechanisms to address concerns related to the anticipated emergence of cryptographically relevant quantum computers (CRQCs). While the encryption-related aspects are covered in other documents, this document focuses on the authentication component of the [TLS] handshake.¶
One approach is the use of dual certificates: issuing two distinct certificates for the same end entity — one using a traditional algorithm (e.g., ECDSA), and the other using a post-quantum (PQ) algorithm (e.g., ML-DSA).¶
This document defines how TLS 1.3 can utilize such certificates to enable dual-algorithm authentication, ensuring that an attacker would need to break both algorithms to compromise the session.¶
It also addresses the challenges of integrating hybrid authentication in TLS 1.3 while balancing backward compatibility, forward security, and deployment practicality.¶
This document makes changes to the Certificate and CertificateVerify messages to take advantage of both certificates when authenticating the end entity.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
This document is intended for use in closed-network deployments, where a single administrative entity manages both TLS peers. It is not designed for use in open or public network environments where peers are operated independently.¶
The approach described herein is also compatible with FIPS-compliant deployments, as it supports the continued use of FIPS-approved traditional signature algorithms during the TLS handshake. This enables systems to maintain regulatory compliance while incrementally introducing post-quantum authentication mechanisms using Exported Authenticators.¶
The proposed mechanism is fully backward compatible: traditional certificates and authentication methods remain functional with existing TLS 1.3 implementations. As cryptographically relevant quantum computers (CRQCs) emerge, deployments can transition by gradually disabling traditional authentication and enabling post-quantum–only authentication. This strategy offers a smooth migration path, ensuring long-term cryptographic agility, regulatory compliance, and operational continuity without disrupting existing infrastructure.¶
This document introduces a mechanism to enable dual-certificate authentication in TLS 1.3. The primary objective is to allow each TLS peer to present two certificate chains—typically a traditional cryptographic chain and a post-quantum (PQ) chain—thereby requiring an attacker to break both authentication algorithms to impersonate a peer.¶
The design builds on existing TLS 1.3 structures and introduces minimal protocol changes. It is applicable to both client and server authentication and is compatible with the Exported Authenticators mechanism.¶
A new extension, secondary_signature_algorithms, is defined to negotiate support for a second category of signature algorithms, typically post-quantum schemes. This extension is structurally identical to signature_algorithms and is used in the same handshake messages:¶
In the ClientHello, it indicates the client's supported secondary (PQ) signature algorithms for server authentication.¶
In the CertificateRequest, it indicates the server's supported secondary (PQ) signature algorithms for client authentication.¶
This allows both endpoints to signal independently two distinct algorithms for dual authentication.¶
The secondary_signature_algorithms can also be used in extensions of CertificateRequest and ClientCertificateRequest structures of Authenticator Request message of Exported Authenticators as defined in Section 4 of [EXPORTED-AUTH].¶
TLS 1.3 defines the Certificate message to carry a list of certificate entries representing a single chain. This document reuses the same structure to convey two certificate chains by concatenating them and inserting a delimiter in the form of a zero-length certificate entry.¶
A zero-length certificate is defined as a CertificateEntry with an empty cert_data field and omitted extensions field. TLS 1.3 prohibits the use of empty certificate entries, making this delimiter unambiguous. Implementations MUST treat all entries before the zero-length delimiter as the first certificate chain (typically classic), and all entries after it as the second certificate chain (typically post-quantum).¶
This encoding applies equally to the CompressedCertificate message and to the Certificate message of Exported Authenticators as defined in Section 5.2.1 of [EXPORTED-AUTH].¶
The CertificateVerify message is extended to include two digital signatures:¶
One computed using a signature algorithm negotiated via signature_algorithms.¶
One computed using an algorithm negotiated via secondary_signature_algorithms.¶
Each signature is computed over the transcript hash as specified in TLS 1.3, but with distinct context strings to domain-separate the two operations. This approach prevents attackers from comparing timing characteristics or reusing one signature in place of the other.¶
This encoding applies equally to the CertificateVerify message of Exported Authenticators as defined in Section 5.2.2 of [EXPORTED-AUTH].¶
The order of the signatures in the message MUST correspond to the order of the certificate chains in the Certificate message.¶
A new TLS flag, dual_certificate_required, is defined using the [TLS-FLAGS] extension. This flag may be set in either direction:¶
When set by the client in ClientHello, it indicates that the server MUST provide both certificate chains and both signatures.¶
When set by the server in CertificateRequest, it indicates that the client MUST do the same.¶
If the flag is not set, the peer MAY choose to send either one or two certificate chains, depending on local policy and capabilities. This flexibility supports incremental deployment of dual-certificate authentication.¶
This section defines the normative changes to TLS 1.3 required to support dual-certificate authentication. These changes extend existing handshake messages and introduce one new extension and one new TLS flag.¶
secondary_signature_algorithms Extension
A new extension, secondary_signature_algorithms, is defined to allow peers to advertise support for a secondary category of signature algorithms, typically post-quantum schemes.¶
The structure of the extension is identical to that of signature_algorithms defined in Section 4.2.3 of [TLS]¶
struct {
SignatureScheme supported_signature_algorithms<2..2^16-2>;
} SignatureSchemeList;
Each SignatureScheme is a 2-octet value identifying a supported signature algorithm as defined in TLS SignatureScheme IANA registry.¶
The client MAY include this extension in ClientHello message to indicate which secondary algorithms it supports for verifying the server's signature. The server MAY include this extension in CertificateRequest message to indicate which secondary algorithms it supports for verifying the client's signature. This extension MAY be included in an Authenticator Request by the requestor to signal support for secondary signature algorithms in the response.¶
This extension MUST NOT be used unless the signature_algorithms extension is also present in the same message.¶
If the extension is present in ClientHello, CertificateRequest or Authenticator Request, the peer MAY respond with a dual-certificate authentication structure. If the extension is absent, the peer MUST NOT send a second certificate chain or a second signature.¶
The presence of this extension alone does not mandate dual authentication; enforcement is controlled by the dual_certificate_required TLS flag.¶
dual_certificate_required TLS Flag
The dual_certificate_required flag is conveyed using the [TLS-FLAGS] extension.¶
When set in ClientHello, it indicates that the client requires the server to present both certificate chains and both signatures. When set in CertificateRequest, it indicates that the server requires the client to present both certificate chains and both signatures if the client is authenticating itself during TLS handshake.¶
If the flag is set and the peer provides only one chain or one signature, the handshake MUST be aborted with an dual_certificate_required alert.¶
This flag MAY be included in TLS flags extension of Authenticator Request message of Exported Authenticators.¶
If the flag is not set, the peer MAY provide either one or two certificate chains, depending on local policy and negotiated capabilities.¶
TLS 1.3 defines the Certificate message as follows:¶
struct {
opaque certificate_request_context<0..2^8-1>;
CertificateEntry certificate_list<0..2^24-1>;
} Certificate;
This document extends the semantics of certificate_list to support two logically distinct certificate chains, encoded sequentially and separated by a delimiter.¶
The delimiter is a zero-length certificate entry, defined as:¶
struct {
opaque cert_data<0..0>;
} CertificateEntry;
TLS 1.3 prohibits empty certificate entries, so this delimiter is unambiguous.¶
All entries before the delimiter are treated as the first certificate chain, all entries after the delimiter are treated as the second certificate chain.¶
A peer receiving this structure MUST validate each chain independently according to its corresponding signature algorithm. The end-entity certificate MUST be the first entry in both the first and second certificate chains. The first certificate chain MUST contain certificates whose public key is compatible with one of the algorithms listed in the signature_algorithms or signature_algorithms_cert extension, if present. The second certificate chain MUST contain certificates whose public key is compatible with one of the algorithms listed in the secondary_signature_algorithms extension.¶
This encoding applies equally to the CompressedCertificate message and to Certificate message of Exported Authenticators.¶
The CertificateVerify message is extended to carry two independent signatures. Its modified structure is as follows:¶
struct {
SignatureScheme first_algorithm;
opaque classic_signature<0..2^16-1>;
SignatureScheme second_algorithm;
opaque pq_signature<0..2^16-1>;
} CertificateVerify;
Each signature covers the transcript hash as in TLS 1.3, but with a distinct context string for domain separation.¶
The context string is used as input to the data over which the signature is computed, consistent with the CertificateVerify construction defined in Section 4.4.3 of [TLS]. The first signature uses the same context string as in the TLS 1.3 specification:¶
for a server context string is "TLS 1.3, server CertificateVerify"¶
for a client context string is "TLS 1.3, client CertificateVerify"¶
The second signature uses a distinct context string to bind it to the secondary certificate:¶
for a server, secondary context string is "TLS 1.3, server secondary CertificateVerify"¶
for a client, secondary context string is "TLS 1.3, client secondary CertificateVerify"¶
Implementations MUST verify both signatures and MUST associate each with its corresponding certificate chain.¶
This dual-signature structure applies equally to CertificateVerify messages carried in Exported Authenticators with second signature using "Secondary Exported Authenticator" as the context string.¶
The use of dual certificates increases the size of individual certificates, certificate chains, and associated signatures, which can result in significantly larger TLS handshake messages. These larger payloads may cause packet fragmentation, retransmissions, and handshake delays, especially in constrained or lossy network environments.¶
To mitigate these impacts, deployments can apply certificate chain optimization techniques, such as those described in Section 6.1 of [PQ-RECOMMEND], to minimize transmission overhead and improve handshake robustness.¶
Implementations MUST strictly associate each CertificateVerify signature with the corresponding certificate chain, based on their order relative to the zero-length delimiter in the Certificate message. Failure to properly align signatures with their intended certificate chains may result in incorrect validation or misattribution of authentication.¶
Certificate parsing logic MUST reject messages that contain more than one zero-length delimiter, or that place the delimiter as the first or last entry in the certificate list.¶
Both signatures in the CertificateVerify message MUST be validated successfully and correspond to their respective certificate chains. Implementations MUST treat failure to validate either signature as a failure of the authentication process. Silent fallback to single-certificate verification undermines the dual-authentication model and introduces downgrade risks.¶
Since both CertificateVerify operations involve signing the transcript using different cryptographic primitives, care MUST be taken to avoid leaking timing or other side-channel information. Implementers MUST ensure constant-time execution and avoid conditional branching that could reveal whether one or both signatures are present or valid.¶
Distinct context strings are REQUIRED for the two signatures to prevent cross-protocol misuse or collision attacks.¶
When the dual_certificate_required flag is set by a peer, failure to provide two certificate chains and two corresponding signatures MUST result in handshake failure. This enforcement MUST NOT be bypassed by falling back to a single-certificate configuration. Implementations MUST emit a dual_certificate_required alert when this requirement is violated.¶
To achieve the intended security guarantees, implementers and deployment operators MUST ensure that the two certificate chains rely on cryptographically independent primitives.¶
Certificate chains must be validated independently, including trust anchors, certificate usage constraints, expiration, and revocation status. Operators MUST ensure that revocation checking, such as using OCSP or CRLs, is consistently applied to both chains to prevent reliance on revoked credentials.¶
This specification registers the secondary_signature_algorithms TLS extension, dual_certificate_required TLS Flag and dual_certificate_required TLS alert.¶
IANA is requested to assign a new value from the TLS ExtensionType Values registry:¶
We would like to thank ... for their comments.¶
Dual certificate authentication must follow the same logical flow as standard TLS certificate authentication, including integration with Certificate, CertificateVerify, and Finished messages.¶
Any additions or modifications to the TLS protocol must be minimal to ease deployment, reduce implementation complexity and minimize new security risks.¶
The mechanism must support both server and client authentication scenarios. In case of mutual authentication dual certificates may be used unidirectionally as well as bidirectionally.¶
The mechanism must be usable with Exported Authenticators (RFC 9261) for mutual authentication in post-handshake settings.¶
Each certificate chain (e.g., classic and PQ) must be independently usable for authentication, allowing endpoints to fall back to classic or PQ-only validation if necessary.¶
The mechanism must clearly distinguish and delimit multiple certificate chains to prevent ambiguity or misinterpretation.¶
Each certificate chain must be associated with its own set of supported signature algorithms, allowing negotiation of appropriate algorithms for classic and PQ use cases.¶
The mechanism must be designed in a way that could support more than two certificate chains in the future, not just hardcoded to classic + PQ.¶
When only one certificate chain is used, the mechanism must remain compatible with existing TLS 1.3 endpoints unaware of dual-certificate support or willing to use only a single certificate.¶
A mechanism must exist for one party (client or server) to signal whether dual certificate presentation is required, optional, or not supported, to coordinate authentication expectations.¶
The mechanism must be expandable to other multi-certificate use cases such as attested TLS¶
The mechanism should avoid constructions that enable side-channel attacks by observing how distinct algorithms are applied to the same message.¶
The order and pairing between certificates and their corresponding signatures must be explicit, so verifiers can unambiguously match them.¶