]> Sanctum SecOps LLC

Pine CityNYUnited States of America bvicente@sanctumsecops.com https://orcid.org/0009-0006-6395-5308

Security Post-Quantum Use In Protocols post-quantum PKI multi-tenant certificate rotation PQC readiness algorithm agility 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. 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/. Source maintained at https://github.com/Sanc-Admin/pquip-multitenant-pki-requirements. Author ORCID iD: https://orcid.org/0009-0006-6395-5308. 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.

Introduction

Background 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 (ML-DSA) and FIPS 205 (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.

Scope and Differentiation This document addresses multi-tenant PKI coordination requirements. It does not define: the PQC certificate format (see , , and LAMPS WG work); the composite-signature format (see draft-ietf-lamps-pq-composite-sigs); or the certificate rotation protocol mechanics (see ACME ). It defines the requirements that a multi-tenant PKI platform and its ACME-compatible CA must satisfy during PQC migration.

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 .

Multi-Tenant PKI Platform:

A PKI platform that issues and manages certificates for multiple distinct tenant organizations using shared infrastructure.

Tenant:

An organization that consumes certificate issuance services from a Multi-Tenant PKI Platform under a distinct administrative domain.

Tenant Migration State:

The per-tenant record of PQC migration progress, including which certificate profiles have been migrated, which remain classical, and any tenant-specific compliance deadline.

Platform Migration Epoch:

A platform-defined time window during which PQC migration is executed for a cohort of tenants.

Algorithm-Agility Horizon:

The date by which a tenant's certificate profile must be migrated to a NIST-approved PQC algorithm to remain compliant with the platform's migration policy.

Requirements

Tenant Isolation Requirements 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.

Platform Coordination Requirements 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.

Interoperability Requirements REQ-MT-7: ACME Protocol Compatibility. The platform's certificate rotation mechanism MUST be compatible with ACME 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.

Security Considerations

Tenant Isolation Failure 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.

Algorithm-Agility Horizon Enforcement 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.

IANA Considerations This document has no IANA actions.

NIST NIST

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.