Re: [Gen-art] Gen-ART Review of draft-ietf-eppext-tmch-smd-04

Gustavo Lozano <gustavo.lozano@icann.org> Fri, 19 February 2016 23:53 UTC

Return-Path: <gustavo.lozano@icann.org>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D80591B36B9; Fri, 19 Feb 2016 15:53:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.207
X-Spam-Level:
X-Spam-Status: No, score=-4.207 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=ham
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 l7qVSfRAulTB; Fri, 19 Feb 2016 15:53:54 -0800 (PST)
Received: from out.west.pexch112.icann.org (pfe112-ca-1.pexch112.icann.org [64.78.40.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14F501B36B7; Fri, 19 Feb 2016 15:53:54 -0800 (PST)
Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) with Microsoft SMTP Server (TLS) id 15.0.1130.7; Fri, 19 Feb 2016 15:53:52 -0800
Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.1130.005; Fri, 19 Feb 2016 15:53:52 -0800
From: Gustavo Lozano <gustavo.lozano@icann.org>
To: Jari Arkko <jari.arkko@piuha.net>, Russ Housley <housley@vigilsec.com>
Thread-Topic: [Gen-art] Gen-ART Review of draft-ietf-eppext-tmch-smd-04
Thread-Index: AQHRZbZ7IpcuizW6s0aHw1ZN/8OW1J8yBJmAgAIRhgA=
Date: Fri, 19 Feb 2016 23:53:51 +0000
Message-ID: <D2ECEA3F.F5462%gustavo.lozano@icann.org>
References: <46A1A261-E9F4-414D-AAD8-9C85A8B53283@vigilsec.com> <2D099350-6295-4486-8919-3E347CDCF109@vigilsec.com> <20EB4776-9221-4732-95D0-A666E6C9903B@piuha.net>
In-Reply-To: <20EB4776-9221-4732-95D0-A666E6C9903B@piuha.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.6.1.160122
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [192.0.35.2]
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3538742028_4409779"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/gen-art/SwhZEyQ4C5rdt10K7uxIKZuVdZM>
Cc: "draft-ietf-eppext-tmch-smd.all@ietf.org" <draft-ietf-eppext-tmch-smd.all@ietf.org>, IETF Gen-ART <gen-art@ietf.org>, IETF <ietf@ietf.org>
Subject: Re: [Gen-art] Gen-ART Review of draft-ietf-eppext-tmch-smd-04
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 19 Feb 2016 23:53:56 -0000

Thank you Jari,

Comments inline.

Regards,
Gustavo

On 2/18/16, 00:18, "Jari Arkko" <jari.arkko@piuha.net> wrote:

>Many thanks for your reviews, Russ.
>
>I have looked at the document as well, looked up the reference, and agree
>with Russ’ comment that there is something missing. I would have wanted
>to talk about this issue wrt this document on tonight’s IESG telechat,
>but Stephen Farrell has already raised this point. I am interested in the
>matter being resolved, however.

Gustavo - I replied to Stephen¹s comment,
reply here: 
https://mailarchive.ietf.org/arch/msg/eppext/cNizylFVKdWXu20OKKlq5gIA1KM


>
>Also, Gustavo, did you get a chance to look at Russ’ editorial comments?
>Those seem worthwhile to be addressed as well.

Gustavo - Yes, I uploaded version 05 of the I-D that includes Russ’
editorial comments.

Version 05 is here:

https://tools.ietf.org/html/draft-ietf-eppext-tmch-smd-05


>
>Thanks,
>
>Jari
>
>On 12 Feb 2016, at 18:57, Russ Housley <housley@vigilsec.com> wrote:
>
>> 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 wait for direction from your
>> document shepherd or AD before posting a new version of the draft.
>> 
>> For more information, please see the FAQ at
>> <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
>> 
>> Document: draft-ietf-eppext-tmch-smd-04
>> Reviewer: Russ Housley
>> Review Date: 2016-02-12
>> IETF LC End Date: 2015-12-04
>> IESG Telechat date: 2016-02-18
>> 
>> Summary:  Not Ready
>> 
>> 
>> Major Concerns:
>> 
>> 
>> The Security Considerations include this paragraph:
>> 
>>   Signed Marks are used primarily for sunrise domain name registrations
>>   in gTLDs, but other third-parties might be using them.  A party using
>>   Signed Marks should verify that the digital signature is valid based
>>   on local policy.  In the case of gTLDs, the RPM Requirements document
>>   [ICANN-TMCH] defines such policy.
>> 
>> The RPM Requirements document [ICANN-TMCH] does not seem to say anything
>> at all about validating a digital signature.
>> 
>> Protocols that make use of certificates perform some checks on the
>> certificate subject name to ensure that it represents an appropriate
>> signer.  That is missing from this document, and it is not contained in
>> [ICANN-TMCH] either.
>> 
>> 
>> Minor Concerns:
>> 
>> Section 2, second paragraph, I think that use of the phrase "in the
>> appropriate objects" ass ambiguity.  I suggest:
>> 
>>   This section defines some elements as OPTIONAL.  If an elements is
>>   not defined as OPTIONAL, then it MUST be included in the object.
>> 
>> The NOTE at the end of Section 2.3 about choosing an algorithm other
>> that RSA-SHA256 is better suited for the Security Considerations.
>> It would be helpful to say something more about the needed security
>> strength.
>> 
>> Why is RFC5730 a normative reference?  I do not see a dependency.
>> 
>> 
>> Other Editorial Comments:
>> 
>> Section 1: s/nothing precudle/nothing precludes/
>> 
>> _______________________________________________
>> Gen-art mailing list
>> Gen-art@ietf.org
>> https://www.ietf.org/mailman/listinfo/gen-art
>