Re: [Acme] AD Review of draft-ietf-acme-email-smime-07

Alexey Melnikov <alexey.melnikov@isode.com> Fri, 29 May 2020 16:38 UTC

Return-Path: <alexey.melnikov@isode.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 5EEF93A0DA8 for <acme@ietfa.amsl.com>; Fri, 29 May 2020 09:38:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 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, 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 wLrX1FZSDaW5 for <acme@ietfa.amsl.com>; Fri, 29 May 2020 09:38:57 -0700 (PDT)
Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id 14F913A0D42 for <acme@ietf.org>; Fri, 29 May 2020 09:38:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1590770335; d=isode.com; s=june2016; i=@isode.com; bh=KryBi3tWEQtYXiH+RTHsMtNhMT9YB0MggBjPH00T2N4=; 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=ZbqxjUMDFABpW50ex2JOUkpyRn4fiUOzBKYzi6E8CPJFKhOURmmBZC8kkLzwRCa1aXbcph 6LuaikGVwlMNqGBNY+0PSYjepn6bA4DOrr7xVJxBPeM4PerJPFNpjvNPw8jhbneyWmasT/ x2gaj/88NSYCj0N55iP+CN1/lFpNeJ4=;
Received: from [172.27.249.118] (connect.isode.net [172.20.0.72]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id <XtE6nABPtHqu@waldorf.isode.com>; Fri, 29 May 2020 17:38:54 +0100
From: Alexey Melnikov <alexey.melnikov@isode.com>
To: Roman Danyliw <rdd@cert.org>
References: <8ecce2820f344c34a124bffa95bd20b6@cert.org>
Cc: IETF ACME <acme@ietf.org>
Message-ID: <c8762036-fc0d-1012-98f3-4bf1ce72cb25@isode.com>
Date: Fri, 29 May 2020 17:38:33 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0
In-Reply-To: <8ecce2820f344c34a124bffa95bd20b6@cert.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-GB
Content-transfer-encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/acme/jLE28nxN847gaffFXjVItkuotWg>
Subject: Re: [Acme] AD Review of draft-ietf-acme-email-smime-07
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: Fri, 29 May 2020 16:38:58 -0000

Hi Roman,

Thank you for your detailed review.

On 22/05/2020 15:54, Roman Danyliw wrote:
> Hi!
>
> I completed my AD review of draft-ietf-acme-email-smime-07.  Thanks for the work on this document.  Here is my feedback:
>
> ** What was the thinking behind the document status being informational?
I don't think there was much thought or discussion of this point. I am 
flexible. I think when I started it was not very clear how much 
support/interest there were in this, but I noticed more interest over time.
> ** Section 3.1.  This section has no (normative) guidance on populating the To and From fields.

The To is the email address of the entity which requested S/MIME 
certificate issuance. I will clarify that.

There is no guidance regarding the From, as it is implementation choice. 
(I am not a fan of mandating specific email address for this, like 
postmaster@<domain>) Do you think this needs to be stated explicitly?

> ** Section 3.1.  Step 5.  Per "If S/MIME signing is used to prove authenticity of the challenge message, then multipart/signed or "application/pkcs7-mime; smime-type=signed-data;" media type should  be used", is there is a reason that this should is not normative (i.e., SHOULD)?
This is just restating requirements from other documents, but also 
emphasizing that both common alternatives are allowed here. I don't 
think this needs normative language.
> ** Section 6.
>
> -- Recommend explicitly naming the registries being updated
> -- Per the challenge type, all of the fields in the registry aren't described here
I will have a look at these.
> -- Per the challenge type, the text in Section 3 says that the challenge type is "email-reply-00" (not "email-reply" as described here)
Thank you for spotting this, I need to make sure that it is the same 
everywhere. I've  changed the document to say "email-reply" everywhere.
> I recommend something like the following:
> NEW:
> 6.1.  Identifier Type
>
> Per this document, a new type has been added to the "ACME Identifier Types" registry defined in Section 9.7.7 of [RFC8555] with Label "email" and a Reference to this document.
>
> 6.2.  Challenge Types
>
> Per this document, a new entry have been added to the "ACME Validation Methods" registry defined in Section 9.7.8 of [RFC8555].  This entry is as follows:
>
>             +-------------+-----------------+------+-----------+
>             | Label       | Identifier Type | ACME | Reference |
>             +=============+=================+======+===========+
>             | email-reply-00 | email              | Y    | This document  |
>             +-------------+-----------------+------+-----------+
>
> ** Section 7.  Per "Any claims about the correctness or    fitness-for-purpose of the email address must be otherwise assured", I don't follow the intent of this text.  For example, what is the "correctness ... of the email address"?  What is meant by "assurances"?
>
> ** Editorial nits:
> -- Section 3.  Typo. s/posession/posession/
I think you meant "possession". Fixed.
> -- Section 4.  As this document is now headed out of the WG, it seems like it should be removed.
Removed.
> -- Section 7.  Typo. s/can can/can/
Fixed.
> -- Section 7. Editorial.  For readability, I would avoid nested parentheses.
>
> OLD
> (by posessing user's password or a secret derived from it that can give read and reply access ("password equivalent" information), or by being given permissions to act on user's behalf using email delegation feature)
>
> NEW
> (by possessing a user's password or a secret derived from it that can give read and reply access, such as "password equivalent" information; or by being given permissions to act on user's behalf using email delegation feature)

Done.


Best Regards,

Alexey