Re: [Acme] WG last call for draft-ietf-acme-email-smime-06

Ben Schwartz <bemasc@google.com> Tue, 21 April 2020 00:13 UTC

Return-Path: <bemasc@google.com>
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 AA0343A139D for <acme@ietfa.amsl.com>; Mon, 20 Apr 2020 17:13:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.699
X-Spam-Level:
X-Spam-Status: No, score=-15.699 tagged_above=-999 required=5 tests=[DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 6kU1cRa9DQHu for <acme@ietfa.amsl.com>; Mon, 20 Apr 2020 17:13:14 -0700 (PDT)
Received: from mail-wm1-x331.google.com (mail-wm1-x331.google.com [IPv6:2a00:1450:4864:20::331]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 290493A139C for <acme@ietf.org>; Mon, 20 Apr 2020 17:13:13 -0700 (PDT)
Received: by mail-wm1-x331.google.com with SMTP id g12so1633764wmh.3 for <acme@ietf.org>; Mon, 20 Apr 2020 17:13:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=qHHaqYyl1RpWo56DfBkFTIiRZE8Q+fWgOi2MxWh26+8=; b=soPfKK5tYbP1Vek2Ou7Zwt74hOToiRUVbE85Jq8aBwwq4Ut4OIa+JsttBcO5IrVw3R obmZP0Msrtscih2dOrcUZItixf2OKnpKd91lV9NpZZ22Re8E9GBEtOguRwBeWwhpDsAe EcY7EDBadlk0xwUicBUBBeNk4rTOCbKt87qAyWIcRy7kB6IsRxhzuOE4/nHRFZ48IXm1 P1al86jeqlm0tqyDHDaLW8dK3N++e0CSm4k4w1HxVPO1DO5rjI2JNRDhv+PPzgUG9c86 MS7WmmGJvmJeqo1by7xLnYsgzjYE3p6pkggVoQhtSNrjV34ldy9UxLdG6MQRosy776iB NHqw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=qHHaqYyl1RpWo56DfBkFTIiRZE8Q+fWgOi2MxWh26+8=; b=SoTCo4AKjpKrq20sSOvPCDc4fslGSFdF7kWOlYepsTi5KXaWt1MHLjskqwwDUEz93R 9deDDrAp+dq4AMP1FKCFVB3V14lHOfR3CW5s+MKO/+k/Amk/Ry/wxgQTwDwn+AekmIo7 Vqluvl/0opo7D+MEj5w4+TobBRpTegLMoVQ3baQzcgXw0DmGTshxm/GvSERuAEYJyX9I ofHtyFi7sz9xIQgYhkhNSDR1tbAqUTlyniVZNm2y+AsPdtVvXAYevDdc80wGsRe5mSjQ 5TRfAP2IJTeUEE8OhJIedyvoixgzGjYTa2WNfLhazOlv8mc9RrCvkHxp21h4WnznduQV cYTw==
X-Gm-Message-State: AGi0PuYwsdnV6+BZE7O8f6lVRniUFKZAdTqY6zks6PByPwljafC2Kk/F LzbxiTrcGLRy4aBFguuUxLsVOFKkg634OuonsqF2zA==
X-Google-Smtp-Source: APiQypL4fUUsMN64qKvorSVi0AyW37d+Ep7SB9yb7VlfPJpzl/QmvYLYRyekH80wp/aYAM9e04ZOQbiZmaU6M5RhZsI=
X-Received: by 2002:a7b:ce8b:: with SMTP id q11mr1912544wmj.101.1587427992095; Mon, 20 Apr 2020 17:13:12 -0700 (PDT)
MIME-Version: 1.0
References: <3703708B-4454-4AC9-87AF-961C73B1F331@akamai.com> <CAHbrMsDco31pxyBMBSdbgh5aMnttyC1G_tDTg1tz-aAzto=5dw@mail.gmail.com> <fee01750-7afb-02a7-50ee-30453805abec@isode.com>
In-Reply-To: <fee01750-7afb-02a7-50ee-30453805abec@isode.com>
From: Ben Schwartz <bemasc@google.com>
Date: Mon, 20 Apr 2020 20:12:59 -0400
Message-ID: <CAHbrMsAdXvpRt2zCUn7DLNerxhZCFe4pS0TM1qzmaCUGKVYT=A@mail.gmail.com>
To: Alexey Melnikov <alexey.melnikov@isode.com>
Cc: "Salz, Rich" <rsalz@akamai.com>, "acme@ietf.org" <acme@ietf.org>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="0000000000009bd5d905a3c1e100"
Archived-At: <https://mailarchive.ietf.org/arch/msg/acme/-ZXK41rS3mwGaFmfHlECBmO7-9k>
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 <acme.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/acme>, <mailto:acme-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/acme/>
List-Post: <mailto:acme@ietf.org>
List-Help: <mailto:acme-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/acme>, <mailto:acme-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 21 Apr 2020 00:13:18 -0000

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 "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.
>
> 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.

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.

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.

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=
> 40akamai.com@dmarc.ietf.org <40akamai.com@dmarc..ietf.org>> 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.
>>
>>
>>
>>                 /r$
>>
>>
>> _______________________________________________
>> Acme mailing list
>> Acme@ietf.org
>> https://www.ietf.org/mailman/listinfo/acme
>>
>
> _______________________________________________
> Acme mailing listAcme@ietf.orghttps://www.ietf.org/mailman/listinfo/acme
>
>