Sanctum SecOps LLC

brian@sanctumsecops.io

Security LAMPS post-quantumX.509 certificate extensioncrypto-agility 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 .

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. PQCHC addresses the pre-transition phase. 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.

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.

REQ-7:

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

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.

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.

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.

Committed Algorithm:

the post-quantum algorithm, identified by an OID, 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, expressed as a GeneralizedTime.

CRQC:

Cryptographically Relevant Quantum Computer, 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 per .

Encoding Implementation notes: AlgorithmIdentifier for ML-DSA, ML-KEM, and SLH-DSA MUST carry a non-null algorithm OID with the parameters field absent, consistent with , , and . GeneralizedTime is used rather than UTCTime to support dates beyond 2049, consistent with Section 4.1.2.5.2.

Processing Rules When a subsequently issued certificate for the same subject presents a post-quantum key, the following verification procedure applies: commitment.commitmentNotAfter: return COMMITMENT_EXPIRED return COMMITMENT_HONORED ]]> A relying party MUST NOT treat a PQCHC commitment as a reason to accept a certificate it would otherwise reject. The commitment is advisory.

Interaction with Composite Certificates 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 An ACME CA that wishes to honor PQCHC commitments SHOULD constrain the ARI scheduling window so that suggestedWindow.end is at or before min(certificate.notAfter, commitment.commitmentNotAfter). 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. An order that fails this check SHOULD be rejected with an orderNotReady error.

Security Considerations The commitment is advisory and MUST NOT be treated as authentication of the committed post-quantum key. A commitment MUST NOT downgrade the validation of the certificate in which it appears.

Downgrade Resistance A man-in-the-middle adversary can attempt forced-classical-reissuance during the PQC transition window. Lifecycle automation SHOULD verify that the renewed certificate's SPKI hash matches committedKeyHash. Operators participating in Certificate Transparency can detect classical re-issuance by scanning CT logs for conflicting subject/SPKI combinations after the commitmentNotAfter deadline.

Commitment-Substitution Attacks A commitment-substitution adversary attempts to find a second preimage of the committed SPKI under the digest algorithm. Second-preimage attacks are mitigated by the digest-algorithm requirements in . The CA re-issuance path is a CA-compromise scenario; Certificate Transparency provides audit-trail mitigation.

Pre-Image Attack Surface on committedKeyHash 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.

Hash Algorithm Agility The committedKeyHash field uses DigestInfo, which carries both the hash algorithm OID and the hash value, enabling digest algorithm upgrades without changing the ASN.1 structure. 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 or greater output are acceptable. Operators SHOULD set commitmentNotAfter at or before the NIST IR 8547 deprecation date of the algorithm used to sign the committing certificate. CA key-generation practices SHOULD require constant-time implementations of the committed algorithm (see , , ).

Implementation Status This section is included per . Organization: Sanctum SecOps LLC. An experimental Go implementation covers encoding/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). Maturity: Experimental. MUST NOT be deployed in production without qualified security and legal review.

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: For early interoperability testing, the experimental OID 1.3.6.1.4.1.65953.1.1 under the Sanctum SecOps PEN arc MAY be used. Deployments MUST transition to the IANA-assigned TBD1 value upon RFC publication.

Digest Algorithms for committedKeyHash Acceptable OIDs for 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.

Normative References Informative References NIST NIST NIST NIST NSA NTT Intel

Worked Example: ML-DSA-65 Commitment All values are synthetic test data. Scenario: a server certificate issued with an ECDSA-P256 key commits to migrating to ML-DSA-65 () by 2030-01-01T00:00:00Z.

NIST IR 8547 and CNSA 2.0 Migration Timeline

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