Hi Ilari, Thank you for taking the time to review the draft so carefully — your comments are very helpful and have prompted us to think more deeply about several design decisions..
> On "why not send the PoP directly in the POST request" You are correct that all current delivery methods in the draft are indirect — the proof is deposited at a resource location (DNS, HTTP, email, or TLS listener), and the AS retrieves it independently. We acknowledge this is not "direct transmission" in the strict sense, and we will revise the wording in the draft to avoid any implication otherwise. 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. > On "associating keys with domains — it is not clear what that actually means" The coupling between domain control validation and PoP is intentional and motivated by a specific threat model: the ACME proxy client scenario. In deployments where an ACME client acts as a proxy on behalf of end entities (EEs), the client intermediates between the EE and the AS. (We mentioned this usage scenario in previous versions.) If domain control validation and PoP are decoupled — for example, domain control is established first and the resulting authorization is reused — the proxy client can subsequently submit an arbitrary public key (not the EE's) in a new order against the already-validated domain. The AS has no basis to reject this, and the result is a certificate issued for a public key that the legitimate domain owner never intended to certify. By requiring that both domain control and PoP are demonstrated in the same challenge interaction, pk-01 ensures that the entity proving control of the domain is the same entity holding the asserted private key. This eliminates the window for key substitution at the proxy layer. There are also practical considerations against decoupling at the protocol level: maintaining separate authorization objects for domain control and key possession would require non-trivial changes to the ACME authorization data model, adding implementation burden on both client and server without clear benefit for the common case. Best regards, Palos 2026年4月11日 15:26，Ilari Liusvaara <[email protected]> 写道： On Sat, Apr 11, 2026 at 01:25:54PM +0800, 吴攀雨 wrote: 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. I do not see any way in -05 for the ACME client to directly trasmit the pk-01 PoP to ACME server. All I see is indirect ways (via DNS, HTTP, E-Mail or TLS-ALPN): "Write proof to the _acme-challenge.<domain> DNS TXT record for the domain:" "Deploy proof to the following HTTP path (using token as part of the path):" "Send the proof as the body of a reply to the server's specified address in an S/MIME email." "Configure a TLS listener on port 443 of the domain. When an AS initiates a connection using the ALPN protocol identifier “acme-pk/1”, return proof as the handshake response data." What would be direct is sending the PoP in POST request to the challenge url. This would also avoid assocating keys with domains, it is not clear what that acutually means. -Ilari _______________________________________________ Acme mailing list -- [email protected] To unsubscribe send an email to [email protected]
_______________________________________________ Acme mailing list -- [email protected] To unsubscribe send an email to [email protected]
