On Sat, May 2, 2020 at 2:11 PM Ben Schwartz <bemasc= [email protected]> wrote:
> > > On Sat, May 2, 2020 at 8:35 AM Alexey Melnikov <[email protected]> > wrote: > >> Hi Ben, >> On 21/04/2020 01:12, Ben Schwartz wrote: >> >> >> On Wed, Apr 1, 2020 at 5:40 AM Alexey Melnikov <[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? >> > My concern is that users will not know what to do if they receive an email > whose subject line is "ACME: awlkNSdpijawrfz...". Users are used to seeing > emails whose subject line is "Please verify your email address" or "Confirm > your email". (My inbox is full of them.) I see no reason to disallow that > here. > > Mandating that the subject line be non-human-readable seems like an > unnecessary barrier to adoption. > Are you expecting humans to be the primary interaction point? It almost seems that ensuring human unfriendliness is a feature, not a bug, towards the goal of automation. This structure seems especially important if it has a chance to be adopted by publicly trusted CAs. One of the big concerns with existing validation approaches is bodies that are rich-text with links used for approval, and for which anti-spam or scanning engines inspect (“click”) and cause improper authorizations. The more structure, the better, towards preventing accidental authorizations. 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. >> > Yes, that's what I was referring to. > >> 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 <rsalz= >>> [email protected] <[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 >
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
