A Post-Quantum Hybrid-Commitment Certificate Extension (PQCHC)
draft-vicente-lamps-pqchc-01
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Active".
|
|
|---|---|---|---|
| Author | Brian Vicente | ||
| Last updated | 2026-06-08 (Latest revision 2026-06-07) | ||
| Replaced by | draft-vicente-lamps-rotation-envelope | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-vicente-lamps-pqchc-01
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> |
| (certID = predecessor cert) |
|---------------------------------->|
| | (1) server decodes PQCHC
| | from predecessor cert
| | (2) sets window.end <=
| | min(notAfter,
| | commitmentNotAfter)
| 200 OK |
| { suggestedWindow: { |
| start: <lead-time>, |
| end: <constrained> }, |
| explanationURL: <uri> } |
|<----------------------------------|
| |
| (client generates new key pair |
| using committedAlgorithm OID) |
| |
| POST /new-order |
| { replaces: <predecessor-certID>,|
| 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,
<https://www.rfc-editor.org/rfc/rfc2119>.
[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,
<https://www.rfc-editor.org/rfc/rfc5280>.
[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,
<https://www.rfc-editor.org/rfc/rfc7942>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
[RFC9773] Gable, A., "ACME Renewal Information (ARI) Extension",
RFC 9773, DOI 10.17487/RFC9773, June 2025,
<https://www.rfc-editor.org/rfc/rfc9773>.
[RFC9794] Driscoll, F., Parsons, M., and B. Hale, "Terminology for
Post-Quantum Traditional Hybrid Schemes", RFC 9794,
DOI 10.17487/RFC9794, June 2025,
<https://www.rfc-editor.org/rfc/rfc9794>.
[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,
<https://www.rfc-editor.org/rfc/rfc9881>.
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,
<https://www.rfc-editor.org/rfc/rfc9909>.
[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,
<https://www.rfc-editor.org/rfc/rfc9935>.
9.2. Informative References
[CNSA2] NSA, "Commercial National Security Algorithm Suite 2.0",
September 2022, <https://www.nsa.gov/Press-Room/News-
Highlights/Article/Article/3148990/>.
[FIPS203] "Module-Lattice-Based Key-Encapsulation Mechanism
Standard", August 2024,
<https://csrc.nist.gov/pubs/fips/203/final>.
[FIPS204] "Module-Lattice-Based Digital Signature Standard", August
2024, <https://csrc.nist.gov/pubs/fips/204/final>.
[FIPS205] "Stateless Hash-Based Digital Signature Standard", August
2024, <https://csrc.nist.gov/pubs/fips/205/final>.
[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,
<https://datatracker.ietf.org/doc/html/draft-ietf-lamps-
pq-composite-sigs-19>.
[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,
<https://datatracker.ietf.org/doc/html/draft-reddy-lamps-
x509-pq-commit-01>.
Vicente Expires 7 December 2026 [Page 15]
Internet-Draft PQCHC X.509 Extension June 2026
[ILPFAULT] "ILP Fault Recovery on Dilithium / ML-DSA", 2025,
<https://www.intel.com/content/www/us/en/security/
security-practices/blogs/fault-injection-attacks.html>.
[IR8547] "Transition to Post-Quantum Cryptography Standards (NIST
IR 8547)", November 2024,
<https://csrc.nist.gov/pubs/ir/8547/ipd>.
[KyberSlash]
Bernstein, D. J., Ducas, L., Landgraf, E., and N. Mulder,
"Exploiting secret-dependent division timings in Kyber
implementations", 2025,
<https://kannwischer.eu/papers/2024_kyberslash.pdf>.
[NTTSIS] "Side-Channel-Assisted Cryptanalysis on Post-Quantum
Algorithms", 2024, <https://eprint.iacr.org/2023/1866>.
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]