A September 12 individual Internet-Draft by Brian Vicente proposes a post-quantum cryptographic agility profile for ACME, the protocol widely used to automate certificate issuance. The proposal adds a way for a certificate requester and server to express per-account PQC posture and per-order preferences or requirements. It is a work in progress, not an adopted IETF standard, and its single reported implementation has not been independently interoperability-tested. Still, it exposes a practical governance question: when certificates are issued automatically, who says what cryptographic outcome is acceptable?
Automation shortened the time between requesting and deploying a certificate. That is usually good operational hygiene. But a fast workflow can also reproduce an old policy at scale. A certificate authority might support a new algorithm while an application keeps ordering the familiar one. A security team might write a migration policy that never reaches the ACME client or the relying parties. The gap between capability, order, issuance, and actual use is where governance has to operate.
The proposal sits above algorithm negotiation
The draft describes directory metadata that would advertise supported PQC algorithms, hybrid modes, and policy options. It then proposes an optional pqcAgility member on an ACME order, including algorithm preferences, a possible hybrid requirement, a rotation-epoch identifier, and a composite-chain policy. A server would honor or reject directives according to its configured policy. The document also sketches a server-side “adequacy” score, but leaves the scoring method deployment-specific.
That is different from simply negotiating an algorithm. Negotiation answers what the endpoints can use. Policy answers what a particular account or order is allowed—or required—to use. The distinction is valuable even if this exact draft never becomes a standard. In any certificate estate, an organization needs to know whether a requested certificate matched the security objective for that service, whether a fallback was permitted, and who approved an exception.
The draft calls for tenant isolation in a multi-tenant ACME service so one account’s posture cannot influence or reveal another’s. That is not a minor implementation footnote. Per-account thresholds and rotation windows can disclose migration plans or security posture if exposed. Organizations considering any policy-aware certificate automation should treat account boundaries and authorization checks as first-order security controls.
Do not confuse a draft field with deployed assurance
The proposal has meaningful limits. Internet-Drafts can change or expire and do not themselves establish interoperable behavior. The document’s implementation section reports one administrator-managed estate and explicitly says no interoperability testing against independent implementations has occurred. It also discloses related pending patent applications and licensing terms. Those facts do not invalidate the underlying governance question, but they matter when evaluating adoption risk.
There is also a technical distinction worth keeping clear. The draft concerns certificate issuance and signature policy. It should not be sold as a general solution to harvest-now-decrypt-later exposure in encrypted traffic; that problem concerns key establishment and confidentiality, not merely the signature on a certificate. Hybrid certificate designs and relying-party validation also need careful end-to-end testing. A field saying “hybrid required” cannot make an unprepared client trust a new chain.
A useful policy checklist, even without this extension
Certificate operators do not need to adopt an experimental extension to start governing these decisions. They can ask five concrete questions now:
- Who owns the profile? Identify the person or team allowed to choose algorithms and approve exceptions for each certificate use case.
- What was actually issued? Record the requested profile, issued certificate, chain, key type, signing algorithm, and the application that consumes it.
- Can relying parties verify it? Test browsers, APIs, devices, firmware, trust stores, and offline verifiers—not just the issuing server.
- How is rotation coordinated? Track the replacement window, overlap, rollback path, and dependencies for each high-impact trust chain.
- What proves policy compliance? Retain issuance logs, configuration, test results, exceptions, and dates so a migration claim can be rechecked.
For a mixed estate, those answers may differ by system. An internal CA serving managed devices can move on a different timetable from a public web PKI service. A long-lived firmware verification chain has different constraints from a short-lived workload certificate. Policy should be explicit about those distinctions rather than flattening every certificate into one “PQC-ready” status.
How Vista Platform can help
Vista Platform is a self-hosted cryptographic system of record. Through discovery, canonical inventory, evaluation, action, and proof, it helps teams connect cryptographic assets and observations to owners, risks, and migration work. Its source-available Core includes discovery, inventory, compliance/PQC assessment, and CBOM generation without asset, sensor, seat, or time caps. That can support the evidence trail around certificate policy, even when the issuance protocol itself is managed elsewhere.
Vista tracks and governs post-quantum migration; it does not run an ACME CA, generate PQC keys, or perform every migration. Selected-asset Active Scan is not indiscriminate network scanning. Vista is not a vulnerability scanner, and discovery gaps do not prove absence. Learn more about Vista’s PQC approach or try Core.
What to watch
The most important uncertainty is whether this individual proposal earns independent implementation, interoperable tests, and broader standards support. Its scoring model is intentionally unspecified, so different deployments could reach different conclusions for the same order. Until those questions are resolved, the draft is best read as a prompt for stronger certificate governance, not as a procurement requirement or evidence that ACME has standardized PQC posture.
Sources
- Post-Quantum Cryptographic Agility Profile for ACME, Brian Vicente, individual Internet-Draft, September 12, 2026 (work in progress).
- RFC 8555: Automatic Certificate Management Environment (ACME), RFC Editor, March 2019.