A Post-Quantum Hybrid-Commitment Certificate Extension (PQCHC)

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 3 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. 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

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 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].¶

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 SubjectPublicKeyInfo in the current certificate in a field covered by the CA's signature. The hash algorithm MUST provide at least 128 bits of second-preimage resistance against a quantum adversary.¶

REQ-2:

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

REQ-3:

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

REQ-4:

A solution MUST include a Commitment Validity Time expressed as a GeneralizedTime. Relying parties MUST NOT enforce commitment semantics after this time.¶

REQ-5:

A solution SHOULD be integrable with ACME Renewal Information (ARI) [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.¶

REQ-7:

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

REQ-8:

A solution MUST be deployable as a non-critical X.509 v3 extension per [RFC5280] Section 4.2. Legacy relying parties MUST be unaffected.¶

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.¶

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.¶

Committed Algorithm:

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

Committed Key Hash:

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

Commitment Validity Time:

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

CRQC:

Cryptographically Relevant Quantum Computer, as described in [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 per [RFC5280].¶

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 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) } ;

id-ce-pqchc-experimental OBJECT IDENTIFIER ::= { 1 3 6 1 4 1 65953 1 1 }
-- id-ce-pqchc OBJECT IDENTIFIER ::= { id-ce TBD1 }

ext-pqchc EXTENSION ::= {
    SYNTAX       PQCHCommitment
    IDENTIFIED BY id-ce-pqchc-experimental }

PQCHCommitment ::= SEQUENCE {
    commitmentValid     BOOLEAN DEFAULT TRUE,
    committedAlgorithm  AlgorithmIdentifier,
    committedKeyHash    DigestInfo,
    commitmentNotAfter  GeneralizedTime,
    policyURI           IA5String OPTIONAL }

END

function VerifyPQCHCCommitment(committingCert, candidatePQCert):
  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
  if candidatePQCert.subjectPublicKeyInfo.algorithm
       != commitment.committedAlgorithm: return ALGORITHM_MISMATCH
  spkiBytes = DER_ENCODE(candidatePQCert.subjectPublicKeyInfo)
  hashAlg   = commitment.committedKeyHash.digestAlgorithm
  computed  = HASH(hashAlg, spkiBytes)
  if computed != commitment.committedKeyHash.digest:
      return HASH_MISMATCH
  if candidatePQCert.validity.notBefore > commitment.commitmentNotAfter:
      return COMMITMENT_EXPIRED
  return COMMITMENT_HONORED

5. Interaction with Composite Certificates

When a composite certificate also carries a PQCHC extension, the committedAlgorithm field MUST use the composite algorithm OID as defined in [COMPOSITESIGS], 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

6. Interaction with ACME-ARI

An ACME CA that wishes to honor PQCHC commitments SHOULD constrain the ARI scheduling window so that suggestedWindow.end is at or before min(certificate.notAfter, commitment.commitmentNotAfter). When the ACME server receives an order with a replaces field referencing a PQCHC-bearing certificate, it SHOULD verify that the CSR's subjectPublicKeyInfo hashes to committedKeyHash.digest. An order that fails this check SHOULD be rejected with an orderNotReady error.¶

7. Security Considerations

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

8. Implementation Status

This section is included per [RFC7942].¶

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

9. IANA Considerations

id-ce-pqchc OBJECT IDENTIFIER ::= { id-ce TBD1 }

Worked Example: ML-DSA-65 Commitment

All values are synthetic test data. Scenario: a server certificate issued with an ECDSA-P256 key commits to migrating to ML-DSA-65 ([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):
30 56                        -- SEQUENCE (86 bytes)
  01 01 ff                   -- BOOLEAN TRUE (commitmentValid)
  30 0b                      -- AlgorithmIdentifier SEQUENCE
    06 09                    -- OID id-ml-dsa-65
      60 86 48 01 86 3a 04 03 12
  30 27                      -- DigestInfo SEQUENCE
    30 0d                    -- digestAlgorithm
      06 09 60 86 48 01 65 03 04 02 01  -- id-sha256
      05 00
    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 32 30 33 30 30 31 30 31 30 30 30 30 30 30 5a

NIST IR 8547 and CNSA 2.0 Migration Timeline

+------+---------------------------------------+---------------------+
| Year | Event                                 | PQCHC implication   |
+------+---------------------------------------+---------------------+
| 2030 | NIST: deprecation of 112-bit classical | commitmentNotAfter  |
|      | asymmetric algorithms                 | SHOULD precede this |
+------+---------------------------------------+---------------------+
| 2031 | CNSA 2.0: full enforcement for NSS    | MUST complete PQC   |
|      | National Security Systems             | migration by 2031.  |
+------+---------------------------------------+---------------------+
| 2035 | NIST: disallowment of new protection  | commitmentNotAfter  |
|      | using quantum-vulnerable algorithms   | MUST NOT exceed.    |
+------+---------------------------------------+---------------------+

Acknowledgments

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

Author's Address