Requirements and Gaps for Post-Quantum Certificate Rotation in Multi-Tenant Public Key Infrastructure Environments

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

Table of Contents

1. Introduction

The publication of NIST FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), and FIPS 205 (SLH-DSA) in 2024 has initiated a global transition away from quantum-vulnerable cryptographic algorithms toward post-quantum alternatives. For organizations operating certificate authority (CA) infrastructure, this transition requires replacing classical key exchange and signature algorithms across all issued certificates, OCSP responders, CRL signing keys, and TLS endpoints before applicable regulatory deadlines.¶

The NSA Commercial National Security Algorithm Suite 2.0 (CNSA 2.0) [CNSA20] establishes concrete migration deadlines: PQC algorithms are required for software and firmware signing by 2027, for TLS and certificate infrastructure by 2029, and classical algorithm use is to be retired by 2033.¶

Multi-tenant PKI deployments — where a single CA platform issues certificates for multiple independent organizational tenants with isolated trust anchors and policy domains — present unique coordination challenges not addressed by existing IETF protocols. This document describes those challenges and derives functional requirements for a compliant solution.¶

2. Problem Statement

Existing PKI management protocols — including the Automatic Certificate Management Environment (ACME) [RFC8555], Certificate Management over CMS (CMC) [RFC5272], and the base X.509 profile [RFC5280] — were designed for single-tenant or hierarchically-managed CA environments. They do not specify:¶

• Mechanisms to detect and report algorithm configuration divergence between the CA policy and the algorithms in use across active tenant certificate populations (configuration drift).¶
• Procedures to ensure that a certificate issuance transaction maintains semantic consistency with the issuing tenant's declared cryptographic policy at the time of issuance.¶
• Protocols for coordinating the sequencing of certificate rotation actions across tenants in a manner that accounts for network topology and service dependency constraints.¶
• Audit mechanisms that provide tenant-isolated, per-transaction evidence of algorithm compliance at issuance time.¶

Without addressing these gaps, a multi-tenant PKI operator has no standardized mechanism to guarantee that all tenants have completed PQC migration in a coordinated, consistent, and auditable manner before regulatory deadlines.¶

3. Terminology

Multi-Tenant PKI:

A PKI deployment in which a single platform instance hosts certificate authority services for multiple independent organizational tenants, each with isolated certificate policies, trust anchors, and subscriber populations.¶

PQC Migration:

The process of replacing quantum-vulnerable cryptographic algorithms (e.g., RSA, ECDSA, ECDH) with post-quantum cryptographic algorithms standardized by NIST (e.g., ML-KEM, ML-DSA, SLH-DSA).¶

Configuration Drift:

A condition in which the cryptographic algorithm configuration of one or more active certificates or CA components diverges from the declared cryptographic policy of the tenant or platform operator.¶

Hybrid Transitional Configuration:

A cryptographic configuration that combines classical and post-quantum algorithms (e.g., X25519 with ML-KEM-768, ECDSA-P256 with ML-DSA-65) as defined in [RFC9794].¶

CRQC:

Cryptographically Relevant Quantum Computer. A quantum computer capable of running Shor's algorithm at sufficient scale to break RSA-2048 and ECDH-P256 in practical time.¶

4. Scope and Limitations of Existing Standards

5. Functional Requirements

A solution addressing the gaps identified in Section 4 SHOULD satisfy the following functional requirements:¶

6. IPR Considerations

The author may hold or apply for patents covering subject matter related to this document. Disclosure of any such patents will be made in accordance with the procedures defined in BCP 79. Publication of this Internet-Draft does not constitute any patent license, express or implied, from the author. License terms, if any, are not yet known.¶

This work product is the original work of the named author and is offered to the IETF community as an Independent Submission. No portion of this document is offered as proprietary or confidential. All technical disclosures herein are intended as public contributions to the IETF standards process and constitute public prior art as of the publication date of the initial -00 revision.¶

7. Security Considerations

The primary threat model motivating this document is the harvest-now, decrypt-later (HNDL) attack, in which an adversary captures ciphertext protected by quantum-vulnerable algorithms today with the intention of decrypting it once a CRQC becomes available. Long-lived certificates and CA signing keys that remain in use beyond the anticipated CRQC arrival window are particularly exposed.¶

Mosca's inequality [MOSCA] provides a practical framework for urgency assessment: if the sum of the time required to complete PQC migration and the remaining confidentiality lifetime of sensitive data exceeds the estimated time to CRQC availability, then migration is overdue. A multi-tenant PKI environment amplifies this risk because a single unrotated CA signing key may protect the entire trust anchor for multiple tenants.¶

Any mechanism that gates certificate issuance based on policy compliance introduces a denial-of-service vector: a misconfigured or overly restrictive policy could block legitimate certificate issuance. Implementations MUST provide auditable override mechanisms and alerting to prevent silent issuance failures.¶

Multi-tenant isolation MUST be preserved at the algorithm policy layer: a drift condition in one tenant MUST NOT trigger issuance blocks in other tenants.¶

8. IANA Considerations

This document has no IANA actions. Future work specifying protocol extensions to address the requirements in Section 5 may require IANA registration of new ACME extensions, X.509 extensions, or CMS attributes.¶

Author's Address