CA-Side Post-Quantum Rotation Envelope for X.509 Issuance Continuity

1.1. Relationship to Existing Work

The design of Rotation Envelope is informed by several related efforts:¶

draft-reddy-lamps-x509-pq-commit [I-D.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 [I-D.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 [RFC9763]: 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 [I-D.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 [I-D.ietf-lamps-pq-composite-sigs] and Composite ML-KEM [I-D.ietf-lamps-pq-composite-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) [RFC9773]: 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.¶

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

3.1. 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 [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 [SHOR1994] 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 [GROVER1996] 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 [MOSCA2018]: 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.¶

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

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

3.4. Why Temporal Declarations Are Insufficient Without Cryptographic Binding

[I-D.reddy-lamps-x509-pq-commit] 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.¶

5.1. Extension Overview

The CA-Side PQ Rotation Envelope extension is an X.509 v3 extension under the id-pe arc ([RFC5280] 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).¶

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

5.3. Field Definitions

spkiHash = Hash( hashAlgorithm, DER( future-SubjectPublicKeyInfo ) )

5.4. Processing Rules

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

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

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

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

7.5. 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 [CNSA2] requirements, which mandate ML-DSA-87 for all NSS certificate signatures by 2031.¶

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

7.7. 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 [I-D.reddy-lamps-x509-pq-commit].¶

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

8.1. 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 [RFC5280] 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.¶

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

A.1. 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).¶

A.2. 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)
    }
}