[Acme] draft-ietf-acme-pop-00 published

[吴攀雨 <[e-mail]>]

Dear ACME Working Group,


Following the successful Call for Adoption, draft-ietf-acme-pop-00 has now
been published:

https://datatracker.ietf.org/doc/draft-ietf-acme-pop/


Compared with draft-geng-acme-public-key-07, this version redesigns PoP
around a dedicated “pop” authorization with a single pop-01 challenge,
while also refining its integration and security considerations based on
the feedback received during the adoption process.


For reference, the Abstract is included below:


"The Automated Certificate Management Environment (ACME) protocol [RFC8555]
requires a PKCS#10 Certificate Signing Request (CSR) at the finalization
stage. This document defines an optional extension that allows a client to
prove possession of a private key directly, without constructing a CSR. The
extension is motivated by use cases where the CSR-based flow is
problematic: KEM-only keys that cannot generate self-signatures,
resource-constrained devices that benefit from reduced encoding overhead,
and issuance models where the certificate is constructed from order and
profile data (e.g., via the ACME Profiles extension
[I-D.ietf-acme-profiles]) rather than a client-generated CSR. This is
particularly relevant when combined with compact encodings such as C509
certificates [I-D.ietf-cose-cbor-encoded-cert].


In the "newOrder" request, the client declares the public key via a popKey
field and includes a pop-type identifier whose value is the empty string.
The server creates a dedicated pop authorization containing a single pop-01
challenge, processed using the same state machine as any other ACME
authorization. When all authorizations (including the pop authorization)
are valid, the ACME server issues a certificate using the validated public
key and the authorized identifiers, eliminating the need for a CSR at
finalization. The extension is additive and strictly optional: clients that
do not use it, and servers that do not support it, continue to use the
standard CSR-based flow defined in [RFC8555] without any changes."


I would also like to take this opportunity to thank everyone who
contributed to the discussion and review of this work. I realized after
publication that the Acknowledgments section was inadvertently omitted from
the -00 version due to my oversight, and we plan to add it in the next
revision.

The authors gratefully acknowledge the ACME Working Group chairs and
participants for their constructive discussions on the architecture of
proof-of-possession in ACME, and the Working Group reviewers whose feedback
shaped this document.


Thank you again for all the comments, suggestions, and discussions that
helped shape and improve this work. Further reviews and feedback on
draft-ietf-acme-pop-00 are very welcome.



Best regards,

Grace

on behalf of the authors