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

From: Fraser Tweedale <[email-masked]>
Date: Thu, 12 Nov 2020 18:14:53 +1000

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

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 12 Nov 2020 10:03:32 +0000

Hi Fraser,

Thank you for your comments.

>        "token-part2": "DGyRejmCefe7v4NfDGDKfA"
Yes.
> sent and the server should prepare to receive and process it).
This might not always be possible when a MUA that doesn't support this 
proposal directly is to be used. But I agree that this needs to be 
clarified one way or another.
> different approaches to server implementation.
Yes, based on feedback from other people I realised that this is 
underspecified. I will add description of you points #1 and #2 in the 
next revision.
> otherwise could it be limited to text/plain?

Basically this needs to work with existing email clients as is and this 
is not something that can always (or easily) be controlled by users. A 
lot of them will generated multipart/alternative instead of text/plain, 
especially if they want to include nicely formatted HTML.

Best Regards,

Alexey

---

From: Fraser Tweedale <[email-masked]>
Date: Thu, 12 Nov 2020 21:53:31 +1000

> clarified one way or another.
Alexey, thank you for your quick reply.

If an MUA does not support this proposal directly (i.e.  with
integrated ACME client) it will also not be able to create the
order, or finalize it and retrieve certificate.  You have to use a
separate ACME client alongside the MUA.  Therefore it seems OK to
require the ACME client to POST to the challenge URL.  User workflow
would be something like:

1. Use ACME client to submit order, awaits challenge email.

2. Receives challenge email, construct response email (perhaps with
   guidance/assistance of ACME client) and send.

3. Tell ACME client that response was sent.  ACME client POSTS to
   challenge URL, polls authz resource and, if all went well,
   finalizes order and emits certificate.

> especially if they want to include nicely formatted HTML.
Makes sense.  Could you please mention this reason in the document?

Thanks,
Fraser

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 12 Nov 2020 11:58:40 +0000

On 12/11/2020 11:53, Fraser Tweedale wrote:
> order, or finalize it and retrieve certificate.
Right.
> You have to use a
> separate ACME client alongside the MUA.
Exactly.
> Therefore it seems OK to
Yes. I am adding something like this to the draft right now.
> Makes sense.  Could you please mention this reason in the document?

Sure.

Best Regards,

Alexey

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 18 Nov 2020 13:29:06 +0000

Hi Fraser,

>     finalizes order and emits certificate.

You are right. I am updating the draft to add "POST to the challenge URL".

Best Regards,

Alexey