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

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

Hi Ilari,

Thank you for the detailed review and thoughtful comments — they are
extremely helpful. We will also incorporate your feedback into the next
revision, and plan to publish version -06 next week.
Please find our responses inline below.

> Having that kind of method overloading seems messy.

Our intention in consolidating multiple challenge types into pk-01 was to
reduce specification fragmentation and make future extensions easier to
manage.
The supported_delivery / delivery negotiation is meant to provide
flexibility without requiring new challenge registrations for each
transport. That said, we agree that the current abstraction may introduce
complexity, and we will further evaluate whether clearer separation or
additional structure would improve readability and implementation
simplicity.


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

This is a very valuable suggestion.
We will update this in the next draft revision: the signature format and
synchronous handshake mode in the protocol will adopt standard formats and
be compatible with TLS 1.3.


> What is ? A single order can have names from multiple domains.

Good point — the current text is indeed ambiguous.
We will optimize the process description for order request scenarios
involving multiple identifiers.


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

This is consistent with our current design. The client generates the PoP by
signing a message including a nonce with the asserted private key, and
sends the resulting proof to the AS.
We suspect the comment may be due to a wording ambiguity in the draft
rather than a behavioral difference. We will clarify the text accordingly.


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

We will reorganize the Security Considerations section and remove redundant
descriptions.


Thanks again for the detailed feedback — this is extremely valuable for
improving the draft. We will incorporate these points in the next revision.

Best regards,
Grace

Ilari Liusvaara <[e-mail]> 于2026年4月3日周五 01:37写道：

> 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
>
> _______________________________________________
> Acme mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>