PQC Certificate Rotation Requirements for Multi-Tenant PKI Environments

Internet-Draft	Multitenant PKI PQC Requirements	September 2026
Vicente	Expires 17 March 2027	[Page]

Abstract

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

IPR Considerations

This note is to be removed before publishing as an RFC.¶

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

Status of This Memo

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 17 March 2027.¶

Copyright Notice

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

1. Introduction

1.1. 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 [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.¶

1.2. Scope and Differentiation

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

2. 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 [RFC2119] [RFC8174].¶

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

3. Requirements

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

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

3.3. Interoperability Requirements

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

4. 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 [RFC7942]. 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.¶

5. Security Considerations

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

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

Appendix A. Acknowledgements

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

PQC Certificate Rotation Requirements for Multi-Tenant PKI Environments

Abstract

Supplementary Materials

Source and Archival