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

Alexey Melnikov <> Tue, 05 May 2020 15:19 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6567A3A0817 for <>; Tue, 5 May 2020 08:19:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.098
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: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id u03htCNhrMDk for <>; Tue, 5 May 2020 08:19:35 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 11C233A0810 for <>; Tue, 5 May 2020 08:19:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1588691974;; s=june2016;; bh=z1GmnY0m+lmzVmnQctefX5xR2EXeNX5eRq8QA8g1CZE=; 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=JjBks82oNTVdhr8fLMB2jBD1rt4YS+C3bjQbVZav+8Cgzz+SebcM77xCdI1oDZSGTW1lFq i0QMB5No/Vx1oEHLmtzu3O3C6gKmcexLO1bwYgwfzDKmZNiEvmLWjQ5B3nTVYezKIyITUI hbFlRhQKGngLVs7kpF0wLfeNGgn9fr0=;
Received: from [] ( []) by (submission channel) via TCP with ESMTPSA id <>; Tue, 5 May 2020 16:19:34 +0100
To: Ryan Sleevi <>, Ben Schwartz <>
Cc: "" <>, "Salz, Rich" <>
References: <> <> <> <> <> <> <>
From: Alexey Melnikov <>
Message-ID: <>
Date: Tue, 5 May 2020 16:18:57 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0
In-Reply-To: <>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="------------391F1717089861A550D37AAD"
Content-Language: en-GB
Archived-At: <>
Subject: Re: [Acme] WG last call for draft-ietf-acme-email-smime-06
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: Tue, 05 May 2020 15:19:38 -0000


On 03/05/2020 06:36, Ryan Sleevi wrote:
> On Sat, May 2, 2020 at 2:11 PM Ben Schwartz 
> < 
> <>> wrote:
>     On Sat, May 2, 2020 at 8:35 AM Alexey Melnikov
>     < <>> wrote:
>         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".  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.

Let me try to elaborate on the current choice and talk about 
alternatives. In general there are 3 ways how an ACME email challenge be 
conveyed in email:

1) In the subject line. Some structure would be helpful for automated 

2) In a new header field.

3) In the body of the message, e.g. using "---BEGIN ACME CHALLENGE---" 
line in text/plain or the like.

Unfortunately all of these have their downsides:

#1 is unfriendly to users and can possibly trigger antispam processing. 
(Not sure how much of an issue the last part is)

#2 might not be accessible from libraries that don't support retrieval 
of arbitrary email header fields. (I am not sure how big of a deal this 
is, but I've heard some claims about that.) Also, non ACME aware clients 
might not be able to show this header field, making them unusable for 
manual processing.

#3 would either require use of text/plain (for simplicity of automated 
processing) or it would require HTML parser with downconversion to 
text/plain. I think the latter choice is a rather high barrier of entry 
for implementations that are not fully capable email clients, which I 
suspect would be too hight for some ACME servers.

So I am open to suggestions about the best choice. I think using some 
structured subject line (choice #1) or possibly text/plain choice #3 are 
the best. If there is a better structure for the subject header field, I 
would be happy to change the document.

Best Regards,