Summary

  • draft-ietf-acme-pop-00 replaces a finalization-time CSR with a popKey, an order-specific pop authorization and a pop-01 challenge bound to the exact decoded newOrder payload.
  • Key possession and identifier control remain separate authorizations. Passing one cannot silently satisfy the other.
  • Signature keys prove possession with a fresh nonce and an order-bound signature. ML-KEM keys use a fresh ciphertext and an HMAC derived after decapsulation; that MAC is useful to the server but is not third-party-verifiable.
  • A KEM certificate key cannot sign an ACME revocation request. With STAR, the account key becomes the only in-protocol control that can stop further issuance.
  • Revision 00 is an active Standards Track Internet-Draft, not an RFC, implementation report, interoperability result or deployment claim.

The last payload says almost nothing

In ordinary ACME, finalization carries a PKCS #10 certificate signing request. In the new optional path, once every authorization is valid, the final payload is an empty JSON object. The draft even recommends the deterministic base64url value e30, the encoding of {}.

That is not a smaller trust decision. It is evidence that the decision has already been assembled.

The client declared the proposed certificate key earlier, in newOrder, as popKey. The same request included one empty-valued pop identifier. The server created a dedicated authorization, issued one pop-01 challenge and stored a hash of the exact decoded request bytes. The certificate identifiers were validated through their ordinary ACME authorizations. The CA retained control over the rest of the certificate.

By the time finalization becomes empty, the order is supposed to contain everything the client may still declare. The absence of a CSR is therefore a relocation of proof, not its disappearance.

The order binds bytes, not a reconstructed intention

The draft defines raw_newOrder as the octets produced by decoding the JWS payload before parsing JSON. newOrder_hash is SHA-256 over those octets. Implementations must not parse the object, serialize it again and hash the new representation.

That choice matters because equivalent-looking JSON can have different byte representations, and ambiguous objects can contain duplicate keys. The raw payload is authoritative for the possession proof. If parsing cannot produce one unambiguous meaning, the server rejects the request.

For a signature key, the proof covers a fixed domain-separation prefix, a fresh 32-byte popNonce and the order hash. For ML-KEM, the server encapsulates to the declared public key, publishes a fresh challenge_ciphertext, derives a mac_key with HKDF-SHA-256, and checks an HMAC over the same order hash. Changing any order byte changes the proof context.

This binds possession to a particular request. It does not prove that the requested DNS name, email address or other identifier belongs to the key holder. That remains the work of the separate identifier authorization.

Two keys, two security domains

The ACME account key signs protocol messages. The popKey is intended for the certificate. Revision 00 requires them to differ after canonical DER SubjectPublicKeyInfo comparison.

The rule is easy to describe as hygiene. Its operational meaning is stronger. The account key authorizes actions inside the ACME service: placing the order, answering the challenge and, in relevant cases, revoking a certificate or cancelling renewal. The certificate key is meant for the application that will use the credential. Reusing one key for both would collapse two control surfaces whose recovery, access and lifetime may need to differ.

The same distinction should survive outside the protocol. Store account-key custody, certificate-key custody, order approval and deployment authority as separate records. A dashboard that merely says “key validated” has discarded the proposition that was actually tested.

A possession authorization is deliberately narrow

An ordinary ACME authorization represents authority over an identifier. The new pop authorization has an empty identifier and a narrower meaning: the participant possessed the private key corresponding to this order's accepted popKey when the challenge completed.

It cannot be pre-authorized. It cannot reuse a valid authorization from another order. Every CSR-less order gets fresh challenge material. The server must place exactly one pop-01 challenge in exactly one dedicated authorization rather than attaching possession checks to every DNS or email authorization.

This creates a clean AND relationship. Identifier control without the certificate private key is insufficient. The certificate private key without identifier control is also insufficient. Device attestation, RATS evidence or a certificate profile can join the order, but they remain independent decisions.

That is a minimum viable trust structure: each check owns one proposition, and the order composes them without pretending they are interchangeable.

KEM proves possession differently

A signature proof can be checked again by a third party that has the transcript and public key. The ML-KEM path has another shape. The server originates the encapsulation and can derive the same MAC that the client returns. A client able to decapsulate can answer correctly, so the exchange demonstrates possession to the server. But the server could also manufacture that MAC.

The draft says the KEM proof supplies no non-repudiation. A later auditor cannot treat the transcript as independent evidence that only the client could have created the response.

This does not defeat its issuance purpose: the ACME server is the relying party. It does change the audit claim. Log the ciphertext, response, order hash, time and server decision if that record is useful internally, while stating that the server could reproduce the proof. Do not sell a symmetric challenge-response transcript as a third-party-verifiable signature.

The draft's secret-lifetime rules reinforce the boundary. The server keeps only the derived mac_key while the challenge lives and destroys it at termination. Ciphertexts must be fresh and not reused. Invalid proof destroys the order path rather than inviting repeated guesses against the same material.

Issuance still belongs to the CA

Once every authorization is valid, the CA must place a key cryptographically equivalent to the accepted popKey in the certificate. For DER X.509, that means byte-for-byte SPKI comparison. A C509 encoding requires comparison of the underlying key values.

The order supplies authorized identifiers. The pop marker is never written into subject or Subject Alternative Name. Validity, Key Usage, Extended Key Usage, subject fields and other extensions remain CA-policy or profile decisions. Removing the CSR does not give the client a new channel for arbitrary certificate extensions.

After issuance, another boundary begins. A correct certificate may remain uninstalled, reach only half a fleet, be paired with the wrong private key or be rejected by a relying client. PoP is instantaneous evidence at challenge completion, not continuing proof of custody or successful service.

The revocation asymmetry is the leadership issue

RFC 8555 permits revocation authenticated by the ACME account key or the certificate private key. A KEM certificate private key cannot sign. That removes the second path.

For an ordinary KEM-bound certificate, loss of the account key can leave no ACME-protocol mechanism for revocation. Provider recovery, short certificate lifetimes, CRLs or OCSP operated through another CA channel may reduce the risk. They are separate controls and need named owners.

The combination with STAR concentrates authority further. The initial popKey persists through automatic renewals and pop-01 is not rerun for every new certificate. STAR certificates are not explicitly revocable through STAR; the account key cancels the order and stops future issuance. Lose that key and renewal may continue until intervention or the order end date.

This is not an argument against KEM or automation. It is a demand that the control graph be drawn before deployment. A post-quantum certificate key can strengthen one cryptographic property while making account-key custody, recovery and cancellation more important operational dependencies.

Status without promotion

Revision 00 was posted on 1 September 2026 as the first ACME working-group version, replacing an individual draft. It is intended for the Standards Track and expires on 5 March 2027. It may change, be replaced or expire.

No named CA or client was verified here as supporting the extension. No issuance, interoperability test, production incident or adoption rate is claimed. The draft itself does not describe RFC 8555 as newly broken under its standard threat model; it presents earlier key commitment as architectural clarity and as a deployment-specific protection where an untrusted proxy can influence finalization.