| Internet-Draft | PQ/T Dual Certs in TLS | July 2026 |
| Shekh-Yusef, et al. | Expires 4 January 2027 | [Page] |
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.¶
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 4 January 2027.¶
Copyright (c) 2026 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 method exemplifies a PQ/T hybrid protocol with non-composite authentication as defined in Section 4 of [PQT-TERMS], where two single-algorithm schemes are used in parallel: when the certificate type is X.509, each certificate chain uses the same format as in standard PKI, and both chains together provide hybrid assurance without modifying the X.509 certificate structure. While this approach does not produce a single cryptographic hybrid signature, it ensures that both certificates are presented, validated, and cryptographically bound to the TLS handshake transcript. This specification is also compatible with other certificate types defined in the TLS Certificate Types registry defined in Section 14 of [IANA-TLS] provided that both components of the dual are of the same type. This document assumes X.509 certificates for all explanatory text.¶
This document defines new SignatureScheme code points that identify
pairs of traditional and post-quantum signature algorithms. Negotiation
uses the existing signature_algorithms extension without modification.
When a dual code point is selected, the Certificate message carries
two independent certificate chains, and the CertificateVerify
signature field encodes two independent signatures. No new TLS
extensions or changes to existing TLS structures are required.¶
A key advantage of defining explicit code points per algorithm pair is that it restricts combinations to known good configurations. This follows the emerging consensus in protocol design that explicit enumeration of vetted pairs is safer than allowing arbitrary combinations of any two algorithms. Each code point defined in this document represents a specific, vetted pair of traditional and post-quantum algorithms.¶
This document is distinct from the composite ML-DSA approach defined in [TLS-COMPOSITE-MLDSA]. In that approach, a single composite certificate contains both public keys and produces a single composite signature. In this document, two independent certificates and two independent signatures are used, each verifiable on its own.¶
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.¶
The approach described herein is also compatible with FIPS-compliant deployments (FIPS 140-2 and FIPS 140-3), as it supports the continued use of FIPS-approved traditional signature algorithms during the TLS handshake.¶
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 new SignatureScheme code points to enable
dual-certificate authentication in TLS 1.3. The primary objective is
to allow each TLS peer to present two certificate chains requiring an
attacker to break both authentication algorithms to impersonate a peer.
Typically one of the certificate chains uses a traditional cryptographic
algorithm while the second leverages post-quantum (PQ) cryptography.¶
The design requires no changes to existing TLS structures or
extensions. It reuses the existing signature_algorithms extension for
negotiation, the existing Certificate message structure with a
delimiter to carry two chains, and the existing CertificateVerify
structure with a defined encoding for two signatures within the
signature opaque field. It is applicable to both client and server
authentication and is compatible with the Exported Authenticators
mechanism [EXPORTED-AUTH].¶
A full set of informal design requirements for this specification can be found in Appendix A.¶
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.¶
A client that wishes to mandate dual authentication includes only dual
code points in signature_algorithms. A client willing to accept
either dual or single-algorithm authentication includes both dual and
single-algorithm code points.¶
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
an unambiguous boundary between the two certificate chains.
Implementations MUST treat all entries before the zero-length delimiter
as the first certificate chain (typically traditional), and all entries
after it as the second certificate chain (typically post-quantum).¶
This encoding applies equally to the CompressedCertificate message
defined in [COMPRESS-CERT] and to the Certificate message
of Exported Authenticators as defined in Section 5.2.1 of [EXPORTED-AUTH].¶
Since TLS 1.3 supports only a single certificate type in each direction, both certificate chains MUST either contain X.509 certificates or certificates of type specified in:¶
server_certificate_type extension in a EncryptedExtensions
message for Server certificates¶
client_certificate_type extension in a EncryptedExtensions
message for Client certificates¶
Note that according to Section 5.2.1 of [EXPORTED-AUTH] Exported Authenticators support only X.509 certificates.¶
The CertificateVerify message is not modified. When a dual code point
has been negotiated, the signature field encodes two independent
signatures:¶
One computed using the traditional algorithm component of the negotiated code point.¶
One computed using the post-quantum algorithm component of the negotiated code point.¶
Both signatures are computed over the same transcript hash specified in
Section 4.4.3 of [TLS], covering the complete Certificate message,
and using the same context string.¶
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: the first
signature MUST correspond to the traditional algorithm component of the
negotiated code point, and the second signature MUST correspond to the
post-quantum algorithm component.¶
This section defines the normative behaviour of TLS 1.3 peers when a
dual code point is negotiated. No new TLS extensions or
modifications to existing TLS structures are introduced. This document
defines new SignatureScheme code points that, when negotiated, govern
the encoding of the Certificate and CertificateVerify messages.¶
This document defines new SignatureScheme values for use in the
signature_algorithms extension defined in Section 4.2.3 of [TLS].
These values MUST NOT be sent in signature_algorithms_cert: a dual
code point identifies a pair of end-entity keys and the two signatures
in CertificateVerify, not an algorithm for the signatures appearing
in certificates:¶
enum {
ecdsa_secp256r1_sha256_mldsa44 (TBD1),
ecdsa_secp384r1_sha384_mldsa65 (TBD2),
} SignatureScheme;
Each code point identifies a vetted pair of algorithms: a traditional
algorithm and a post-quantum algorithm. The traditional component names
match the existing TLS SignatureScheme IANA registry entries exactly.
The naming order <traditional>_<pq> reflects the order in which the
two signatures appear in the CertificateVerify signature field, as
defined in Section 5.3.¶
These code points are distinct from the composite ML-DSA
SignatureScheme values defined in
[TLS-COMPOSITE-MLDSA], which use a
single certificate and a single composite signature, and which use the
opposite naming order <pq>_<traditional>.¶
When a code point defined in this document is negotiated, the
authenticating peer MUST send two certificate chains in the
Certificate message as described in Section 5.2, and MUST encode
two independent signatures in the signature field of the
CertificateVerify message as described in Section 5.3.¶
These code points MUST NOT be used in TLS 1.2. A peer that receives a
CertificateVerify message in a TLS 1.2 connection with a code point
defined in this document MUST abort the connection with an
illegal_parameter alert.¶
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 re-uses the Certificate structure as-is and 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 encoded as 3 bytes of 0x00. TLS 1.3 prohibits empty certificate entries, so this delimiter is unambiguous. The delimiter MUST NOT be sent to peers that did not negotiate a dual code point.¶
This specification expands the CertificateEntry structure from Section 4.4.2 of [TLS] in the following way:¶
struct {
select (is_delimiter) {
case Delimiter: uint24 delimiter = 0;
case Non_Delimiter:
opaque cert_specific_data<1..2^24-1>;
Extension extensions<0..2^16-1>;
};
} CertificateEntry;
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.¶
All entries before the delimiter form the first certificate chain (traditional) and all entries after the delimiter form the second certificate chain (post-quantum). As specified in Section 4.4.2 of [TLS], the end-entity certificate MUST be the first in each chain. The algorithm requirements for the end-entity certificates and for the certificates within each chain are specified below.¶
A peer receiving this structure MUST validate each chain independently, using the algorithms permitted for that chain. Implementers MAY wish to consider performing this verification in a timing-invariant way so as not to leak which certificate failed, for example if it failed for policy reasons rather than cryptographic reasons, however since this information is not hidden in a single-certificate TLS handshake, implementers MAY decide that this is not important.¶
The first certificate chain MUST contain an end-entity certificate whose public key is compatible with the traditional algorithm component of the negotiated code point. The second certificate chain MUST contain an end-entity certificate whose public key is compatible with the post-quantum algorithm component of the negotiated code point. End-entity certificates of both chains MUST use different public keys.¶
The negotiated code point constrains only the end-entity public keys,
as specified above, together with the two signatures in
CertificateVerify. It does not constrain, and cannot express, the
algorithms of the signatures appearing in the certificates of either
chain: a dual code point is not a usable certificate signature
algorithm (Section 5.1). Consequently, when either chain contains
CA-issued certificates, the peer MUST advertise the acceptable
certificate signature algorithms in signature_algorithms_cert
(Section 4.2.3 of [TLS]).¶
Each certificate in the traditional chain MUST be signed with a
traditional signature algorithm, and each certificate in the
post-quantum chain MUST be signed with a post-quantum signature
algorithm. Different algorithms of the same category
(traditional or post-quantum) MAY be mixed within a chain,
for example an ML-DSA certificate signed with SLH-DSA. A chain that
mixes traditional and post-quantum signature algorithms MUST be
rejected with a bad_certificate alert. signature_algorithms_cert
cannot enforce this, as it is a single list that does not
distinguish the two chains.¶
Both end-entity certificates MUST identify the same peer. A relying
party MUST verify that both match the reference identity it is
authenticating ([RFC9525]) and MUST abort with a bad_certificate
alert otherwise. The two certificates MAY also be bound using the
RelatedCertificate extension [RELATED-CERTS]; a receiver
that processes this extension MUST verify it references the end-entity
certificate of the other chain.¶
This encoding applies equally to the CompressedCertificate message
and to Certificate message of Exported Authenticators.¶
TLS 1.3 defines the CertificateVerify message as follows:¶
struct {
SignatureScheme algorithm;
opaque signature<0..2^16-1>;
} CertificateVerify;
This document does not modify this structure. When a code point defined
in Section 5.1 has been negotiated, the algorithm field
carries that code point and the signature field encodes two
independent signatures as follows.¶
Both signatures are computed over the single signing input defined in
Section 4.4.3 of [TLS], that is over Transcript-Hash(Handshake
Context, Certificate), where Certificate is the Certificate
handshake message as sent and carries both certificate chains. This
document does not introduce any per-chain or otherwise modified signing
input.¶
first-signature = Sign(traditional-private-key, signing-input) second-signature = Sign(pq-private-key, signing-input)¶
first-signature is produced with the traditional algorithm component
and second-signature with the post-quantum algorithm component of the
negotiated code point.¶
These are encoded in the signature field as:¶
signature = uint16(len(first-signature)) || first-signature
|| second-signature
¶
The first two bytes encode the length of the traditional signature
as a uint16, followed by the traditional signature (first-signature)
of that length, followed by the post-quantum signature
(second-signature) occupying the remaining bytes.¶
The context string used in the signing input is unchanged from Section 4.4.3 of [TLS].¶
Before verifying either signature, the receiver MUST validate the
encoding of the signature field and MUST abort the connection with a
decrypt_error alert if the field is shorter than the two-byte length
prefix, if the length prefix is zero, or if the length prefix leaves no
bytes for second-signature. second-signature consists of all bytes
following first-signature.¶
The receiver MUST verify both signatures. Failure to verify either
signature MUST be treated as an authentication failure and MUST cause
the connection to be aborted with a decrypt_error alert.¶
This encoding applies equally to the CertificateVerify message of
Exported Authenticators Section 5.2.2 of [EXPORTED-AUTH].¶
Policy enforcement regarding the use of dual certificates is
implementation-defined and driven by the authenticating peer. When
dual certificate authentication is required by local policy, the client
MUST include only dual code points in signature_algorithms. A server
that cannot satisfy this will be unable to complete the handshake.¶
When a client is willing to accept either dual or single-algorithm
authentication, it MAY include both dual code points and
single-algorithm schemes in signature_algorithms.¶
A single composite certificate chain and signature such as defined by
[TLS-COMPOSITE-MLDSA] MAY be an
acceptable alternative during the post-quantum transition period as
long as the corresponding signature scheme is listed in
signature_algorithms.¶
Additional policy examples are given in Appendix C.¶
The use of dual certificates increases the size of the certificate and certificate verify messages, which can result in 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.¶
This dual certificate scheme achieves Weak Non-Separability as defined in [HYBRID-SIGS], which is defined as:¶
the guarantee that an adversary cannot simply "remove" one of the component signatures without evidence left behind.¶
As defined in Section 4.4 of [TLS], CertificateVerify contains
signatures over the value Transcript-Hash(Handshake Context,
Certificate). In the dual certificate context, Certificate will
contain both certificate chains, which is sufficient to cause the
client to abort and therefore achieves Weak Non-Separability.¶
Implementations MUST strictly associate each signature in the
CertificateVerify signature field 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 could result in
incorrect validation or misattribution of authentication.¶
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. Implementations MAY short-circuit
if the first signature or certificate chain fails, or MAY process both
regardless to achieve timing invariance if the implementer deems it
valuable to hide which signature or certificate validation failed, for
example if one of the certificates was rejected for policy reasons
rather than cryptographic reasons.¶
Some implementations MAY wish to treat a dual signature as an atomic signing oracle and thus hide side-channels that would allow an attacker to distinguish the first algorithm from the second algorithm, for example if the first signature fails, still perform the second signature before returning an alert. However, in most cases this does not have practical value, for example if all algorithms offered as dual are also offered as single.¶
The two end-entity certificates contain keys of different algorithms, one traditional and one post-quantum. As required in Section 5.2, the traditional chain is signed only with traditional signature algorithms and the post-quantum chain only with post-quantum signature algorithms, so the two chains rely on cryptographically independent primitives.¶
Certificate chains MUST be validated independently with the same logic as if they were each presented in isolation, including trust anchors, certificate usage constraints, expiration, and revocation status.¶
TLS clients that are capable of accepting both traditional-only certificates and dual certificate configurations may remain vulnerable to downgrade attacks. In such a scenario, an attacker with access to a CRQC could forge a valid traditional certificate to impersonate the server and indicate no support for dual certificates. To mitigate this risk, clients should progressively phase out acceptance of traditional-only certificate chains once dual certificate deployment is widespread and interoperability with legacy servers is no longer necessary. During the transition period, accepting traditional-only certificate chains may remain necessary to maintain backward compatibility with servers that have not yet deployed dual certificates.¶
This document requests new entries in the TLS SignatureScheme registry [TLSIANA].¶
| Value | Description | Recommended | Reference |
|---|---|---|---|
| TBD1 | ecdsa_secp256r1_sha256_mldsa44 | N | This document |
| TBD2 | ecdsa_secp384r1_sha384_mldsa65 | N | This document |
These values are distinct from the composite ML-DSA SignatureScheme values defined in [TLS-COMPOSITE-MLDSA], which use a single certificate and a single composite signature.¶
We would like to thank Suzanne Wibada (Université de Sherbrooke) for her reviews and comments during the work on the initial version of this document, and her willingness to implement the recommendation of this document.¶
We also want to thank Anthony Hu from WolfSSL for his review and feedback on the initial version of this draft.¶
Thanks to Songbo Bu and Eric Rescorla for the review and suggestions.¶
This section documents the design requirements that drove the development of this specification.¶
This section is primarily intended to ease WG review and could be removed or simplified prior to RFC publication.¶
The dual certificate authentication achieves, at least, Weak
Non-Separability [HYBRID-SIGS] at the time of verification
of the CertificateVerify message.¶
Each certificate chain (e.g., traditional and PQ) must be independently usable for authentication, allowing endpoints to fall back to traditional or PQ-only validation if necessary.¶
The mechanism must clearly distinguish and delimit multiple certificate chains to prevent ambiguity or misinterpretation.¶
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.¶
The mechanism must be capable of negotiating algorithms requiring dual certificates as well as algorithms that are acceptable standalone.¶
Any additions or modifications to the TLS protocol must be minimal to ease deployment, reduce implementation complexity and minimize new security risks.¶
This mechanism is specific to cryptographic algorithm migration. It is
not a generic mechanism for using multiple identities in a single TLS
handshake. In particular, this mechanism does not allow for negotiating
two certificates with the same algorithm but containing different
identifiers, or for negotiating two independent sets of
certificate_authorities.¶
Clients and servers may choose to support composite certificate schemes, such as those defined in [TLS-COMPOSITE-MLDSA]. In these schemes, a single certificate contains a composite public key, and the associated signature proves knowledge of private keys of all components. However, from the perspective of the TLS protocol, this is a single certificate producing a single composite signature.¶
If a composite signature algorithm appears in the signature_algorithms
extension, it can fulfill the client's requirements for both traditional
and PQ authentication in a single certificate and signature. It is up
to the client policy to decide whether a composite certificate is
acceptable in place of a dual-certificate configuration. This allows
further deployment flexibility and compatibility with hybrid
authentication strategies.¶
The advantages of dual certificates over composites are operational flexibility for both Certification Authority operators and TLS server and client operators because two CAs and end-entity certificates, one traditional and one PQ, allow for backward-compatible and dynamic negotiation of pure traditional, pure PQ, or dual.¶
The advantages of composites over dual certificates are that the certificate chains themselves are protected by dual-algorithms, which can be of great importance in use cases where trust stores are not easily updatable.¶
A client may include both composite and dual code points in
signature_algorithms, leaving the server to select whichever it can
satisfy.¶
This section provides non-normative examples of how a client populates
signature_algorithms to express different authentication policies.
For client authentication, the same principles apply with roles
reversed: the server drives requirements via CertificateRequest.¶
Client requires only one traditional, PQ or a composite signature. Client either does not support or is not configured to accept dual certificates.¶
Client behavior:¶
Includes only single-algorithm and/or composite code points in
signature_algorithms and optionally signature_algorithms_cert.¶
To satisfy this client, the server MUST send a single certificate chain
with compatible algorithms and include a single signature in
CertificateVerify.¶
Client supports both traditional and PQ authentication. It allows the server to send either a traditional chain alone or both chains.¶
Client behavior:¶
Includes both traditional single-algorithm code points and dual code
points in signature_algorithms and optionally
signature_algorithms_cert.¶
To satisfy this client, the server MUST either:¶
Provide a single certificate chain with compatible traditional
algorithms and include a single signature in CertificateVerify, or¶
Provide a traditional certificate chain followed by a PQ certificate
chain as described in Section 5.2 and encode two signatures in
CertificateVerify as described in Section 5.3.¶
Client requires both traditional and PQ authentication to be performed simultaneously.¶
Client behavior:¶
Includes only dual code points in signature_algorithms.¶
To satisfy this client, the server MUST provide a traditional
certificate chain followed by a PQ certificate chain as described in
Section 5.2 and encode two signatures in CertificateVerify as
described in Section 5.3. If the server cannot satisfy this,
the handshake will fail.¶
Client supports both traditional and PQ authentication. It allows the server to send either a PQ chain alone or both chains.¶
Client behavior:¶
Includes both PQ single-algorithm code points and dual code points
in signature_algorithms and optionally signature_algorithms_cert.¶
To satisfy this client, the server MUST either:¶
Provide a single certificate chain with compatible PQ algorithms and
include a single signature in CertificateVerify, or¶
Provide a traditional certificate chain followed by a PQ certificate
chain as described in Section 5.2 and encode two signatures in
CertificateVerify as described in Section 5.3.¶