Re: [Acme] AD Review of draft-ietf-acme-email-smime-07
Roman Danyliw <rdd@cert.org> Tue, 02 June 2020 20:38 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 94EDB3A0FD7 for <acme@ietfa.amsl.com>; Tue, 2 Jun 2020 13:38:42 -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 0z1IsxqDSMyK for <acme@ietfa.amsl.com>; Tue, 2 Jun 2020 13:38:41 -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 E28633A0FD9 for <acme@ietf.org>; Tue, 2 Jun 2020 13:38:40 -0700 (PDT)
Received: from korb.sei.cmu.edu (korb.sei.cmu.edu [10.64.21.30]) by taper.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id 052KcdE3027939; Tue, 2 Jun 2020 16:38:39 -0400
DKIM-Filter: OpenDKIM Filter v2.11.0 taper.sei.cmu.edu 052KcdE3027939
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1591130319; bh=3mAwoiliE6DW9LoGqm+4KgFt32DAiBznju7JocT030I=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=iB9dNvQZcbqH8PGFjoHjmWoaAQF0zrK7aN4q0d1k0JXegZysRydDsZxQgxpSlbAfb CpODQwKAq3wQt+KLl6p++F8NwNxU2akbQCQ9tLxxg8wAwjIGeY33YUFx81ypafxv3S eBEESTVzFXz/cp6TGrWisYoU3XV4uBDZ2LRTDh5w=
Received: from CASCADE.ad.sei.cmu.edu (cascade.ad.sei.cmu.edu [10.64.28.248]) by korb.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id 052KcYPJ009610; Tue, 2 Jun 2020 16:38:34 -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; Tue, 2 Jun 2020 16:38:34 -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.1979.3; Tue, 2 Jun 2020 16:38:34 -0400
Received: from MORRIS.ad.sei.cmu.edu ([fe80::555b:9498:552e:d1bb]) by MORRIS.ad.sei.cmu.edu ([fe80::555b:9498:552e:d1bb%13]) with mapi id 15.01.1979.003; Tue, 2 Jun 2020 16:38:34 -0400
From: Roman Danyliw <rdd@cert.org>
To: Alexey Melnikov <alexey.melnikov@isode.com>
CC: IETF ACME <acme@ietf.org>
Thread-Topic: [Acme] AD Review of draft-ietf-acme-email-smime-07
Thread-Index: AdYwRw45XRk4tpgoS1iG4gmrMAvW6QFshBaAAMjvKvA=
Date: Tue, 02 Jun 2020 20:38:33 +0000
Message-ID: <24a7c0f12bf64ce1a4f20495329227a4@cert.org>
References: <8ecce2820f344c34a124bffa95bd20b6@cert.org> <c8762036-fc0d-1012-98f3-4bf1ce72cb25@isode.com>
In-Reply-To: <c8762036-fc0d-1012-98f3-4bf1ce72cb25@isode.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.64.202.162]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/acme/iYeSl6VYdVqrTn-DdOmjxvlpiCs>
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: Tue, 02 Jun 2020 20:38:43 -0000
Hi Alexey! > -----Original Message----- > From: Acme <acme-bounces@ietf.org> On Behalf Of Alexey Melnikov > Sent: Friday, May 29, 2020 12:39 PM > To: Roman Danyliw <rdd@cert.org> > Cc: IETF ACME <acme@ietf.org> > Subject: Re: [Acme] AD Review of draft-ietf-acme-email-smime-07 > > 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. I see this is being discussed on a separate thread. My thinking is that if there is ambiguity on what should done here then informational makes sense. > > ** 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. Thanks. > 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? Specifying the To is the one that matters. I might repeat what you said above that the From is an implementation choice. I just wouldn't leave it unsaid. > > ** 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. Understood. That makes sense. > > ** 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. Thanks. > > -- 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. Thanks. > > 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"? Any thoughts on this one? > > ** 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. Thanks. Regards, Roman > > Best Regards, > > Alexey > > _______________________________________________ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme
- [Acme] AD Review of draft-ietf-acme-email-smime-07 Roman Danyliw
- Re: [Acme] AD Review of draft-ietf-acme-email-smi… Salz, Rich
- Re: [Acme] AD Review of draft-ietf-acme-email-smi… Alexey Melnikov
- Re: [Acme] AD Review of draft-ietf-acme-email-smi… Russ Housley
- Re: [Acme] AD Review of draft-ietf-acme-email-smi… Ryan Sleevi
- Re: [Acme] AD Review of draft-ietf-acme-email-smi… Roman Danyliw
- Re: [Acme] AD Review of draft-ietf-acme-email-smi… Alexey Melnikov
- Re: [Acme] AD Review of draft-ietf-acme-email-smi… Roman Danyliw
- Re: [Acme] AD Review of draft-ietf-acme-email-smi… Roman Danyliw
- Re: [Acme] AD Review of draft-ietf-acme-email-smi… Alexey Melnikov