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

[Alexey Melnikov <[e-mail]>]

Hi Gerd,

Thank you very much for your comments and sorry for taking long time to 
reply to you.

On 15/07/2019 14:01, Gerd v. Egidy wrote:
> 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?
In many clients automatic processing can be invoked based on receiving a 
particular media type. Also, if an external application is used to 
handle challenge, it can be associated with a particular media type of 
various operating systems.
> 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.
This is one of my open issues. I would like to make implementations of 
ACME S/MIME-aware clients as easy as possible. If you have a generic 
email client, support for HTML is pretty much required. But if you don't 
have a generic email client, adding support for HTML might be an extra 
burden. So my question is: does better display of instructions to users 
outweigh extra complexity of handling of text/html? (I am on the fence 
on this. I think you are arguing that the answer is "yes").
> 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.

Having recently added HTML tag stripping in an email server, I think 
this is a big implementation burden, so I would prefer not to do that.

In regards to using something like RFC 7468: I think adding BEGIN/END 
wrapper would provide some extra help in detecting invalid content, so I 
will add it to the document.

> 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.

I really dislike email clients using localized versions of "Re:", but I 
think you are right :-).

Best Regards,

Alexey