Certificate issuance often uses a certificate signing request as both a container and evidence that the requester controls the private key. That model becomes awkward for keys that cannot sign, including KEM-only keys. Updated November 1, the IETF ACME Working Group’s proof-of-possession extension draft proposes an optional challenge that can validate key control directly without requiring a CSR.
The document is an active Internet-Draft and may change. Its operational value is broader than one protocol extension: proof of key control should be recorded as a discrete issuance event with its own identity, state, scope, and evidence.
Possession is not a permanent attribute
A certificate record may say which public key was issued, but that does not explain how control of the corresponding private key was demonstrated, by which client, for which order, at what time, or under which algorithm-specific rules.
A useful inventory should connect:
- ACME directory, account, client, order, authorization, challenge, and certificate identifiers;
- declared public key, algorithm, parameter set, encoding, fingerprint, and intended use;
- proof method, nonce or challenge material, creation time, expiration, response, and result;
- cryptographic binding among account, order, authorized identifiers, profile, and public key;
- private-key generation location, custody boundary, HSM or device, exportability, and backup policy;
- application, service, endpoint, device, host, location, environment, and accountable owner;
- CA, ACME server, profile, certificate template, library, firmware, and supplier version;
- replay controls, authorization reuse, rejection reason, retry, and incident handling;
- issuance, deployment, activation, renewal, revocation, and destruction evidence; and
- discovery source, timestamp, scope, confidence, and known coverage gaps.
These fields distinguish “a certificate exists” from “the correct client proved control of the intended key for the intended order.”
KEM keys change the proof mechanism
A KEM public key is used to encapsulate shared secret material rather than create a signature. A workflow that assumes every certificate key can self-sign a CSR may not fit that role.
The draft addresses proof for both signature and KEM keys. For operations teams, this means algorithm role belongs in the inventory. “Public key” is too broad: the proof, error behavior, validation rules, and certificate usage depend on whether the key signs, establishes secrets, or serves another function.
Post-quantum migrations will increase the number of these distinctions. Inventory systems should record the concrete algorithm and role, not infer readiness from a certificate profile name or vendor feature flag.
Removing the CSR moves responsibility
A CSR carries requested certificate information as well as a public key. If issuance instead uses authorized order and profile data, the source of each certificate field shifts toward the ACME server, profile, or policy system.
That can reduce client encoding work and support constrained devices, but it makes profile ownership and order binding more important. Teams need to know who defines subject information, extensions, key usages, validity, and policy identifiers, and how changes are reviewed.
Evidence should preserve the exact profile version and order data used for issuance. A later profile edit should not obscure why an existing certificate contains particular values.
Proof evidence has its own lifecycle
Challenge material should not become a permanent secret archive, but organizations still need enough evidence to demonstrate successful validation, troubleshoot failures, and investigate abuse. Retention should be intentional: identifiers, hashes, timestamps, outcomes, server versions, and audit events may be sufficient where raw proof material would create unnecessary exposure.
Reusable authorizations and automated renewals need special attention. A proof accepted once should not silently justify unrelated keys or orders. Inventory should expose reuse scope, expiry, and the exact binding validated by the server.
What organizations should do next
First, map current ACME flows from key generation through order, challenge, finalization, deployment, activation, renewal, and revocation. Identify where control is assumed rather than evidenced.
Second, model proof-of-possession as an event linked to the canonical key, order, asset, owner, profile, and certificate. Preserve result and binding data.
Third, test signature-key and KEM-key flows separately, including replay, wrong-key, wrong-order, expired challenge, rejection, retry, and rollback scenarios.
Finally, follow the working-group draft and supplier implementations. Keep experiments distinct from production policy until semantics, interoperability, and security review mature.
How Vista Platform helps
Vista Platform is a self-hosted infrastructure inventory and DCIM platform with cryptographic posture built in. It serves as a cryptographic system of record through discovery, canonical inventory, evaluation, action, and proof. Teams can connect certificates, keys, algorithms, applications, devices, hosts, locations, owners, suppliers, policy, exceptions, and migration evidence.
Vista Core is source-available and includes discovery, inventory, compliance and PQC assessment, and CBOM generation without asset, sensor, seat, or time caps. Vista tracks and governs post-quantum migration; it does not generate PQC keys or perform every migration. Selected-asset Active Scan is targeted rather than indiscriminate network scanning. Vista is not a vulnerability scanner, and discovery gaps are not proof of absence.
Explore Vista’s cryptographic inventory, post-quantum migration, and CBOM and compliance resources.
Where uncertainty remains
The extension remains a work in progress. Field definitions, proof procedures, authorization reuse, privacy properties, KEM handling, and implementation support may change. A successful proof demonstrates control under the protocol; it does not prove that the endpoint is uncompromised, the key is well protected, or every certificate field is appropriate.
Source
- Automated Certificate Management Environment Extension for Proof-of-Possession, draft-ietf-acme-pop-01, Internet Engineering Task Force, updated November 1, 2026.