| Internet-Draft | PQCHC X.509 Extension | June 2026 |
| Vicente | Expires 7 December 2026 | [Page] |
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.¶
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 (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.¶
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]. 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.¶
[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.¶
This section states requirements that a conforming PQCHC implementation SHOULD satisfy.¶
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.¶
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.¶
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.¶
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.¶
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.¶
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]).¶
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.¶
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.¶
The extension value MUST be encoded in Distinguished Encoding Rules (DER) per [RFC5280]. All internal fields MUST use DER canonical encoding.¶
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.¶
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:¶
the post-quantum algorithm, identified by an object identifier, to which the subject commits for a future certificate.¶
a cryptographic hash over the subjectPublicKeyInfo the subject intends
to use for the committed algorithm in a future certificate.¶
the time by which the committed algorithm is intended to be in force for
the subject, expressed as a GeneralizedTime.¶
Cryptographically Relevant Quantum Computer. A quantum computer capable of breaking classical asymmetric cryptography at operationally relevant key sizes, as described in [RFC9794].¶
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.¶
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) } ;
-- 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.
-- 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.¶
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:¶
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.¶
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
[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¶
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.¶
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
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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
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):¶
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.¶
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:¶
+------+---------------------------------------+---------------------+ | 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.¶
The author thanks the LAMPS Working Group for the foundational post-quantum X.509 work on which this extension builds.¶