Re: [Acme] Benjamin Kaduk's Discuss on draft-ietf-acme-email-smime-10: (with DISCUSS and COMMENT)

[Benjamin Kaduk <[e-mail]>]

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