On Thu, Nov 12, 2020 at 03:48:25PM -0800, Benjamin Kaduk wrote: > On a related note, the thread with Fraser, combined with our live > discussion earlier today, made me realize that we really should say what > the contents of the 'url' field of the challenge object are. I know Fraser > wanted it to be an HTTPS resource, but it seems like a mailto: URL might > make more sense. A mailto: URL could also (in some cases) play the role of > the > "token-part0" I had pondered about previously, in that if the ACME server > uses a challenge-specific address with sufficient entropy, and that is > the From: line of the challenge email, then a sufficiently aware MUA/client > can use that address to link the incoming challenge email with the pending > ACME challenge. (More below.) >
Hi Benjamin, It is an interesting idea. A mailto: challenge URL seems technically feasible but has some consequences: - RFC 8555 says that the client POSTs to that URL, implying HTTPS. We can define a different semantics for a different challenge types, but... - POST to an HTTPS URL, after email was sent, should work fine for the "email-reply-00" validation method. It is coherent with other challenge types (prepare HTTP resource then notify; create DNS records then notify; etc). I don't think we should forfeit this cohesion lightly; it will aid implementors of both clients and servers to keep the mental model for difference challenge types as close as possible. - And, as I discussed in the other thread, NOT having the client POST to notify the server that challenge email was sent does restrict the ways you could implement the server. Specifically, the Mail Delivery Agent would have to _proactively_ perform ACME-related processing of received messages. Compare to a server implementation where the MDA can just store mail somewhere, and the ACME server can search for the reply after client has POSTed that the mail was sent. This maintains a nice separation between mail delivery, and ACME server behaviour. If I were implementing the server side, this is how I would prefer to do it. Cheers, Fraser _______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
