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

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

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 when, and only when, they appear in all capitals.

Existing PKI management protocols — including the Automatic Certificate Management Environment (ACME) , Certificate Management over CMS (CMC) , and the base X.509 profile — 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.

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

ACME automates the issuance, renewal, and revocation of certificates by specifying challenge-response domain ownership verification. ACME does not specify: Enforcement of algorithm policy at the per-issuance-transaction level. Detection of divergence between a certificate's algorithm and the issuing CA's current declared policy. Coordination protocols for rotating certificates across multiple tenants in dependency order.

defines the X.509 certificate and CRL profile. It specifies certificate structure and validation, but does not address: Real-time detection of certificates whose algorithms are inconsistent with a CA's current policy. Mechanisms to gate certificate issuance based on a policy-compliance precondition.

provides guidelines for implementing algorithm agility in IETF protocols — specifically, the ability to select and negotiate cryptographic algorithms without hard-coded dependencies. It does not specify: How a CA system should enforce algorithm agility requirements uniformly across all tenants in a multi-tenant deployment. How consistency of algorithm selections across a distributed certificate population should be monitored or enforced.

defines the RelatedCertificate X.509 extension, which allows two certificates with different algorithms to be cryptographically linked. This supports dual-algorithm operation during PQC transition but does not address the coordination and scheduling concerns identified in this document.

establishes terminology for post-quantum and traditional hybrid cryptographic schemes. This document uses that terminology but addresses a separate problem: the operational management gap in migrating multi-tenant PKI systems to PQC.

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

REQ-1: The system MUST be capable of detecting, for each active certificate in a tenant's issued certificate population, whether the certificate's algorithms are consistent with the tenant's current cryptographic policy. REQ-2: The system MUST provide a per-tenant view of algorithm consistency across the entire active certificate population.

REQ-3: The system SHOULD support a mechanism by which a certificate issuance request can be evaluated for compliance with the issuing tenant's current algorithm policy before the certificate is issued. REQ-4: The system SHOULD maintain per-issuance-transaction audit records sufficient to demonstrate that each issued certificate was algorithm-compliant at the time of issuance.

REQ-5: The system MUST provide a mechanism for ordering certificate rotation actions across a multi-tenant environment to avoid service disruption caused by rotating certificates in an order that violates trust chain or service dependency constraints. REQ-6: The system SHOULD support awareness of the network topology context in which certificates are deployed to inform the sequencing of rotation operations.

REQ-7: The system MUST support mapping of each tenant's algorithm posture against applicable compliance deadline frameworks (e.g., CNSA 2.0) and provide gap reports identifying certificates and CA components that require migration before specific deadlines. REQ-8: The system SHOULD provide aggregate and per-tenant compliance progress metrics suitable for regulatory reporting.

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

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.