Re: [Acme] Genart last call review of draft-ietf-acme-email-smime-08

Alexey Melnikov <> Thu, 24 September 2020 17:26 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1088A3A1131; Thu, 24 Sep 2020 10:26:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Status: No, score=-2.1 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, NICE_REPLY_A=-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 4Vg947g1FEen; Thu, 24 Sep 2020 10:26:14 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 3C01C3A0FCB; Thu, 24 Sep 2020 10:26:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1600968370;; s=june2016;; bh=kiTLsZAq2alxYJDUozppYIp4uAltMmSXQrISCCEddA4=; 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=knUb5gPn1HAYJWPUriuD1P3ihLiImhJTRUCxzKAl0KH0n73z/7Owm5TLhgvCkVK3RomUV6 vknEtyieH9LIgJ+ZfoutH8iBx3u5KfKskJRsGqQ7huQh58dGyAsogH6jwk1P1c6Ew2Vprt 6x4QWK1Ni/99v+mFZz+OZntLCRrM1RA=;
Received: from [] ( []) by (submission channel) via TCP with ESMTPSA id <>; Thu, 24 Sep 2020 18:26:09 +0100
To: Peter Yee <>,
References: <>
From: Alexey Melnikov <>
Message-ID: <>
Date: Thu, 24 Sep 2020 18:26:08 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0
In-Reply-To: <>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-GB
Content-transfer-encoding: quoted-printable
Archived-At: <>
Subject: Re: [Acme] Genart last call review of draft-ietf-acme-email-smime-08
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: Thu, 24 Sep 2020 17:26:16 -0000

Hi Peter,

Thank you for your detailed review. My answers/comments are below:

On 09/07/2020 09:21, Peter Yee via Datatracker wrote:
> Reviewer: Peter Yee
> Review result: Ready with Issues
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF Chair. Please treat these comments just
> like any other last call comments.
> For more information, please see the FAQ at
> <>.
> Document: draft-ietf-acme-email-smime-08
> Reviewer: Peter Yee
> Review Date: 2020-07-09
> IETF LC End Date: 2020-07-09
> IESG Telechat date: Not scheduled for a telechat
> Summary: This Informational Track draft defines an ACME challenge to be used in
> the issuance of S/MIME certificates. I have points I'd like to see clarified as
> well as some nits that need to be cleaned up before I would declare it ready.
> [Ready with Issues]
> Major issues: None
> Minor issues:
> General: this draft doesn’t frame the operation of the ACME request that uses
> this challenge. It mentions a token-part2 that magically arrives over HTTPS,
> but gives no indication of why this happened or what causes the generation of
> the email challenge. Some context around when this challenge is invoked and
> what signals the ACME server that this challenge is required would be helpful.
Good point. I've added a paragraph on this.
> Page 3, 1st enumerated item: I find the definition of “first part of the token”
> to be far looser than it needs to be. You merely say that it needs to contain
> 64 bits of entropy. Is there an upper bound?
No. I don't believe base ACME has upper bound on tokens either.
> Do you need to say anything about it not being reused in another challenge?
This was the intent and I clarified that.
> Page 4, example Subject header field: it would be much better if you gave an
> actual example of a base64url-encoded value here rather than some explanatory
> text in much the same way you have given actual, legal values for Date,
> Message-ID, etc.
> Page 5, section 3.2, 1st enumerated item, 1st sentence: it doesn’t seem like
> you particularly care what is in front of “ACME:”. While you say it’s typically
> “Re:” , it could be anything. Would there ever be a case to reject a response
> message based on what appears before “ACME:”? I’d like to see a little more
> rigor here on what’s required. Some characters followed by a colon and a white
> space before the “ACME:” suffices?

I would like for email to use standardardized reply prefix, but there 
are variations. E.g. using "Re[<number>]". And don't get me started on 
localized versions, which should be banned from the face of the Earth ;-).

You do have a point that probably anything before "ACME:" can be 
allowed. I will clarify that.

> Page 5, section 3.2, 6th enumerated item, 2nd sentence: where it says
> “calculated based on”…, it would be preferable to point back to page 3, 2nd
> enumerated item where you explicitly indicate that the two token parts are
> concatenated.
I clarified that.
> Page 5, section 3.2, 6th enumerated item, last sentence: I’m assuming that
> ACME-unaware clients are only receiving this email in the case of the email
> being bounced to an administrator or returned to the user.
I suppose ACME server processing can be manual, but this is more likely 
to be a misconfiguration.
> In either case, it’s
> not the client that will be reading this outside-the-block text, it’s a user.
> There’s no processing to be done on that text.
Yes, it will be read by a user. I am not sure what needs changing in the 
> Page 7, example Subject header field: use a real value here, please.
> Nits/editorial comments:

I've applied these and the changes will appear in -09. Use of English 
language articles is not my strong point :-)

Best Regards,