Post-Quantum Traditional (PQ/T) Hybrid Authentication with Dual Certificates in TLS 1.3

Internet-Draft	PQ/T Dual Certs in TLS	June 2025
Shekh-Yusef, et al.	Expires 20 December 2025	[Page]

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.¶

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 document defines a new extension dual_signature_algorithms to negotiate support for two categories of signature algorithms, typically one set of classic schemes and one set of PQ schemes. It also makes changes to the Certificate and CertificateVerify messages to take advantage of both certificates when authenticating the end entity.¶

This method exemplifies a PQ/T hybrid protocol with non-composite authentication as defined in Section 4 of {I-D.ietf-pquip-pqt-hybrid-terminology}, 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 [?RFC8447] provided that both components of the dual are of the same type. This document assumes X.509 certificates for all explanatory text.¶

4. Design Overview

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 requiring an attacker to break both authentication algorithms to impersonate a peer. Typically one of the certificate chains is using a traditional cryptographic algorithms while the second leverages post-quantum (PQ) cryptography.¶

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 [EXPORTED-AUTH].¶

4.1. Signature Algorithms Negotiation

A new extension, dual_signature_algorithms, is defined to negotiate support for two distinct categories of signature algorithms. The extension carries two disjoint lists: one for classical signature algorithms and one for post-quantum signature algorithms.¶

In the ClientHello, this extension indicates the client's supported classical and PQ signature algorithms for dual certificate server authentication.¶
In the CertificateRequest, this extension indicates the server's supported classical and PQ signature algorithms for dual certificate client authentication.¶

This allows both endpoints to signal independently two distinct algorithms for dual authentication.¶

The dual_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].¶

The dual_signature_algorithms extension does not replace signature_algorithms. TLS peers MUST include the signature_algorithms extension regardless of whether dual_signature_algorithms is used. The signature_algorithms extension indicates algorithms acceptable for single-certificate authentication and MUST contain either a non-empty list of such algorithms or be empty if only dual-certificate authentication is acceptable.¶

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.¶

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 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 extended to include two digital signatures:¶

One computed using a signature algorithm selected from the first list of the dual_signature_algorithms extension.¶
One computed using a signature algorithm selected from the second list of the dual_signature_algorithms extension.¶

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 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 a classical algorithm from first_signature_algorithms list of dual_signature_algorithms extension, while the second signature MUST correspond to a PQ algorithm from second_signature_algorithms list of dual_signature_algorithms extension.¶

5. Protocol Changes

This section defines the normative changes to TLS 1.3 required to support dual-certificate authentication. These changes extend existing handshake messages and introduce the new extension.¶

5.1. `dual_signature_algorithms` Extension

A new extension, dual_signature_algorithms, is defined to allow peers to advertise support for two distinct categories of signature algorithms: classical and post-quantum.¶

5.1.1. Structure

The structure of the extension as follows:¶

struct {
    SignatureScheme first_signature_algorithms<2..2^16-2>;
    SignatureScheme second_signature_algorithms<2..2^16-2>;
} DualSignatureSchemeList;

Figure 1: Contents of dual_signature_algorithms extension

SignatureScheme is a 2-octet value identifying a supported signature algorithm as defined in TLS SignatureScheme IANA registry. first_signature_algorithms and second_signature_algorithms list MUST NOT contain common elements. TLS endpoint observing such overlap between primary and secondary supported signature lists MUST terminate the connection with illegal_parameter alert.¶

5.1.2. Use in Handshake and Exported Authenticator Messages

The client MAY include this extension in ClientHello message to indicate classical and PQ algorithms it supports for verifying the server's signature. The server MAY include this extension in CertificateRequest message to classical and PQ 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 dual certificates in the response.¶

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 two certificate chains or two signatures.¶

The presence of this extension alone does not mandate dual authentication. It is up to the peer to determine whether one or two certificate chains and signatures are required based on local policy and validation logic. A single certificate and a single signature encoded in Certificate and CertificateVerify messages remain valid as long as the certificate and its corresponding signature algorithm comply with the values in the signature_algorithms or signature_algorithms_cert extension.¶

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 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 indicated support for dual certificates by including dual_signature_algorithms extension.¶

This specification expands 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:
          select (certificate_type) {
              case RawPublicKey:
                /* From RFC 7250 ASN.1_subjectPublicKeyInfo */
                opaque ASN1_subjectPublicKeyInfo<1..2^24-1>;

              case X509:
                opaque cert_data<1..2^24-1>;
          };
          Extension extensions<0..2^16-1>;
    };
} CertificateEntry;

Figure 3: Updated CertificateEntry structure definition

All entries before the delimiter are treated as the first certificate chain and MUST use classical algorithms from first_signature_algorithms list of dual_signature_algorithms extension, all entries after the delimiter are treated as the second certificate chain and MUST use PQ algorithms from second_signature_algorithms list of dual_signature_algorithms extension. As specified in Section 4.4.2 of [TLS], end-entity certificate MUST be the first in both chains.¶

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 first_signature_algorithms section of dual_signature_algorithms extension. The second certificate chain MUST contain certificates whose public key is compatible with one of the algorithms listed in the second_signature_algorithms section of dual_signature_algorithms extension.¶

This encoding applies equally to the CompressedCertificate message and to Certificate message of Exported Authenticators.¶

5.3. CertificateVerify Message

The CertificateVerify message is extended to carry two independent signatures. Its modified structure is as follows:¶

struct {
    SignatureScheme first_algorithm;
    opaque first_signature<0..2^16-1>;
    SignatureScheme second_algorithm;
    opaque second_signature<0..2^16-1>;
} CertificateVerify;

Figure 4: CertificateVerify message

Each signature covers the transcript hash as in TLS 1.3, but with a distinct context string for domain separation.¶

5.3.1. Context Strings

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.¶

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, such as during high-assurance sessions or post-quantum transition periods, the authenticating endpoint MUST abort a handshake where only one signature or one certificate chain is present with an dual_certificate_required alert. Implementations MUST ensure that both certificates and both signatures are processed together and MUST NOT accept fallback to single-certificate authentication when dual-authentication is expected.¶

A single composite certificate chain and signature such as defined by [TLS-COMPOSITE-MLDSA] MAY be an acceptable alternative during post-quantum transition period as long as corresponding signature scheme is listed in signature_algorithms extension.¶

7. Client-Driven Authentication Requirements

The scenarios in this section describe server authentication behavior based on client policy. Each case reflects a different client capability and authentication policy, based on how the client populates the signature_algorithms, signature_algorithms_cert, and dual_signature_algorithms extensions.¶

For client authentication, the same principles apply with roles reversed: the server drives authentication requirements by sending a CertificateRequest message that includes appropriate extensions.¶

7.1. Type 1: Single-certificate

Client requires only one classical, pq or a composite signature. Client does not support dual certificates.¶

Client behavior:¶

Includes supported algorithms in signature_algorithms and optionally signature_algorithms_cert.¶
Does not include dual_signature_algorithms.¶

To satisfy this client, the server MUST send a single certificate chain with compatible algorithms and include a single signature in CertificateVerify.¶

7.2. Type 2: Dual-Compatible, PQ Optional (Classic Primary)

Client supports both classical and PQ authentication. It allows the server to send either a classical chain alone or both chains.¶

Client behavior:¶

Includes supported classical algorithms in signature_algorithms and optionally signature_algorithms_cert.¶
Includes supported classical algorithms in first_signature_algorithms list of dual_signature_algorithms and supported PQ algorithms in second_signature_algorithms list of dual_signature_algorithms.¶

To satisfy this client, the server MUST either:¶

Provide a single certificate chain with compatible classical algorithms and include a single signature in CertificateVerify¶
Provide a classical certificate chain followed by a PQ certificate chain as described in Section 5.2 and two signatures in CertificateVerify as described in Section 5.3 ¶

7.3. Type 3: Strict Dual

Client requires both classical and PQ authentication to be performed simultaneously. It does not support composite certificates.¶

Client behavior:¶

Includes an empty list in signature_algorithms.¶
Includes supported classical algorithms in first_signature_algorithms list of dual_signature_algorithms and supported PQ algorithms in second_signature_algorithms list of dual_signature_algorithms.¶

To satisfy this client, the server MUST provide a classical certificate chain followed by a PQ certificate chain as described in Section 5.2 and two signatures in CertificateVerify as described in Section 5.3 ¶

7.4. Type 4: Dual-Compatible, Classic Optional (PQ Primary)

Client supports both classical and PQ authentication. It allows the server to send either a PQ chain alone or both chains.¶

Client behavior:¶

Includes supported PQ algorithms in signature_algorithms and optionally signature_algorithms_cert.¶
Includes supported classical algorithms in first_signature_algorithms list of dual_signature_algorithms and supported PQ algorithms in second_signature_algorithms list of dual_signature_algorithms.¶

To satisfy this client, the server MUST either:¶

Provide a single certificate chain with compatible PQ algorithms and include a single signature in CertificateVerify¶
Provide a PQ certificate chain followed by a classical certificate chain as described in Section 5.2 and two signatures in CertificateVerify as described in Section 5.3 ¶

7.5. 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 keys, and the associated signature proves knowledge of private keys of all components.¶

If a composite signature algorithm appears in the signature_algorithms extension, it can fulfill the client's requirements for both classical 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.¶

8. Security Considerations

8.1. Signature Association and Parsing 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.¶

8.2. Signature Validation Requirements

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.¶

8.3. Side-Channel Resistance

Since both CertificateVerify operations involve signing the transcript using different cryptographic primitives, care MUST be taken to avoid leaking 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.¶

8.4. Cryptographic Independence

To achieve the intended security guarantees, implementers and deployment operators MUST ensure that the two certificate chains rely on cryptographically independent primitives.¶

8.5. Certificate Usage and Trust

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.¶

8.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 it does not indicate 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.¶