| Internet-Draft | ACME PQC Agility Profile | June 2026 |
| Vicente | Expires 25 December 2026 | [Page] |
This document defines an Automated Certificate Management Environment (ACME) [RFC8555] profile extension that enables ACME servers and clients to express per-account and per-order post-quantum cryptographic (PQC) posture. The extension introduces a pqcAgility metadata object in the ACME directory, an optional pqcAgility member in order objects, and a server-side adequacy scoring mechanism that determines whether a given order satisfies an account's declared PQC readiness threshold.¶
The profile is designed for both public and private ACME deployments and does not modify the core ACME state machine: it adds discoverable capability metadata and per-order policy directives that servers MAY enforce. Multi-tenant ACME servers MUST implement tenant-isolation controls that prevent cross-account PQC posture leakage.¶
This document is distinguished from draft-giron-acme-pqcnegotiation [I-D.giron-acme-pqcnegotiation], which defines algorithm negotiation at the ACME protocol level. This profile operates above the negotiation layer: it defines per-account posture scoring, adequacy thresholds, hybrid policy bits, rotation epoch anchoring, and tenant-isolation requirements that apply regardless of which negotiation mechanism is used.¶
This note is to be removed before publishing as an RFC.¶
Source for this draft is maintained at https://github.com/Sanc-Admin/acme-pqc-agility-profile. A citable archival version is published at Zenodo upon each tagged release. Author ORCID: https://orcid.org/0009-0006-6395-5308.¶
Discussion of this document should occur on the ACME working group mailing list (acme@ietf.org).¶
This note is to be removed before publishing as an RFC.¶
The author has filed United States patent applications covering subject matter relevant to this document, including U.S. Provisional Patent Application No. 64/080,137 (filed 2026-06-01) and U.S. Patent Application No. 19/698,870 (filed 2026-06-05). 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. The Sanctum SecOps Private Enterprise Number (PEN) root used for any OID allocations referenced in companion documents is 1.3.6.1.4.1.65953.¶
The scope of the pending patent applications includes, but is not limited to, the per-account PQC posture scoring, adequacy threshold gating, tenant-isolation orchestration, and rotation epoch anchoring mechanisms described in this document. This Internet-Draft itself does not grant any patent license. Implementation parameters that would extend beyond the disclosed interface (including but not limited to scoring weights, rotation triggers, tenant carve-out parameters, and adequacy thresholds) are intentionally out of scope and are not disclosed in this Internet-Draft.¶
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 25 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.¶
ACME [RFC8555] is the dominant protocol for automated certificate issuance. As certificate deployments migrate to post-quantum cryptography (PQC) — driven by NIST FIPS 203 [FIPS203], FIPS 204 [FIPS204], and FIPS 205 [FIPS205] — ACME implementations require a uniform mechanism to express per-account PQC posture and enforce per-order PQC policy.¶
This document defines that mechanism. It is intentionally scoped to the policy and posture layer, above the algorithm negotiation layer addressed by draft-giron-acme-pqcnegotiation [I-D.giron-acme-pqcnegotiation]. The two documents are complementary: algorithm negotiation determines which PQC algorithms a server supports; this profile determines whether a given order satisfies an account's declared PQC readiness requirements and how multi-tenant isolation is maintained.¶
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.¶
An ACME server supporting this profile MUST include a pqcAgility object in its directory metadata response [RFC8555] Section 7.1.1. The object has the following fields:¶
An ACME client MAY include a pqcAgility member in an order object submitted via POST to the newOrder endpoint [RFC8555] Section 7.4. The member carries the following fields:¶
The server MUST honor or reject the pqcAgility directive based on its configured policy. A rejection MUST return an ACME error of type "urn:ietf:params:acme:error:pqcPolicyViolation".¶
Servers implementing this profile MAY compute a per-order adequacy score based on the requested algorithm set, hybrid posture, and the account's declared readiness threshold. The scoring algorithm is deployment-specific and is not specified in this document; concrete scoring parameters are intentionally out of scope to preserve implementation flexibility and to avoid constraining patent-pending orchestration mechanisms.¶
Servers MUST NOT expose raw adequacy scores to clients in a way that reveals other accounts' posture information.¶
Multi-tenant ACME servers MUST ensure that pqcAgility directives from one account do not influence issuance decisions for other accounts. Specifically:¶
Concrete tenant-isolation implementation parameters are deployment-specific and are not disclosed in this document.¶
PQC posture metadata is security-sensitive. ACME servers SHOULD treat per-account pqcAgility configuration with the same access controls as account key material. Servers MUST NOT expose aggregated tenant PQC posture information through any unauthenticated endpoint.¶
Clients SHOULD validate hybrid certificate chains end-to-end, verifying both the classical and PQC signature paths independently.¶
Harvest-now-decrypt-later (HNDL) attacks motivate the urgency of hybrid deployment. The hybridRequired field provides a mechanism for accounts that require protection against HNDL during the migration period.¶
Rotation epoch IDs SHOULD be cryptographically bound to the issuing server's current state to prevent replay of stale epoch identifiers.¶
IANA is requested to register the following ACME error type:¶
IANA is also requested to create an "ACME PQC Agility" registry for composite chain policy identifiers, with a registration policy of Specification Required.¶