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

[Ilari Liusvaara <[e-mail]>]

On Thu, Apr 23, 2026 at 06:41:05PM -0500, Mike Ounsworth wrote:
> Hi,
> 
> > We have considered adding a "direct" delivery mode where the client
> includes the proof inline in the challenge response POST body. This is
> technically straightforward and we agree it would simplify both client and
> server implementations. However, it comes with an important security
> trade-off: direct delivery only proves key possession — it provides no
> evidence that the submitting party controls the named domain. We believe
> this distinction is significant enough to warrant explicit treatment in the
> draft rather than leaving it implicit.
> 
> I have not yet reviewed the new draft version, but just based on this
> comment, this design seems anti-modular design. The ACME protocol already
> has robust mechanisms for proving domain control.

What I think is much simpler way to do the verification:

- For signature keys:
  * The challenge object in pk authorization contains nonce.
  * The ACME client POSTs TLS 1.3 signature for the nonce and
    sha256 hash of raw new order payload.
  * The ACME server verifies the signature.

- For KEM keys:
  * The challenge object in pk authorization contains challenge
    ciphertext.
  * The ACME client decapsulates the challenge ciphertext and POSTs
    MAC of context and sha256 of the raw new order payload made using
    the shared key.
  * The ACME server verifies the MAC using the shared key.


Using raw newOrder payload avoids any C16N and also includes things
like ACME profiles or future extensions.

A proxy can still sign the newOrder request, since the needed fields
(kid, nonce, url, etc.) are in the header, not in the payload.

If a proxy tries to change the newOrder request, the signature or MAC
will be wrong, and the validation fails.

A proxy can not replay challenge responses across orders, since each
order has unique pk authorization (the whole thing will not work
otherwise!), and each pk authorization has unique nonce or challenge
ciphertext.




-Ilari