PQC Hybrid Commitment (PQCHC) X.509 Extension
draft-vicente-lamps-pqchc-00
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-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-00
LAMPS Working Group B. Vicente
Internet-Draft Sanctum SecOps LLC
Intended status: Informational 8 June 2026
Expires: 10 December 2026
PQC Hybrid Commitment (PQCHC) X.509 Extension
draft-vicente-lamps-pqchc-00
Abstract
The current Internet Public Key Infrastructure (PKI) lacks a machine-
verifiable, cryptographically bound mechanism for certificate holders
to commit, at issuance time, to the specific post-quantum (PQ) or PQ/
T hybrid key material they intend to present at the next certificate
renewal. Without such a mechanism, relying parties cannot
distinguish a legitimate algorithm migration from a covert downgrade
attack — one in which a cryptographically relevant quantum computer
(CRQC) enables an adversary to suppress a PQ or composite certificate
at renewal and substitute one based solely on a classical algorithm
whose long-term security has been compromised.
This document defines the PQC Hybrid Commitment (PQCHC) X.509 v3
extension. The extension carries an advisory, non-authoritative
commitment that is encoded as a cryptographic hash of the future
SubjectPublicKeyInfo the certificate subject intends to present in
the successor certificate, together with the intended committed
algorithm identifier and an expiry time for the commitment. The
extension is non-critical, preserving backward compatibility with
legacy relying parties that do not recognize it. PQCHC-aware relying
parties may use the commitment to detect downgrade at renewal time,
to integrate with ACME Renewal Information (ARI) scheduling, and to
provide an observable signal of an operator's concrete, binding
intent to complete PQ migration within a declared time window.
Source and Archival
This note is to be removed before publishing as an RFC.
Source for this draft is maintained at https://github.com/Sanc-Admin/
lamps-pqchc (https://github.com/Sanc-Admin/lamps-pqchc). A citable
archival version of this document is available at Zenodo:
https://doi.org/10.5281/zenodo.20584243 (https://doi.org/10.5281/
zenodo.20584243). Author ORCID iD:
https://orcid.org/0009-0006-6395-5308
(https://orcid.org/0009-0006-6395-5308).
Vicente Expires 10 December 2026 [Page 1]
Internet-Draft PQCHC June 2026
Discussion of this document occurs on the IETF "spasm" mailing list
(spasm@ietf.org). Issues and pull requests may be filed at the
GitHub repository linked above.
IPR Considerations
This note is to be removed before publishing as an RFC.
The author has filed or intends to file United States patent
applications covering subject matter described in this document. By
posting this Internet-Draft, the author submits to the IETF Trust the
rights described in Section 5 of BCP 78 and BCP 79. Patent licensing
terms are not yet known. Implementers and reviewers should consult
the IETF Datatracker IPR disclosure page for this document for
current disclosure status.
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 10 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.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Vicente Expires 10 December 2026 [Page 2]
Internet-Draft PQCHC June 2026
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Relationship to Existing Work . . . . . . . . . . . . . . 5
1.2. Patent Notice . . . . . . . . . . . . . . . . . . . . . . 6
2. Conventions and Definitions . . . . . . . . . . . . . . . . . 6
3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 7
3.1. The Harvest-Now-Decrypt-Later and
Transcript-Now-Forge-Later Threats . . . . . . . . . . . 8
3.2. The Multi-Year Migration Window . . . . . . . . . . . . . 9
3.3. The Downgrade-at-Renewal Gap . . . . . . . . . . . . . . 9
3.4. Why Temporal Declarations Are Insufficient Without
Cryptographic Binding . . . . . . . . . . . . . . . . . . 10
4. Requirements for a Forward Key Commitment Extension . . . . . 11
5. The PQCHC Extension . . . . . . . . . . . . . . . . . . . . . 12
5.1. Extension Overview . . . . . . . . . . . . . . . . . . . 12
5.2. ASN.1 Module . . . . . . . . . . . . . . . . . . . . . . 13
5.3. Field Definitions . . . . . . . . . . . . . . . . . . . . 14
5.3.1. commitmentValid . . . . . . . . . . . . . . . . . . . 14
5.3.2. committedAlgorithm . . . . . . . . . . . . . . . . . 14
5.3.3. futureKeyCommitment . . . . . . . . . . . . . . . . . 15
5.3.4. commitmentNotAfter . . . . . . . . . . . . . . . . . 16
5.3.5. policyURI . . . . . . . . . . . . . . . . . . . . . . 16
5.4. Processing Rules . . . . . . . . . . . . . . . . . . . . 17
5.4.1. Certificate Issuance . . . . . . . . . . . . . . . . 17
5.4.2. Certificate Consumption by PQCHC-Aware Relying
Parties . . . . . . . . . . . . . . . . . . . . . . . 17
5.4.3. Renewal and Commitment Fulfillment . . . . . . . . . 18
5.4.4. Downgrade Detection . . . . . . . . . . . . . . . . . 19
5.4.5. Integration with ACME Renewal Information (ARI) . . . 20
6. Security Considerations . . . . . . . . . . . . . . . . . . . 21
6.1. Advisory, Not Authoritative . . . . . . . . . . . . . . . 21
6.2. Preimage Resistance and Hash Algorithm Selection . . . . 21
6.3. Public Key Correlation . . . . . . . . . . . . . . . . . 22
6.4. Commitment Substitution Attack . . . . . . . . . . . . . 22
6.5. CRQC-Era Considerations . . . . . . . . . . . . . . . . . 23
6.6. Downgrade-Forcing Attack . . . . . . . . . . . . . . . . 24
6.7. TOFU Bootstrap Problem . . . . . . . . . . . . . . . . . 24
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
7.1. id-pe OID Assignment . . . . . . . . . . . . . . . . . . 25
7.2. Experimental OID Arc . . . . . . . . . . . . . . . . . . 25
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 26
8.1. Normative References . . . . . . . . . . . . . . . . . . 26
8.2. Informative References . . . . . . . . . . . . . . . . . 26
Appendix A. Appendix A: Example PQCHC Extension DER Encoding . . 28
A.1. Certificate Subject Scenario . . . . . . . . . . . . . . 28
A.2. ASN.1 Value (Informative) . . . . . . . . . . . . . . . . 28
Vicente Expires 10 December 2026 [Page 3]
Internet-Draft PQCHC June 2026
Appendix B. Appendix B: Relationship to NIST IR 8547 Migration
Timeline . . . . . . . . . . . . . . . . . . . . . . . . 29
Appendix C. Appendix C: Comparison with Related Mechanisms . . . 30
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 31
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 31
1. Introduction
The standardization of post-quantum cryptographic (PQC) algorithms by
the National Institute of Standards and Technology (NIST) —
specifically ML-DSA [FIPS204], ML-KEM [FIPS203], and SLH-DSA
[FIPS205] — marks an inflection point for Internet PKI. NIST IR 8547
[NIST-IR-8547] establishes that all quantum-vulnerable traditional
asymmetric algorithms are to be deprecated after 2030 and disallowed
for new protection after 2035. The CNSA 2.0 suite [CNSA2] requires
National Security Systems to be fully compliant by 2031. Operators
of long-lived PKI infrastructure must therefore plan and execute
algorithm migrations across a multi-year window that spans
certificate lifetimes currently in service.
ML-DSA [FIPS204] and ML-KEM [FIPS203] are founded on the hardness of
Module Learning With Errors (MLWE) and Module Short Integer Solution
(MSIS) problems over polynomial rings — lattice-based problems for
which no efficient quantum algorithm is known. SLH-DSA [FIPS205] is
founded on the collision resistance of cryptographic hash functions,
providing security even against adversaries with quantum computers
running Grover's algorithm [GROVER1996], subject to the hash length
requirements discussed in Section 6.2.
The LAMPS Working Group has made substantial progress in defining how
PQ and PQ/T hybrid algorithms are encoded in X.509 certificates.
Composite ML-DSA [I-D.ietf-lamps-pq-composite-sigs] defines 18
composite signature algorithm identifiers; Composite ML-KEM
[I-D.ietf-lamps-pq-composite-kem] defines 12 composite KEM
identifiers. RFC 9763 [RFC9763] allows a current traditional
certificate and a current PQ certificate to be bound to the same
subject. The certificate discovery mechanism
[I-D.ietf-lamps-certdiscovery] enables a primary certificate to point
to a secondary certificate already issued.
Despite this progress, a specific lifecycle gap remains unaddressed:
no existing mechanism allows a certificate holder to make a
cryptographically verifiable commitment, in the current certificate,
to the specific PQ key material that will appear in the successor
certificate. [I-D.reddy-lamps-x509-pq-commit] provides a
continuityPeriod field that declares, in days, the subject's intent
to continue presenting PQC or composite certificates after the
current certificate's notAfter. This is a valuable declaration of
Vicente Expires 10 December 2026 [Page 4]
Internet-Draft PQCHC June 2026
temporal intent, but it does not bind that intent to any specific
future key. A relying party that caches this declaration cannot
determine whether the key in a future renewal certificate matches
what was actually intended at the time of issuance — nor can it
detect a key substitution by an adversary.
This document addresses that gap by defining a PQCHC extension that:
1. Carries a cryptographic hash of the future SubjectPublicKeyInfo
(SPKI) in a FutureKeyCommitment structure, binding the commitment
to specific key material.
2. Encodes the intended committed algorithm identifier alongside the
hash, enabling relying parties to assess algorithm support
without awaiting the successor certificate.
3. Declares a commitmentNotAfter time after which the commitment is
considered expired and MUST NOT be enforced.
4. Provides an optional policyURI where operators may publish human-
readable migration commitments and supporting documentation.
5. Remains non-critical per RFC 5280 [RFC5280] Section 4.2, so
legacy relying parties that do not recognize the extension will
ignore it, preserving backward compatibility throughout the
migration window.
The PQCHC extension is advisory and non-authoritative. The extension
does not modify RFC 5280 path validation semantics. Enforcement of
the commitment is left to PQCHC-aware application software,
certificate policy, and relying-party trust decisions.
1.1. Relationship to Existing Work
The design of PQCHC is informed by several related efforts:
*draft-reddy-lamps-x509-pq-commit* [I-D.reddy-lamps-x509-pq-commit]:
The closest direct predecessor. That document defines a
continuityPeriod integer expressing the number of days beyond
notAfter during which the subject intends to continue presenting PQC
or composite certificates. PQCHC addresses the explicit gap noted in
that draft: the absence of any cryptographic binding to a specific
future key.
*draft-ounsworth-lamps-pq-external-pubkeys*
[I-D.ounsworth-lamps-pq-external-pubkeys]: This expired individual
submission references a current external public key by hash. PQCHC
extends the same hash-of-SPKI principle into the forward-commitment
Vicente Expires 10 December 2026 [Page 5]
Internet-Draft PQCHC June 2026
dimension: rather than referencing a key that exists today, the PQCHC
commitment references a key that is intended for use in the future
successor certificate.
*RFC 9763* [RFC9763]: Binds a current traditional certificate and a
current PQ certificate to the same subject identity. RFC 9763
addresses horizontal binding between coexisting certificates; PQCHC
addresses vertical, forward binding between a current certificate and
its future successor.
*draft-ietf-lamps-certdiscovery* [I-D.ietf-lamps-certdiscovery]:
Points to a secondary certificate via hash and URI. The secondary
certificate must already exist. PQCHC targets the prior period
before the successor certificate has been issued.
*Composite ML-DSA* [I-D.ietf-lamps-pq-composite-sigs] and *Composite
ML-KEM* [I-D.ietf-lamps-pq-composite-kem]: Define how composite keys
are encoded in current X.509 structures. They contain no commitment
mechanism, no downgrade signaling, and no lifecycle integration.
PQCHC is complementary: it can commit to either a pure ML-DSA/ML-KEM
key or a composite key as the intended successor.
*RFC 9773 (ACME ARI)* [RFC9773]: Defines the ACME Renewal Information
extension, including renewalInfo, suggestedWindow, and the replaces
field. Section 5.4 of this document describes how a PQCHC-bearing
certificate can be integrated with ARI to schedule commitment-aware
renewals before the commitmentNotAfter deadline.
1.2. Patent Notice
The authors are not aware of any patent or patent application that
covers the mechanisms described in this document. This notice is
provided pursuant to IETF BCPs on intellectual property.
2. 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. Terms defined
in RFC 9794 [RFC9794] ("PQ/T Hybrid terminology") are used in
accordance with the definitions therein.
Vicente Expires 10 December 2026 [Page 6]
Internet-Draft PQCHC June 2026
*Committed Algorithm:* The post-quantum or PQ/T hybrid algorithm that
the certificate subject declares it intends to use in the successor
certificate, identified by an AlgorithmIdentifier in the PQCHC
extension.
*Committed Key Hash:* A cryptographic hash computed over the DER
encoding of the intended future SubjectPublicKeyInfo, bound in the
FutureKeyCommitment structure of the PQCHC extension. The hash
serves as a pre-commitment to specific future key material.
*Commitment Validity Time (commitmentNotAfter):* The GeneralizedTime
value in the PQCHC extension beyond which the commitment is
considered expired. A PQCHC-aware relying party MUST NOT enforce
downgrade detection semantics after this time has passed.
*FutureKeyCommitment:* The ASN.1 structure within the PQCHC extension
that carries the hash algorithm identifier, the Committed Key Hash,
and an optional algorithm hint for the future key.
*Issuance-Time Policy Binding:* The property that the Committed Key
Hash is embedded in the certificate at issuance and signed by the
issuing CA, making the commitment part of the CA-signed certificate
content. The CA's signature over the PQCHC extension binds the
commitment to the certificate subject and the issuance time.
*CRQC:* A cryptographically relevant quantum computer — one with
sufficient qubit depth and fidelity to threaten the security of
classical asymmetric algorithms such as RSA, ECDSA, and ECDH.
*HNDL / TNFL:* Harvest-Now-Decrypt-Later (HNDL) or Transcript-Now-
Forge-Later (TNFL): a threat model in which an adversary records
classical-algorithm-protected traffic today and decrypts or forges it
once a CRQC becomes available.
*SPKI:* SubjectPublicKeyInfo — the ASN.1 structure defined in RFC
5280 that encodes a subject's public key and its associated algorithm
identifier.
*Successor Certificate:* The certificate issued to renew or replace
the current certificate. The PQCHC extension commits to the SPKI
that is intended to appear in the successor certificate.
3. Problem Statement
Vicente Expires 10 December 2026 [Page 7]
Internet-Draft PQCHC June 2026
3.1. The Harvest-Now-Decrypt-Later and Transcript-Now-Forge-Later
Threats
Adversaries with sufficient resources are believed to be collecting
encrypted data and signed records today under the expectation that a
CRQC will eventually be available to break the underlying classical
algorithms. For long-lived secrets, key establishment material, and
non-repudiation records, this "harvest" phase has effectively already
begun. NIST IR 8547 [NIST-IR-8547] projects a 2035 hard cutoff for
applying new cryptographic protection using quantum-vulnerable
algorithms.
The specific threat to PKI arises from two quantum algorithms.
Shor's algorithm [SHOR1994] solves the Integer Factorization Problem
(IFP) and the Elliptic Curve Discrete Logarithm Problem (ECDLP) in
polynomial quantum time, directly breaking the security of RSA (whose
security rests on IFP) and ECDSA/ECDH (whose security rests on
ECDLP). A certificate whose public key uses RSA-2048, P-256, or any
elliptic curve group of equivalent classical security is rendered
completely insecure by a sufficiently capable CRQC running Shor's
algorithm. Grover's algorithm [GROVER1996] provides a quadratic
speedup for unstructured search, effectively halving the bit-security
of symmetric keys and hash functions; this motivates the SHA-384/
SHA-512 requirements in Section 4 and Section 6.2 of this document.
The urgency of PQ migration is further quantified by Mosca's
inequality [MOSCA2018]: if the sum of (1) the time remaining until a
CRQC is available and (2) the secrecy lifetime required for data
protected today exceeds the time available to complete a migration,
then migration should be treated as overdue. For long-lived PKI root
certificates with 25-year validity periods, Mosca's inequality
implies that migration cannot be safely deferred even if a CRQC is
not expected for a decade or more. The PQCHC extension directly
addresses the migration phase that Mosca's inequality makes urgent:
providing a machine-verifiable, cryptographically bound mechanism for
orderly per-certificate PQ transition.
The HNDL and TNFL threat models share a common implication for PKI:
the window between when a classical key is first used and when a CRQC
breaks it is the exposure window. Narrowing this window requires
early, orderly migration to PQ algorithms — a process that spans
multiple certificate issuance cycles.
Vicente Expires 10 December 2026 [Page 8]
Internet-Draft PQCHC June 2026
3.2. The Multi-Year Migration Window
A typical TLS end-entity certificate has a validity period of 90 days
to two years. A root CA certificate may have a validity period of 25
years. The multi-year migration window created by NIST IR 8547
timelines means that multiple successive certificate issuance events
must each move incrementally toward a fully PQ or PQ/T hybrid PKI.
During this window, the same domain or service will present different
certificates at successive renewal events — some classical, some
composite, and eventually some fully PQ.
This creates the downgrade-at-renewal gap: an adversary who can
present a forged or substitute classical certificate at the moment of
renewal, preventing the PQ or composite certificate from being issued
or accepted, gains access to encrypted traffic for the lifetime of
that substitute certificate.
3.3. The Downgrade-at-Renewal Gap
Downgrade attacks during the migration window take the following
form:
1. The current certificate is about to expire or be renewed.
2. The legitimate operator has generated a PQ or composite successor
key and intends to request issuance of a PQ or composite
successor certificate.
3. An adversary, potentially equipped with a CRQC, intercepts or
influences the renewal process — for example, by forging ACME
order responses, by suppressing the PQ certificate in TLS
negotiation, or by exploiting CA issuance policies that still
accept classical CSRs.
4. The certificate presented after renewal is classical rather than
PQ.
5. The relying party, lacking any machine-verifiable record of the
prior commitment to a PQ key, accepts the classical certificate.
The adversary has achieved an undetectable downgrade. The relying
party has no basis to reject the classical certificate because no
prior commitment was recorded in the previous certificate.
Vicente Expires 10 December 2026 [Page 9]
Internet-Draft PQCHC June 2026
3.4. Why Temporal Declarations Are Insufficient Without Cryptographic
Binding
[I-D.reddy-lamps-x509-pq-commit] defines a continuityPeriod field
that declares the number of days beyond notAfter that the subject
intends to present PQC or composite certificates. This declaration
addresses the observation-based heuristic: if a relying party has
previously seen a PQC certificate for a given subject, it may treat
the absence of a PQC certificate during the continuity window as
suspicious.
However, temporal declarations without cryptographic binding have the
following limitations:
1. *No key specificity:* The declaration says "we will use some PQ
algorithm" but does not commit to which key. An adversary who
generates a different PQ key pair and presents it at renewal
bypasses the downgrade heuristic entirely — the relying party
observes a PQ certificate and accepts it, not knowing a key
substitution occurred.
2. *TOFU bootstrap problem:* A relying party that connects to a
service for the first time during the migration window may never
have seen a PQCHC-bearing certificate. It has no cached
commitment to use as a downgrade baseline.
3. *Silent cessation:* If the operator or an adversary presents a
classical certificate without revoking the prior PQ certificate,
the temporal declaration cannot distinguish intentional policy
change from attack. The draft acknowledges this as an open
problem.
4. *No ACME-ARI integration:* The temporal declaration provides no
hook for automated certificate management systems to schedule
commitment-aware renewals that verify the PQ key material is
consistent with what was committed at issuance time.
A cryptographically bound commitment to specific future key material
addresses each of these gaps. Cryptographic binding means:
* The CA's signature over the commitment makes substitution of the
committed hash a forgery that any verifier can detect.
* The hash of the future SPKI is specific to a particular key, not
merely an algorithm family declaration.
* The commitmentNotAfter field provides a machine-processable
schedule anchor that ACME-ARI can act on.
Vicente Expires 10 December 2026 [Page 10]
Internet-Draft PQCHC June 2026
4. Requirements for a Forward Key Commitment Extension
This section states requirements that a solution to the downgrade-at-
renewal gap SHOULD satisfy. These requirements are stated in
abstract, non-implementation-specific language.
REQ-1: *Forward SPKI Hash Binding.* A solution MUST provide a
mechanism for embedding a cryptographic hash of the future
SubjectPublicKeyInfo in the current certificate, in a field that is
covered by the CA's signature. The hash algorithm used MUST itself
be post-quantum resistant (i.e., resistant to the Grover speedup on
second-preimage search, which reduces SHA-256's effective quantum
second-preimage resistance from 256 bits to approximately 128 bits,
and SHA-384's from 384 bits to approximately 192 bits). SHA-384 or
SHA-512, or their SHA-3 equivalents of equivalent or greater length,
SHOULD be used.
REQ-2: *Committed Algorithm Identification.* 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: *Machine-Verifiable Downgrade Detection.* A PQCHC-aware
relying party MUST be able to verify, at the time of observing a
successor certificate, whether the SPKI in that certificate matches
the Committed Key Hash in the predecessor certificate. A mismatch
MUST be treated as a commitment failure.
REQ-4: *Commitment Validity Window.* A solution MUST include a
commitment expiry time (commitmentNotAfter) expressed as a
GeneralizedTime. Relying parties MUST NOT enforce commitment
semantics after this time has passed. The commitmentNotAfter value
SHOULD be set to a time no later than the latest date by which the
operator's declared algorithm migration policy requires completion.
REQ-5: *ACME-ARI Scheduling Hook.* A solution SHOULD be integrable
with ACME Renewal Information (ARI) [RFC9773] so that a CA or ACME
server can trigger a renewal with a suggestedWindow that falls at or
before commitmentNotAfter. The renewal SHOULD result in a successor
certificate whose SPKI matches the Committed Key Hash.
REQ-6: *NIST Security Level Identification.* The committed algorithm
SHOULD be specified with sufficient precision to allow relying
parties to identify the NIST security level of the intended future
key. For ML-DSA, this corresponds to the distinction between ML-DSA-
44, ML-DSA-65, and ML-DSA-87 as defined in [FIPS204].
Vicente Expires 10 December 2026 [Page 11]
Internet-Draft PQCHC June 2026
REQ-7: *Policy URI Binding.* A solution SHOULD provide an optional
URI field pointing to a human-readable or machine-parseable policy
document that describes the operator's algorithm migration schedule
and commitment governance.
REQ-8: *Non-Critical, Legacy-Safe Deployment.* A solution MUST be
deployable as a non-critical X.509 v3 extension per RFC 5280
[RFC5280] Section 4.2. Legacy relying parties that do not recognize
the extension MUST be unaffected — the extension MUST NOT cause them
to reject the certificate. PQCHC-aware behavior is layered on top of
the existing RFC 5280 path validation semantics, not substituted for
them.
REQ-9: *DER Encoding.* The extension value MUST be encoded in
Distinguished Encoding Rules (DER) as specified in [RFC5280]
Section 1. All internal fields MUST use DER canonical encoding.
REQ-10: *Experimental Deployability.* Prior to formal IANA assignment
of an id-pe OID, 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.
5. The PQCHC Extension
5.1. Extension Overview
The PQC Hybrid Commitment (PQCHC) extension is an X.509 v3 extension
under the id-pe arc ([RFC5280] Section 4.2.2). The extension MUST be
marked non-critical.
The extension carries an advisory, non-authoritative statement from
the certificate subject (as recorded by the issuing CA) that:
1. The subject intends the named committed algorithm to be present
in the successor certificate issued before commitmentNotAfter.
2. The specific key material for that successor certificate is
identified by a cryptographic hash over the future
SubjectPublicKeyInfo, if the FutureKeyCommitment field is
present.
3. A policy URI, if present, identifies further operator-published
commitment governance documentation.
The extension content is covered by the issuing CA's signature over
the tbsCertificate, providing Issuance-Time Policy Binding (see
Section 3 definitions).
Vicente Expires 10 December 2026 [Page 12]
Internet-Draft PQCHC June 2026
5.2. ASN.1 Module
PQCHC-2026
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0) TBD1 }
DEFINITIONS IMPLICIT TAGS ::= BEGIN
IMPORTS
EXTENSION
FROM PKIX-CommonTypes-2009
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0) 57 }
AlgorithmIdentifier{}
FROM PKIX1Algorithms2008
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0) 45 }
id-pe
FROM PKIX1Explicit-2009
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0) 51 } ;
-- Object Identifier for the PQCHC Extension
id-pe-pqchc OBJECT IDENTIFIER ::= { id-pe TBD2 }
-- The PQCHC Extension
ext-PQCHC EXTENSION ::= {
SYNTAX PQCHCommitment
IDENTIFIED BY id-pe-pqchc }
-- Main Extension Structure
PQCHCommitment ::= SEQUENCE {
commitmentValid BOOLEAN,
committedAlgorithm AlgorithmIdentifier { ALGORITHM, {...} },
futureKeyCommitment FutureKeyCommitment OPTIONAL,
commitmentNotAfter GeneralizedTime,
policyURI IA5String OPTIONAL
}
-- Future Key Commitment Structure
FutureKeyCommitment ::= SEQUENCE {
hashAlgorithm AlgorithmIdentifier { DIGEST-ALGORITHM, {...} },
spkiHash OCTET STRING,
keyAlgorithmHint AlgorithmIdentifier { ALGORITHM, {...} } OPTIONAL
Vicente Expires 10 December 2026 [Page 13]
Internet-Draft PQCHC June 2026
}
END
5.3. Field Definitions
5.3.1. commitmentValid
The commitmentValid field is a BOOLEAN indicating whether the
commitment encoded in this extension is currently asserted as valid
by the certificate subject.
* A value of TRUE indicates the subject is asserting an active
commitment. This is the normative case.
* A value of FALSE indicates the commitment has been explicitly
rescinded by the subject (e.g., due to a change in key generation
schedule). A PQCHC-aware relying party that observes
commitmentValid set to FALSE in a certificate MUST treat any prior
cached commitment for this subject as revoked. Issuance of a
certificate with commitmentValid FALSE is the mechanism by which
subjects signal commitment revocation without revoking the
certificate itself.
Conforming implementations MUST include this field.
5.3.2. committedAlgorithm
The committedAlgorithm field is an AlgorithmIdentifier identifying
the post-quantum or PQ/T hybrid algorithm the subject intends to use
in the successor certificate.
The AlgorithmIdentifier MUST identify a post-quantum or composite
algorithm. AlgorithmIdentifiers for ML-DSA variants are defined in
the LAMPS ML-DSA certificate profile (draft-ietf-lamps-dilithium-
certificates). AlgorithmIdentifiers for composite algorithms are
defined in [I-D.ietf-lamps-pq-composite-sigs] (for signatures) and
[I-D.ietf-lamps-pq-composite-kem] (for KEMs).
A PQCHC-aware relying party SHOULD verify that the algorithm OID in
the committedAlgorithm field is an algorithm the relying party
supports, as an early signal of future interoperability.
Vicente Expires 10 December 2026 [Page 14]
Internet-Draft PQCHC June 2026
5.3.3. futureKeyCommitment
The futureKeyCommitment field is OPTIONAL. When present, it contains
a FutureKeyCommitment structure binding the commitment to a specific
public key value. When absent, the commitment is algorithm-level
only (an advisory declaration of which algorithm will be used),
without binding to specific key material.
Implementations that wish to enable REQ-3 (machine-verifiable
downgrade detection at the key level) MUST include this field. Its
omission reduces the strength of the commitment to algorithm-level
intent only.
5.3.3.1. hashAlgorithm
The hashAlgorithm field in FutureKeyCommitment is an
AlgorithmIdentifier specifying the hash algorithm used to compute
spkiHash. The hash is computed over the full DER encoding of the
future SubjectPublicKeyInfo.
The hash algorithm MUST provide at least 256 bits of preimage
resistance. Implementations SHOULD use SHA-384 or SHA-512
([FIPS180]), or SHA3-384 or SHA3-512 ([FIPS202]). Use of SHA-256 is
permitted but not recommended, as its effective quantum-collision
resistance is reduced to approximately 85 bits under the Grover
algorithm. Implementations MUST NOT use MD5, SHA-1, or SHA-224.
5.3.3.2. spkiHash
The spkiHash field is an OCTET STRING containing the output of
hashAlgorithm applied to the DER encoding of the full
SubjectPublicKeyInfo that is intended to appear in the successor
certificate.
spkiHash = Hash( hashAlgorithm, DER( future-SubjectPublicKeyInfo ) )
The DER encoding of SubjectPublicKeyInfo is taken over the complete
ASN.1 structure including the AlgorithmIdentifier and the
subjectPublicKey BIT STRING, as defined in RFC 5280 [RFC5280]
Section 4.1.
Vicente Expires 10 December 2026 [Page 15]
Internet-Draft PQCHC June 2026
5.3.3.3. keyAlgorithmHint
The keyAlgorithmHint field is OPTIONAL. When present, it provides
the AlgorithmIdentifier for the algorithm used to generate the
committed key, as a convenience for relying parties that wish to
assess future algorithm compatibility before the successor
certificate is issued. In most cases, keyAlgorithmHint and
committedAlgorithm will carry the same OID, and keyAlgorithmHint MAY
be omitted. keyAlgorithmHint is useful when committedAlgorithm is a
composite OID and the relying party needs to independently assess
each component's compatibility.
5.3.4. commitmentNotAfter
The commitmentNotAfter field is a GeneralizedTime value specifying
the last time at which the commitment is asserted to be valid. After
this time, a PQCHC-aware relying party MUST NOT rely on the
commitment for downgrade detection.
The commitmentNotAfter value:
* SHOULD NOT be later than the certificate's own notAfter field plus
the maximum expected renewal lead time for the operator's
environment. Excessively long commitmentNotAfter values prolong
the exposure window if the committed key is later compromised.
* SHOULD be set so as to fall before or coincident with any
applicable regulatory or compliance deadline (e.g., NIST IR 8547
2035 cutoff, or CNSA 2.0 2031 enforcement date [CNSA2]).
* MUST be expressed in the format "YYYYMMDDHHMMSSZ" per RFC 5280
[RFC5280] Section 4.1.2.5.
5.3.5. policyURI
The policyURI field is OPTIONAL. When present, it is an IA5String
containing a URI that points to a human-readable or machine-parseable
document where the operator publishes its PQ algorithm migration
policy, key custody procedures, and commitment governance
documentation.
Relying parties SHOULD NOT require the URI to be resolvable at
certificate validation time. The URI is informational; its
availability and content are outside the scope of this specification.
Vicente Expires 10 December 2026 [Page 16]
Internet-Draft PQCHC June 2026
5.4. Processing Rules
5.4.1. Certificate Issuance
1. The certificate subject SHALL generate the intended future PQ or
composite key pair before requesting issuance of a certificate
containing the PQCHC extension.
2. The subject computes spkiHash = Hash(hashAlgorithm, DER(future-
SPKI)) over the full DER encoding of the future
SubjectPublicKeyInfo.
3. The subject includes the FutureKeyCommitment in the Certificate
Signing Request (CSR) or in a separate signed commitment
attestation submitted to the CA.
4. The issuing CA MUST verify that the commitmentValid field is TRUE
before embedding an active commitment.
5. The issuing CA MUST verify that the committedAlgorithm OID refers
to a post-quantum or composite algorithm. A CA MUST NOT issue a
certificate with a PQCHC extension in which committedAlgorithm
identifies a classical-only algorithm.
6. The issuing CA SHOULD verify that commitmentNotAfter is not less
than the current time plus a reasonable minimum commitment window
(e.g., at least as long as the certificate's own validity
period).
7. The extension MUST be marked non-critical (criticality = FALSE).
8. The CA signs the tbsCertificate, which includes the extension,
thereby providing Issuance-Time Policy Binding over the
commitment.
5.4.2. Certificate Consumption by PQCHC-Aware Relying Parties
1. Upon processing a certificate containing a PQCHC extension, a
PQCHC-aware relying party:
a. Verifies the certificate chain per RFC 5280 [RFC5280] path
validation (Section 6) without modification. The PQCHC
extension does not alter path validation semantics.
b. If commitmentValid is FALSE, clears any previously cached
commitment for the subject and treats this certificate as
having no active forward commitment.
Vicente Expires 10 December 2026 [Page 17]
Internet-Draft PQCHC June 2026
c. If commitmentValid is TRUE and the current time is before
commitmentNotAfter, stores the following commitment record
for the subject's identity (e.g., SubjectAltName):
* The committed algorithm OID.
* The FutureKeyCommitment (hashAlgorithm, spkiHash,
keyAlgorithmHint), if present.
* The commitmentNotAfter value.
* The policyURI, if present.
* The issuer and serial number of the current certificate
(for correlation with ACME replaces tracking per
[RFC9773]).
2. The commitment record MUST be purged when:
a. The current time exceeds commitmentNotAfter.
b. A successor certificate is accepted whose SPKI matches the
Committed Key Hash (successful commitment fulfillment; see
Section 5.3).
c. A certificate with commitmentValid = FALSE is received for
the subject.
d. The relying party's local policy for commitment record
retention has been exceeded (implementation-defined).
5.4.3. Renewal and Commitment Fulfillment
1. When a PQCHC-aware relying party encounters a successor
certificate for a subject for which a commitment record exists:
a. Compute CandidateHash = Hash(hashAlgorithm from commitment
record, DER(SPKI of successor certificate)).
b. Compare CandidateHash to the spkiHash in the commitment
record.
c. If the hashes match: the commitment is FULFILLED. The
relying party SHOULD accept the successor certificate
(subject to normal RFC 5280 path validation) and SHOULD log
the commitment fulfillment event. The commitment record is
purged per Section 5.2(2b).
Vicente Expires 10 December 2026 [Page 18]
Internet-Draft PQCHC June 2026
d. If the hashes do NOT match: the commitment is VIOLATED. The
relying party MUST treat this as a commitment failure. The
appropriate response is implementation-defined and MAY
include:
* Rejecting the successor certificate for PQCHC-dependent
application-layer operations.
* Generating an alert or log entry indicating a commitment
failure event.
* Initiating out-of-band confirmation with the certificate
subject via the policyURI.
A relying party MUST NOT silently accept a successor
certificate with a commitment violation when the
FutureKeyCommitment field was present and commitmentValid was
TRUE in the predecessor certificate.
2. If the FutureKeyCommitment field is absent in the predecessor
certificate, the commitment is algorithm-level only. In this
case, a PQCHC-aware relying party SHOULD verify that the
successor certificate's SPKI algorithm OID matches the
committedAlgorithm OID. A mismatch between the committed
algorithm and the successor certificate's key algorithm SHOULD be
treated as a commitment failure.
5.4.4. Downgrade Detection
1. If a PQCHC-aware relying party holds a commitment record for a
subject with commitmentNotAfter in the future, and the relying
party encounters a certificate for that subject whose SPKI is
based solely on a classical algorithm (RSA, ECDSA, ECDH, EdDSA in
standalone non-composite form):
a. The relying party SHOULD treat this as a potential downgrade
event.
b. The relying party MUST NOT accept the certificate for PQCHC-
dependent operations without additional out-of-band
assurance.
c. The relying party SHOULD log the downgrade event, including
the subject identity, the committed algorithm OID, and the
observed classical algorithm OID.
2. A commitment failure and a potential downgrade event are
distinct:
Vicente Expires 10 December 2026 [Page 19]
Internet-Draft PQCHC June 2026
* A commitment failure occurs when the SPKI hash does not match
the Committed Key Hash (key substitution case).
* A downgrade event occurs when the algorithm family is
classical rather than PQ or composite (algorithm regression
case).
Both are treated as protocol violations for PQCHC-dependent
operations.
5.4.5. Integration with ACME Renewal Information (ARI)
ACME Renewal Information [RFC9773] provides the renewalInfo resource,
suggestedWindow, and replaces field. The following integration is
RECOMMENDED for operators using ACME certificate management:
1. *Scheduling:* When an ACME server manages certificates bearing
the PQCHC extension, the suggestedWindow in the renewalInfo
resource for that certificate SHOULD be set to begin no later
than a reasonable lead time before commitmentNotAfter. This
ensures the renewal process completes and the successor
certificate is issued while the commitment is still in force.
2. *Replacement tracking:* When an ACME order is submitted to renew
a PQCHC-bearing certificate, the replaces field in the new ACME
Order SHOULD reference the predecessor certificate (by the
{issuer, serial} identifier as defined in [RFC9773] Section 5).
This allows the CA and relying parties to correlate the renewal
with the outstanding commitment.
3. *PQ key validation at order time:* A CA that receives an ACME
Order with a replaces field referencing a PQCHC-bearing
predecessor certificate SHOULD verify that the SPKI in the new
Order's CSR matches the spkiHash in the predecessor's
FutureKeyCommitment. If the hash does not match, the CA SHOULD
reject the Order with an appropriate error indicating a
commitment mismatch.
This step is OPTIONAL for CAs that do not implement PQCHC-aware
order validation, and it requires the CA to have access to the
predecessor certificate — which is typically possible via the
issuer's own certificate repository or the replaces reference.
4. *Explanation URL:* The CA MAY set the explanationURL field of the
renewalInfo resource to the same URI as the policyURI in the
PQCHC extension, providing consistent reference between the ACME
renewal workflow and the commitment governance documentation.
Vicente Expires 10 December 2026 [Page 20]
Internet-Draft PQCHC June 2026
6. Security Considerations
6.1. Advisory, Not Authoritative
The PQCHC extension is advisory and non-authoritative. The
commitment expressed in the extension is made by the certificate
subject and recorded by the CA; it is not a guarantee enforceable by
technical protocol alone. A relying party's response to a commitment
violation is a matter of local policy.
A certificate subject that includes the PQCHC extension but fails to
honor the commitment (by presenting a classical or non-matching key
at renewal) incurs a protocol violation that PQCHC-aware relying
parties may detect and act upon. The extension is analogous to a
published service commitment — machine-verifiable and CA-attested,
but not self-executing.
6.2. Preimage Resistance and Hash Algorithm Selection
The security of the spkiHash commitment depends on the second-
preimage resistance of the hashAlgorithm. An adversary who can find
a second preimage can substitute a different future key while
maintaining the hash match.
For a hash algorithm providing n bits of output, the relevant
security properties for the spkiHash commitment are:
* *Second-preimage resistance* (finding a different input with the
same hash): classically 2^n operations; under Grover's algorithm
applied to second-preimage search, approximately 2^(n/2) quantum
operations.
* *Collision resistance* (finding any two inputs with the same
hash): classically 2^(n/2) operations (birthday bound); under the
Brassard-Høyer-Tapp (BHT) algorithm, approximately 2^(n/3) quantum
operations.
For the spkiHash commitment, the relevant property is *second-
preimage resistance*: an adversary must find a distinct
SubjectPublicKeyInfo that hashes to the same value as the committed
future SPKI. The classical security level equals the hash output
length n; the quantum security level under Grover is approximately
n/2 bits. This implies:
Vicente Expires 10 December 2026 [Page 21]
Internet-Draft PQCHC June 2026
* SHA-256 (n=256): 256-bit classical second-preimage resistance;
approximately 128-bit quantum second-preimage resistance. SHA-256
SHOULD NOT be used as the sole hash algorithm in commitments
extending beyond 2030, as the effective quantum advantage is
approaching practical relevance.
* SHA-384 (n=384): 384-bit classical second-preimage resistance;
approximately 192-bit quantum second-preimage resistance. SHA-384
is the RECOMMENDED minimum for high-assurance environments.
* SHA-512 (n=512) or SHA3-512 (n=512): 512-bit classical;
approximately 256-bit quantum second-preimage resistance.
Preferred for commitments extending to 2035 or beyond.
The hash algorithm selection SHOULD be consistent with the security
level implied by the committedAlgorithm. For example, a commitment
to ML-DSA-87 (NIST security category 5, targeting at least 256 bits
of classical security) warrants SHA-512 or SHA3-512.
6.3. Public Key Correlation
The spkiHash field reveals information about the future public key to
any party that observes the current certificate. Specifically:
* The hash provides a commitment binding: if two certificates appear
with the same spkiHash and hashAlgorithm, they commit to the same
future key. This enables correlation of certificates across
different organizational entities if the same future key hash
appears in multiple PQCHC extensions.
* The hash does not reveal the future public key itself. However,
if the committed algorithm is an asymmetric algorithm with known
key structure, an adversary with access to the public key at
renewal time can trivially verify whether the key matches the
prior commitment.
Operators SHOULD generate a unique future key pair for each PQCHC
commitment and MUST NOT reuse a committed future key in more than one
PQCHC extension unless the operator explicitly intends cross-
certificate correlation to be observable.
6.4. Commitment Substitution Attack
An adversary who can perform a man-in-the-middle attack at the CA
during certificate issuance could, in principle, substitute a
different spkiHash for the value submitted by the legitimate subject.
The adversary would then substitute the corresponding key at renewal
time.
Vicente Expires 10 December 2026 [Page 22]
Internet-Draft PQCHC June 2026
The Issuance-Time Policy Binding property (the CA's signature over
the extension in the tbsCertificate) prevents post-issuance
substitution of the hash. However, it does not prevent issuance-time
substitution if the adversary can compromise the CA issuance
pipeline. Mitigations include:
* The subject retaining a signed copy of the CSR or commitment
attestation containing the original spkiHash before submitting it
to the CA.
* Certificate Transparency (CT) logging, which records the issued
certificate and thus the committed spkiHash, enabling detection of
discrepancies between submitted and issued commitments.
* Use of CSR attestation mechanisms such as draft-ietf-lamps-csr-
attestation to provide hardware-backed proof of the private key
controlling the committed SPKI.
6.5. CRQC-Era Considerations
The PQCHC extension is designed for deployment during the transition
to PQC. Once a CRQC becomes available:
* Existing classical certificates in the PKI can be forged or
decrypted.
* CAs that sign certificates with classical algorithms can have
their signing keys broken, enabling forgery of PQCHC extensions.
Therefore, the value of the PQCHC commitment depends on the
certificate chain and the CA's signing algorithm:
* A PQCHC extension in a certificate signed by a CA using only
classical algorithms does not provide post-quantum security for
the commitment itself. A CRQC adversary could forge the CA
signature and substitute the commitment.
* A PQCHC extension in a certificate signed by a CA using ML-DSA or
a composite algorithm retains its commitment integrity even if a
CRQC is available, because forging the CA signature would require
breaking the PQ component.
Operators seeking CRQC-era integrity of their PQCHC commitments
SHOULD ensure their issuing CA chain uses ML-DSA or composite signing
algorithms before the commitment window extends into the period when
a CRQC is considered a realistic threat. This is consistent with
CNSA 2.0 [CNSA2] requirements, which mandate ML-DSA-87 for all NSS
certificate signatures by 2031.
Vicente Expires 10 December 2026 [Page 23]
Internet-Draft PQCHC June 2026
6.6. Downgrade-Forcing Attack
An adversary may attempt to force a downgrade by:
1. Preventing the legitimate subject from completing renewal during
the ACME-ARI suggested window.
2. Presenting a classical or non-matching certificate after
commitmentNotAfter has passed, when the relying party's downgrade
detection has expired.
Mitigations:
* The operator SHOULD set commitmentNotAfter to a value sufficiently
beyond the expected renewal date to account for operational
delays, but not so far beyond as to create an extended window
during which a compromised classical key is assumed to be valid.
* The CA SHOULD reject a renewal order for a PQCHC-bearing
certificate that references a classical-only SPKI when ARI-
integrated PQCHC validation is in force.
* Relying parties SHOULD log commitment expirations and flag any
transitions from PQ or composite certificates to classical
certificates that occur close to or after commitmentNotAfter.
6.7. TOFU Bootstrap Problem
A relying party that encounters a PQCHC-bearing certificate for the
first time has no prior basis for validating the freshness of the
commitment. The "trust on first use" (TOFU) problem means that if
the very first certificate observed for a subject already contains a
commitment violation, the relying party cannot detect it.
This problem is not specific to PQCHC; it is shared by all
observation- based downgrade detection mechanisms, including
[I-D.reddy-lamps-x509-pq-commit].
Partial mitigations include:
* Certificate Transparency logs: relying parties can query CT logs
to observe the history of certificates issued for a subject before
the first direct connection. A subject that has previously issued
PQCHC- bearing certificates creates a CT-observable commitment
history.
Vicente Expires 10 December 2026 [Page 24]
Internet-Draft PQCHC June 2026
* ACME replaces field correlation: when ARI is in use, the chain of
renewal Orders provides a verifiable history of certificate
issuance events that can be cross-checked against CT log entries.
* Out-of-band pinning: high-assurance environments may publish the
expected spkiHash via a separate, authenticated channel (e.g.,
DNSSEC- signed TXT records or operator-published PQCHC policy
documents referenced by policyURI).
The TOFU bootstrap problem is acknowledged as a known limitation of
this specification. Future work may address it through additional
mechanisms such as signed commitment announcements or integration
with certificate policy OIDs that attest to an operator's PQCHC
enrollment.
7. IANA Considerations
7.1. id-pe OID Assignment
IANA is requested to assign an Object Identifier for the PQCHC
extension under the id-pe arc:
id-pe-pqchc OBJECT IDENTIFIER ::= { id-pe TBD2 }
The base id-pe arc is 1.3.6.1.5.5.7.1 as defined in RFC 5280
[RFC5280] Section 4.2.2. The assigned id-pe value TBD2 will result
in a final OID of 1.3.6.1.5.5.7.1.TBD2.
IANA is also requested to assign an Object Identifier for the ASN.1
module under the id-mod arc:
id-mod-pqchc-2026 OBJECT IDENTIFIER ::= { id-mod TBD1 }
Both assignments are TBD pending IANA processing.
7.2. Experimental OID Arc
Prior to permanent IANA assignment, operators wishing to conduct
experimental deployments of the PQCHC extension may use OIDs under
the IANA Private Enterprise Number (PEN) arc for Sanctum SecOps LLC:
1.3.6.1.4.1.65953
Specifically, the experimental arc for PQCHC extensions is:
id-pe-pqchc-experimental OBJECT IDENTIFIER ::=
{ 1 3 6 1 4 1 65953 1 1 }
Vicente Expires 10 December 2026 [Page 25]
Internet-Draft PQCHC June 2026
This experimental OID MUST NOT be used in production deployments or
in certificates submitted to public Certificate Transparency logs
without explicit documentation that the OID is experimental and
subject to change. The experimental arc is distinct from any
permanent id-pe assignment.
8. References
8.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/info/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/info/rfc5280>.
[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/info/rfc8174>.
[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/info/rfc9794>.
[FIPS203] NIST, "Module-Lattice-Based Key-Encapsulation Mechanism
Standard", NIST FIPS 203, August 2024.
[FIPS204] NIST, "Module-Lattice-Based Digital Signature Standard",
NIST FIPS 204, August 2024.
[FIPS205] NIST, "Stateless Hash-Based Digital Signature Standard",
NIST FIPS 205, August 2024.
8.2. Informative References
[RFC9773] Gable, A., "ACME Renewal Information (ARI) Extension",
RFC 9773, DOI 10.17487/RFC9773, June 2025,
<https://www.rfc-editor.org/info/rfc9773>.
Vicente Expires 10 December 2026 [Page 26]
Internet-Draft PQCHC June 2026
[RFC9763] Becker, A., Guthrie, R., and M. Jenkins, "Related
Certificates for Use in Multiple Authentications within a
Protocol", RFC 9763, DOI 10.17487/RFC9763, June 2025,
<https://www.rfc-editor.org/info/rfc9763>.
[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.ietf-lamps-pq-composite-kem]
Ounsworth, M., Gray, J., Pala, M., Klaußner, J., and S.
Fluhrer, "Composite ML-KEM for use in X.509 Public Key
Infrastructure", Work in Progress, Internet-Draft, draft-
ietf-lamps-pq-composite-kem-14, 27 March 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-lamps-
pq-composite-kem-14>.
[I-D.ietf-lamps-certdiscovery]
Okubo, T., Bonnell, C., Gray, J., Ounsworth, M., and J.
Mandel, "A Mechanism for X.509 Certificate Discovery",
Work in Progress, Internet-Draft, draft-ietf-lamps-
certdiscovery-03, 21 May 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-lamps-
certdiscovery-03>.
[I-D.reddy-lamps-x509-pq-commit]
Reddy.K, T., Gray, J., and Y. Sheffer, "X.509 Certificate
Extension for Post-Quantum Hosting Continuity", 25
February 2026.
[I-D.ounsworth-lamps-pq-external-pubkeys]
Ounsworth, M. and J. Gray, "External Public Key
Information for use in PKI messages", 2024.
[NIST-IR-8547]
NIST, "Transition to Post-Quantum Cryptography Standards",
NIST IR 8547 ipd, November 2024.
[CNSA2] NSA, "Commercial National Security Algorithm Suite 2.0",
September 2022.
[FIPS180] NIST, "Secure Hash Standard (SHS)", NIST FIPS 180-4,
August 2015.
Vicente Expires 10 December 2026 [Page 27]
Internet-Draft PQCHC June 2026
[FIPS202] NIST, "SHA-3 Standard: Permutation-Based Hash and
Extendable-Output Functions", NIST FIPS 202, August 2015.
[SHOR1994] Shor, P.W., "Algorithms for Quantum Computation: Discrete
Logarithms and Factoring", Proceedings of the 35th Annual
Symposium on Foundations of Computer Science pp. 124-134,
1994.
[GROVER1996]
Grover, L.K., "A Fast Quantum Mechanical Algorithm for
Database Search", Proceedings of the 28th Annual ACM
Symposium on Theory of Computing pp. 212-219, 1996.
[MOSCA2018]
Mosca, M., "Cybersecurity in an Era with Quantum
Computers: Will We Be Ready?", IEEE Security &
Privacy Vol. 16, No. 5, pp. 38-41, 2018.
Appendix A. Appendix A: Example PQCHC Extension DER Encoding
This appendix shows a non-normative, illustrative encoding of a PQCHC
extension. The example commits to a future ML-DSA-65 key using a
SHA-384 hash.
A.1. Certificate Subject Scenario
* Current certificate: ECDSA P-256, 2-year validity, expires
2027-01-01.
* Committed algorithm: ML-DSA-65 (OID 2.16.840.1.101.3.4.3.18).
* Future key: Pre-generated ML-DSA-65 key pair. The DER encoding of
the future SubjectPublicKeyInfo is hashed with SHA-384.
* commitmentNotAfter: 2027-04-01 (3 months beyond certificate
notAfter to accommodate renewal lead time).
A.2. ASN.1 Value (Informative)
Vicente Expires 10 December 2026 [Page 28]
Internet-Draft PQCHC June 2026
PQCHCommitment ::= SEQUENCE {
commitmentValid TRUE,
committedAlgorithm SEQUENCE {
algorithm 2.16.840.1.101.3.4.3.18 -- id-ML-DSA-65
},
futureKeyCommitment SEQUENCE {
hashAlgorithm SEQUENCE {
algorithm 2.16.840.1.101.3.4.2.2 -- id-sha384
},
spkiHash OCTET STRING (48 bytes -- SHA-384 output),
keyAlgorithmHint ABSENT -- same as committedAlgorithm
},
commitmentNotAfter GeneralizedTime "20270401000000Z",
policyURI ABSENT
}
The extension appears in the certificate's extensions list as:
Extension ::= SEQUENCE {
extnID 1.3.6.1.5.5.7.1.TBD2, -- id-pe-pqchc
critical FALSE, -- MUST be non-critical
extnValue OCTET STRING { -- DER encoding of PQCHCommitment
-- (DER bytes omitted; see description above)
}
}
Appendix B. Appendix B: Relationship to NIST IR 8547 Migration Timeline
NIST IR 8547 [NIST-IR-8547] (initial public draft, November 2024)
establishes the following transition timeline for quantum-vulnerable
algorithms:
Vicente Expires 10 December 2026 [Page 29]
Internet-Draft PQCHC June 2026
+===================+======+========================================+
| Milestone | Date | Implication for PQCHC |
+===================+======+========================================+
| Deprecation of | 2030 | PQCHC commitments for lower- |
| 112-bit classical | | security-level environments |
| algorithms | | SHOULD have commitmentNotAfter |
| | | no later than 2030. |
+-------------------+------+----------------------------------------+
| Disallowment of | 2035 | PQCHC commitments in high- |
| all classical | | assurance environments SHOULD |
| asymmetric | | be set to complete migration |
| algorithms | | before 2035. |
+-------------------+------+----------------------------------------+
| CNSA 2.0 full | 2031 | PQCHC commitments in National |
| enforcement for | | Security System contexts |
| NSS | | SHOULD have commitmentNotAfter |
| | | no later than 2031. |
+-------------------+------+----------------------------------------+
Table 1
The NIST IR 8547 note on hybrid modes states that the disallowment of
quantum-vulnerable algorithms after 2035 was not intended to apply to
hybrid modes that incorporate an approved PQC algorithm alongside a
quantum-vulnerable algorithm. This means PQ/T composite certificates
(as defined in [I-D.ietf-lamps-pq-composite-sigs]) remain usable
beyond 2035 within the scope of that NIST guidance. PQCHC
commitments to composite algorithms are therefore consistent with
long-term compliance, provided the composite includes an approved PQC
component.
Appendix C. Appendix C: Comparison with Related Mechanisms
+==================+===========+===========+==========+========+=========+
|Mechanism |Forward |Key- |Downgrade |ARI |Non- |
| |Commitment?|Specific |Detection?|Hook? |Critical?|
| | |Binding? | | | |
+==================+===========+===========+==========+========+=========+
|draft-reddy PQCHC |Temporal |No |Heuristic |No |Yes |
|(continuityPeriod)|only | |only | | |
+------------------+-----------+-----------+----------+--------+---------+
|RFC 9763 |No (current|Current |No |No |Yes |
|RelatedCertificate|binding) |cert only | | | |
+------------------+-----------+-----------+----------+--------+---------+
|draft- |No |Existing |No |No |Yes |
|certdiscovery |(existing |cert hash | | | |
|certHash |cert) | | | | |
+------------------+-----------+-----------+----------+--------+---------+
Vicente Expires 10 December 2026 [Page 30]
Internet-Draft PQCHC June 2026
|draft-ounsworth |No (current|Current key|No |No |N/A |
|external-pubkeys |key) |hash | | | |
+------------------+-----------+-----------+----------+--------+---------+
|*This document |*Yes |*Yes |*Yes (REQ-|*Yes |*Yes* |
|(PQCHC -01)* |(future |(spkiHash)*|3)* |(Section| |
| |SPKI hash)*| | |5.4)* | |
+------------------+-----------+-----------+----------+--------+---------+
Table 2
This comparison illustrates that the PQCHC extension as defined in
this document is the only mechanism in the current LAMPS WG landscape
that simultaneously provides forward key commitment with
cryptographic binding, machine-verifiable downgrade detection, and
ACME-ARI scheduling integration.
Acknowledgments
The author thanks Tirumaleswar Reddy.K, John Gray, and Yaron Sheffer
for their work on draft-reddy-lamps-x509-pq-commit, which identified
the temporal commitment gap and provided the direct motivation for
this work.
Thanks to Mike Ounsworth, Massimiliano Pala, Jan Klaußner, and Scott
Fluhrer for their work on composite ML-DSA and composite ML-KEM,
which establish the algorithm encoding infrastructure that PQCHC
commitments reference.
Thanks to Alison Becker, Rebecca Guthrie, and Michael J. Jenkins for
their work on RFC 9763 and the CNSA 2.0 PKIX profile, which clarify
the NSS certificate requirements that motivate PQCHC in high-
assurance contexts.
Thanks to the LAMPS Working Group for the broader PQC certificate
infrastructure this document builds upon.
This document was prepared for public review as a contribution to the
IETF LAMPS Working Group. It describes a problem domain and
requirements; it does not disclose any proprietary internal
architecture.
Author's Address
Brian Vicente
Sanctum SecOps LLC
Pine City, NY
United States of America
Email: admin@sanctumsecops.com
Vicente Expires 10 December 2026 [Page 31]
Internet-Draft PQCHC June 2026
URI: https://orcid.org/0009-0006-6395-5308
Vicente Expires 10 December 2026 [Page 32]