[Acme] Update: draft-geng-acme-public-key-05

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

Hi all,


We’ve just published an updated version of the draft:

https://www.ietf.org/archive/id/draft-geng-acme-public-key-05.html


Thanks again for all the valuable feedback and discussions during IETF 125
— especially thanks to Aaron Gable, Ilari Liusvaara, David Benjamin,
Richard Barnes, and others for the insightful comments.


Here’s a summary of the main changes from -04 to -05:


*1. Challenge type consolidation*

The six challenge types in -04 (pk-dns-01, pk-http-01, pk-tls-alpn-01,
pk-email-01, pk-csr-01, pk-cert-01) are now unified into a single pk-01
challenge. Delivery is negotiated via supported_delivery / delivery fields
in the challenge object.


*2. newOrder restructuring*

The pk_binding object has been split into three top-level fields: public_key
(SPKI), pop_mode ("async" / "sync"), and csr_less.

*3. Unified PoP signing formula*

All delivery methods now use a consistent signature construction with
domain separation and identifier binding:

  to_sign = "ACME-pk-01\x00" || keyAuthorization || "." || identifier


*4. New ALPN identifier “acme-pk/1”*

Defined a new TLS ALPN protocol identifier independent of RFC 8737
(“acme-tls/1”).

In sync mode, the TLS handshake directly returns the raw proof bytes as
application data, without requiring a self-signed X.509 certificate with
the acmeValidation extension. An IANA registration has been requested per
RFC 7301.


*5. Security enhancements*

Added defenses against:

    •Unknown Key Share (UKS) via identifier binding

    •Cross-protocol attacks via “ACME-pk-01\x00” domain separation

    •Authorization reuse via SPKI-level binding checks


*6. Post-quantum (PQC) considerations*

Added motivation for PQC transition. Noted that PQ signatures may exceed
DNS TXT limits, and recommend using sync mode (pop_mode: "sync", TLS-ALPN
delivery) for PQ scenarios.


*7. Removal of IdP-based authentication mode*

Removed non-Web PKI IdP-based authentication (pk-csr-01, pk-cert-01) and
related WebAuthn/OPAQUE integration. These will be addressed in a separate
document following prior feedback.


As always, comments and feedback are very welcome!


Best regards,

Grace