Gen-ART Review of draft-ietf-eppext-tmch-smd-04

Russ Housley <housley@vigilsec.com> Fri, 12 February 2016 16:57 UTC

Return-Path: <housley@vigilsec.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E27531A6FF8; Fri, 12 Feb 2016 08:57:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.9
X-Spam-Level:
X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] 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 7GOe_5_AC_nO; Fri, 12 Feb 2016 08:57:14 -0800 (PST)
Received: from odin.smetech.net (x-bolt-wan.smeinc.net [209.135.219.146]) by ietfa.amsl.com (Postfix) with ESMTP id D88AB1A6FF7; Fri, 12 Feb 2016 08:57:13 -0800 (PST)
Received: from localhost (unknown [209.135.209.5]) by odin.smetech.net (Postfix) with ESMTP id 4D9F29A4003; Fri, 12 Feb 2016 11:57:13 -0500 (EST)
X-Virus-Scanned: amavisd-new at smetech.net
Received: from odin.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id gYiPuTLDZr4a; Fri, 12 Feb 2016 11:55:54 -0500 (EST)
Received: from [192.168.2.104] (pool-108-51-128-219.washdc.fios.verizon.net [108.51.128.219]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id D13C79A4001; Fri, 12 Feb 2016 11:57:01 -0500 (EST)
Subject: Gen-ART Review of draft-ietf-eppext-tmch-smd-04
Mime-Version: 1.0 (Apple Message framework v1085)
Content-Type: text/plain; charset=us-ascii
From: Russ Housley <housley@vigilsec.com>
In-Reply-To: <46A1A261-E9F4-414D-AAD8-9C85A8B53283@vigilsec.com>
Date: Fri, 12 Feb 2016 11:57:01 -0500
Content-Transfer-Encoding: 7bit
Message-Id: <2D099350-6295-4486-8919-3E347CDCF109@vigilsec.com>
References: <46A1A261-E9F4-414D-AAD8-9C85A8B53283@vigilsec.com>
To: draft-ietf-eppext-tmch-smd.all@ietf.org
X-Mailer: Apple Mail (2.1085)
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/1lYo4vtf-nMwAq4F3SUUozRJuOY>
Cc: IETF Gen-ART <gen-art@ietf.org>, IETF <ietf@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 12 Feb 2016 16:57:16 -0000

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/