Hi Fraser, On Sat, Nov 14, 2020 at 02:47:03PM +1000, Fraser Tweedale wrote: > 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...
Ah, you're quite right. I apparently jumped to the line "[t]he URL to which a response can be posted" and missed the previous "the client responds by sending a response object in a POST request to a challenge URL." So it seems we may want to reiterate these URL semantics and add a different field to convey the email address associated with the response email. (I read the stuff below and can't argue with it.) Thanks! Ben > - 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
