]> Sanctum SecOps LLC

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

Security Limited Additional Mechanisms for PKIX and SMIME post-quantum cryptography X.509 certificate extension CA continuity rotation envelope issuance manifest hybrid cryptography migration This document defines the X.509 Post-Quantum Rotation Envelope extension, a Certification Authority (CA) side commitment mechanism that allows an issuing CA to publish, sign, and bind to its issued certificates a machine-verifiable guarantee of post-quantum (PQ) or PQ/T hybrid issuance continuity across the CA's own key-rotation boundaries. The mechanism is complementary to, and does not overlap with, subject-side commitments such as the continuityPeriod field defined in : where that draft captures the CA's continuity obligation to continue presenting PQ or composite certificates after the current certificate's notAfter, this document captures the issuing CA's parallel obligation to remain capable of issuing such certificates across its own root and intermediate key rotations during the same migration window. The Rotation Envelope extension carries a SHA-384 hash of a CA-published, signed JSON manifest hosted at a stable /.well-known/pki-rotation-envelope URI under the issuer's authorityInfoAccess host. The manifest enumerates: (a) the algorithm identifiers the CA commits to continue supporting for issuance through a stated envelopeNotAfter date, (b) the successor-CA SubjectPublicKey hashes already provisioned for the next CA key generation, and (c) the OCSP and CRL distribution endpoints that will remain authoritative through the envelope window. Relying parties that understand the extension can verify, at any time during the current certificate's lifetime, that the CA's published continuity posture matches what was bound at issuance, detecting silent CA-side degradation, unannounced CA replacement, or rollback of PQ-capable issuance commitments. This document is filed independently and is intended to be considered alongside, not in place of, . The two mechanisms address orthogonal sides of the same PQ migration window: subject-side declaration of intent (Reddy et al.) and CA-side guarantee of issuance capability (this document). 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 for this draft is maintained at https://github.com/Sanc-Admin/lamps-pqchc (repository to be renamed to lamps-rotation-envelope in a subsequent maintenance cycle; the existing repository continues to host the canonical source until that rename completes). A citable archival version of this document is available at Zenodo: https://doi.org/10.5281/zenodo.20584243. Author ORCID iD: https://orcid.org/0009-0006-6395-5308. Discussion of this document occurs on the IETF "spasm" (LAMPS) mailing list (spasm@ietf.org). Issues and pull requests may be filed at the GitHub repository linked above. Sanctum IP Co (a Delaware corporation, assignee of Sanctum SecOps LLC) has filed or intends to file United States patent applications covering subject matter described in this document. By posting this Internet-Draft, the author submits to the IETF Trust the rights described in Section 5 of BCP 78 and BCP 79. Patent licensing terms are not yet known. Implementers and reviewers should consult the IETF Datatracker IPR disclosure page for this document for current disclosure status. 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 document is intentionally orthogonal to . The Reddy et al. draft places a subject-side continuityPeriod declaration in end-entity certificates, declaring the subject's intent to continue presenting PQ or composite certificates after notAfter. This document places a CA-side Rotation Envelope extension in CA-issued certificates, binding a hash of a CA-published, signed manifest of issuance-continuity commitments across the CA's own key rotations. The two mechanisms answer different questions:

• draft-reddy answers "Will the subject still present a PQ certificate next time?"
• This document answers "Will the issuing CA still be capable of, and committed to, signing a PQ certificate at the next renewal?"

Introduction The standardization of post-quantum cryptographic (PQC) algorithms by the National Institute of Standards and Technology (NIST) — specifically ML-DSA , ML-KEM , and SLH-DSA — marks an inflection point for Internet PKI. NIST IR 8547 establishes that all quantum-vulnerable traditional asymmetric algorithms are to be deprecated after 2030 and disallowed for new protection after 2035. The CNSA 2.0 suite requires National Security Systems to be fully compliant by 2031. Operators of long-lived PKI infrastructure must therefore plan and execute algorithm migrations across a multi-year window that spans certificate lifetimes currently in service. ML-DSA and ML-KEM are founded on the hardness of Module Learning With Errors (MLWE) and Module Short Integer Solution (MSIS) problems over polynomial rings — lattice-based problems for which no efficient quantum algorithm is known. SLH-DSA is founded on the collision resistance of cryptographic hash functions, providing security even against adversaries with quantum computers running Grover's algorithm , subject to the hash length requirements discussed in . The LAMPS Working Group has made substantial progress in defining how PQ and PQ/T hybrid algorithms are encoded in X.509 certificates. Composite ML-DSA defines 18 composite signature algorithm identifiers; Composite ML-KEM defines 12 composite KEM identifiers. RFC 9763 allows a current traditional certificate and a current PQ certificate to be bound to the same subject. The certificate discovery mechanism enables a primary certificate to point to a secondary certificate already issued. Despite this progress, a specific lifecycle gap remains unaddressed: no existing mechanism allows a certificate holder to make a cryptographically verifiable commitment, in the current certificate, to the specific PQ key material that will appear in the successor certificate. provides a continuityPeriod field that declares, in days, the subject's intent to continue presenting PQC or composite certificates after the current certificate's notAfter. This is a valuable declaration of temporal intent, but it does not bind that intent to any specific future key. A relying party that caches this declaration cannot determine whether the key in a future renewal certificate matches what was actually intended at the time of issuance — nor can it detect a key substitution by an adversary. This document addresses that gap by defining a Rotation Envelope extension that:

1. Carries a cryptographic hash of the future SubjectPublicKeyInfo (SPKI) in a EnvelopeManifestReference structure, binding the commitment to specific key material.
2. Encodes the intended envelope committed algorithm-set identifier alongside the hash, enabling relying parties to assess algorithm support without awaiting the next-generation CA-signed successor certificate.
3. Declares a envelopeNotAfter time after which the commitment is considered expired and MUST NOT be enforced.
4. Provides an optional manifestURI where operators may publish human-readable migration commitments and supporting documentation.
5. Remains non-critical per RFC 5280 Section 4.2, so legacy relying parties that do not recognize the extension will ignore it, preserving backward compatibility throughout the migration window.

The Rotation Envelope extension is advisory and non-authoritative. The extension does not modify RFC 5280 path validation semantics. Enforcement of the commitment is left to envelope-aware application software, certificate policy, and relying-party trust decisions.

Relationship to Existing Work The design of Rotation Envelope is informed by several related efforts: draft-reddy-lamps-x509-pq-commit : The closest direct predecessor. That document defines a continuityPeriod integer expressing the number of days beyond notAfter during which the subject intends to continue presenting PQC or composite certificates. Rotation Envelope addresses the explicit gap noted in that draft: the absence of any cryptographic binding to a specific future key. draft-ounsworth-lamps-pq-external-pubkeys : This expired individual submission references a current external public key by hash. Rotation Envelope extends the same hash-of-SPKI principle into the forward-commitment dimension: rather than referencing a key that exists today, the Rotation Envelope commitment references a key that is intended for use in the future next-generation CA-signed successor certificate. RFC 9763 : Binds a current traditional certificate and a current PQ certificate to the same subject identity. RFC 9763 addresses horizontal binding between coexisting certificates; Rotation Envelope addresses vertical, forward binding between a current certificate and its future successor. draft-ietf-lamps-certdiscovery : Points to a secondary certificate via hash and URI. The secondary certificate must already exist. Rotation Envelope targets the prior period before the next-generation CA-signed successor certificate has been issued. Composite ML-DSA and Composite ML-KEM : Define how composite keys are encoded in current X.509 structures. They contain no commitment mechanism, no downgrade signaling, and no lifecycle integration. Rotation Envelope is complementary: it can commit to either a pure ML-DSA/ML-KEM key or a composite key as the intended successor. RFC 9773 (ACME ARI) : Defines the ACME Renewal Information extension, including renewalInfo, suggestedWindow, and the replaces field. Section 5.4 of this document describes how a envelope-bearing certificate can be integrated with ARI to schedule commitment-aware renewals before the envelopeNotAfter deadline.

Patent Notice The authors are not aware of any patent or patent application that covers the mechanisms described in this document. This notice is provided pursuant to IETF BCPs on intellectual property.

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 when, and only when, they appear in all capitals, as shown here. The following terms are used throughout this document. Terms defined in RFC 9794 ("PQ/T Hybrid terminology") are used in accordance with the definitions therein. Envelope Committed Algorithm Set: The post-quantum or PQ/T hybrid algorithm that the issuing CA declares it intends to use in the next-generation CA-signed successor certificate, identified by an AlgorithmIdentifier in the Rotation Envelope extension. Envelope Manifest Hash: A cryptographic hash computed over the DER encoding of the intended future SubjectPublicKeyInfo, bound in the EnvelopeManifestReference structure of the Rotation Envelope extension. The hash serves as a pre-commitment to specific future key material. Commitment Validity Time (envelopeNotAfter): The GeneralizedTime value in the Rotation Envelope extension beyond which the commitment is considered expired. A envelope-aware relying party MUST NOT enforce downgrade detection semantics after this time has passed. EnvelopeManifestReference: The ASN.1 structure within the Rotation Envelope extension that carries the hash algorithm identifier, the Envelope Manifest Hash, and an optional algorithm hint for the future key. Issuance-Time Policy Binding: The property that the Envelope Manifest Hash is embedded in the certificate at issuance and signed by the issuing CA, making the commitment part of the CA-signed certificate content. The CA's signature over the Rotation Envelope extension binds the commitment to the issuing CA and the issuance time. CRQC: A cryptographically relevant quantum computer — one with sufficient qubit depth and fidelity to threaten the security of classical asymmetric algorithms such as RSA, ECDSA, and ECDH. HNDL / TNFL: Harvest-Now-Decrypt-Later (HNDL) or Transcript-Now-Forge-Later (TNFL): a threat model in which an adversary records classical-algorithm-protected traffic today and decrypts or forges it once a CRQC becomes available. SPKI: SubjectPublicKeyInfo — the ASN.1 structure defined in RFC 5280 that encodes a subject's public key and its associated algorithm identifier. Successor Certificate: The certificate issued to renew or replace the current certificate. The Rotation Envelope extension commits to the SPKI that is intended to appear in the next-generation CA-signed successor certificate.

Problem Statement

The Harvest-Now-Decrypt-Later and Transcript-Now-Forge-Later Threats Adversaries with sufficient resources are believed to be collecting encrypted data and signed records today under the expectation that a CRQC will eventually be available to break the underlying classical algorithms. For long-lived secrets, key establishment material, and non-repudiation records, this "harvest" phase has effectively already begun. NIST IR 8547 projects a 2035 hard cutoff for applying new cryptographic protection using quantum-vulnerable algorithms. The specific threat to PKI arises from two quantum algorithms. Shor's algorithm solves the Integer Factorization Problem (IFP) and the Elliptic Curve Discrete Logarithm Problem (ECDLP) in polynomial quantum time, directly breaking the security of RSA (whose security rests on IFP) and ECDSA/ECDH (whose security rests on ECDLP). A certificate whose public key uses RSA-2048, P-256, or any elliptic curve group of equivalent classical security is rendered completely insecure by a sufficiently capable CRQC running Shor's algorithm. Grover's algorithm provides a quadratic speedup for unstructured search, effectively halving the bit-security of symmetric keys and hash functions; this motivates the SHA-384/SHA-512 requirements in Section 4 and Section 6.2 of this document. The urgency of PQ migration is further quantified by Mosca's inequality : if the sum of (1) the time remaining until a CRQC is available and (2) the secrecy lifetime required for data protected today exceeds the time available to complete a migration, then migration should be treated as overdue. For long-lived PKI root certificates with 25-year validity periods, Mosca's inequality implies that migration cannot be safely deferred even if a CRQC is not expected for a decade or more. The Rotation Envelope extension directly addresses the migration phase that Mosca's inequality makes urgent: providing a machine-verifiable, cryptographically bound mechanism for orderly per-certificate PQ transition. The HNDL and TNFL threat models share a common implication for PKI: the window between when a classical key is first used and when a CRQC breaks it is the exposure window. Narrowing this window requires early, orderly migration to PQ algorithms — a process that spans multiple certificate issuance cycles.

The Multi-Year Migration Window A typical TLS end-entity certificate has a validity period of 90 days to two years. A root CA certificate may have a validity period of 25 years. The multi-year migration window created by NIST IR 8547 timelines means that multiple successive certificate issuance events must each move incrementally toward a fully PQ or PQ/T hybrid PKI. During this window, the same domain or service will present different certificates at successive renewal events — some classical, some composite, and eventually some fully PQ. This creates the downgrade-at-renewal gap: an adversary who can present a forged or substitute classical certificate at the moment of renewal, preventing the PQ or composite certificate from being issued or accepted, gains access to encrypted traffic for the lifetime of that substitute certificate.

The Downgrade-at-Renewal Gap Downgrade attacks during the migration window take the following form:

1. The current certificate is about to expire or be renewed.
2. The legitimate operator has generated a PQ or composite successor key and intends to request issuance of a PQ or composite next-generation CA-signed successor certificate.
3. An adversary, potentially equipped with a CRQC, intercepts or influences the renewal process — for example, by forging ACME order responses, by suppressing the PQ certificate in TLS negotiation, or by exploiting CA issuance policies that still accept classical CSRs.
4. The certificate presented after renewal is classical rather than PQ.
5. The relying party, lacking any machine-verifiable record of the prior commitment to a PQ key, accepts the classical certificate.

The adversary has achieved an undetectable downgrade. The relying party has no basis to reject the classical certificate because no prior commitment was recorded in the previous certificate.

Why Temporal Declarations Are Insufficient Without Cryptographic Binding defines a continuityPeriod field that declares the number of days beyond notAfter that the subject intends to present PQC or composite certificates. This declaration addresses the observation-based heuristic: if a relying party has previously seen a PQC certificate for a given subject, it may treat the absence of a PQC certificate during the continuity window as suspicious. However, temporal declarations without cryptographic binding have the following limitations:

1. No key specificity: The declaration says "we will use some PQ algorithm" but does not commit to which key. An adversary who generates a different PQ key pair and presents it at renewal bypasses the downgrade heuristic entirely — the relying party observes a PQ certificate and accepts it, not knowing a key substitution occurred.
2. TOFU bootstrap problem: A relying party that connects to a service for the first time during the migration window may never have seen a envelope-bearing certificate. It has no cached commitment to use as a downgrade baseline.
3. Silent cessation: If the operator or an adversary presents a classical certificate without revoking the prior PQ certificate, the temporal declaration cannot distinguish intentional policy change from attack. The draft acknowledges this as an open problem.
4. No ACME-ARI integration: The temporal declaration provides no hook for automated certificate management systems to schedule commitment-aware renewals that verify the PQ key material is consistent with what was committed at issuance time.

A cryptographically bound commitment to specific future key material addresses each of these gaps. Cryptographic binding means:

• The CA's signature over the commitment makes substitution of the committed hash a forgery that any verifier can detect.
• The hash of the future SPKI is specific to a particular key, not merely an algorithm family declaration.
• The envelopeNotAfter field provides a machine-processable schedule anchor that ACME-ARI can act on.

Requirements for a Forward Key Commitment Extension This section states requirements that a solution to the downgrade-at-renewal gap SHOULD satisfy. These requirements are stated in abstract, non-implementation-specific language. REQ-1: Forward SPKI Hash Binding. A solution MUST provide a mechanism for embedding a cryptographic hash of the future SubjectPublicKeyInfo in the current certificate, in a field that is covered by the CA's signature. The hash algorithm used MUST itself be post-quantum resistant (i.e., resistant to the Grover speedup on second-preimage search, which reduces SHA-256's effective quantum second-preimage resistance from 256 bits to approximately 128 bits, and SHA-384's from 384 bits to approximately 192 bits). SHA-384 or SHA-512, or their SHA-3 equivalents of equivalent or greater length, SHOULD be used. REQ-2: Envelope Committed Algorithm Set Identification. A solution MUST include an AlgorithmIdentifier for the intended committed algorithm, enabling relying parties to assess algorithm support without waiting for the next-generation CA-signed successor certificate to be issued. REQ-3: Machine-Verifiable Downgrade Detection. A envelope-aware relying party MUST be able to verify, at the time of observing a next-generation CA-signed successor certificate, whether the SPKI in that certificate matches the Envelope Manifest Hash in the predecessor certificate. A mismatch MUST be treated as a commitment failure. REQ-4: Commitment Validity Window. A solution MUST include a commitment expiry time (envelopeNotAfter) expressed as a GeneralizedTime. Relying parties MUST NOT enforce commitment semantics after this time has passed. The envelopeNotAfter value SHOULD be set to a time no later than the latest date by which the operator's declared algorithm migration policy requires completion. REQ-5: ACME-ARI Scheduling Hook. A solution SHOULD be integrable with ACME Renewal Information (ARI) so that a CA or ACME server can trigger a renewal with a suggestedWindow that falls at or before envelopeNotAfter. The renewal SHOULD result in a next-generation CA-signed successor certificate whose SPKI matches the Envelope Manifest Hash. REQ-6: NIST Security Level Identification. The committed algorithm SHOULD be specified with sufficient precision to allow relying parties to identify the NIST security level of the intended future key. For ML-DSA, this corresponds to the distinction between ML-DSA-44, ML-DSA-65, and ML-DSA-87 as defined in . REQ-7: Policy URI Binding. A solution SHOULD provide an optional URI field pointing to a human-readable or machine-parseable policy document that describes the operator's algorithm migration schedule and commitment governance. REQ-8: Non-Critical, Legacy-Safe Deployment. A solution MUST be deployable as a non-critical X.509 v3 extension per RFC 5280 Section 4.2. Legacy relying parties that do not recognize the extension MUST be unaffected — the extension MUST NOT cause them to reject the certificate. envelope-aware behavior is layered on top of the existing RFC 5280 path validation semantics, not substituted for them. REQ-9: DER Encoding. The extension value MUST be encoded in Distinguished Encoding Rules (DER) as specified in Section 1. All internal fields MUST use DER canonical encoding. REQ-10: Experimental Deployability. Prior to formal IANA assignment of an id-pe OID, operators SHOULD be able to use a private enterprise arc for experimental deployments, with documentation clearly distinguishing the experimental arc from any future permanent assignment.

The Rotation Envelope Extension

Extension Overview The CA-Side PQ Rotation Envelope extension is an X.509 v3 extension under the id-pe arc ( Section 4.2.2). The extension MUST be marked non-critical. The extension carries an advisory, non-authoritative statement from the issuing CA (as recorded by the issuing CA) that:

1. The subject intends the named committed algorithm to be present in the next-generation CA-signed successor certificate issued before envelopeNotAfter.
2. The specific key material for that next-generation CA-signed successor certificate is identified by a cryptographic hash over the future SubjectPublicKeyInfo, if the EnvelopeManifestReference field is present.
3. A policy URI, if present, identifies further operator-published commitment governance documentation.

The extension content is covered by the issuing CA's signature over the tbsCertificate, providing Issuance-Time Policy Binding (see Section 3 definitions).

ASN.1 Module PQ-Rotation-Envelope-2026 { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) TBD1 } DEFINITIONS IMPLICIT TAGS ::= BEGIN IMPORTS EXTENSION FROM PKIX-CommonTypes-2009 { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) 57 } AlgorithmIdentifier{} FROM PKIX1Algorithms2008 { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) 45 } id-pe FROM PKIX1Explicit-2009 { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) 51 } ; -- Object Identifier for the Rotation Envelope Extension id-pe-pq-rotation-envelope OBJECT IDENTIFIER ::= { id-pe TBD2 } -- The Rotation Envelope Extension ext-PQRotationEnvelope EXTENSION ::= { SYNTAX PQRotationEnvelope IDENTIFIED BY id-pe-pq-rotation-envelope } -- Main Extension Structure PQRotationEnvelope ::= SEQUENCE { envelopeValid BOOLEAN, envelopeCommittedAlgorithmSet AlgorithmIdentifier { ALGORITHM, {...} }, futureKeyCommitment EnvelopeManifestReference OPTIONAL, envelopeNotAfter GeneralizedTime, manifestURI IA5String OPTIONAL } -- Future Key Commitment Structure EnvelopeManifestReference ::= SEQUENCE { hashAlgorithm AlgorithmIdentifier { DIGEST-ALGORITHM, {...} }, spkiHash OCTET STRING, keyAlgorithmHint AlgorithmIdentifier { ALGORITHM, {...} } OPTIONAL } END

Field Definitions

envelopeValid The envelopeValid field is a BOOLEAN indicating whether the commitment encoded in this extension is currently asserted as valid by the issuing CA.

• A value of TRUE indicates the subject is asserting an active commitment. This is the normative case.
• A value of FALSE indicates the commitment has been explicitly rescinded by the subject (e.g., due to a change in key generation schedule). A envelope-aware relying party that observes envelopeValid set to FALSE in a certificate MUST treat any prior cached commitment for this subject as revoked. Issuance of a certificate with envelopeValid FALSE is the mechanism by which subjects signal commitment revocation without revoking the certificate itself.

Conforming implementations MUST include this field.

envelopeCommittedAlgorithmSet The envelopeCommittedAlgorithmSet field is an AlgorithmIdentifier identifying the post-quantum or PQ/T hybrid algorithm the subject intends to use in the next-generation CA-signed successor certificate. The AlgorithmIdentifier MUST identify a post-quantum or composite algorithm. AlgorithmIdentifiers for ML-DSA variants are defined in the LAMPS ML-DSA certificate profile (draft-ietf-lamps-dilithium-certificates). AlgorithmIdentifiers for composite algorithms are defined in (for signatures) and (for KEMs). A envelope-aware relying party SHOULD verify that the algorithm OID in the envelopeCommittedAlgorithmSet field is an algorithm the relying party supports, as an early signal of future interoperability.

futureKeyCommitment The futureKeyCommitment field is OPTIONAL. When present, it contains a EnvelopeManifestReference structure binding the commitment to a specific public key value. When absent, the commitment is algorithm-level only (an advisory declaration of which algorithm will be used), without binding to specific key material. Implementations that wish to enable REQ-3 (machine-verifiable downgrade detection at the key level) MUST include this field. Its omission reduces the strength of the commitment to algorithm-level intent only.

hashAlgorithm The hashAlgorithm field in EnvelopeManifestReference is an AlgorithmIdentifier specifying the hash algorithm used to compute spkiHash. The hash is computed over the full DER encoding of the future SubjectPublicKeyInfo. The hash algorithm MUST provide at least 256 bits of preimage resistance. Implementations SHOULD use SHA-384 or SHA-512 (), or SHA3-384 or SHA3-512 (). Use of SHA-256 is permitted but not recommended, as its effective quantum-collision resistance is reduced to approximately 85 bits under the Grover algorithm. Implementations MUST NOT use MD5, SHA-1, or SHA-224.

spkiHash The spkiHash field is an OCTET STRING containing the output of hashAlgorithm applied to the DER encoding of the full SubjectPublicKeyInfo that is intended to appear in the successor certificate. spkiHash = Hash( hashAlgorithm, DER( future-SubjectPublicKeyInfo ) ) The DER encoding of SubjectPublicKeyInfo is taken over the complete ASN.1 structure including the AlgorithmIdentifier and the subjectPublicKey BIT STRING, as defined in RFC 5280 Section 4.1.

keyAlgorithmHint The keyAlgorithmHint field is OPTIONAL. When present, it provides the AlgorithmIdentifier for the algorithm used to generate the committed key, as a convenience for relying parties that wish to assess future algorithm compatibility before the next-generation CA-signed successor certificate is issued. In most cases, keyAlgorithmHint and envelopeCommittedAlgorithmSet will carry the same OID, and keyAlgorithmHint MAY be omitted. keyAlgorithmHint is useful when envelopeCommittedAlgorithmSet is a composite OID and the relying party needs to independently assess each component's compatibility.

envelopeNotAfter The envelopeNotAfter field is a GeneralizedTime value specifying the last time at which the commitment is asserted to be valid. After this time, a envelope-aware relying party MUST NOT rely on the commitment for downgrade detection. The envelopeNotAfter value:

• SHOULD NOT be later than the certificate's own notAfter field plus the maximum expected renewal lead time for the operator's environment. Excessively long envelopeNotAfter values prolong the exposure window if the committed key is later compromised.
• SHOULD be set so as to fall before or coincident with any applicable regulatory or compliance deadline (e.g., NIST IR 8547 2035 cutoff, or CNSA 2.0 2031 enforcement date ).
• MUST be expressed in the format "YYYYMMDDHHMMSSZ" per RFC 5280 Section 4.1.2.5.

manifestURI The manifestURI field is OPTIONAL. When present, it is an IA5String containing a URI that points to a human-readable or machine-parseable document where the operator publishes its PQ algorithm migration policy, key custody procedures, and commitment governance documentation. Relying parties SHOULD NOT require the URI to be resolvable at certificate validation time. The URI is informational; its availability and content are outside the scope of this specification.

Processing Rules

Certificate Issuance

1. The certificate subject SHALL generate the intended future PQ or composite key pair before requesting issuance of a certificate containing the Rotation Envelope extension.
2. The subject computes spkiHash = Hash(hashAlgorithm, DER(future-SPKI)) over the full DER encoding of the future SubjectPublicKeyInfo.
3. The subject includes the EnvelopeManifestReference in the Certificate Signing Request (CSR) or in a separate signed commitment attestation submitted to the CA.
4. The issuing CA MUST verify that the envelopeValid field is TRUE before embedding an active commitment.
5. The issuing CA MUST verify that the envelopeCommittedAlgorithmSet OID refers to a post-quantum or composite algorithm. A CA MUST NOT issue a certificate with a Rotation Envelope extension in which envelopeCommittedAlgorithmSet identifies a classical-only algorithm.
6. The issuing CA SHOULD verify that envelopeNotAfter is not less than the current time plus a reasonable minimum commitment window (e.g., at least as long as the certificate's own validity period).
7. The extension MUST be marked non-critical (criticality = FALSE).
8. The CA signs the tbsCertificate, which includes the extension, thereby providing Issuance-Time Policy Binding over the commitment.

Certificate Consumption by Envelope-Aware Relying Parties

1. Upon processing a certificate containing a Rotation Envelope extension, a envelope-aware relying party:
   1. Verifies the certificate chain per RFC 5280 path validation (Section 6) without modification. The Rotation Envelope extension does not alter path validation semantics.
   2. If envelopeValid is FALSE, clears any previously cached commitment for the subject and treats this certificate as having no active forward commitment.
   3. If envelopeValid is TRUE and the current time is before envelopeNotAfter, stores the following commitment record for the subject's identity (e.g., SubjectAltName):
      • The committed algorithm OID.
      • The EnvelopeManifestReference (hashAlgorithm, spkiHash, keyAlgorithmHint), if present.
      • The envelopeNotAfter value.
      • The manifestURI, if present.
      • The issuer and serial number of the current certificate (for correlation with ACME replaces tracking per ).
2. The commitment record MUST be purged when:
   1. The current time exceeds envelopeNotAfter.
   2. A next-generation CA-signed successor certificate is accepted whose SPKI matches the Envelope Manifest Hash (successful commitment fulfillment; see Section 5.3).
   3. A certificate with envelopeValid = FALSE is received for the subject.
   4. The relying party's local policy for commitment record retention has been exceeded (implementation-defined).

Renewal and Commitment Fulfillment

1. When a envelope-aware relying party encounters a next-generation CA-signed successor certificate for a subject for which a commitment record exists:
   1. Compute CandidateHash = Hash(hashAlgorithm from commitment record, DER(SPKI of next-generation CA-signed successor certificate)).
   2. Compare CandidateHash to the spkiHash in the commitment record.
   3. If the hashes match: the commitment is FULFILLED. The relying party SHOULD accept the next-generation CA-signed successor certificate (subject to normal RFC 5280 path validation) and SHOULD log the commitment fulfillment event. The commitment record is purged per Section 5.2(2b).
   4. If the hashes do NOT match: the commitment is VIOLATED. The relying party MUST treat this as a commitment failure. The appropriate response is implementation-defined and MAY include:
      • Rejecting the next-generation CA-signed successor certificate for envelope-dependent application-layer operations.
      • Generating an alert or log entry indicating a commitment failure event.
      • Initiating out-of-band confirmation with the certificate subject via the manifestURI.
      A relying party MUST NOT silently accept a next-generation CA-signed successor certificate with a commitment violation when the EnvelopeManifestReference field was present and envelopeValid was TRUE in the predecessor certificate.
2. If the EnvelopeManifestReference field is absent in the predecessor certificate, the commitment is algorithm-level only. In this case, a envelope-aware relying party SHOULD verify that the successor certificate's SPKI algorithm OID matches the envelopeCommittedAlgorithmSet OID. A mismatch between the committed algorithm and the successor certificate's key algorithm SHOULD be treated as a commitment failure.

Downgrade Detection

1. If a envelope-aware relying party holds a commitment record for a subject with envelopeNotAfter in the future, and the relying party encounters a certificate for that subject whose SPKI is based solely on a classical algorithm (RSA, ECDSA, ECDH, EdDSA in standalone non-composite form):
   1. The relying party SHOULD treat this as a potential downgrade event.
   2. The relying party MUST NOT accept the certificate for envelope-dependent operations without additional out-of-band assurance.
   3. The relying party SHOULD log the downgrade event, including the subject identity, the committed algorithm OID, and the observed classical algorithm OID.
2. A commitment failure and a potential downgrade event are distinct:
   • A commitment failure occurs when the SPKI hash does not match the Envelope Manifest Hash (key substitution case).
   • A downgrade event occurs when the algorithm family is classical rather than PQ or composite (algorithm regression case).
   Both are treated as protocol violations for envelope-dependent operations.

Integration with ACME Renewal Information (ARI) ACME Renewal Information provides the renewalInfo resource, suggestedWindow, and replaces field. The following integration is RECOMMENDED for operators using ACME certificate management:

1. Scheduling: When an ACME server manages certificates bearing the Rotation Envelope extension, the suggestedWindow in the renewalInfo resource for that certificate SHOULD be set to begin no later than a reasonable lead time before envelopeNotAfter. This ensures the renewal process completes and the next-generation CA-signed successor certificate is issued while the commitment is still in force.
2. Replacement tracking: When an ACME order is submitted to renew a envelope-bearing certificate, the replaces field in the new ACME Order SHOULD reference the predecessor certificate (by the {issuer, serial} identifier as defined in Section 5). This allows the CA and relying parties to correlate the renewal with the outstanding commitment.
3. This step is OPTIONAL for CAs that do not implement envelope-aware order validation, and it requires the CA to have access to the predecessor certificate — which is typically possible via the issuer's own certificate repository or thePQ key validation at order time: A CA that receives an ACME Order with a replaces field referencing a envelope-bearing predecessor certificate SHOULD verify that the SPKI in the new Order's CSR matches the spkiHash in the predecessor's EnvelopeManifestReference. If the hash does not match, the CA SHOULD reject the Order with an appropriate error indicating a commitment mismatch. replaces reference.
4. Explanation URL: The CA MAY set the explanationURL field of the renewalInfo resource to the same URI as the manifestURI in the Rotation Envelope extension, providing consistent reference between the ACME renewal workflow and the commitment governance documentation.

Security Considerations

Advisory, Not Authoritative The Rotation Envelope extension is advisory and non-authoritative. The commitment expressed in the extension is made by the issuing CA and recorded by the CA; it is not a guarantee enforceable by technical protocol alone. A relying party's response to a commitment violation is a matter of local policy. A certificate subject that includes the Rotation Envelope extension but fails to honor the commitment (by presenting a classical or non-matching key at renewal) incurs a protocol violation that envelope-aware relying parties may detect and act upon. The extension is analogous to a published service commitment — machine-verifiable and CA-attested, but not self-executing.

Preimage Resistance and Hash Algorithm Selection The security of the spkiHash commitment depends on the second-preimage resistance of the hashAlgorithm. An adversary who can find a second preimage can substitute a different future key while maintaining the hash match. For a hash algorithm providing n bits of output, the relevant security properties for the spkiHash commitment are:

• Second-preimage resistance (finding a different input with the same hash): classically 2^n operations; under Grover's algorithm applied to second-preimage search, approximately 2^(n/2) quantum operations.
• Collision resistance (finding any two inputs with the same hash): classically 2^(n/2) operations (birthday bound); under the Brassard-Høyer-Tapp (BHT) algorithm, approximately 2^(n/3) quantum operations.

For the spkiHash commitment, the relevant property is second-preimage resistance: an adversary must find a distinct SubjectPublicKeyInfo that hashes to the same value as the committed future SPKI. The classical security level equals the hash output length n; the quantum security level under Grover is approximately n/2 bits. This implies:

• SHA-256 (n=256): 256-bit classical second-preimage resistance; approximately 128-bit quantum second-preimage resistance. SHA-256 SHOULD NOT be used as the sole hash algorithm in commitments extending beyond 2030, as the effective quantum advantage is approaching practical relevance.
• SHA-384 (n=384): 384-bit classical second-preimage resistance; approximately 192-bit quantum second-preimage resistance. SHA-384 is the RECOMMENDED minimum for high-assurance environments.
• SHA-512 (n=512) or SHA3-512 (n=512): 512-bit classical; approximately 256-bit quantum second-preimage resistance. Preferred for commitments extending to 2035 or beyond.

The hash algorithm selection SHOULD be consistent with the security level implied by the envelopeCommittedAlgorithmSet. For example, a commitment to ML-DSA-87 (NIST security category 5, targeting at least 256 bits of classical security) warrants SHA-512 or SHA3-512.

Public Key Correlation The spkiHash field reveals information about the future public key to any party that observes the current certificate. Specifically:

• The hash provides a commitment binding: if two certificates appear with the same spkiHash and hashAlgorithm, they commit to the same future key. This enables correlation of certificates across different organizational entities if the same future key hash appears in multiple Rotation Envelope extensions.
• The hash does not reveal the future public key itself. However, if the committed algorithm is an asymmetric algorithm with known key structure, an adversary with access to the public key at renewal time can trivially verify whether the key matches the prior commitment.

Operators SHOULD generate a unique future key pair for each Rotation Envelope commitment and MUST NOT reuse a committed future key in more than one Rotation Envelope extension unless the operator explicitly intends cross-certificate correlation to be observable.

Commitment Substitution Attack An adversary who can perform a man-in-the-middle attack at the CA during certificate issuance could, in principle, substitute a different spkiHash for the value submitted by the legitimate subject. The adversary would then substitute the corresponding key at renewal time. The Issuance-Time Policy Binding property (the CA's signature over the extension in the tbsCertificate) prevents post-issuance substitution of the hash. However, it does not prevent issuance-time substitution if the adversary can compromise the CA issuance pipeline. Mitigations include:

• The subject retaining a signed copy of the CSR or commitment attestation containing the original spkiHash before submitting it to the CA.
• Certificate Transparency (CT) logging, which records the issued certificate and thus the committed spkiHash, enabling detection of discrepancies between submitted and issued commitments.
• Use of CSR attestation mechanisms such as draft-ietf-lamps-csr-attestation to provide hardware-backed proof of the private key controlling the committed SPKI.

CRQC-Era Considerations The Rotation Envelope extension is designed for deployment during the transition to PQC. Once a CRQC becomes available:

• Existing classical certificates in the PKI can be forged or decrypted.
• CAs that sign certificates with classical algorithms can have their signing keys broken, enabling forgery of Rotation Envelope extensions.

Therefore, the value of the Rotation Envelope commitment depends on the certificate chain and the CA's signing algorithm:

• A Rotation Envelope extension in a certificate signed by a CA using only classical algorithms does not provide post-quantum security for the commitment itself. A CRQC adversary could forge the CA signature and substitute the commitment.
• A Rotation Envelope extension in a certificate signed by a CA using ML-DSA or a composite algorithm retains its commitment integrity even if a CRQC is available, because forging the CA signature would require breaking the PQ component.

Operators seeking CRQC-era integrity of their CA continuity envelopes SHOULD ensure their issuing CA chain uses ML-DSA or composite signing algorithms before the commitment window extends into the period when a CRQC is considered a realistic threat. This is consistent with CNSA 2.0 requirements, which mandate ML-DSA-87 for all NSS certificate signatures by 2031.

Downgrade-Forcing Attack An adversary may attempt to force a downgrade by:

1. Preventing the legitimate subject from completing renewal during the ACME-ARI suggested window.
2. Presenting a classical or non-matching certificate after envelopeNotAfter has passed, when the relying party's downgrade detection has expired.

Mitigations:

• The operator SHOULD set envelopeNotAfter to a value sufficiently beyond the expected renewal date to account for operational delays, but not so far beyond as to create an extended window during which a compromised classical key is assumed to be valid.
• The CA SHOULD reject a renewal order for a envelope-bearing certificate that references a classical-only SPKI when ARI-integrated Rotation Envelope validation is in force.
• Relying parties SHOULD log commitment expirations and flag any transitions from PQ or composite certificates to classical certificates that occur close to or after envelopeNotAfter.

TOFU Bootstrap Problem A relying party that encounters a envelope-bearing certificate for the first time has no prior basis for validating the freshness of the commitment. The "trust on first use" (TOFU) problem means that if the very first certificate observed for a subject already contains a commitment violation, the relying party cannot detect it. This problem is not specific to the Rotation Envelope mechanism; it is shared by all observation- based downgrade detection mechanisms, including . Partial mitigations include:

• Certificate Transparency logs: relying parties can query CT logs to observe the history of certificates issued for a subject before the first direct connection. A subject that has previously issued envelope- bearing certificates creates a CT-observable commitment history.
• ACME replaces field correlation: when ARI is in use, the chain of renewal Orders provides a verifiable history of certificate issuance events that can be cross-checked against CT log entries.
• Out-of-band pinning: high-assurance environments may publish the expected spkiHash via a separate, authenticated channel (e.g., DNSSEC- signed TXT records or operator-published Rotation Envelope policy documents referenced by manifestURI).

The TOFU bootstrap problem is acknowledged as a known limitation of this specification. Future work may address it through additional mechanisms such as signed commitment announcements or integration with certificate policy OIDs that attest to an operator's Rotation Envelope enrollment.

IANA Considerations

id-pe OID Assignment IANA is requested to assign an Object Identifier for the Rotation Envelope extension under the id-pe arc: id-pe-pq-rotation-envelope OBJECT IDENTIFIER ::= { id-pe TBD2 } The base id-pe arc is 1.3.6.1.5.5.7.1 as defined in RFC 5280 Section 4.2.2. The assigned id-pe value TBD2 will result in a final OID of 1.3.6.1.5.5.7.1.TBD2. IANA is also requested to assign an Object Identifier for the ASN.1 module under the id-mod arc: id-mod-pq-rotation-envelope-2026 OBJECT IDENTIFIER ::= { id-mod TBD1 } Both assignments are TBD pending IANA processing.

Experimental OID Arc Prior to permanent IANA assignment, operators wishing to conduct experimental deployments of the Rotation Envelope extension may use OIDs under the IANA Private Enterprise Number (PEN) arc for Sanctum SecOps LLC: 1.3.6.1.4.1.65953 Specifically, the experimental arc for Rotation Envelope extensions is: id-pe-pq-rotation-envelope-experimental OBJECT IDENTIFIER ::= { 1 3 6 1 4 1 65953 1 1 } This experimental OID MUST NOT be used in production deployments or in certificates submitted to public Certificate Transparency logs without explicit documentation that the OID is experimental and subject to change. The experimental arc is distinct from any permanent id-pe assignment.

References Normative References NIST NIST NIST Informative References Nokia Entrust Intuit Entrust Entrust NIST NSA NIST NIST

Appendix A: Example Rotation Envelope Extension DER Encoding This appendix shows a non-normative, illustrative encoding of a Rotation Envelope extension. The example commits to a future ML-DSA-65 key using a SHA-384 hash.

Certificate Subject Scenario

• Current certificate: ECDSA P-256, 2-year validity, expires 2027-01-01.
• Committed algorithm: ML-DSA-65 (OID 2.16.840.1.101.3.4.3.18).
• Future key: Pre-generated ML-DSA-65 key pair. The DER encoding of the future SubjectPublicKeyInfo is hashed with SHA-384.
• envelopeNotAfter: 2027-04-01 (3 months beyond certificate notAfter to accommodate renewal lead time).

ASN.1 Value (Informative) PQRotationEnvelope ::= SEQUENCE { envelopeValid TRUE, envelopeCommittedAlgorithmSet SEQUENCE { algorithm 2.16.840.1.101.3.4.3.18 -- id-ML-DSA-65 }, futureKeyCommitment SEQUENCE { hashAlgorithm SEQUENCE { algorithm 2.16.840.1.101.3.4.2.2 -- id-sha384 }, spkiHash OCTET STRING (48 bytes -- SHA-384 output), keyAlgorithmHint ABSENT -- as above }, envelopeNotAfter GeneralizedTime "20270401000000Z", manifestURI ABSENT } The extension appears in the certificate's extensions list as: Extension ::= SEQUENCE { extnID 1.3.6.1.5.5.7.1.TBD2, -- id-pe-pq-rotation-envelope critical FALSE, -- MUST be non-critical extnValue OCTET STRING { -- DER of PQRotationEnvelope -- (DER bytes omitted; see description above) } }

Appendix B: Relationship to NIST IR 8547 Migration Timeline NIST IR 8547 (initial public draft, November 2024) establishes the following transition timeline for quantum-vulnerable algorithms:

Milestone	Date	Implication for Rotation Envelope
Deprecation of 112-bit classical algorithms	2030	CA continuity envelopes for lower-security-level environments SHOULD have envelopeNotAfter no later than 2030.
Disallowment of all classical asymmetric algorithms	2035	CA continuity envelopes in high-assurance environments SHOULD be set to complete migration before 2035.
CNSA 2.0 full enforcement for NSS	2031	CA continuity envelopes in National Security System contexts SHOULD have envelopeNotAfter no later than 2031.

The NIST IR 8547 note on hybrid modes states that the disallowment of quantum-vulnerable algorithms after 2035 was not intended to apply to hybrid modes that incorporate an approved PQC algorithm alongside a quantum-vulnerable algorithm. This means PQ/T composite certificates (as defined in ) remain usable beyond 2035 within the scope of that NIST guidance. CA continuity envelopes to composite algorithms are therefore consistent with long-term compliance, provided the composite includes an approved PQC component.

Appendix C: Comparison with Related Mechanisms

Mechanism	Fwd Commit?	Key Bind?	Downgrade?	ARI Hook?	Non-Crit?
draft-reddy pq-commit	Temporal only	No	Heuristic only	No	Yes
RFC 9763 Related Cert	No (current binding)	Current cert only	No	No	Yes
certdiscovery certHash	No (existing cert)	Existing cert hash	No	No	Yes
ounsworth ext-pubkeys	No (current key)	Current key hash	No	No	N/A
This document (Rotation Envelope -01)	Yes (future SPKI hash)	Yes (spkiHash)	Yes (REQ-3)	Yes (Section 5.4)	Yes

This comparison illustrates that the Rotation Envelope extension as defined in this document is the only mechanism in the current LAMPS WG landscape that simultaneously provides forward key commitment with cryptographic binding, machine-verifiable downgrade detection, and ACME-ARI scheduling integration.

Acknowledgments The author thanks Tirumaleswar Reddy.K, John Gray, and Yaron Sheffer for their work on draft-reddy-lamps-x509-pq-commit, which identified the temporal commitment gap and provided the direct motivation for this work. Thanks to Mike Ounsworth, Massimiliano Pala, Jan Klaußner, and Scott Fluhrer for their work on composite ML-DSA and composite ML-KEM, which establish the algorithm encoding infrastructure that CA continuity envelopes reference. Thanks to Alison Becker, Rebecca Guthrie, and Michael J. Jenkins for their work on RFC 9763 and the CNSA 2.0 PKIX profile, which clarify the NSS certificate requirements that motivate Rotation Envelope in high-assurance contexts. Thanks to the LAMPS Working Group for the broader PQC certificate infrastructure this document builds upon. This document was prepared for public review as a contribution to the IETF LAMPS Working Group. It describes a problem domain and requirements; it does not disclose any proprietary internal architecture.