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

Roman Danyliw <rdd@cert.org> Thu, 25 June 2020 18:48 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 ED71C3A0FCB for <acme@ietfa.amsl.com>; Thu, 25 Jun 2020 11:48:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
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, RCVD_IN_DNSWL_BLOCKED=0.001, 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 Y4t2Eod7_uTn for <acme@ietfa.amsl.com>; Thu, 25 Jun 2020 11:48:09 -0700 (PDT)
Received: from veto.sei.cmu.edu (veto.sei.cmu.edu [147.72.252.17]) (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 241473A0FC9 for <acme@ietf.org>; Thu, 25 Jun 2020 11:48:08 -0700 (PDT)
Received: from korb.sei.cmu.edu (korb.sei.cmu.edu [10.64.21.30]) by veto.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id 05PIm7Oj041865; Thu, 25 Jun 2020 14:48:07 -0400
DKIM-Filter: OpenDKIM Filter v2.11.0 veto.sei.cmu.edu 05PIm7Oj041865
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1593110887; bh=5WO0WhxUOPot2+3Nf4YfoLvLKu9DK0AcDGMvZy1rBok=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=ZyR/yVzlFFy1gjKezHa0FEg58cOs5Dz2jiRsg57PFP8aVxOBHb7N4bn0CK5LNQCkt /1jDV8yUCra/N42KDeUmVagFQNcFL1CRDlp1tTfYDmh1WSm4zZ8/RJn7ow6JTezeKM ZYKDCjZ1+e+8MT+OcIaSJnxVQEds6Ef8DMYEL05c=
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 05PIm2fC024122; Thu, 25 Jun 2020 14:48:02 -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; Thu, 25 Jun 2020 14:48:02 -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; Thu, 25 Jun 2020 14:48:01 -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; Thu, 25 Jun 2020 14:48:01 -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: AdYwRw45XRk4tpgoS1iG4gmrMAvW6QFshBaABUkwXQA=
Date: Thu, 25 Jun 2020 18:48:00 +0000
Message-ID: <1f0ef224791b4c8aa68eb8d1b0730153@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.201.72]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/acme/LPbHetSFM7JbNxCo5FhUppqumz0>
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: Thu, 25 Jun 2020 18:48:11 -0000

Hi Alexey!

Thanks for making the updated in -08.

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

Given very limited support to elevate this to PS, and the limited certainty that there is agreement that this is the canonical way from Cas, let's proceed with informational.

If you have strong a opinion to change the document's track, please say so during IETC LC.

> > ** 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.

Thanks for making these edits and publishing -08.  They address my feedback. 

Regards,
Roman

> 
> 
> Best Regards,
> 
> Alexey
> 
> _______________________________________________
> Acme mailing list
> Acme@ietf.org
> https://www.ietf.org/mailman/listinfo/acme