LAMPS B. Vicente Internet-Draft Sanctum SecOps LLC Intended status: Standards Track 5 June 2026 Expires: 7 December 2026 A Post-Quantum Hybrid-Commitment Certificate Extension (PQCHC) draft-vicente-lamps-pqchc-01 Abstract 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. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 7 December 2026. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Vicente Expires 7 December 2026 [Page 1] Internet-Draft PQCHC X.509 Extension June 2026 Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Relationship to Existing Work . . . . . . . . . . . . . . 3 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Conventions and Definitions . . . . . . . . . . . . . . . . . 5 4. The PQCHC Extension . . . . . . . . . . . . . . . . . . . . . 5 4.1. Encoding . . . . . . . . . . . . . . . . . . . . . . . . 5 4.2. Processing Rules . . . . . . . . . . . . . . . . . . . . 7 4.3. Interaction with Composite Certificates . . . . . . . . . 8 4.4. Interaction with ACME-ARI . . . . . . . . . . . . . . . . 9 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 5.1. Downgrade Resistance . . . . . . . . . . . . . . . . . . 11 5.2. Commitment-Substitution Attacks . . . . . . . . . . . . . 11 5.3. Pre-Image Attack Surface on committedKeyHash . . . . . . 12 5.4. Hash Algorithm Agility . . . . . . . . . . . . . . . . . 12 6. Implementation Status . . . . . . . . . . . . . . . . . . . . 13 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 7.1. X.509 Certificate Extension OID . . . . . . . . . . . . . 13 7.2. Digest Algorithms for committedKeyHash . . . . . . . . . 14 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 9.1. Normative References . . . . . . . . . . . . . . . . . . 14 9.2. Informative References . . . . . . . . . . . . . . . . . 15 Appendix A. Worked Example: ML-DSA-65 Commitment . . . . . . . . 16 Appendix B. Appendix B. NIST IR 8547 and CNSA 2.0 Migration Timeline . . . . . . . . . . . . . . . . . . . . . . . . 17 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 18 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 18 1. Introduction The finalization of NIST post-quantum standards FIPS 203 [FIPS203], FIPS 204 [FIPS204], and FIPS 205 [FIPS205] establishes the algorithms to which existing PKIs must migrate. NIST IR 8547 [IR8547] sets a deprecation calendar that makes migration time-bounded. Migration of an X.509 [RFC5280] 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 Vicente Expires 7 December 2026 [Page 2] Internet-Draft PQCHC X.509 Extension June 2026 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 [RFC9773]) 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 [RFC9881] (ML-DSA), [RFC9909] (SLH-DSA), and [RFC9935] (ML-KEM). This document uses the post-quantum terminology of [RFC9794]. 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. 1.1. Relationship to Existing Work [I-D.reddy-lamps-x509-pq-commit] 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 ([I-D.ietf-lamps-pq-composite-sigs]) 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 Section 4.3 for the interaction model. 2. Requirements This section states requirements that a conforming PQCHC implementation SHOULD satisfy. REQ-1: A solution MUST embed a cryptographic hash of the future Vicente Expires 7 December 2026 [Page 3] Internet-Draft PQCHC X.509 Extension June 2026 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) [RFC9773] 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 [FIPS204]). 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 [RFC5280] 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 [RFC5280]. 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. Vicente Expires 7 December 2026 [Page 4] Internet-Draft PQCHC X.509 Extension June 2026 3. Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] 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 [RFC9794]. 4. 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 [RFC5280]. 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. 4.1. Encoding PQCHC-2025 { iso(1) identified-organization(3) dod(6) internet(1) private(4) enterprise(1) 65953 modules(0) pqchc(1) } DEFINITIONS IMPLICIT TAGS ::= BEGIN IMPORTS AlgorithmIdentifier Vicente Expires 7 December 2026 [Page 5] Internet-Draft PQCHC X.509 Extension June 2026 FROM PKIX1Explicit88 { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-pkix1-explicit(18) } DigestInfo FROM CryptographicMessageSyntax2004 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) modules(0) cms-2004(24) } EXTENSION FROM PKIX-CommonTypes-2009 { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-pkixCommon-02(57) } ; -- Experimental OID under public PEN arc 1.3.6.1.4.1.65953. -- MUST NOT be used in production; replace with IANA-assigned TBD1. id-ce-pqchc-experimental OBJECT IDENTIFIER ::= { 1 3 6 1 4 1 65953 1 1 } -- Placeholder for permanent IANA assignment (use in deployment). -- id-ce-pqchc OBJECT IDENTIFIER ::= { id-ce TBD1 } ext-pqchc EXTENSION ::= { SYNTAX PQCHCommitment IDENTIFIED BY id-ce-pqchc-experimental } PQCHCommitment ::= SEQUENCE { -- TRUE indicates a binding PQC migration commitment is present. -- FALSE indicates the commitment has been invalidated. commitmentValid BOOLEAN DEFAULT TRUE, -- AlgorithmIdentifier for the committed post-quantum algorithm. -- MUST reference a standardized PQC algorithm OID: -- ML-DSA-44/65/87 (id-ml-dsa-44/65/87 per RFC 9881) -- ML-KEM-512/768/1024 (id-alg-ml-kem-* per RFC 9935) -- SLH-DSA-* (id-slh-dsa-* per RFC 9909) -- For composite algorithms, use the composite OID per -- draft-ietf-lamps-pq-composite-sigs. committedAlgorithm AlgorithmIdentifier, -- DigestInfo over the DER-encoded subjectPublicKeyInfo of the -- committed future key. The digest algorithm 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 output are acceptable. Vicente Expires 7 December 2026 [Page 6] Internet-Draft PQCHC X.509 Extension June 2026 -- 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 [RFC9881], [RFC9935], and [RFC9909] 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 [RFC5280] Section 4.1.2.5.2. * commitmentValid DEFAULT TRUE allows the extension to omit the flag in the common case. 4.2. 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: Vicente Expires 7 December 2026 [Page 7] Internet-Draft PQCHC X.509 Extension June 2026 function VerifyPQCHCCommitment(committingCert, candidatePQCert): # Step 1: Locate and decode the PQCHC extension. ext = committingCert.findExtension(id-ce-pqchc) if ext is absent: return NOT_COMMITTED commitment = DER_DECODE(ext.extnValue, PQCHCommitment) if commitment.commitmentValid == FALSE: return COMMITMENT_INVALIDATED # Step 2: Check the committed algorithm matches the candidate cert. if candidatePQCert.subjectPublicKeyInfo.algorithm != commitment.committedAlgorithm: return ALGORITHM_MISMATCH # Step 3: Compute the hash of the candidate SPKI. spkiBytes = DER_ENCODE(candidatePQCert.subjectPublicKeyInfo) hashAlg = commitment.committedKeyHash.digestAlgorithm computed = HASH(hashAlg, spkiBytes) # Step 4: Compare hashes. if computed != commitment.committedKeyHash.digest: return HASH_MISMATCH # Step 5: Check temporal ordering. if candidatePQCert.validity.notBefore > 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. 4.3. Interaction with Composite Certificates Composite certificates ([I-D.ietf-lamps-pq-composite-sigs]) 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 Vicente Expires 7 December 2026 [Page 8] Internet-Draft PQCHC X.509 Extension June 2026 [I-D.ietf-lamps-pq-composite-sigs], and committedKeyHash MUST be over the DER-encoded composite subjectPublicKeyInfo. Migration Phase Mechanism ------------------------- ---------------------------------------- Pre-migration PQCHC: forward-key-hash commitment (classical cert) to specific PQC algorithm and time Transition Composite ML-DSA: simultaneous (composite cert) classical AND PQ in one certificate Post-migration Pure PQ cert satisfies prior PQCHC (pure PQ cert) commitment; neither mechanism needed 4.4. Interaction with ACME-ARI ACME Renewal Information (ARI) [RFC9773] 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: suggestedWindow.end <= min(certificate.notAfter, commitment.commitmentNotAfter) 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. Vicente Expires 7 December 2026 [Page 9] Internet-Draft PQCHC X.509 Extension June 2026 Client ACME Server | | | GET /renewal-info/ | | (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 [RFC9773] 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 Vicente Expires 7 December 2026 [Page 10] Internet-Draft PQCHC X.509 Extension June 2026 committedKeyHash.digestAlgorithm. An order that fails this check SHOULD be rejected with an orderNotReady error [RFC9773] 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. 5. 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. 5.1. 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. 5.2. 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 Section 5.4. The CA re-issuance path is a CA-compromise scenario; Certificate Transparency provides the same audit-trail mitigation. Vicente Expires 7 December 2026 [Page 11] Internet-Draft PQCHC X.509 Extension June 2026 5.3. 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. 5.4. 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 [IR8547] 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 (Section 4.2) 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 [KyberSlash], [NTTSIS], [ILPFAULT]). CA key-generation practices SHOULD require constant- time implementations of the committed algorithm. Vicente Expires 7 December 2026 [Page 12] Internet-Draft PQCHC X.509 Extension June 2026 6. 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 [RFC7942]. 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 Section 4.2. 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 Section 4.2, and ACME-ARI scheduling integration per Section 4.4. 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. 7. IANA Considerations 7.1. X.509 Certificate Extension OID IANA is requested to assign an object identifier for the PQCHC certificate extension from the id-ce arc: id-ce-pqchc OBJECT IDENTIFIER ::= { id-ce TBD1 } 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: id-ce-pqchc-experimental OBJECT IDENTIFIER ::= { 1 3 6 1 4 1 65953 1 1 } This experimental value MUST NOT be relied upon as the permanent identifier. Deployments MUST transition to the IANA-assigned TBD1 value upon RFC publication. Vicente Expires 7 December 2026 [Page 13] Internet-Draft PQCHC X.509 Extension June 2026 7.2. 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. 8. References 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, . [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running Code: The Implementation Status Section", BCP 205, RFC 7942, DOI 10.17487/RFC7942, July 2016, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC9773] Gable, A., "ACME Renewal Information (ARI) Extension", RFC 9773, DOI 10.17487/RFC9773, June 2025, . [RFC9794] Driscoll, F., Parsons, M., and B. Hale, "Terminology for Post-Quantum Traditional Hybrid Schemes", RFC 9794, DOI 10.17487/RFC9794, June 2025, . [RFC9881] Massimo, J., Kampanakis, P., Turner, S., and B. E. Westerbaan, "Internet X.509 Public Key Infrastructure -- Algorithm Identifiers for the Module-Lattice-Based Digital Signature Algorithm (ML-DSA)", RFC 9881, DOI 10.17487/RFC9881, October 2025, . Vicente Expires 7 December 2026 [Page 14] Internet-Draft PQCHC X.509 Extension June 2026 [RFC9909] Bashiri, K., Fluhrer, S., Gazdag, S., Van Geest, D., and S. Kousidis, "Internet X.509 Public Key Infrastructure -- Algorithm Identifiers for the Stateless Hash-Based Digital Signature Algorithm (SLH-DSA)", RFC 9909, DOI 10.17487/RFC9909, December 2025, . [RFC9935] Turner, S., Kampanakis, P., Massimo, J., and B. E. Westerbaan, "Internet X.509 Public Key Infrastructure - Algorithm Identifiers for the Module-Lattice-Based Key- Encapsulation Mechanism (ML-KEM)", RFC 9935, DOI 10.17487/RFC9935, March 2026, . 9.2. Informative References [CNSA2] NSA, "Commercial National Security Algorithm Suite 2.0", September 2022, . [FIPS203] "Module-Lattice-Based Key-Encapsulation Mechanism Standard", August 2024, . [FIPS204] "Module-Lattice-Based Digital Signature Standard", August 2024, . [FIPS205] "Stateless Hash-Based Digital Signature Standard", August 2024, . [I-D.ietf-lamps-pq-composite-sigs] Ounsworth, M., Gray, J., Pala, M., Klaußner, J., and S. Fluhrer, "Composite Module-Lattice-Based Digital Signature Algorithm (ML-DSA) for use in X.509 Public Key Infrastructure", Work in Progress, Internet-Draft, draft- ietf-lamps-pq-composite-sigs-19, 21 April 2026, . [I-D.reddy-lamps-x509-pq-commit] Reddy.K, T., Gray, J., and Y. Sheffer, "X.509 Extensions for PQC or Composite Certificate Hosting Continuity", Work in Progress, Internet-Draft, draft-reddy-lamps-x509-pq- commit-01, 25 February 2026, . Vicente Expires 7 December 2026 [Page 15] Internet-Draft PQCHC X.509 Extension June 2026 [ILPFAULT] "ILP Fault Recovery on Dilithium / ML-DSA", 2025, . [IR8547] "Transition to Post-Quantum Cryptography Standards (NIST IR 8547)", November 2024, . [KyberSlash] Bernstein, D. J., Ducas, L., Landgraf, E., and N. Mulder, "Exploiting secret-dependent division timings in Kyber implementations", 2025, . [NTTSIS] "Side-Channel-Assisted Cryptanalysis on Post-Quantum Algorithms", 2024, . Appendix A. 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 [RFC9881]) 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): a3 f8 2d 11 cc 4e 9b 7f e1 05 3a 88 d2 60 b9 4c 7d 19 e2 aa 55 fc 3b 0e 84 c7 21 63 09 f4 1b 8e (Synthetic value -- not derived from any real key.) commitmentNotAfter: 20300101000000Z ASN.1 DER encoding of PQCHCommitment (hex): Vicente Expires 7 December 2026 [Page 16] Internet-Draft PQCHC X.509 Extension June 2026 30 56 -- SEQUENCE (86 bytes) 01 01 ff -- BOOLEAN TRUE (commitmentValid) 30 0b -- AlgorithmIdentifier SEQUENCE 06 09 -- OID 60 86 48 01 86 3a 04 03 12 -- 2.16.840.1.101.3.4.3.18 30 27 -- DigestInfo SEQUENCE 30 0d -- digestAlgorithm 06 09 -- OID id-sha256 60 86 48 01 65 03 04 02 01 05 00 -- NULL parameters 04 20 -- OCTET STRING (32 bytes) a3 f8 2d 11 cc 4e 9b 7f e1 05 3a 88 d2 60 b9 4c 7d 19 e2 aa 55 fc 3b 0e 84 c7 21 63 09 f4 1b 8e 18 0f -- GeneralizedTime (15 bytes) 32 30 33 30 30 31 30 31 -- "20300101" 30 30 30 30 30 30 5a -- "000000Z" X.509 extension snippet: Extension ::= SEQUENCE { extnID OBJECT IDENTIFIER -- id-ce-pqchc-experimental (1.3.6.1.4.1.65953.1.1) -- or TBD1 for production deployments critical BOOLEAN DEFAULT FALSE -- absent (non-critical) extnValue OCTET STRING -- DER encoding of PQCHCommitment above } Verification outcome per Section 4.2: 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. Appendix B. NIST IR 8547 and CNSA 2.0 Migration Timeline NIST IR 8547 [IR8547] (initial public draft, November 2024) and the NSA CNSA 2.0 suite [CNSA2] establish the following migration milestones relevant to PQCHC commitment deadlines: Vicente Expires 7 December 2026 [Page 17] Internet-Draft PQCHC X.509 Extension June 2026 +------+---------------------------------------+---------------------+ | Year | Event | PQCHC implication | +------+---------------------------------------+---------------------+ | 2030 | NIST: deprecation of 112-bit classical | commitmentNotAfter | | | asymmetric algorithms | SHOULD precede this | | | | date for lower-sec | | | | environments. | +------+---------------------------------------+---------------------+ | 2031 | CNSA 2.0: full enforcement for | NSS deployments | | | National Security Systems | MUST complete PQC | | | | migration by 2031. | +------+---------------------------------------+---------------------+ | 2035 | NIST: disallowment of new protection | commitmentNotAfter | | | using quantum-vulnerable algorithms | MUST NOT extend | | | | beyond 2035. | +------+---------------------------------------+---------------------+ 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 [I-D.ietf-lamps-pq-composite-sigs]) are therefore consistent with long-term compliance when the composite satisfies that condition. Informative references: [IR8547], [CNSA2]. Acknowledgments The author thanks the LAMPS Working Group for the foundational post- quantum X.509 work on which this extension builds. Author's Address Brian Vicente Sanctum SecOps LLC Email: admin@sanctumsecops.com Vicente Expires 7 December 2026 [Page 18]