Hi Ben, On 21/04/2020 01:12, Ben Schwartz wrote: > > On Wed, Apr 1, 2020 at 5:40 AM Alexey Melnikov > <[email protected] <mailto:[email protected]>> wrote: > > Hi Ben, > > My apologies for missing your email in March: > > > And mine for this delayed response. > > On 12/03/2020 20:42, Ben Schwartz wrote: >> Section 3 says token-part1 "contains at least 64 bit of entropy", >> but Section 3.1 says token-part1 "MUST be at least 64 octet long >> after decoding". Is this difference deliberate? > > No, I obviously made a typo when saying octets. I will fix. > Fixed. > >> Also 64 octets of entropy is a _lot_. RFC 8555 says "the token >> is required to contain at least 128 bits of entropy". >> >> The draft seems to be oriented entirely toward use with e-mail >> clients that have a built-in ACME-S/MIME client. I'm a bit >> disappointed that the draft doesn't accommodate users with >> "naive" email clients very well, e.g. by allowing customized >> subject lines. > > Actually, I was trying to accommodate naive email clients, but it > was a fine balance trying to specify minimal requirements. > > Can you suggest some specific text to change and then we can > discuss whether or not it should be done? My thinking about the > Subject header field was that I wanted to have a unique subject > (so that ACME email messages are easily findable). I also wanted > to allow the token in the subject for APIs that can easily access > Subject and not other header fields. > > In that case, I would suggest "... subject ending with "(ACME: > <token-part1>)", where ...". That would allow the first part of the > subject (most likely to be seen by a human) to be human-readable.
After thinking a bit more about this: As ACME servers are generating ACME challenge emails, the requirement on them is stricter (they create the first message in an email thread). I am tempted to leave this as is. Can you think of a case where ACME servers would be unable to comply with this restriction? ACME responses already allow arbitrary prefix to accommodate naive clients. > Similarly, for Section 3.2. Point 6, I would relax the requirement to > state that this block must appear somewhere in the body. That way, if > the user sees the response message, it can provide some explanation of > what is going on. Good idea. Changed. > For Section 3.1 Point 5, I don't understand why the body is restricted > to text/plain. In particular, I think hyperlinks to explanations and > instructions are likely to be helpful. I also wonder whether support > for multipart/multilingual could be useful. > The body is irrelevant to ACME-aware clients, so it seems like there > could be a lot of freedom in how this is constructed. This is true for the challenge email. There is a requirement on S/MIME (if used) to provide header protection, but I agree that otherwise the body structure can be pretty flexible. > Most email clients automatically convert HTTPS URLs to hyperlinks, > which should make the silly schemes I'm imagining possible, but not > very attractive, for ordinary users. > > Best Regards, > > Alexey > >> I assume this is deliberate, perhaps because of a desire to use >> short-TTL S/MIME certificates that would be impractical to >> provision manually, but the draft doesn't mention a rationale. >> >> On Thu, Mar 12, 2020 at 2:52 PM Salz, Rich >> <[email protected] >> <mailto:[email protected]>> wrote: >> >> This mail begins a one-week working group last call on >> >> https://datatracker.ietf.org/doc/draft-ietf-acme-email-smime/?include_text=1 >> >> >> >> If you have comments or issues, please post here. >> >> >> >> If anyone wants to be a document shepherd, please contact the >> chairs. >> Best Regards, Alexey
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
