Guidance for Migration to Composite, Dual, or PQC Authentication
draft-reddy-pquip-pqc-signature-migration-01
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 | Tirumaleswar Reddy.K , Dan Wing , Yaroslav Rosomakho | ||
| Last updated | 2025-10-14 | ||
| 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-reddy-pquip-pqc-signature-migration-01
PQUIP T. Reddy
Internet-Draft Nokia
Intended status: Informational D. Wing
Expires: 17 April 2026 Citrix
Y. Rosomakho
Zscaler
14 October 2025
Guidance for Migration to Composite, Dual, or PQC Authentication
draft-reddy-pquip-pqc-signature-migration-01
Abstract
This document provides guidance for migration from traditional
digital signature algorithms to post-quantum cryptographic (PQC)
signature algorithms. It compares three models under discussion in
the IETF for PKI-based protocols: composite certificates, dual
certificates, and PQC certificates. The goal is to help operators
and engineers working on cryptographic libraries, network security,
and PKI/key management infrastructure select an approach that
balances interoperability, security, and operational efficiency
during the transition to post-quantum authentication.
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 17 April 2026.
Copyright Notice
Copyright (c) 2025 IETF Trust and the persons identified as the
document authors. All rights reserved.
Reddy, et al. Expires 17 April 2026 [Page 1]
Internet-Draft PQC Signature Migration Guidance October 2025
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. Motivation for PQC Signatures . . . . . . . . . . . . . . . . 5
4. Composite certificates . . . . . . . . . . . . . . . . . . . 6
4.1. Advantages . . . . . . . . . . . . . . . . . . . . . . . 7
4.2. Disadvantages . . . . . . . . . . . . . . . . . . . . . . 7
5. Dual Certificates . . . . . . . . . . . . . . . . . . . . . . 8
5.1. Advantages . . . . . . . . . . . . . . . . . . . . . . . 8
5.2. Disadvantages . . . . . . . . . . . . . . . . . . . . . . 8
6. PQC Certificates . . . . . . . . . . . . . . . . . . . . . . 9
6.1. Advantages . . . . . . . . . . . . . . . . . . . . . . . 9
6.2. Disadvantages . . . . . . . . . . . . . . . . . . . . . . 9
7. Operational and Ecosystem Considerations . . . . . . . . . . 10
7.1. Trust Anchors and Transitions . . . . . . . . . . . . . . 10
7.2. Multiple Transitions and Crypto-Agility . . . . . . . . . 12
7.3. Support from Hardware Security Modules (HSMs) . . . . . . 12
7.4. Constrained Devices and IoT Environments . . . . . . . . 13
8. Transition Considerations . . . . . . . . . . . . . . . . . . 13
8.1. Transition Logic Overview . . . . . . . . . . . . . . . . 13
8.2. Negotiation and Interoperability . . . . . . . . . . . . 13
8.3. Composite Certificates . . . . . . . . . . . . . . . . . 15
8.4. Dual Certificates . . . . . . . . . . . . . . . . . . . . 15
8.5. Loss of Strong Unforgeability in Composite and Dual
Certificates . . . . . . . . . . . . . . . . . . . . . . 15
9. Migration Guidance . . . . . . . . . . . . . . . . . . . . . 16
10. Use of SLH-DSA in PQC-Only Deployments . . . . . . . . . . . 17
11. Security Considerations . . . . . . . . . . . . . . . . . . . 18
11.1. Downgrade Attacks . . . . . . . . . . . . . . . . . . . 18
11.2. Strong Unforgeability versus Existential
Unforgeability . . . . . . . . . . . . . . . . . . . . . 19
11.3. Operational Risks . . . . . . . . . . . . . . . . . . . 19
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
14.1. Normative References . . . . . . . . . . . . . . . . . . 20
14.2. Informative References . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24
Reddy, et al. Expires 17 April 2026 [Page 2]
Internet-Draft PQC Signature Migration Guidance October 2025
1. Introduction
The emergence of cryptographically relevant quantum computer (CRQC)
poses a threat to widely deployed public-key algorithms such as RSA
and elliptic-curve cryptography (ECC). Post-quantum algorithms are
being standardized by NIST and other bodies, but migration is not
immediate. In the meantime, protocols need to ensure that
authentication mechanisms remain secure against both classical and
quantum adversaries.
For data authentication, the primary concern is that adversaries who
obtain a CRQC will be able to forge digital signatures produced by
traditional public-key algorithms (e.g., RSA, ECDSA). Such forgeries
enable a range of attacks, including on-path man-in-the-middle (MitM)
attacks, and off-path attacks such as software-artifact forgery, and
client impersonation in mutual TLS when a client private key is
compromised. In addition, on-path adversaries can attempt active
downgrade techniques (for example, suppressing PQC or hybrid
signature schemes during negotiation) to force reliance on broken
traditional algorithms. PQC or Hybrid certificates do not by
themselves prevent downgrade attack when relying parties continue to
accept traditional-only certificates. These risks motivate a
transition of certificate-based authentication toward post-quantum
security.
The IETF has defined two hybrid transition models for use in TLS,
IKEv2/IPsec, JOSE/COSE, and PKIX:
* Composite certificates: A single X.509 certificate that contains a
composite public key and a composite signature, combining a
traditional and a PQC algorithm. Certificates using composite ML-
DSA are specified in [COMPOSITE-ML-DSA].
* Dual-certificate model: A deployment model in which two separate
certificates, one using a traditional algorithm and one using a
PQC algorithm, issued for the same identity, presented and
validated together during authentication. Some protocols may
require these certificates to include the RelatedCertificate
extension [RELATED-CERTS] to ensure that both refer to the same
identity and binding.
Another approach is to use a PQC certificate which contains only a
post-quantum public key and produces signatures using a PQC
algorithm. Examples include [ML-DSA] and [SLH-DSA].
This document provides guidance on selecting among the two hybrid
certificate models and the PQC model depending on the deployment
context, the readiness of the supporting ecosystem, and security
requirements.
Reddy, et al. Expires 17 April 2026 [Page 3]
Internet-Draft PQC Signature Migration Guidance October 2025
It is important to note that the use of PQC certificates, composite
certificates, or the dual-certificate model alone does not guarantee
post-quantum security. As long as relying parties continue to trust
or accept traditional-only certificates, an attacker equipped with a
CRQC can forge traditional certificates and impersonate an
authenticated party, even if that party does not use a traditional
certificate. Post-quantum security is achieved only when relying
parties enforce policies that reject traditional-only authentication.
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.
This document uses the terms "composite certificates" and "PQC
certificates" as defined in Section 1.
The term "dual certificates" in this document refers to the dual-
certificate model as defined in Section 1.
Composite: A key, certificate, or signature that merges traditional
and PQC algorithms into one object.
The terms hybrid signature scheme and hybrid signature are used as
defined in [HYBRID-SPECTRUMS].
The term hybrid certificates is used herein to refer to either
composite or dual certificate models.
Relying Party: An endpoint which validates the certificate of a
remote peer. With classic HTTPS authentication, this is the HTTPS
client. With mutual TLS authentication, this is both TLS endpoints.
Authenticated Party: An endpoint which provides its certificate for a
remote peer to validate. With classic HTTPS authentication, this is
the HTTPS server. With mutual TLS authentication, this is both TLS
endpoints.
Reddy, et al. Expires 17 April 2026 [Page 4]
Internet-Draft PQC Signature Migration Guidance October 2025
3. Motivation for PQC Signatures
Unlike "Harvest Now, Decrypt Later" attacks (see Section 7 of
[PQC-ENGINEERS]) that target the confidentiality of encrypted data,
the threat to authentication arises only from the moment a CRQC
becomes available. Compromise of authentication is therefore not
retrospective: previously established identities and signatures
cannot be forged in hindsight, but all future authentications using
traditional algorithms become insecure once a CRQC exists.
Once a CRQC is available, continued reliance on traditional public-
key algorithms (e.g., RSA, ECDSA) becomes untenable, as an attacker
could forge digital signatures and impersonate legitimate entities.
In practice, the availability of a CRQC may not be publicly
disclosed. Similar to a zero-day vulnerability, an adversary could
exploit quantum capabilities privately to compromise traditional
certificates without alerting the wider ecosystem.
Addressing this risk requires replacing traditional signatures with
post-quantum (PQC) signatures. Doing so entails ecosystem-wide
upgrades across:
* Software components: cryptographic libraries and protocol
implementations;
* Hardware security devices: Hardware Security Modules (HSMs) and
Trusted Platform Modules (TPMs);
* Public Key Infrastructure (PKI): Certification Authorities (CAs),
intermediate CAs, and trust anchors;
* Dependent protocols: TLS ([TLS], [DTLS]), [IKEv2], and JOSE/COSE.
Because these transitions require years of planning, coordination,
and investment, preparations must begin well before a CRQC is
publicly known.
PQC or hybrid certificates provide post-quantum security only when
relying parties reject traditional-only certificates (see
Section 11.1). The implications of this requirement differ across
deployment environments:
* Open environments (e.g., the Web): Enforcing rejection of
traditional-only certificates would cause substantial disruption
due to the wide diversity of clients and servers. As discussed in
Section 11.1, there will be no single “flag day” for PQC
authentication; instead, relying parties will have to adopt PQC
enforcement gradually, using mechanisms such as continuity signals
or learned authenticated party behavior to resist downgrades while
maintaining compatibility during the transition.
Reddy, et al. Expires 17 April 2026 [Page 5]
Internet-Draft PQC Signature Migration Guidance October 2025
* Closed or enterprise-managed environments: In deployments where
both the authenticated party and the relying party are managed by
the same organization, enforcing PQC or hybrid authentication
policies is operationally feasible. Organizations can coordinate
certificate issuance and validation policies centrally, enabling
earlier transition to PQC or hybrid models without affecting
interoperability.
* mixed environments
In environments where a relying party visits authenticated parties
that have a mix of quantum-safe and traditional authentication, and
administrators or users need to protect against downgrade attacks
(Section 11.1), relying parties will need the configurations that are
per-domain or per-FQDN. Such mixed environments will likely be the
long tail.
4. Composite certificates
A composite certificate contains a composite public key and a
composite signature, each combining a traditional and a post-quantum
(PQC) algorithm within a single X.509 structure. Both the key and
the signature use new encodings defined in
[I-D.ietf-lamps-pq-composite-sigs], and therefore composite
certificates do not offer interoperability with legacy PKI
deployments. The goal is of the composite approach is defense-in-
depth: the traditional component preserves authentication security if
a flaw is found in the PQC algorithm before a CRQC exists, while the
PQC component preserves security after CRQCs can break traditional
algorithms. Verification succeeds only if all component signatures
validate over the same canonical message.
ML-DSA composite certificates are defined in
[I-D.ietf-lamps-pq-composite-sigs], which defines the use of ML-DSA
in combination with one or more traditional algorithms such as RSA-
PKCS#1v1.5, RSA-PSS, ECDSA, Ed25519, or Ed448. The framework in that
document is designed to be extensible and is expected to accommodate
additional post-quantum algorithms in future specifications.
Protocol-specific drafts describe how composite certificates are used
in different environments, including: [TLS-COMPOSITE-ML-DSA] for TLS,
[IKEv2-COMPOSITE-ML-DSA] for IKEv2, and [JOSE-COSE-COMPOSITE-ML-DSA]
for JOSE and COSE. In each case, the relying party validates a
single certification path anchored in a multi-algorithm trust anchor,
avoiding the need for parallel certificate chains.
Reddy, et al. Expires 17 April 2026 [Page 6]
Internet-Draft PQC Signature Migration Guidance October 2025
4.1. Advantages
A key benefit of the composite model is single-path operation.
Because both algorithms are embedded in one certificate chain, the
relying party validates only one path, which reduces chain-management
complexity compared to dual-chain deployments. Conveying a single
certificate and signature object can also reduce message size
relative to transmitting two independent chains. From a protocol
perspective, composite certificates typically require minimal changes
to handshakes, since authentication still relies on one certificate
and one signature.
4.2. Disadvantages
The main challenge with composite certificates is ecosystem
readiness. Clients, servers, and Certification Authorities must
support composite public keys and composite signature verification,
which are not yet widely deployed. The new certificate encodings and
multi-algorithm signing introduce updates across PKI components,
libraries, and Hardware Security Modules. Once these components
support the composite structures, using a composite signature
algorithm is no more complex than adopting any new PQC algorithm.
Another operational limitation is the need for algorithm-set
coordination: all participants in a composite ecosystem must agree on
the specific and acceptable combinations of post-quantum and
traditional algorithms (for example, ML-DSA-44 + ECDSA P-256 or ML-
DSA-65 + EdDSA Ed448). A composite certificate can only be validated
if both endpoints and all intermediate CAs recognize the same
algorithm identifiers and policy. Disagreement on permitted
combinations can lead to handshake failures, certificate re-issuance
delays, or policy fragmentation across vendors. This is primarily a
policy and interoperability issue during early deployment: once
endpoints and CAs recognize the same algorithm identifiers and
policies, a composite algorithm behaves like any other registered
signature algorithm.
Composite deployments are also an intermediate step: once traditional
algorithms are deprecated due to CRQCs, operators will still need to
transition from composite to PQC certificates. This requires
deploying new PQC trust anchors, issuing PQC certificates, and
revoking composite certificates. While automated mechanisms such as
ACME or CMP can streamline end-entity certificate issuance, trust
anchors are typically distributed through OS, Browser, or device
update mechanisms, and their replacement generally requires platform-
specific processes. As a result, for some organizations, this two-
stage path may lengthen the overall migration.
Reddy, et al. Expires 17 April 2026 [Page 7]
Internet-Draft PQC Signature Migration Guidance October 2025
5. Dual Certificates
Dual certificates rely on issuing two separate certificates for the
same identity: one using a traditional algorithm (for example, RSA or
ECDSA) and one using a post-quantum algorithm (for example, ML-DSA).
Both certificates are presented and validated during authentication,
providing hybrid assurance without introducing new certificate
formats or encodings.
5.1. Advantages
A major advantage of the dual-certificate model is its negotiation
flexibility. Because each certificate contains only a single
algorithm, endpoints do not need to agree in advance on a specific
combination of traditional and post-quantum algorithms. The server
can select which certificate (or both) to present based on the
client's advertised capabilities, and the client can validate
whichever chain it supports. This enables smoother incremental
deployment and interoperation between implementations that support
different PQC algorithms or security policies.
Dual certificates also use standard X.509 structures and single-
algorithm chains, maximizing compatibility with existing PKI and
avoiding changes to certificate parsing or signature verification
logic. The clear separation between traditional and PQC keys
simplifies operational control, audit, and incident response.
Deployments can move from traditional-only to dual certificates, and
later retire the traditional certificate when PQC support is
ubiquitous, without redefining certificate formats or introducing
composite encodings. The model also fits well in multi-tenant
environments where different tenants or business units may adopt
different combinations of traditional and PQC algorithms without
requiring global agreement on a composite set.
5.2. Disadvantages
The dual-certificate model increases protocol overhead, since both
certificate chains and signatures must be transmitted and validated.
Protocols that traditionally authenticate a single certificate chain,
such as [TLS] and [IKEv2], require extensions to support validation
of two end-entity certificates and to ensure that both are
cryptographically bound to the same identity. This adds
implementation complexity and may increase handshake latency.
Reddy, et al. Expires 17 April 2026 [Page 8]
Internet-Draft PQC Signature Migration Guidance October 2025
Managing two distinct certificate chains introduces operational cost
and new failure modes. Debugging becomes more difficult, as
validation errors may originate from either chain or from
inconsistent identity binding. Operators must also obtain and renew
two certificates from Certification Authorities, which can be
significant in large-scale deployments.
Finally, while dual certificates avoid the need for a fixed algorithm
pairing, they require explicit binding and coordination between the
two chains. Each relying party must verify that the traditional and
PQC certificates correspond to the same entity, typically using
mechanisms such as the RelatedCertificate extension [RELATED-CERTS].
Lack of consistent binding policies can lead to interoperability
issues and potential downgrade risks if only one chain is validated.
6. PQC Certificates
PQC certificates represent the final stage of migration. They use
exclusively post-quantum cryptographic algorithms for both public
keys and signatures, providing no fallback to traditional algorithms.
Once adopted at scale, they eliminate hybrid complexity and rely
entirely on quantum-resistant primitives for authentication.
6.1. Advantages
The PQC model offers the simplest and most forward-looking
architecture. It removes all dependency on classical algorithms,
thus avoiding future deprecation or phased-out support for RSA and
ECC. Certificate management is streamlined, as there is only one
algorithm family to provision, monitor, and renew. Operational
overhead decreases compared to dual deployments, since each entity
maintains a single certificate chain and consistent cryptographic
policy.
PQC certificates also enable long-term assurance: the entire
certificate path is verifiable using post-quantum signatures,
ensuring uniform resistance against quantum adversaries.
6.2. Disadvantages
The primary risk of PQC deployments is algorithmic fragility. If a
vulnerability or cryptanalytic weakness is discovered in a deployed
PQC scheme, there is no classical fallback for continued
authentication. Protocols and infrastructures must therefore
maintain strong crypto-agility and be prepared to replace algorithms
rapidly if needed.
Reddy, et al. Expires 17 April 2026 [Page 9]
Internet-Draft PQC Signature Migration Guidance October 2025
Backward compatibility can be maintained if the authenticated party
also holds a traditional certificate and presents it to relying
parties that have not yet deployed PQC support. While this approach
preserves interoperability during the transition, it also introduces
downgrade risk: an attacker could suppress PQC options and force
peers to authenticate using the traditional certificate.
PQC operation where traditional algorithms are completely removed
eliminates this downgrade vector, but it is feasible only once
relying parties enforce PQC–only authentication.
Adoption may also be uneven across jurisdictions. Regulatory
frameworks and certification programs may not recognize the same PQC
algorithms at the same time. Divergent compliance regimes could
delay global deployment or require organizations operating in
multiple regions to maintain mixed trust infrastructures until
regulatory alignment is achieved.
Finally, PQC deployments remain feasible only once PQC algorithms are
fully standardized, broadly implemented, and supported by hardware
security modules, operating systems, and major application
ecosystems.
7. Operational and Ecosystem Considerations
Migration to post-quantum authentication requires addressing broader
ecosystem dependencies, including trust anchors, hardware security
modules, and constrained devices.
7.1. Trust Anchors and Transitions
Trust anchors represent the ultimate root of trust in a PKI. If
existing trust anchors are RSA or ECC-based, then new PQC-capable
trust anchors will need to be distributed. Operators will have to
plan for a phased introduction of PQC trust anchors, which may
involve:
* Rolling out composite trust anchors that support both traditional
and PQC signatures.
* Establishing parallel trust anchor hierarchies and phasing out the
traditional hierarchy once PQC adoption is universal.
* Ensuring secure and authenticated distribution of updated trust
anchors to clients, especially devices that cannot be easily
updated.
Reddy, et al. Expires 17 April 2026 [Page 10]
Internet-Draft PQC Signature Migration Guidance October 2025
Deployments migrating from traditional to post-quantum authentication
may have to operate with multiple trust anchors for a period of time.
A new PQC or composite root may be introduced, or alternatively a PQ
intermediate may be added beneath an existing traditional root,
leading to different trust chain models:
* Traditional chain: anchored in a Traditional root (e.g., RSA/
ECDSA), which may issue a PQC intermediate.
* PQC chain: anchored in a PQC root (e.g., ML-DSA, SLH-DSA).
* Parallel roots: both a traditional root and a PQC root are
distributed as trust anchors, with separate hierarchies operating
in parallel until the traditional root can be phased out.
* Composite chain: anchored in a composite root and using composite
algorithms, with a single certificate chain that combines
traditional and PQC public keys and signatures. This forms a
distinct chain, rather than two parallel ones.
During this coexistence phase, clients generally fall into five
categories:
1. Legacy-only: trust only traditional roots and support only
traditional algorithms.
2. Mixed: trust only traditional roots but support both traditional
and PQC algorithms. These clients can validate PQC certificates
only if a PQC intermediate is cross-signed by a traditional root.
3. Dual-trust: trust both traditional and PQC roots, supporting both
algorithm families.
4. Composite-trust: trusts composite root and support composite
algorithms, validating a single chain that integrates traditional
and PQ signatures.
5. PQC: trust only PQC roots and support only PQC algorithms.
The main challenge is that servers cannot easily distinguish between
mixed clients (2) and dual-trust clients (3), since both advertise
PQC algorithms, but only dual-trust clients actually recognize PQC
roots. To ensure compatibility with mixed clients (2), servers may
default to sending longer PQC chains that include a cross-signed PQC
root (i.e., a PQC root certificate signed by a traditional root).
However, this is unnecessary and even counterproductive for dual-
trust clients (3), which already trust the PQC root directly; such
clients will fail to validate the cross-signed PQC root. For dual-
trust clients, including the cross-signed PQC root only increases
message size and introduces validation errors.
[I-D.ietf-tls-trust-anchor-ids] (TAI) addresses this problem by
allowing clients to indicate, on a per-connection basis, which trust
anchors they recognize. Servers can use that information to select a
compatible certificate chain, reducing unnecessary chain elements and
Reddy, et al. Expires 17 April 2026 [Page 11]
Internet-Draft PQC Signature Migration Guidance October 2025
providing operators with better telemetry on PQC adoption. TAI also
enables PQC-capable clients to tell PQC-aware servers exactly which
PQC trust anchors they recognize, while still supporting traditional
roots for compatibility with legacy servers.
In all cases, the long-term goal is a transition to PQC roots and
certificate chains. Hybrid signature schemes help bridge the gap,
but operators will have to plan carefully for the eventual retirement
of traditional and composite roots once PQC adoption is widespread.
7.2. Multiple Transitions and Crypto-Agility
Post-quantum migration is not a single event. There may be multiple
transitions over time, as:
* Traditional signature algorithms are gradually retired.
* Initial PQC signature algorithms are standardized and deployed.
* New PQC signature algorithms may replace early ones due to
cryptanalysis or efficiency improvements.
Protocols and infrastructures will have to be designed with crypto-
agility in mind, supporting:
* Negotiation of standalone PQC algorithms and hybrid signature
schemes.
* Phased migration paths, including initial use of hybrid signature
schemes, eventual transition to PQC certificates, and later
migration to new PQC algorithms as cryptanalysis or security
policy guidance evolves.
7.3. Support from Hardware Security Modules (HSMs)
Many organizations rely on HSMs for secure key storage and
operations. Challenges include:
* HSMs must be upgraded to support PQC algorithms and, where
relevant, composite or dual key management models.
* PQC algorithms often have larger key sizes and signatures,
requiring sufficient memory and processing capability in HSMs.
* For dual certificate deployments, HSMs can manage the underlying
traditional and PQC private keys independently, and no API changes
are required. The security protocol is responsible for
coordinating how signatures from both keys are used. By contrast,
supporting composite keys and composite signing operations will
require HSM and API extensions to represent composite private keys
and perform multi-algorithm signing atomically.
Reddy, et al. Expires 17 April 2026 [Page 12]
Internet-Draft PQC Signature Migration Guidance October 2025
Without HSM vendor support for PQC, migration may be delayed or
require software-based fallback solutions, which will weaken
security.
7.4. Constrained Devices and IoT Environments
Constrained environments, such as IoT devices, present unique
challenges for PQC deployment due to limited processing, memory, and
bandwidth. Guidance is provided in
[I-D.ietf-pquip-pqc-hsm-constrained], including the use of seeds for
efficient key generation, PQC-protected firmware updates, and other
techniques for enabling PQC in lightweight HSMs and resource-
constrained devices.
8. Transition Considerations
Migration to post-quantum authentication will proceed gradually
across protocols, products, and organizations. During this period,
endpoints may support multiple authentication models (traditional,
composite, dual, or PQC) depending on their stage of deployment. The
transition requires careful coordination of certificate management,
protocol negotiation, and policy enforcement to maintain security and
interoperability throughout the migration.
8.1. Transition Logic Overview
The migration to post-quantum authentication will occur in phases as
organizations adopt PQC algorithms and update their infrastructures.
Because CRQCs may be deployed without public disclosure, continued
reliance on traditional algorithms will become increasingly risky.
During the transition, dual certificates enable interoperability
between PQC-capable and legacy systems, while composite certificates
provide hybrid authentication within upgraded ecosystems. These
approaches serve as intermediate steps toward PQC deployments. Post-
quantum security is achieved only when relying parties stop accepting
traditional-only authentication. At that point, authenticated
parties can also stop issuing or presenting traditional-only
certificates.
8.2. Negotiation and Interoperability
During coexistence, endpoints must be able to discover which
authentication mechanisms the peer supports. In most protocols, this
is achieved through existing negotiation mechanisms such as, the
signature_algorithms extension in [TLS]. Clients advertise their
supported algorithms and certificate types, and servers select the
strongest mutually supported option or fail authentication if no
common algorithm is found.
Reddy, et al. Expires 17 April 2026 [Page 13]
Internet-Draft PQC Signature Migration Guidance October 2025
In hybrid or PQC-capable deployments, there is no security benefit if
authentication using only traditional algorithms continues to be
accepted, since an attacker can always downgrade to that option. The
specific choice between PQC and hybrid mechanisms may be influenced
by regulatory guidance, national cryptography policies, or the
organization's appetite for defense-in-depth during early adoption.
Negotiation mechanisms must also include downgrade protection so that
an adversary cannot suppress PQC or hybrid options and force a
fallback to traditional signatures (see Section 11.1). TLS already
provide such protection through transcript binding of the handshake
messages that carry the algorithm negotiation results, but new or
proprietary protocols have to ensure similar safeguards.
A deployment will typically adopt one of three models, PQC
certificates, dual certificates, or composite certificates.
The choice depends on several factors, including:
* Frequency and duration of system upgrades
* The expected timeline for CRQC availability
* Operational flexibility to deploy, enable, and retire PQC
algorithms
* Availability of automated certificate provisioning mechanisms such
as [ACME] and [CMP]
Deployments with limited flexibility benefit from hybrid signature
schemes. These approaches mitigate risks associated with delays in
transitioning to PQC and provide an immediate safeguard against zero-
day vulnerabilities. Both approaches improve resilience during
migration, but they do so in different ways and carry different
operational trade-offs.
Hybrid signature schemes enhance resilience during the adoption of
PQC by:
* Providing defense in depth: security is maintained as long as
either the PQC or traditional algorithm remains unbroken.
* Reducing exposure to unforeseen vulnerabilities: immediate
protection against weaknesses in PQC algorithms.
However, each approach comes with long-term implications.
Reddy, et al. Expires 17 April 2026 [Page 14]
Internet-Draft PQC Signature Migration Guidance October 2025
8.3. Composite Certificates
Composite certificate embeds both a traditional and a PQC algorithm
into a single certificate and signature. However, once a traditional
algorithm is no longer secure against CRQCs, it will have to be
deprecated. For discussion of the security impact in security
protocols, such as TLS and IKEv2, versus artifact-signing use cases,
see Section 8.5.
To complete the transition to a fully quantum-resistant
authentication model, operators will need a PQC CA root and CA
intermediates, resulting in PQC end-entity certificates.
Protocol configurations will likewise need to be updated to negotiate
only PQC-based authentication, ensuring that the entire certification
path and protocol handshake are cryptographically resistant to
quantum attacks and no longer depend on any traditional algorithms.
8.4. Dual Certificates
When CRQCs become available, the traditional certificate chain will
no longer provide secure authentication. At that point, relying
parties must stop accepting or requesting traditional certificate
chains and validate only PQC-based chains. Authenticated parties
will automatically cease using traditional chains once relying
parties no longer request them. Dual-certificate deployments
therefore defer, but do not avoid, the eventual migration to a PQC
environment.
8.5. Loss of Strong Unforgeability in Composite and Dual Certificates
A deployment may choose to continue using a composite or dual
certificate configuration even after a traditional algorithm has been
broken by the advent of a CRQC. While this may simplify operations
by avoiding re-provisioning of trust anchors, it introduces a
significant risk: security properties degrade once one component of
the hybrid is no longer secure.
In composite certificates, the composite signature will no longer
achieve Strong Unforgeability under chosen message attack (SUF-CMA)
(see Section 10.1.1 of [PQC-ENGINEERS] and Section 10.2 of
[I-D.ietf-lamps-pq-composite-sigs]). A CRQC can forge the broken
traditional signature component (s1_) over a message (m). That
forged component can then be combined with the valid post-quantum
component (s2) to produce a new composite signature (m, (s1_, s2))
that verifies successfully, thereby violating SUF-CMA.
Reddy, et al. Expires 17 April 2026 [Page 15]
Internet-Draft PQC Signature Migration Guidance October 2025
In dual certificate deployments where the client requires both a
traditional and a PQC chain, the SUF-CMA property is likewise not
achieved once the traditional algorithm is broken.
In protocols such as TLS and IKEv2, a composite signature remains
secure against impersonation as long as at least one component
algorithm remains unbroken, because verification succeeds only if
every component signature validates over the same canonical message
defined by the authentication procedure. However, in artifact
signing use cases, the break of a single component does not enable
forgery of a composite signature but does enable "repudiation":
multiple distinct composite signatures can exist for the same
artifact, undermining the "one signature, one artifact" guarantee.
This creates ambiguity about which composite signature is authentic,
complicating long-term non-repudiation guarantees.
Hybrid signature schemes should not be used for artifact signing
(such as software packages), since the loss of SUF-CMA makes them
unsuitable for long-term non-repudiation. In security protocols,
hybrid signature schemes may continue to function for a limited time
after a CRQC is realized, since they still provide impersonation
resistance as long as one component algorithm remains secure. This
situation does not constitute a zero-day vulnerability requiring an
immediate upgrade. However, operators will have to plan an orderly
migration to PQC certificates in order to restore SUF-CMA security
guarantees.
9. Migration Guidance
* Long-term to adopt and deploy:: Dual certificates have been
standardized in [RFC9763]. However, at the time of writing, none
of the security protocols (e.g., TLS, IKEv2, JOSE/COSE) have
adopted this mechanism. The proposals are being discussed in
IKEv2 ([I-D.hu-ipsecme-pqt-hybrid-auth]), TLS
([I-D.yusef-tls-pqt-dual-certs]), and in the form of paired
certificates with a single certificate
([I-D.bonnell-lamps-chameleon-certs]).
* Medium-term to adopt and deploy: Composite certificates become
viable once ecosystem support across PKIX, IPsec, JOSE/COSE, and
TLS is mature. Composite ML-DSA is already being standardized in
the LAMPS WG ([I-D.ietf-lamps-pq-composite-sigs]) and leveraged in
[I-D.reddy-tls-composite-mldsa] for TLS,
[I-D.hu-ipsecme-pqt-hybrid-auth] for IPsec/IKEv2, and
[I-D.prabel-jose-pq-composite-sigs] for JOSE/COSE.
* Long-to-medium term to adopt and deploy: PQC certificates are the
final goal, once PQ algorithms are well-established, trust anchors
have been updated, HSMs and devices support PQC operations, and
traditional algorithms are fully retired. Work to enable PQC
Reddy, et al. Expires 17 April 2026 [Page 16]
Internet-Draft PQC Signature Migration Guidance October 2025
signatures is already underway in JOSE/COSE
[I-D.ietf-cose-dilithium], TLS [I-D.ietf-tls-mldsa], and IPsec
[I-D.ietf-ipsecme-ikev2-pqc-auth].
10. Use of SLH-DSA in PQC-Only Deployments
SLH-DSA does not introduce any new hardness assumptions beyond those
inherent to its underlying hash functions. It builds upon
established cryptographic foundations, making it a reliable and
robust digital signature scheme for a post-quantum world. While
attacks on lattice-based schemes such as ML-DSA are currently
hypothetical, if realized they could compromise the security of those
schemes. SLH-DSA would remain unaffected by such attacks due to its
distinct mathematical foundations, helping to ensure the ongoing
security of systems and protocols that rely on it for digital
signatures. Unlike ML-DSA, SLH-DSA is not defined for use in
composite certificates and is intended to be deployed directly in PQC
certificate hierarchies.
SLH-DSA may be used for both end-entity and CA certificates. It
provides strong post-quantum security but produces larger signatures
than ML-DSA or traditional algorithms. At security levels 1, 3, and
5, two parameter sets are available:
* "Small" (s) variants minimize signature size, ranging from 7856
bytes (128-bit) to 29792 bytes (256-bit).
* "Fast" (f) variants optimize key generation and signing speed,
with signature sizes from 17088 bytes (128-bit) to 29792 bytes
(256-bit), but slower verification performance.
Because of these large signatures, SLH-DSA will increase handshake
size in protocols such as TLS 1.3 or IKEv2. However, the impact on
performance is minimal for long-lived connections or large data
transfers, where handshake overhead is amortized over session
duration (e.g., DTLS-in-SCTP in 3GPP N2 interfaces, or signature
authentication in IKEv2 using PQC [I-D.ietf-ipsecme-ikev2-pqc-auth]).
In deployments where minimizing handshake size is critical, operators
may prefer SLH-DSA for root and intermediate certificates while using
smaller- signature algorithms (e.g., ML-DSA) in end-entity
certificates or in the "CertificateVerify" message.
Reddy, et al. Expires 17 April 2026 [Page 17]
Internet-Draft PQC Signature Migration Guidance October 2025
Mechanisms such as Abridged TLS Certificate Chains
[I-D.ietf-tls-cert-abridge] and Suppressing CA Certificates
[I-D.kampanakis-tls-scas-latest] reduce handshake size by limiting
certificate exchange to only end-entity certificates. In such cases,
intermediate certificates are assumed to be known to the peer,
allowing the use of larger signature algorithms like SLH-DSA for
those certificates without adding overhead to the handshake.
11. Security Considerations
Hybrid signature schemes are designed to provide defense in depth
during the migration to PQC. Their goal is to ensure that
authentication remains secure as long as at least one of the
algorithms in use remains unbroken. However, several important
security considerations arise.
11.1. Downgrade Attacks
Implementations must ensure downgrade protection so that an adversary
cannot suppress PQC or hybrid schemes and force reliance solely on
traditional algorithms. This is especially important in scenarios
where a CRQC is available but not publicly disclosed. Without
downgrade protection, a MitM attacker could impersonate servers by
presenting only traditional certificates even when PQC or hybrid
certificates are supported by both peers.
Downgrade protection is critical throughout the migration period,
since relying parties may otherwise be tricked into accepting weaker
traditional authentication even when PQC or hybrid credentials exist.
In open environments (for example, the Web), there will likely be no
single "flag day" for post-quantum authentication. One possible
mitigation is the X.509 Post-Quantum/Composite Hosting Continuity
(PQCHC) extension [PQCHC], which allows a certificate subject to to
signal its intent to continue presenting PQC or composite credentials
for a configured continuity period beyond the certificate’s
"notAfter" date. Relying parties can use this information to detect
downgrade attempts and enforce continuity by rejecting traditional-
only certificates during that period.
Other mechanisms may complement this approach. For example, relying
parties could maintain and distribute curated lists of domains known
to use PQC-capable authentication, similar to mechanisms used by Safe
Browsing. Such mechanisms could automatically enforce downgrade
resistance for well-known, public domains. For other domains, the
relying party might simply cache that a server previously used a PQ
certificate.
Reddy, et al. Expires 17 April 2026 [Page 18]
Internet-Draft PQC Signature Migration Guidance October 2025
Together, these mechanisms help ensure that PQC-aware relying parties
maintain strong downgrade resistance where possible, while still
allowing interoperability with traditional-only authenticated parties
during the transition.
11.2. Strong Unforgeability versus Existential Unforgeability
In hybrid signature schemes, once one component algorithm is broken
(e.g., the traditional algorithm under a CRQC), the overall scheme no
longer achieves SUF-CMA. While Existential Unforgeability under
chosen message attack (EUF-CMA) (see Section 10.1.1 of
[I-D.ietf-pquip-pqc-engineers]) is still preserved by the PQC
component, meaning that an adversary who can obtain signatures on
arbitrary messages still cannot forge a valid PQC signature on any
new message that was not previously signed. The loss of SUF-CMA
means that hybrid mechanisms will have be eventually retired once
traditional algorithms are no longer secure.
11.3. Operational Risks
Managing multiple certificate paths (composite, dual, and PQC)
increases the risk of misconfiguration and operational errors. For
example, relying parties might continue to accept traditional-only
certificates after the traditional algorithms are broken, fail to
enforce PQC validation policies, or select an incorrect chain when
multiple options are available, resulting in validation of weaker
authentication than intended. Effective downgrade protection (see
Section 11.1) requires relying parties to reject traditional-only
certificate paths once post-quantum alternatives are available,
regardless of whether authenticated parties continue to support
traditional credentials for legacy interoperability.
Clear operational guidance and automated monitoring are essential to
minimize these risks. Operators need best practices for certificate
lifecycle and migration planning, along with automated checks to
ensure PQC chains remain present, valid, and not replaced by weaker
alternatives.
12. IANA Considerations
This document has no IANA actions.
13. Acknowledgments
Thanks to Martin McGrath, Suresh P. Nair, Eric Rescorla, and German
Peinado for the detailed review.
14. References
Reddy, et al. Expires 17 April 2026 [Page 19]
Internet-Draft PQC Signature Migration Guidance October 2025
14.1. Normative References
[COMPOSITE-ML-DSA]
Ounsworth, M., Gray, J., Pala, M., Klaußner, J., and S.
Fluhrer, "Composite ML-DSA for use in X.509 Public Key
Infrastructure", Work in Progress, Internet-Draft, draft-
ietf-lamps-pq-composite-sigs-12, 10 October 2025,
<https://datatracker.ietf.org/doc/html/draft-ietf-lamps-
pq-composite-sigs-12>.
[HYBRID-SPECTRUMS]
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>.
[I-D.ietf-cose-dilithium]
Prorock, M. and O. Steele, "ML-DSA for JOSE and COSE",
Work in Progress, Internet-Draft, draft-ietf-cose-
dilithium-09, 12 September 2025,
<https://datatracker.ietf.org/doc/html/draft-ietf-cose-
dilithium-09>.
[I-D.ietf-ipsecme-ikev2-pqc-auth]
Reddy.K, T., Smyslov, V., and S. Fluhrer, "Signature
Authentication in the Internet Key Exchange Version 2
(IKEv2) using PQC", Work in Progress, Internet-Draft,
draft-ietf-ipsecme-ikev2-pqc-auth-04, 5 October 2025,
<https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-
ikev2-pqc-auth-04>.
[I-D.ietf-lamps-pq-composite-sigs]
Ounsworth, M., Gray, J., Pala, M., Klaußner, J., and S.
Fluhrer, "Composite ML-DSA for use in X.509 Public Key
Infrastructure", Work in Progress, Internet-Draft, draft-
ietf-lamps-pq-composite-sigs-12, 10 October 2025,
<https://datatracker.ietf.org/doc/html/draft-ietf-lamps-
pq-composite-sigs-12>.
[I-D.ietf-pquip-pqc-hsm-constrained]
Reddy.K, T., Wing, D., S, B., and K. Kwiatkowski,
"Adapting Constrained Devices for Post-Quantum
Cryptography", Work in Progress, Internet-Draft, draft-
ietf-pquip-pqc-hsm-constrained-01, 4 July 2025,
<https://datatracker.ietf.org/doc/html/draft-ietf-pquip-
pqc-hsm-constrained-01>.
Reddy, et al. Expires 17 April 2026 [Page 20]
Internet-Draft PQC Signature Migration Guidance October 2025
[I-D.ietf-tls-mldsa]
Hollebeek, T., Schmieg, S., and B. Westerbaan, "Use of ML-
DSA in TLS 1.3", Work in Progress, Internet-Draft, draft-
ietf-tls-mldsa-01, 26 September 2025,
<https://datatracker.ietf.org/doc/html/draft-ietf-tls-
mldsa-01>.
[I-D.ietf-tls-trust-anchor-ids]
Beck, B., Benjamin, D., O'Brien, D., and K. Nekritz, "TLS
Trust Anchor Identifiers", Work in Progress, Internet-
Draft, draft-ietf-tls-trust-anchor-ids-02, 15 September
2025, <https://datatracker.ietf.org/doc/html/draft-ietf-
tls-trust-anchor-ids-02>.
[ML-DSA] Massimo, J., Kampanakis, P., Turner, S., and B.
Westerbaan, "Internet X.509 Public Key Infrastructure -
Algorithm Identifiers for the Module-Lattice-Based Digital
Signature Algorithm (ML-DSA)", Work in Progress, Internet-
Draft, draft-ietf-lamps-dilithium-certificates-13, 30
September 2025, <https://datatracker.ietf.org/doc/html/
draft-ietf-lamps-dilithium-certificates-13>.
[PQCHC] Reddy.K, T., Gray, J., and Y. Sheffer, "X.509 Extensions
for PQC or Composite Certificate Hosting Continuity", Work
in Progress, Internet-Draft, draft-reddy-lamps-x509-pq-
commit-00, 12 October 2025,
<https://datatracker.ietf.org/doc/html/draft-reddy-lamps-
x509-pq-commit-00>.
[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>.
[RFC9763] 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>.
Reddy, et al. Expires 17 April 2026 [Page 21]
Internet-Draft PQC Signature Migration Guidance October 2025
[SLH-DSA] Bashiri, K., Fluhrer, S., Gazdag, S., Van Geest, D., and
S. Kousidis, "Internet X.509 Public Key Infrastructure:
Algorithm Identifiers for SLH-DSA", Work in Progress,
Internet-Draft, draft-ietf-lamps-x509-slhdsa-09, 30 June
2025, <https://datatracker.ietf.org/doc/html/draft-ietf-
lamps-x509-slhdsa-09>.
14.2. Informative References
[ACME] Barnes, R., Hoffman-Andrews, J., McCarney, D., and J.
Kasten, "Automatic Certificate Management Environment
(ACME)", RFC 8555, DOI 10.17487/RFC8555, March 2019,
<https://www.rfc-editor.org/rfc/rfc8555>.
[CMP] Brockhaus, H., von Oheimb, D., Ounsworth, M., and J. Gray,
"Internet X.509 Public Key Infrastructure -- Certificate
Management Protocol (CMP)", RFC 9810,
DOI 10.17487/RFC9810, July 2025,
<https://www.rfc-editor.org/rfc/rfc9810>.
[DTLS] Rescorla, E., Tschofenig, H., and N. Modadugu, "The
Datagram Transport Layer Security (DTLS) Protocol Version
1.3", RFC 9147, DOI 10.17487/RFC9147, April 2022,
<https://www.rfc-editor.org/rfc/rfc9147>.
[I-D.bonnell-lamps-chameleon-certs]
Bonnell, C., Gray, J., Hook, D., Okubo, T., and M.
Ounsworth, "A Mechanism for Encoding Differences in Paired
Certificates", Work in Progress, Internet-Draft, draft-
bonnell-lamps-chameleon-certs-06, 16 April 2025,
<https://datatracker.ietf.org/doc/html/draft-bonnell-
lamps-chameleon-certs-06>.
[I-D.hu-ipsecme-pqt-hybrid-auth]
Hu, J., Morioka, Y., and G. WANG, "Post-Quantum
Traditional (PQ/T) Hybrid PKI Authentication in the
Internet Key Exchange Version 2 (IKEv2)", Work in
Progress, Internet-Draft, draft-hu-ipsecme-pqt-hybrid-
auth-02, 1 May 2025,
<https://datatracker.ietf.org/doc/html/draft-hu-ipsecme-
pqt-hybrid-auth-02>.
Reddy, et al. Expires 17 April 2026 [Page 22]
Internet-Draft PQC Signature Migration Guidance October 2025
[I-D.ietf-pquip-pqc-engineers]
Banerjee, A., Reddy.K, T., Schoinianakis, D., Hollebeek,
T., and M. Ounsworth, "Post-Quantum Cryptography for
Engineers", Work in Progress, Internet-Draft, draft-ietf-
pquip-pqc-engineers-14, 25 August 2025,
<https://datatracker.ietf.org/doc/html/draft-ietf-pquip-
pqc-engineers-14>.
[I-D.ietf-tls-cert-abridge]
Jackson, D., "Abridged Compression for WebPKI
Certificates", Work in Progress, Internet-Draft, draft-
ietf-tls-cert-abridge-02, 16 September 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-tls-
cert-abridge-02>.
[I-D.kampanakis-tls-scas-latest]
Kampanakis, P., Bytheway, C., Westerbaan, B., and M.
Thomson, "Suppressing CA Certificates in TLS 1.3", Work in
Progress, Internet-Draft, draft-kampanakis-tls-scas-
latest-03, 5 January 2023,
<https://datatracker.ietf.org/doc/html/draft-kampanakis-
tls-scas-latest-03>.
[I-D.prabel-jose-pq-composite-sigs]
Prabel, L., Shuzhou, S., Gray, J., and T. Reddy.K, "PQ/T
Hybrid Composite Signatures for JOSE and COSE", Work in
Progress, Internet-Draft, draft-prabel-jose-pq-composite-
sigs-04, 22 August 2025,
<https://datatracker.ietf.org/doc/html/draft-prabel-jose-
pq-composite-sigs-04>.
[I-D.reddy-tls-composite-mldsa]
Reddy.K, T., Hollebeek, T., Gray, J., and S. Fluhrer, "Use
of Composite ML-DSA in TLS 1.3", Work in Progress,
Internet-Draft, draft-reddy-tls-composite-mldsa-05, 4 July
2025, <https://datatracker.ietf.org/doc/html/draft-reddy-
tls-composite-mldsa-05>.
[I-D.yusef-tls-pqt-dual-certs]
Shekh-Yusef, R., Tschofenig, H., Ounsworth, M., Sheffer,
Y., Reddy.K, T., and Y. Rosomakho, "Post-Quantum
Traditional (PQ/T) Hybrid Authentication with Dual
Certificates in TLS 1.3", Work in Progress, Internet-
Draft, draft-yusef-tls-pqt-dual-certs-00, 18 June 2025,
<https://datatracker.ietf.org/doc/html/draft-yusef-tls-
pqt-dual-certs-00>.
Reddy, et al. Expires 17 April 2026 [Page 23]
Internet-Draft PQC Signature Migration Guidance October 2025
[IKEv2] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen,
"Internet Key Exchange Protocol Version 2 (IKEv2)",
RFC 5996, DOI 10.17487/RFC5996, September 2010,
<https://www.rfc-editor.org/rfc/rfc5996>.
[IKEv2-COMPOSITE-ML-DSA]
Hu, J., Morioka, Y., and G. WANG, "Post-Quantum
Traditional (PQ/T) Hybrid PKI Authentication in the
Internet Key Exchange Version 2 (IKEv2)", Work in
Progress, Internet-Draft, draft-hu-ipsecme-pqt-hybrid-
auth-02, 1 May 2025,
<https://datatracker.ietf.org/doc/html/draft-hu-ipsecme-
pqt-hybrid-auth-02>.
[JOSE-COSE-COMPOSITE-ML-DSA]
Prabel, L., Shuzhou, S., Gray, J., and T. Reddy.K, "PQ/T
Hybrid Composite Signatures for JOSE and COSE", Work in
Progress, Internet-Draft, draft-prabel-jose-pq-composite-
sigs-04, 22 August 2025,
<https://datatracker.ietf.org/doc/html/draft-prabel-jose-
pq-composite-sigs-04>.
[PQC-ENGINEERS]
Banerjee, A., Reddy.K, T., Schoinianakis, D., Hollebeek,
T., and M. Ounsworth, "Post-Quantum Cryptography for
Engineers", Work in Progress, Internet-Draft, draft-ietf-
pquip-pqc-engineers-14, 25 August 2025,
<https://datatracker.ietf.org/doc/html/draft-ietf-pquip-
pqc-engineers-14>.
[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>.
[TLS] "*** BROKEN REFERENCE ***".
[TLS-COMPOSITE-ML-DSA]
Reddy.K, T., Hollebeek, T., Gray, J., and S. Fluhrer, "Use
of Composite ML-DSA in TLS 1.3", Work in Progress,
Internet-Draft, draft-reddy-tls-composite-mldsa-05, 4 July
2025, <https://datatracker.ietf.org/doc/html/draft-reddy-
tls-composite-mldsa-05>.
Authors' Addresses
Reddy, et al. Expires 17 April 2026 [Page 24]
Internet-Draft PQC Signature Migration Guidance October 2025
Tirumaleswar Reddy
Nokia
Bangalore
Karnataka
India
Email: k.tirumaleswar_reddy@nokia.com
Dan Wing
Citrix
United States of America
Email: danwing@gmail.com
Yaroslav Rosomakho
Zscaler
Email: yrosomakho@zscaler.com
Reddy, et al. Expires 17 April 2026 [Page 25]