| Internet-Draft | Multi-Tenant PKI PQC Requirements | June 2026 |
| Vicente | Expires 7 December 2026 | [Page] |
Organizations operating Public Key Infrastructure (PKI) across multiple isolated tenant environments face a critical gap: existing PKI management protocols and standards do not address the coordination requirements for post-quantum cryptographic (PQC) algorithm migration in shared, multi-tenant certificate authority deployments. This document identifies the functional requirements and open protocol gaps that must be addressed to enable safe, consistent, and auditable PQC certificate rotation across multi-tenant PKI environments. No new protocol mechanisms are specified; this is an informational requirements document intended to motivate future standards work.¶
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 7 December 2026.¶
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.¶
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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals.¶
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.¶
ACME [RFC8555] automates the issuance, renewal, and revocation of certificates by specifying challenge-response domain ownership verification. ACME does not specify:¶
[RFC5280] defines the X.509 certificate and CRL profile. It specifies certificate structure and validation, but does not address:¶
[RFC7696] 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:¶
[RFC9763] 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.¶
[RFC9794] 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 [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.¶
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.¶