Post-Quantum Traditional (PQ/T) Hybrid Authentication with Dual Certificates in TLS 1.3
draft-yusef-tls-pqt-dual-certs-03
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Rifaat Shekh-Yusef , Tirumaleswar Reddy.K , Hannes Tschofenig , Mike Ounsworth , Yaroslav Rosomakho | ||
| Last updated | 2026-10-23 (Latest revision 2026-07-03) | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-yusef-tls-pqt-dual-certs-03
TLS Working Group R. Shekh-Yusef
Internet-Draft Ciena
Updates: RFC9261, RFC8446 (if approved) T. Reddy
Intended status: Standards Track Nokia
Expires: 4 January 2027 H. Tschofenig
UniBw M.
M. Ounsworth
Cryptic Forest
Y. Rosomakho
Zscaler
3 July 2026
Post-Quantum Traditional (PQ/T) Hybrid Authentication with Dual
Certificates in TLS 1.3
draft-yusef-tls-pqt-dual-certs-03
Abstract
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.
Status of This Memo
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.
Shekh-Yusef, et al. Expires 4 January 2027 [Page 1]
Internet-Draft PQ/T Dual Certs in TLS July 2026
Copyright Notice
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions and Definitions . . . . . . . . . . . . . . . . . 4
3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Design Overview . . . . . . . . . . . . . . . . . . . . . . . 5
4.1. Signature Algorithms Negotiation . . . . . . . . . . . . 5
4.2. Certificate Chain Encoding . . . . . . . . . . . . . . . 5
4.3. CertificateVerify Signatures . . . . . . . . . . . . . . 6
5. Protocol Changes . . . . . . . . . . . . . . . . . . . . . . 7
5.1. SignatureScheme Code Points . . . . . . . . . . . . . . . 7
5.2. Certificate Message Encoding . . . . . . . . . . . . . . 8
5.2.1. Delimiter . . . . . . . . . . . . . . . . . . . . . . 8
5.3. CertificateVerify Message . . . . . . . . . . . . . . . . 10
5.4. Dual Certificate Policy Enforcement . . . . . . . . . . . 11
6. Performance Considerations . . . . . . . . . . . . . . . . . 11
7. Security Considerations . . . . . . . . . . . . . . . . . . . 12
7.1. Weak Non-Separability . . . . . . . . . . . . . . . . . . 12
7.2. Signature Validation Requirements . . . . . . . . . . . . 12
7.3. Side-Channel Resistance . . . . . . . . . . . . . . . . . 12
7.4. Cryptographic Independence Of The Two Chains . . . . . . 13
7.5. Certificate Usage and Trust . . . . . . . . . . . . . . . 13
7.6. Preventing Downgrade Attacks . . . . . . . . . . . . . . 13
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
10.1. Normative References . . . . . . . . . . . . . . . . . . 14
10.2. Informative References . . . . . . . . . . . . . . . . . 14
Appendix A. Informal Requirements for Dual TLS Certificate
Support . . . . . . . . . . . . . . . . . . . . . . . . . 16
A.1. Dual-Algorithm Security . . . . . . . . . . . . . . . . . 16
A.1.1. Weak Non-Separability . . . . . . . . . . . . . . . . 16
A.2. Dual Certificate Semantics . . . . . . . . . . . . . . . 16
A.2.1. Independent Chain Usability . . . . . . . . . . . . . 16
Shekh-Yusef, et al. Expires 4 January 2027 [Page 2]
Internet-Draft PQ/T Dual Certs in TLS July 2026
A.2.2. Unambiguous Chain Separation . . . . . . . . . . . . 16
A.3. Use Case and Deployment Flexibility . . . . . . . . . . . 16
A.3.1. Backward Compatibility . . . . . . . . . . . . . . . 16
A.3.2. Forward Compatibility . . . . . . . . . . . . . . . . 17
A.3.3. Minimal Protocol Changes . . . . . . . . . . . . . . 17
A.4. Non-Goals . . . . . . . . . . . . . . . . . . . . . . . . 17
A.4.1. Multiple Identities . . . . . . . . . . . . . . . . . 17
Appendix B. Compatibility with composite certificates . . . . . 17
Appendix C. Policy Examples . . . . . . . . . . . . . . . . . . 18
C.1. Example 1: Single-certificate . . . . . . . . . . . . . . 18
C.2. Example 2: Dual-Compatible, Traditional Primary, PQ
Optional . . . . . . . . . . . . . . . . . . . . . . . . 18
C.3. Example 3: Strict Dual . . . . . . . . . . . . . . . . . 19
C.4. Example 4: Dual-Compatible, PQ Primary, Traditional
Optional . . . . . . . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
1. Introduction
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
Shekh-Yusef, et al. Expires 4 January 2027 [Page 3]
Internet-Draft PQ/T Dual Certs in TLS July 2026
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.
2. Conventions and Definitions
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.
3. Scope
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-
Shekh-Yusef, et al. Expires 4 January 2027 [Page 4]
Internet-Draft PQ/T Dual Certs in TLS July 2026
quantum-only authentication. This strategy offers a smooth migration
path, ensuring long-term cryptographic agility, regulatory
compliance, and operational continuity without disrupting existing
infrastructure.
4. Design Overview
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.
4.1. Signature Algorithms Negotiation
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.
4.2. Certificate Chain Encoding
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.
Shekh-Yusef, et al. Expires 4 January 2027 [Page 5]
Internet-Draft PQ/T Dual Certs in TLS July 2026
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.
4.3. CertificateVerify Signatures
The CertificateVerify message is not modified. When a dual code
point has been negotiated, the signature field encodes two
independent signatures:
1. One computed using the traditional algorithm component of the
negotiated code point.
2. 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].
Shekh-Yusef, et al. Expires 4 January 2027 [Page 6]
Internet-Draft PQ/T Dual Certs in TLS July 2026
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.
5. Protocol Changes
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.
5.1. SignatureScheme Code Points
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;
Figure 1: Dual SignatureScheme code points
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.
Shekh-Yusef, et al. Expires 4 January 2027 [Page 7]
Internet-Draft PQ/T Dual Certs in TLS July 2026
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.
5.2. Certificate Message Encoding
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;
Figure 2: TLS 1.3 Certificate message
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.
5.2.1. 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;
Figure 3: Updated CertificateEntry structure definition
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.
Shekh-Yusef, et al. Expires 4 January 2027 [Page 8]
Internet-Draft PQ/T Dual Certs in TLS July 2026
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
Shekh-Yusef, et al. Expires 4 January 2027 [Page 9]
Internet-Draft PQ/T Dual Certs in TLS July 2026
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.
5.3. CertificateVerify Message
TLS 1.3 defines the CertificateVerify message as follows:
struct {
SignatureScheme algorithm;
opaque signature<0..2^16-1>;
} CertificateVerify;
Figure 4: TLS 1.3 CertificateVerify message
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].
Shekh-Yusef, et al. Expires 4 January 2027 [Page 10]
Internet-Draft PQ/T Dual Certs in TLS July 2026
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].
5.4. Dual Certificate Policy Enforcement
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.
6. Performance Considerations
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.
Shekh-Yusef, et al. Expires 4 January 2027 [Page 11]
Internet-Draft PQ/T Dual Certs in TLS July 2026
7. Security Considerations
7.1. Weak Non-Separability
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.
7.2. Signature Validation Requirements
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.
7.3. Side-Channel Resistance
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.
Shekh-Yusef, et al. Expires 4 January 2027 [Page 12]
Internet-Draft PQ/T Dual Certs in TLS July 2026
7.4. Cryptographic Independence Of The Two Chains
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.
7.5. Certificate Usage and Trust
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.
7.6. Preventing Downgrade Attacks
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.
8. IANA Considerations
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 |
+-------+--------------------------------+-------------+-----------+
Table 1: New TLS SignatureScheme values
Shekh-Yusef, et al. Expires 4 January 2027 [Page 13]
Internet-Draft PQ/T Dual Certs in TLS July 2026
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.
9. Acknowledgments
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.
10. References
10.1. Normative References
[EXPORTED-AUTH]
Sullivan, N., "Exported Authenticators in TLS", RFC 9261,
DOI 10.17487/RFC9261, July 2022,
<https://www.rfc-editor.org/rfc/rfc9261>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
[TLS] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", Work in Progress, Internet-Draft, draft-
ietf-tls-rfc8446bis-14, 13 September 2025,
<https://datatracker.ietf.org/doc/html/draft-ietf-tls-
rfc8446bis-14>.
10.2. Informative References
[COMPRESS-CERT]
Ghedini, A. and V. Vasiliev, "TLS Certificate
Compression", RFC 8879, DOI 10.17487/RFC8879, December
2020, <https://www.rfc-editor.org/rfc/rfc8879>.
Shekh-Yusef, et al. Expires 4 January 2027 [Page 14]
Internet-Draft PQ/T Dual Certs in TLS July 2026
[ECDSA] "Digital Signature Standard (DSS)", National Institute of
Standards and Technology (U.S.),
DOI 10.6028/nist.fips.186-5, February 2023,
<https://doi.org/10.6028/nist.fips.186-5>.
[HYBRID-SIGS]
Bindel, N., Hale, B., Connolly, D., and F. D, "Hybrid
signature spectrums", Work in Progress, Internet-Draft,
draft-ietf-pquip-hybrid-signature-spectrums-07, 20 June
2025, <https://datatracker.ietf.org/doc/html/draft-ietf-
pquip-hybrid-signature-spectrums-07>.
[IANA-TLS] Salowey, J. and S. Turner, "IANA Registry Updates for TLS
and DTLS", RFC 8447, DOI 10.17487/RFC8447, August 2018,
<https://www.rfc-editor.org/rfc/rfc8447>.
[ML-DSA] Hollebeek, T., Schmieg, S., and B. Westerbaan, "Use of ML-
DSA in TLS 1.3", Work in Progress, Internet-Draft, draft-
ietf-tls-mldsa-04, 18 June 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-tls-
mldsa-04>.
[PQ-RECOMMEND]
Reddy.K, T. and H. Tschofenig, "Post-Quantum Cryptography
Recommendations for TLS-based Applications", Work in
Progress, Internet-Draft, draft-reddy-uta-pqc-app-08, 2
July 2025, <https://datatracker.ietf.org/doc/html/draft-
reddy-uta-pqc-app-08>.
[PQT-TERMS]
D, F., P, M., and B. Hale, "Terminology for Post-Quantum
Traditional Hybrid Schemes", Work in Progress, Internet-
Draft, draft-ietf-pquip-pqt-hybrid-terminology-06, 10
January 2025, <https://datatracker.ietf.org/doc/html/
draft-ietf-pquip-pqt-hybrid-terminology-06>.
[RELATED-CERTS]
Becker, A., Guthrie, R., and M. Jenkins, "Related
Certificates for Use in Multiple Authentications within a
Protocol", RFC 9763, DOI 10.17487/RFC9763, June 2025,
<https://www.rfc-editor.org/rfc/rfc9763>.
[RFC9525] Saint-Andre, P. and R. Salz, "Service Identity in TLS",
RFC 9525, DOI 10.17487/RFC9525, November 2023,
<https://www.rfc-editor.org/rfc/rfc9525>.
Shekh-Yusef, et al. Expires 4 January 2027 [Page 15]
Internet-Draft PQ/T Dual Certs in TLS July 2026
[TLS-COMPOSITE-MLDSA]
Reddy.K, T., Hollebeek, T., Gray, J., Fluhrer, S., and D.
Van Geest, "Use of Composite ML-DSA in TLS 1.3", Work in
Progress, Internet-Draft, draft-reddy-tls-composite-mldsa-
10, 13 May 2026, <https://datatracker.ietf.org/doc/html/
draft-reddy-tls-composite-mldsa-10>.
[TLSIANA] Salowey, J. and S. Turner, "IANA Registry Updates for TLS
and DTLS", RFC 8447, DOI 10.17487/RFC8447, August 2018,
<https://www.rfc-editor.org/rfc/rfc8447>.
Appendix A. Informal Requirements for Dual TLS Certificate Support
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.
A.1. Dual-Algorithm Security
A.1.1. Weak Non-Separability
The dual certificate authentication achieves, at least, Weak Non-
Separability [HYBRID-SIGS] at the time of verification of the
CertificateVerify message.
A.2. Dual Certificate Semantics
A.2.1. Independent Chain Usability
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.
A.2.2. Unambiguous Chain Separation
The mechanism must clearly distinguish and delimit multiple
certificate chains to prevent ambiguity or misinterpretation.
A.3. Use Case and Deployment Flexibility
A.3.1. Backward Compatibility
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.
Shekh-Yusef, et al. Expires 4 January 2027 [Page 16]
Internet-Draft PQ/T Dual Certs in TLS July 2026
A.3.2. Forward Compatibility
The mechanism must be capable of negotiating algorithms requiring
dual certificates as well as algorithms that are acceptable
standalone.
A.3.3. Minimal Protocol Changes
Any additions or modifications to the TLS protocol must be minimal to
ease deployment, reduce implementation complexity and minimize new
security risks.
A.4. Non-Goals
A.4.1. Multiple Identities
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.
Appendix B. Compatibility with composite certificates
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.
Shekh-Yusef, et al. Expires 4 January 2027 [Page 17]
Internet-Draft PQ/T Dual Certs in TLS July 2026
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.
Appendix C. Policy Examples
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.
C.1. Example 1: Single-certificate
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.
C.2. Example 2: Dual-Compatible, Traditional Primary, PQ Optional
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
Shekh-Yusef, et al. Expires 4 January 2027 [Page 18]
Internet-Draft PQ/T Dual Certs in TLS July 2026
* 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.
C.3. Example 3: Strict Dual
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.
C.4. Example 4: Dual-Compatible, PQ Primary, Traditional Optional
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.
Authors' Addresses
Rifaat Shekh-Yusef
Ciena
Canada
Email: rifaat.s.ietf@gmail.com
Shekh-Yusef, et al. Expires 4 January 2027 [Page 19]
Internet-Draft PQ/T Dual Certs in TLS July 2026
Tirumaleswar Reddy
Nokia
India
Email: kondtir@gmail.com
Hannes Tschofenig
University of the Bundeswehr Munich
85577 Neubiberg
Germany
Email: hannes.tschofenig@gmx.net
Mike Ounsworth
Cryptic Forest Software
Sioux Lookout, Ontario
Canada
Email: mike@ounsworth.ca
Yaroslav Rosomakho
Zscaler
Email: yrosomakho@zscaler.com
Shekh-Yusef, et al. Expires 4 January 2027 [Page 20]