| Internet-Draft | Multitenant PKI PQC Requirements | September 2026 |
| Vicente | Expires 15 March 2027 | [Page] |
This document specifies requirements for post-quantum cryptography (PQC) certificate rotation in multi-tenant public key infrastructure (PKI) environments. Multi-tenant PKI deployments — in which a single PKI platform issues and manages certificates for multiple distinct tenant organizations — face coordination challenges that single-tenant PKI deployments do not encounter during PQC migration.¶
This revision (-03) adds a unified Posture B IPR notice, a section noting awareness of the existing IPR disclosure on record for this draft (IPR: 1 on Datatracker), and machine-readable JSON evidence. Readers MUST consult the IETF Datatracker IPR tab for this document for all current IPR disclosure status.¶
This note is to be removed before publishing as an RFC.¶
Reference implementation: CygnetLib
(https://github.com/sanctumsecopsmssp/CygnetLib).
JSON evidence: algorithm registry, CNSA 2.0 compliance matrix, IETF PQC
interoperability status, and ACTV test vectors are in the
evidence/ directory.
CAGE/NCAGE: 20XS3. Apex website:
https://www.sanctumsecops.com/.¶
This note is to be removed before publishing as an RFC.¶
Source maintained at https://github.com/Sanc-Admin/pquip-multitenant-pki-requirements. Author ORCID iD: https://orcid.org/0009-0006-6395-5308.¶
This note is to be removed before publishing as an RFC.¶
Sanctum IP Co (a Delaware corporation, assignee of Sanctum SecOps LLC) holds or intends to file patent or other intellectual property rights covering subject matter described in this document, including the multi-tenant certificate rotation coordination mechanism, the tenant-isolation requirements during PQC migration, and the phased-rollout sequencing model. The public disclosure of this Internet-Draft constitutes prior art as of its submission date with respect to the specific combination of features described herein. By posting this Internet-Draft, the author submits to the IETF Trust the rights described in BCP 78 and BCP 79. Implementers MUST consult the IETF Datatracker IPR page for this document before implementation.¶
Note: As of the date of this revision, at least one IPR disclosure (IPR: 1) has been filed against this draft on the IETF Datatracker. Readers are directed to review that disclosure at https://datatracker.ietf.org/doc/draft-vicente-pquip-multitenant-pki-requirements/ (IPR tab) before implementing any aspect of this specification.¶
All intellectual property described in this document is owned by Sanctum IP Co, 128 Dry Run Rd, Pine City, NY 14871. Contact: bvicente@sanctumsecops.com.¶
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 15 March 2027.¶
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. 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.¶
The transition to post-quantum cryptography requires PKI operators to replace classical (RSA, ECDSA) certificates with PQC certificates across their entire issuing hierarchy. In single-tenant PKI deployments, this transition is coordinated by a single organizational policy owner. In multi-tenant PKI deployments, the transition must be coordinated across multiple tenant organizations, each of which may have distinct: (a) contractual terms governing certificate issuance, (b) application stacks with varying PQC algorithm support, (c) compliance deadlines imposed by sector-specific regulators, and (d) revocation and renewal SLAs.¶
NIST FIPS 204 [FIPS204] (ML-DSA) and FIPS 205 [FIPS205] (SLH-DSA) define the primary PQC signature algorithms to which PKI platforms must migrate. This document defines requirements that a multi-tenant PKI platform MUST satisfy to support orderly, tenant-isolated PQC certificate rotation.¶
This document addresses multi-tenant PKI coordination requirements. It does not define: the PQC certificate format (see [FIPS204], [FIPS205], and LAMPS WG work); the composite-signature format (see draft-ietf-lamps-pq-composite-sigs); or the certificate rotation protocol mechanics (see ACME [RFC8555]). It defines the requirements that a multi-tenant PKI platform and its ACME-compatible CA must satisfy during PQC migration.¶
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].¶
REQ-MT-1: Tenant Migration State Isolation. The platform MUST maintain Tenant Migration State independently for each tenant. The migration state of one tenant MUST NOT affect the certificate issuance or validation service for any other tenant during the migration period.¶
REQ-MT-2: Tenant-Specific Algorithm-Agility Horizon. The platform MUST support configuring a distinct Algorithm-Agility Horizon per tenant. A tenant with an earlier regulatory compliance deadline MUST be migrable to PQC independently of tenants with later deadlines.¶
REQ-MT-3: Classical Fallback for Non-Migrated Tenants. During the Platform Migration Epoch, the platform MUST continue to issue classical (RSA/ECDSA) certificates for tenants that have not yet completed PQC migration without requiring those tenants to accept PQC certificates before their Algorithm-Agility Horizon.¶
REQ-MT-4: Phased Rollout Sequencing. The platform SHOULD support a phased rollout model in which tenants are migrated in sequenced cohorts, with each cohort validated before the next cohort begins migration. The sequencing policy MUST be documented and made available to tenants.¶
REQ-MT-5: Per-Tenant Migration Notification. The platform MUST notify each tenant of its scheduled Platform Migration Epoch and Algorithm-Agility Horizon at least 90 days before the epoch begins, via a machine-readable notification mechanism (e.g., ACME Directory metadata or a platform API endpoint).¶
REQ-MT-6: Cross-Tenant Revocation Isolation. An emergency revocation of certificates in one tenant's domain due to a PQC migration failure MUST NOT trigger revocation of certificates in other tenants' domains, even if those certificates were issued by the same intermediate CA.¶
REQ-MT-7: ACME Protocol Compatibility. The platform's certificate rotation mechanism MUST be compatible with ACME [RFC8555] as the primary automated certificate rotation protocol. PQC certificate issuance MUST be accessible via ACME without requiring proprietary extensions that break ACME client compatibility.¶
REQ-MT-8: Dual-Mode Issuance During Transition. During the Platform Migration Epoch, the platform MUST support issuing both classical and PQC certificates to different tenants simultaneously. The platform MUST NOT require a flag-day cutover that forces all tenants to migrate simultaneously.¶
REQ-MT-9: Machine-Readable Migration Metadata. The platform MUST expose per-tenant migration state via a machine-readable metadata endpoint (e.g., JSON API or ACME Directory extension) that tenant systems can poll to determine their current migration status and upcoming Algorithm-Agility Horizon.¶
Failure to maintain Tenant Migration State isolation (REQ-MT-1) can cause a PQC migration failure in one tenant to cascade to other tenants via shared intermediate CA state. Platform implementations MUST use separate intermediate CA contexts per tenant or enforce strict logical isolation at the issuance policy layer.¶
The Algorithm-Agility Horizon (REQ-MT-2) is only effective if the platform enforces it. Platforms MUST implement automated enforcement that prevents issuance of classical certificates to tenants that have passed their Algorithm-Agility Horizon, except in documented emergency override scenarios with explicit audit logging.¶
This document has no IANA actions.¶
The author thanks Mike Ounsworth (Entrust) for valuable feedback on draft structure and boilerplate compliance, and the IETF PQUIP, LAMPS, and OAuth working groups for their ongoing work on post-quantum cryptography standardization.¶
CygnetLib (https://github.com/sanctumsecopsmssp/CygnetLib)
serves as the reference implementation for algorithms described in this
document. JSON evidence files including the algorithm registry, CNSA 2.0
compliance matrix, IETF PQC interoperability status, and ACTV test
vector results are available in the
evidence/ directory of the CygnetLib repository.¶