]> Sanctum SecOps LLC

admin@sanctumsecops.com

Security LAMPS post-quantum X.509 certificate extension crypto-agility hybrid migration This document defines a non-critical X.509 certificate extension, the Post-Quantum Hybrid Commitment (PQCHC), that allows a certificate issued with a classical or hybrid key to carry a verifiable, cryptographically bound commitment to a specific future post-quantum algorithm and a Commitment Validity Time. The PQCHC commitment binds to a hash of the committed future public key and algorithm identifier, enabling a relying party to verify that a subsequently issued post-quantum certificate honors the earlier commitment. This mechanism provides a crypto-agility signal for certificate-lifecycle automation, including ACME Renewal Information (ARI), to plan and verify PQC migration.

Introduction The finalization of NIST post-quantum standards FIPS 203 , FIPS 204 , and FIPS 205 establishes the algorithms to which existing PKIs must migrate. NIST IR 8547 sets a deprecation calendar that makes migration time-bounded. Migration of an X.509 hierarchy is gated by the certificate lifecycle: a relying party is not protected against a cryptographically relevant quantum computer (CRQC) until quantum-vulnerable certificates have expired or been replaced. During the multi-year transition window, a relying party frequently holds a certificate that is still classical (or hybrid) but whose subject intends to migrate to a specific post-quantum algorithm at a known time. Today there is no interoperable, machine-verifiable way to express that intent inside the certificate itself. This document addresses that gap. PQCHC allows a certificate that is not yet composite to carry a machine-verifiable commitment to the post-quantum algorithm and the time by which the subject intends to migrate, such that lifecycle automation (for example, ACME Renewal Information ) can act on it and a relying party can later verify the migration was honored. Algorithm identifiers in this document use the registrations defined in (ML-DSA), (SLH-DSA), and (ML-KEM). This document uses the post-quantum terminology of . A PQCHC commitment is neither a "composite" nor a "hybrid" key per that terminology; it is a forward-looking policy and continuity commitment carried as a certificate extension. Specific tuning parameters used by implementations of this mechanism are out of scope of this document; see the Applicability section of the corresponding Sanctum SecOps publication.

Relationship to Existing Work defines a declarative post-quantum continuity signal expressed as a period of time, without a cryptographic binding to a specific future key. PQCHC differs by binding the commitment to a hash of the committed future public key and algorithm identifier, permitting later verification that an issued post-quantum certificate honors the prior commitment. Composite certificates () address the transition phase: simultaneous classical-and-PQ security in a single certificate. PQCHC addresses the pre-transition phase: a purely classical certificate carries a machine-verifiable binding to its intended successor. The two mechanisms are not mutually exclusive; see for the interaction model.

Requirements This section states requirements that a conforming PQCHC implementation SHOULD satisfy.

REQ-1:

A solution MUST embed a cryptographic hash of the future SubjectPublicKeyInfo in the current certificate in a field covered by the CA's signature. The hash algorithm MUST provide at least 128 bits of second-preimage resistance against a quantum adversary.

REQ-2:

A solution MUST include an AlgorithmIdentifier for the intended committed algorithm, enabling relying parties to assess algorithm support without waiting for the successor certificate to be issued.

REQ-3:

A PQCHC-aware relying party MUST be able to verify, at the time of observing a successor certificate, whether the SPKI hash matches the Committed Key Hash in the predecessor certificate. A mismatch MUST be treated as a commitment failure.

REQ-4:

A solution MUST include a Commitment Validity Time expressed as a GeneralizedTime. Relying parties MUST NOT enforce commitment semantics after this time. The value SHOULD be set no later than the operator's declared algorithm-migration deadline.

REQ-5:

A solution SHOULD be integrable with ACME Renewal Information (ARI) so that the suggestedWindow falls at or before the Commitment Validity Time, and the resulting renewal uses the committed key.

REQ-6:

The committed algorithm SHOULD be specified with sufficient precision to identify the NIST security level of the intended future key (e.g., ML-DSA-44, ML-DSA-65, or ML-DSA-87 per ).

REQ-7:

A solution SHOULD provide an optional URI field pointing to a human-readable or machine-parseable document describing the operator's algorithm migration policy and commitment governance.

REQ-8:

A solution MUST be deployable as a non-critical X.509 v3 extension per Section 4.2. Legacy relying parties MUST be unaffected. PQCHC-aware behavior MUST NOT alter RFC 5280 path validation semantics.

REQ-9:

The extension value MUST be encoded in Distinguished Encoding Rules (DER) per . All internal fields MUST use DER canonical encoding.

REQ-10:

Prior to formal IANA OID assignment, 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.

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:

Committed Algorithm:

the post-quantum algorithm, identified by an object identifier, to which the subject commits for a future certificate.

Committed Key Hash:

a cryptographic hash over the subjectPublicKeyInfo the subject intends to use for the committed algorithm in a future certificate.

Commitment Validity Time:

the time by which the committed algorithm is intended to be in force for the subject, expressed as a GeneralizedTime.

CRQC:

Cryptographically Relevant Quantum Computer. A quantum computer capable of breaking classical asymmetric cryptography at operationally relevant key sizes, as described in .

The PQCHC Extension The PQCHC extension is a non-critical X.509 v3 certificate extension. Relying parties that do not understand the extension MUST ignore it, as required for non-critical extensions by . The extension carries: a commitment flag indicating a PQC migration commitment is present; the committed post-quantum algorithm identifier; a hash of the committed future public key (the Committed Key Hash); the Commitment Validity Time; and an optional URI to the operator's PQC migration policy document.

Encoding

= 256-bit output are acceptable. -- SHA-1 and MD5 MUST NOT be used. committedKeyHash DigestInfo, -- Latest time by which the committed algorithm is in force. -- Encoded as GeneralizedTime in format YYYYMMDDHHMMSSZ. -- Operators SHOULD set this at or before the NIST IR 8547 -- deprecation date of the signing algorithm. commitmentNotAfter GeneralizedTime, -- Optional URI to operator's PQC migration policy document. policyURI IA5String OPTIONAL } END ]]>

Implementation notes: AlgorithmIdentifier for ML-DSA, ML-KEM, and SLH-DSA MUST carry a non-null algorithm OID. The parameters field MUST be absent, consistent with , , and respectively. DigestInfo carries { digestAlgorithm AlgorithmIdentifier, digest OCTET STRING }. The algorithm field enables hash agility; bare OCTET STRING SHOULD NOT be used. GeneralizedTime is used rather than UTCTime to support dates beyond 2049, consistent with Section 4.1.2.5.2. commitmentValid DEFAULT TRUE allows the extension to omit the flag in the common case.

Processing Rules A relying party that understands the extension MAY use the commitment as an input to lifecycle planning. When a subsequently issued certificate for the same subject presents a post-quantum key, the following five-step verification procedure applies:

commitment.commitmentNotAfter: return COMMITMENT_EXPIRED return COMMITMENT_HONORED ]]>

A relying party MUST NOT treat the presence, absence, or content of a PQCHC commitment as a reason to accept a certificate it would otherwise reject. The commitment is advisory with respect to the trust decision for the certificate in which it appears. A certificate MAY carry multiple PQCHC extensions when committing to both a signature algorithm and a KEM algorithm. Implementations that encounter more than one PQCHC extension MUST process each independently.

Interaction with Composite Certificates Composite certificates () bind a classical and a post-quantum key simultaneously; PQCHC binds a forward-looking commitment. The two mechanisms address different migration phases and are not mutually exclusive. When a composite certificate also carries a PQCHC extension, the committedAlgorithm field MUST use the composite algorithm OID as defined in , and committedKeyHash MUST be over the DER-encoded composite subjectPublicKeyInfo.

Interaction with ACME-ARI ACME Renewal Information (ARI) allows an ACME server to advertise a suggestedWindow within which clients should renew a certificate. An ACME CA that wishes to honor PQCHC commitments SHOULD constrain the ARI scheduling window as follows:

The specific lead time for suggestedWindow.start is implementation- defined and out of scope of this document. The following ASCII timing diagram illustrates a PQCHC-constrained ARI interaction, including post- issuance verification.

| | (certID = predecessor cert) | |---------------------------------->| | | (1) server decodes PQCHC | | from predecessor cert | | (2) sets window.end <= | | min(notAfter, | | commitmentNotAfter) | 200 OK | | { suggestedWindow: { | | start: , | | end: }, | | explanationURL: } | |<----------------------------------| | | | (client generates new key pair | | using committedAlgorithm OID) | | | | POST /new-order | | { replaces: ,| | identifiers: [...] } | |---------------------------------->| | | (3) server verifies: | | HASH(newSPKI) == | | committedKeyHash | | newSPKI.alg == | | committedAlgorithm | | notBefore <= | | commitmentNotAfter | 201 Created | |<----------------------------------| ]]>

The client MUST generate a new key pair using the algorithm specified in commitment.committedAlgorithm. After issuance, the CA or lifecycle automation SHOULD verify that the issued certificate's SPKI hash matches commitment.committedKeyHash.digest and that newCert.validity.notBefore <= commitment.commitmentNotAfter. If any verification check fails, the CA SHOULD log the failure and MAY notify the operator. The replaces field in the new-order request identifies the predecessor certificate per Section 5; the ACME server uses this to look up the predecessor's PQCHC extension and apply the constrained scheduling logic above. When the ACME server receives an order with a replaces field referencing a PQCHC-bearing certificate, it SHOULD verify that the CSR's subjectPublicKeyInfo hashes to committedKeyHash.digest under committedKeyHash.digestAlgorithm. An order that fails this check SHOULD be rejected with an orderNotReady error and a problem document indicating commitment-mismatch. If the commitmentNotAfter deadline has already passed, the server MAY proceed with a standard renewal using the suggestedWindow absent a commitment constraint, and SHOULD record the expired-commitment event for audit purposes. The CA MAY set the explanationURL field of the renewalInfo resource to the policyURI from the PQCHC extension to maintain consistent reference between the renewal workflow and the operator's migration policy documentation.

Security Considerations The commitment is advisory and MUST NOT be treated as authentication of the committed post-quantum key; it expresses intent and a binding to a future key hash, not possession of that key at the time of the committing certificate. A commitment MUST NOT downgrade the validation of the certificate in which it appears. Specific implementation parameters for posture evaluation and renewal scheduling are out of scope of this document; see the Applicability section of the corresponding Sanctum SecOps publication.

Downgrade Resistance A man-in-the-middle adversary operating during the PQC transition window can attempt forced-classical-reissuance: intercept a post-quantum renewal, serve a freshly obtained classical certificate, and block the relying party from observing a prior PQCHC commitment. Two defensive layers apply: (1) lifecycle automation SHOULD verify that the renewed certificate's SPKI hash matches committedKeyHash, creating an audit trail; and (2) operators who participate in Certificate Transparency can detect classical re-issuance to a subject that had committed to PQC by scanning CT logs for conflicting subject/SPKI combinations after the commitmentNotAfter deadline. The downgrade risk is bounded by the classical algorithm's remaining security margin.

Commitment-Substitution Attacks A commitment-substitution adversary attempts to make a different future key satisfy the committedKeyHash check by finding a second preimage of the committed SPKI under the digest algorithm, or by persuading a CA to re-issue the committing certificate with an altered committedKeyHash. Second-preimage attacks are mitigated by the digest-algorithm requirements in . The CA re-issuance path is a CA-compromise scenario; Certificate Transparency provides the same audit-trail mitigation.

Pre-Image Attack Surface on committedKeyHash The committedKeyHash field is a DigestInfo over the DER encoding of the committed subjectPublicKeyInfo. Its security depends on second-preimage resistance. Under Grover's algorithm, a quantum adversary can find a preimage of an n-bit hash in approximately 2^(n/2) quantum queries. For SHA-256, quantum preimage cost is approximately 2^128, which remains computationally infeasible. Implementations MUST NOT use MD5, SHA-1, or SHA-224 for committedKeyHash, as their classical security margins are already inadequate.

Hash Algorithm Agility The committedKeyHash field uses DigestInfo, which carries both the hash algorithm OID and the hash value, enabling the digest algorithm to be upgraded in future certificates without changing the ASN.1 structure. The digest algorithm used in committedKeyHash MUST provide at least 128 bits of second-preimage resistance against a quantum adversary. SHA-256, SHA-384, SHA-512, and SHA-3 variants with 256-bit or greater output are acceptable. SHA-1 and MD5 MUST NOT be used. The remaining threat considerations follow from the general properties of the mechanisms. CRQC-era forgery: if a CRQC becomes available before the commitmentNotAfter deadline, the classical signature on the committing certificate can be forged and an adversary could introduce an arbitrary committedKeyHash. This is a consequence of the general CRQC threat the entire PKI faces. Operators SHOULD set commitmentNotAfter at or before the NIST IR 8547 deprecation date of the algorithm used to sign the committing certificate. Cross-certification: a PQCHC commitment is CA-agnostic and survives re-issuance by a different CA. The verification procedure () does not require the verifier to know which CA issued either certificate. Implementations SHOULD treat commitments as advisory per path and MUST NOT fail path validation if multiple valid paths yield different commitment values. Implementation quality: PQCHC commitments bind to keys generated by PQC implementations. Published cryptanalysis demonstrates that implementation quality is critical (see , , ). CA key-generation practices SHOULD require constant-time implementations of the committed algorithm.

Implementation Status This section records the status of known implementations of the protocol defined by this specification at the time of posting, as required by . Organization: Sanctum SecOps LLC Description: An experimental Go implementation of the PQCHC extension covering encoding and decoding of PQCHCommitment structures, DigestInfo computation, and commitment verification per . Located at poc/pqchc/ in the companion repository at https://github.com/Sanc-Admin/sanctum-ietf (private until counsel hand-off). Coverage: Full extension encoding/decoding (ASN.1 DER), DigestInfo computation for SHA-256, commitment verification per , and ACME-ARI scheduling integration per . Maturity: Experimental reference implementation. This implementation is provided for early interoperability testing only and MUST NOT be deployed in production or used for security-critical operations without review by qualified security and legal counsel.

IANA Considerations

X.509 Certificate Extension OID IANA is requested to assign an object identifier for the PQCHC certificate extension from the id-ce arc:

The value TBD1 is a placeholder to be assigned by IANA upon publication. For early interoperability testing, an experimental OID under the publicly registered Sanctum SecOps PEN arc MAY be used:

This experimental value MUST NOT be relied upon as the permanent identifier. Deployments MUST transition to the IANA-assigned TBD1 value upon RFC publication.

Digest Algorithms for committedKeyHash IANA is requested to note that the following digest algorithm OIDs are acceptable for use in committedKeyHash: id-sha256, id-sha384, id-sha512, id-sha3-256, id-sha3-384, id-sha3-512. The following MUST NOT be used: id-md5, id-sha1.

References

In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet. An overview of this approach and model is provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate extensions are described and two Internet-specific extensions are defined. A set of required certificate extensions is specified. The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions. An algorithm for X.509 certification path validation is described. An ASN.1 module and examples are provided in the appendices. [STANDARDS-TRACK] RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. One aspect of the transition to post-quantum algorithms in cryptographic protocols is the development of hybrid schemes that incorporate both post-quantum and traditional asymmetric algorithms. This document defines terminology for such schemes. It is intended to be used as a reference and, hopefully, to ensure consistency and clarity across different protocols, standards, and organisations. Digital signatures are used within X.509 certificates and Certificate Revocation Lists (CRLs), and to sign messages. This document specifies the conventions for using FIPS 204, the Module-Lattice-Based Digital Signature Algorithm (ML-DSA) in Internet X.509 certificates and CRLs. The conventions for the associated signatures, subject public keys, and private key are also described. Digital signatures are used within the X.509 Public Key Infrastructure, such as X.509 certificates and Certificate Revocation Lists (CRLs), as well as to sign messages. This document specifies the conventions for using the Stateless Hash-Based Digital Signature Algorithm (SLH-DSA) in the X.509 Public Key Infrastructure. The conventions for the associated signatures, subject public keys, and private keys are also specified. The Module-Lattice-Based Key-Encapsulation Mechanism (ML-KEM) is a quantum-resistant Key Encapsulation Mechanism. This document specifies the conventions for using the ML-KEM in X.509 Public Key Infrastructure. The conventions for the subject public keys and private keys are also specified. This document specifies how an Automated Certificate Management Environment (ACME) server may provide suggestions to ACME clients as to when they should attempt to renew their certificates. This allows servers to mitigate load spikes and ensures that clients do not make false assumptions about appropriate certificate renewal periods. This document describes a simple process that allows authors of Internet-Drafts to record the status of known implementations by including an Implementation Status section. This will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature. This process is not mandatory. Authors of Internet-Drafts are encouraged to consider using the process for their documents, and working groups are invited to think about applying the process to all of their protocol specifications. This document obsoletes RFC 6982, advancing it to a Best Current Practice. Entrust Limited Entrust Limited OpenCA Labs Bundesdruckerei GmbH Cisco Systems This document defines combinations of US NIST Module-Lattice-Based Digital Signature Algorithm (ML-DSA) in hybrid with traditional algorithms RSASSA-PKCS1-v1.5, RSASSA-PSS, ECDSA, Ed25519, and Ed448. These combinations are tailored to meet regulatory guidelines in certain regions. Composite ML-DSA is applicable in applications that use X.509 or PKIX data structures that accept ML-DSA, but where the operator wants extra protection against breaks or catastrophic bugs in ML-DSA, and where existential unforgeability (EUF-CMA) level security is acceptable. Nokia Entrust Limited Intuit This document specifies a new X.509 certificate extension, Post- Quantum or Composite Hosting Continuity (PQCHC), which enables a certificate subject to signal a intent to continue serving PQC or composite certificates for a defined continuity period after certificate expiration. This extension helps relying parties detect downgrade and man-in-the-middle (MitM) attacks during transition phases, where a cryptographically relevant quantum computer (CRQC) would make traditional certificates insecure. NSA

Worked Example: ML-DSA-65 Commitment All values are synthetic test data. No real keys or production data are used. Scenario: A server certificate is issued with an ECDSA-P256 key. The operator commits to migrating to ML-DSA-65 (per ) by 2030-01-01T00:00:00Z. committedAlgorithm OID for id-ml-dsa-65: 2.16.840.1.101.3.4.3.18 committedKeyHash (SHA-256 over synthetic future ML-DSA-65 SPKI):

(Synthetic value -- not derived from any real key.) commitmentNotAfter: 20300101000000Z ASN.1 DER encoding of PQCHCommitment (hex):

X.509 extension snippet:

Verification outcome per : when the corresponding ML-DSA-65 successor certificate is issued with the above SPKI, steps 1-5 all pass and the result is COMMITMENT_HONORED.

Appendix B. NIST IR 8547 and CNSA 2.0 Migration Timeline NIST IR 8547 (initial public draft, November 2024) and the NSA CNSA 2.0 suite establish the following migration milestones relevant to PQCHC commitment deadlines:

NIST IR 8547 notes that PQ/T hybrid (composite) modes remain usable beyond 2035 when the composite includes an approved PQC component. PQCHC commitments to composite algorithms (per ) are therefore consistent with long-term compliance when the composite satisfies that condition. Informative references: , .

Acknowledgments The author thanks the LAMPS Working Group for the foundational post-quantum X.509 work on which this extension builds.