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 _______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
