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

Roman Danyliw <rdd@cert.org> Fri, 22 May 2020 14:54 UTC

Return-Path: <rdd@cert.org>
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 7AC363A0AC7 for <acme@ietfa.amsl.com>; Fri, 22 May 2020 07:54:47 -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=cert.org
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 XeVMRW4zyL6c for <acme@ietfa.amsl.com>; Fri, 22 May 2020 07:54:46 -0700 (PDT)
Received: from taper.sei.cmu.edu (taper.sei.cmu.edu [147.72.252.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E713D3A0B32 for <acme@ietf.org>; Fri, 22 May 2020 07:54:44 -0700 (PDT)
Received: from delp.sei.cmu.edu (delp.sei.cmu.edu [10.64.21.31]) by taper.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id 04MEshpf031419 for <acme@ietf.org>; Fri, 22 May 2020 10:54:43 -0400
DKIM-Filter: OpenDKIM Filter v2.11.0 taper.sei.cmu.edu 04MEshpf031419
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1590159283; bh=EIKabNOPEubL8aZSApIMgy4YIWJDI3gW0A80WVjlOCo=; h=From:To:Subject:Date:From; b=nQYC1Ev1i+M6ILxr4NyQSPuYXDVjUb+/gGMka+wvFt/o+TCxUEPuX4+uooPZdE+k4 t4cM7b8MXR8xn9zdKrgdtLPrC2QvTqU0mofBvB/+vt95yUwGd3y19zhaN72AnGZ8BM 1j+EawNsnbcQ0H79eYSTzuXqYJBQJ3Xg+538IkpE=
Received: from CASCADE.ad.sei.cmu.edu (cascade.ad.sei.cmu.edu [10.64.28.248]) by delp.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id 04MEsdE3039022 for <acme@ietf.org>; Fri, 22 May 2020 10:54:39 -0400
Received: from MORRIS.ad.sei.cmu.edu (147.72.252.46) by CASCADE.ad.sei.cmu.edu (10.64.28.248) with Microsoft SMTP Server (TLS) id 14.3.487.0; Fri, 22 May 2020 10:54:38 -0400
Received: from MORRIS.ad.sei.cmu.edu (147.72.252.46) by MORRIS.ad.sei.cmu.edu (147.72.252.46) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1847.3; Fri, 22 May 2020 10:54:38 -0400
Received: from MORRIS.ad.sei.cmu.edu ([fe80::555b:9498:552e:d1bb]) by MORRIS.ad.sei.cmu.edu ([fe80::555b:9498:552e:d1bb%22]) with mapi id 15.01.1847.007; Fri, 22 May 2020 10:54:38 -0400
From: Roman Danyliw <rdd@cert.org>
To: IETF ACME <acme@ietf.org>
Thread-Topic: AD Review of draft-ietf-acme-email-smime-07
Thread-Index: AdYwRw45XRk4tpgoS1iG4gmrMAvW6Q==
Date: Fri, 22 May 2020 14:54:38 +0000
Message-ID: <8ecce2820f344c34a124bffa95bd20b6@cert.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.64.202.68]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/acme/OI3zdTCsxlytWgu3F72mNNmvBgY>
Subject: [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, 22 May 2020 14:54:48 -0000

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?

** Section 3.1.  This section has no (normative) guidance on populating the To and From fields.

** 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)?

** Section 6.  

-- Recommend explicitly naming the registries being updated
-- Per the challenge type, all of the fields in the registry aren't described here
-- Per the challenge type, the text in Section 3 says that the challenge type is "email-reply-00" (not "email-reply" as described here)

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/

-- Section 4.  As this document is now headed out of the WG, it seems like it should be removed.

-- Section 7.  Typo. s/can can/can/

-- 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)

Regards,
Roman