On Sun, May 3, 2020 at 1:36 AM Ryan Sleevi <[email protected]> wrote:
> > > 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? > Ideally, ACME-aware mail clients will handle these messages in some beautiful, mostly-invisible way, but mail clients don't update as fast as browsers. Even many years after most users have ACME-aware clients, I think a sizable fraction will have non-aware clients. It almost seems that ensuring human unfriendliness is a feature, not a bug, > towards the goal of automation. > That was my expectation after reading draft-06, but Alexey explained that human-friendliness was in-scope, hence my suggestions. 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. > According to this draft, authorization requires sending a specially formed reply email, so I think the risk of a scanning engine accidentally authorizing is low. 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 >> >
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
