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

[Fraser Tweedale <[e-mail]>]

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