Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18DAB3A1106 for ; Sat, 2 May 2020 05:35:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 90ODCOBH7Y3k for ; Sat, 2 May 2020 05:35:45 -0700 (PDT) Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id 616803A1104 for ; Sat, 2 May 2020 05:35:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1588422944; d=isode.com; s=june2016; i=@isode.com; bh=Uz2hdcnwaJvo3DoJ4p6StgFsOkhhGISzvAaaetBPLDg=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=G6nS8OkZIstvzTmFI1Mge1F+0Gez63WfA8repeurd0H7geZ19CTm6A86R4ltgY9AbZNYj4 QjqFkA/ibKr2NuwaIqTkvrlaB//MQtS14zFBxX2EoPe7hzxy5WsOPjySsXQhYIMB+FqezV Rzcp96a+uBx67hPNQOqGphC0cc9P9qI=; Received: from [192.168.0.8] (0546c907.skybroadband.com [5.70.201.7]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Sat, 2 May 2020 13:35:44 +0100 From: Alexey Melnikov To: Ben Schwartz Cc: "Salz, Rich" , "acme@ietf.org" References: <3703708B-4454-4AC9-87AF-961C73B1F331@akamai.com> Autocrypt: addr=alexey.melnikov@isode.com; prefer-encrypt=mutual; keydata= mQENBFWQBiQBCADFmiucA1/FCqO+LUOm/Xf2+NpPuSbPcLAWd0x1K1V4F1WTPScSolQ/u0y8 faozrF3uQXZxInvmLJOALfOqm4lfg8CN2BqAxMrlCqka1Ku8UJ9A6kOGaZWlBKUmiIjVng9D 91k8MRare9dE5b0Yj33mUO/ifhC+np0H7CXpB6E2IzvAUkgWCPlXEVO6ffV1Xr+J/UeArqoF Fj1RoMN+Kc701e3GzKHpuryng66Jx9+k7daOSgWNF1zOU1JCJKIZ1uHIlzro1y0KtvWTwwM1 331q72HWESG0NatDnu1QotxxFHLDQFsHZ59A5yvIdyeZvjuEr9paorNVIk7Esg4THaljABEB AAG0K0FsZXhleSBNZWxuaWtvdiA8YWxleGV5Lm1lbG5pa292QGlzb2RlLmNvbT6JATkEEwEI ACMFAlWQBiQCGw8HCwkIBwMCAQYVCAIJCgsEFgIDAQIeAQIXgAAKCRBdp82zsCM7iDACB/4q EiLSBhpjDJ+pm1f6IXQvtTW3YGrca0kidZ0yX/qn30bkRtFsjXJVOspKENzBhZCI5bX/Si0I qKkR0DqnuJqchVzKXl25HfMvA2w2KRr8VFLFWMnCB4/jnaMWWQ4EV1MqbyFXl3m0LwZ1U4rd EQLvzPTNd8tqyy093rN53jTl0FmBAEHYzbUHsYB6wx8gqJBFkIGEgPHftZboJ/8ywo983YBQ /8Brb8awV3PeonmHc7W9QMKoN37U9VLbXOvAZVDvJ4QI1P/P3Uad1tkkeyuCcluuPe2M7CjK HF8zQHYGSCz70NY+MhbfhgT5WMjPuW5ls+Q1yES257+lmRkx3eyT Message-ID: Date: Sat, 2 May 2020 13:35:43 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------AD9D87F463811A70853A22AD" Content-Language: en-US Archived-At: Subject: Re: [Acme] WG last call for draft-ietf-acme-email-smime-06 X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 May 2020 12:35:49 -0000 --------------AD9D87F463811A70853A22AD Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Ben, On 21/04/2020 01:12, Ben Schwartz wrote: > > On Wed, Apr 1, 2020 at 5:40 AM Alexey Melnikov > > 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".=C2=A0 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_.=C2=A0 RFC 8555 says "the=C2=A0= 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.=C2=A0 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: > )", where ...".=C2=A0 That would allow the first part of t= he > 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 client= s. > Similarly, for Section 3.2. Point 6, I would relax the requirement to > state that this block must appear somewhere in the body.=C2=A0 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.=C2=A0 In particular, I think hyperlinks to explanations = and > instructions are likely to be helpful.=C2=A0 I also wonder whether supp= ort > 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,=C2=A0but no= t > very attractive, for ordinary users. > > Best Regards, > > Alexey > >> I assume this is deliberate, perhaps because=C2=A0of a desire to u= se >> 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 >> > > wrote: >> >> This mail begins a one-week working group last call on >> https://datatracker.ietf.org/doc/draft-ietf-acme-email-smime/?= include_text=3D1 >> >> =C2=A0 >> >> If you have comments or issues, please post here. >> >> =C2=A0 >> >> If anyone wants to be a document shepherd, please contact the >> chairs. >> Best Regards, Alexey --------------AD9D87F463811A70853A22AD Content-Type: text/html; charset=utf-8 Content-transfer-encoding: quoted-printable

Hi Ben,

On 21/04/2020 01:12, Ben Schwartz wrote:

On Wed, Apr 1, 2020 at 5:40 AM Alexey Melnikov <alexey.melnikov@isode.com> 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 "contain= s at least 64 bit of entropy", but Section 3.1 says token-part1 "MUST be at least 64 octet long after decoding".=C2=A0 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_.=C2=A0 RFC 8555 says "the=C2=A0token 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.=C2=A0 I'm a bit disappointed that th= e 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 ...".=C2=A0 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.=C2=A0 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.=C2=A0 In particular, I think hyperlinks to explanations and instructions are likely to be helpful.=C2=A0 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,=C2=A0but not very attractive, for ordinary users.

Best Regards,

Alexey

I assume this is deliberate, perhaps because=C2=A0of = 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=3D40akamai.= com@dmarc.ietf.org> wrote:
=20

This mail begins a one-week working group last call on https://datatracker.ietf.org/doc/draft-ietf-acme-email-smime/?include_text= =3D1

=C2=A0

If you have comments or issues, please post here.

=C2=A0

If anyone wants to be a document shepherd, please contact the chairs.

Best Regards,

Alexey


--------------AD9D87F463811A70853A22AD--