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

["Gerd v. Egidy" <[e-mail]>]

Hi Alexey,

thanks for continuing your work on the smime draft.

> 1.  Do we need to handle text/html or multipart/alternative in email
>       challenge?  Simplicity suggests "no".  However, for automated
>       processing it might be better to use at least multipart/mixed
>       with a special MIME type.

hmm. I guess with "automated processing" you mean an acme client on the user 
side. 

How would a multipart/mixed with a special MIME type help implementing the 
client?

The client just needs to detect the challenge email and extract <token-part1> 
from the Subject:-Header. What other data, that could be in the part with the 
special mime type, would help implementing such a client?

An ACME CA might want to include multipart/alternative and text/html to 
present nicely formatted usage instructions to the user when the ACME client 
is not integrated into the MUA. Automated clients should not be confused by 
such messages.

The same is true for the challenge response:

When the user manully copies the response from his ACME client program into 
his regular MUA, the MUA may compose a multipart/alternative mail with text/
html and text/plain or even just text/html. Also some company disclaimers and 
so on could be added automatically.

How about using something like in RFC 7468?

-----BEGIN ACME RESPONSE-----
LoqXcYV8q5ONbJQxbmR7SCTNo3tiAXDfowy
jxAjEuX0.9jg46WB3rR_AHD-EBXdN7cBkH1WOu0tA3M9
fm21mqTI
-----END ACME RESPONSE-----

This would allow the ACME server to extract the relevant data from most of 
such emails by stripping all html tags and ignoring everything outside the 
BEGIN/END block.

We also should not force the response email to use a subject of "Re: ACME: 
<token-part1>", just "<something>ACME: <token-part1>" because MUAs with non-
english language settings may use something else than "Re:" to denote a reply.

Kind regards,

Gerd