Re: [Acme] I-D Action: draft-ietf-acme-email-smime-10.txt

[Fraser Tweedale <[e-mail]>]

Hello!

I have some issues with this proposal.

1. It does not adequately explain how the ACME client receives
token-part2.  "Over HTTPS" is vague.  Presumably it comes as a field
in the challenge object, e.g.

  "challenges": [
    {
      "type": "email-reply-01",
      "url": "https://example.com/acme/chall/prV_B7yEyA4",
      "token-part2": "DGyRejmCefe7v4NfDGDKfA"
    }
  ]

This needs to be fully specified in the document.

2. It is not stated whether, in addition to sending the response
email, the client also has to POST to the challenge URL as specified
in RFC 8555 Section 7.5.1 (e.g. to signal that the email has been
sent and the server should prepare to receive and process it).

I suggest explicitly requiring the client to POST to the challenge
URL to advise the server to prepare to receive and validate it.
This is what RFC 8555 implies a client should do, and facilitates
different approaches to server implementation.

3. What is the motivation for supporting both text/plain and
multipart/alternative in the body of the response email?  This
complicates server implementations, but I can't think why it would
be needed.  Please either explain why both options are needed,
otherwise could it be limited to text/plain?

Thank you,
Fraser Tweedale