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

[Ilari Liusvaara <[e-mail]>]

On Thu, Apr 02, 2026 at 10:15:48PM +0800, 吴攀雨 wrote:
> 
> 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.

Having that kind of method overloading seems messy.


> *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

Because that signs with key that is likely used in TLS, it should use
the TLS 1.3 signature format (but with its own context). This can be
done by prepending 0x20 (space) byte repeated 64 times to that.
 
 
> *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.

- What is <domain>? A single order can have names from multiple domains.
- If the ACME client is supposed to compute the PoP, why not return it
  directly? Much simpler for client and ACME server.
  * E.g. .onion validation can use direct return.


> *5. Security enhancements*
> 
> Added defenses against:
> 
>     •Unknown Key Share (UKS) via identifier binding

Is this because of indirect PoP return?


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

Should be using TLS 1.3-compatible format, instead of new format that
risks cross-protocol attacks.


>     •Authorization reuse via SPKI-level binding checks.

It is not clear to me why this is needed. 

It seems to be just stating that the authorization can not be reused
between different keys, which is obvious.

 
> *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.

Base64-encoded ML-DSA-87 signatures are ~6kB, which is well below DNS TXT
limits. And DNS TXT is 8-bit clean, so Base64 is not needed.




-Ilari