]> Sanctum SecOps LLC

128 Dry Run Rd Pine City NY 14871 United 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. 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. Certain technology described in this document is covered or may be covered by pending United States patent applications owned by Sanctum SecOps LLC, including U.S. Application Nos. 64/080,137 and 19/698,870. Brian Vicente is the inventor. Patent pending. Sanctum SecOps LLC is prepared to grant to all implementers, under a separate written agreement, a non-exclusive, worldwide license on reasonable and non-discriminatory terms that may include reasonable fees or royalties, under Necessary Patent Claims owned or controlled by Sanctum SecOps LLC. "Necessary Patent Claims" means claims subject to the applicable IETF disclosure that would necessarily be infringed by implementing technology required by this specification and for which no technically and commercially feasible non-infringing alternative is available. The license applies only to the compliant portion of a product or service implementing required technology. It does not extend to optional features, proprietary enhancements, noncompliant implementations, methods not required by the specification, unrelated Sanctum SecOps LLC products, hosted control planes, managed services, trade secrets or claims that are not Necessary Patent Claims. Licensing may be conditioned on reciprocal licensing on reasonable and non-discriminatory terms for necessary claims owned or controlled by the licensee. Sanctum SecOps LLC reserves defensive suspension and available remedies if the licensee or an affiliate asserts patents against Sanctum SecOps LLC, its affiliates, licensees, customers, compliant products or compliant services, except for a defensive claim compelled by a prior assertion. Nothing in this document admits or warrants issuance, validity, enforceability, infringement, essentiality, claim scope, absence of alternatives or freedom to operate. No patent license arises merely from publication of this specification. The controlling IETF Datatracker IPR disclosures remain authoritative.

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.

Implementation Status This section records the status of known implementations of the mechanisms described in this document at the time of posting, based on the proposal in . A listing here does not imply endorsement by the IETF, and this section is expected to be removed by the RFC Editor before publication.

Implementation:

CygnetSSL certification authority driver, Sanctum SecOps LLC.

Description:

Certificate issuance, revocation, chain and profile verification, CRL generation and publication, and OCSP status responses, built on OpenSSL 3 with the FIPS provider active.

Maturity:

Operated on a single administrator-managed estate. No interoperability testing against independent implementations has been performed.

Licensing:

Proprietary; source not publicly available.

Contact:

bvicente@sanctumsecops.com

Observations recorded on 2026-09-12 on that implementation: the OpenSSL base, default and FIPS providers were active with the kernel FIPS indicator set; 22 end-entity certificates were issued and verified across two profiles; all certificates used ECDSA on P-384 with ecdsa-with-SHA384 signatures and carried non-sequential 20-octet serial numbers drawn from a CSPRNG; the certificate revocation list was published in DER form at the URI named in the CRL distribution points extension; and a newly issued certificate returned an OCSP status of "good" and, following revocation with reason cessationOfOperation, returned "revoked" with a matching revocation time.

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.

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