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