Re: [eppext] Stephen Farrell's Discuss on draft-ietf-eppext-tmch-smd-04: (with DISCUSS and COMMENT)

Gustavo Lozano <gustavo.lozano@icann.org> Thu, 18 February 2016 17:20 UTC

Return-Path: <gustavo.lozano@icann.org>
X-Original-To: eppext@ietfa.amsl.com
Delivered-To: eppext@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22A2E1B3149; Thu, 18 Feb 2016 09:20:26 -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 t4rZsY9m-S3N; Thu, 18 Feb 2016 09:20:24 -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 3AA6E1B314F; Thu, 18 Feb 2016 09:20:24 -0800 (PST)
Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-2.pexch112.icann.org (64.78.40.23) with Microsoft SMTP Server (TLS) id 15.0.1130.7; Thu, 18 Feb 2016 09:20:21 -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; Thu, 18 Feb 2016 09:20:21 -0800
From: Gustavo Lozano <gustavo.lozano@icann.org>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>, The IESG <iesg@ietf.org>
Thread-Topic: Stephen Farrell's Discuss on draft-ietf-eppext-tmch-smd-04: (with DISCUSS and COMMENT)
Thread-Index: AQHRanCkrFsYsBamS0CJSQ5Aj4BPiw==
Date: Thu, 18 Feb 2016 17:20:20 +0000
Message-ID: <D2EB39F0.F50BD%gustavo.lozano@icann.org>
References: <20160215191046.25962.24626.idtracker@ietfa.amsl.com>
In-Reply-To: <20160215191046.25962.24626.idtracker@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.6.0.151221
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_3538632017_545259"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/eppext/cNizylFVKdWXu20OKKlq5gIA1KM>
Cc: "draft-ietf-eppext-tmch-smd@ietf.org" <draft-ietf-eppext-tmch-smd@ietf.org>, "eppext-chairs@ietf.org" <eppext-chairs@ietf.org>, "eppext@ietf.org" <eppext@ietf.org>, "nkong@cnnic.cn" <nkong@cnnic.cn>
Subject: Re: [eppext] Stephen Farrell's Discuss on draft-ietf-eppext-tmch-smd-04: (with DISCUSS and COMMENT)
X-BeenThere: eppext@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: EPPEXT <eppext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/eppext>, <mailto:eppext-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/eppext/>
List-Post: <mailto:eppext@ietf.org>
List-Help: <mailto:eppext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/eppext>, <mailto:eppext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 18 Feb 2016 17:20:26 -0000

Thank you for your review Stephen,

Regarding the DISCUSS portion of your email:

Short story: in the case of the gTLD space, the information regarding the
PKI used for validating SMDs is defined here:
https://tools.ietf.org/html/draft-ietf-eppext-tmch-func-spec-00 (sections:
4.1, 5.1.1.3, 5.1.2.3, 5.2.1, 5.2.2, 5.2.3.1, 5.2.3.2, 5.2.4, 5.2.5, 6.2,
6.4).

Long story: https://tools.ietf.org/html/draft-ietf-eppext-tmch-smd-04 (SMD
draft) was conceived as a draft defining a mapping of the common elements
found in trademark data. The design goal is that the SMD draft
specification could be used by any entity (e.g. ccTLDs, gTLDs, trademark
validators <-> distribution channel) for mapping the tradermak data. The
organizations using the digitally signed portion of the spec will need to
define a PKI and the policy for that particular use-case scenario. In the
case of new gTLDs, the [ICANN-TMCH]
(<http://newgtlds.icann.org/en/about/trademark-clearinghouse/rpm-requiremen
ts-30sep13-en.pdf>) is the document (included by reference in the new gTLD
contracts) defining the policy / technical requirements. The document
[ICANN-TMCH] links to
https://tools.ietf.org/html/draft-ietf-eppext-tmch-func-spec-00 where the
technical requirements are specified. For example, a ccTLD may use this
spec with different policy / technical requirements, therefore
[ICANN-TMCH] / draft-ietf-eppext-tmch-func-spec-00 is just how it was done
in the gTLD space. I included [ICANN-TMCH] to provide the context for the
creation of this spec, an as an example of how it was done for new gTLDs.

Regarding the COMMENT portion of your email:

- Please see the secdir review [1] which raises a number of
significant points (including the DISCUSS above) and which
hasn't as far as I've seen gotten a response (apologies if I
missed that).

   [1]
https://www.ietf.org/mail-archive/web/secdir/current/msg06248.html

Gustavo - I think that I resolved all the issues raised in [1] in version
04 of the draft.

- "precudle" nice:-)


Gustavo - I will fix this :).

Regards,

Gustavo

On 2/15/16, 11:10, "Stephen Farrell" <stephen.farrell@cs.tcd.ie>; wrote:

>Stephen Farrell has entered the following ballot position for
>draft-ietf-eppext-tmch-smd-04: Discuss
>
>When responding, please keep the subject line intact and reply to all
>email addresses included in the To and CC lines. (Feel free to cut this
>introductory paragraph, however.)
>
>
>Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
>for more information about IESG DISCUSS and COMMENT positions.
>
>
>The document, along with other ballot positions, can be found here:
>https://datatracker.ietf.org/doc/draft-ietf-eppext-tmch-smd/
>
>
>
>----------------------------------------------------------------------
>DISCUSS:
>----------------------------------------------------------------------
>
>
>Section 7 points to [ICANN-TMCH] for signature validation policy
>(I think, not quite sure). I did a quick scan (so I might have
>missed it) of that document and did not find any mention of
>security or signature validation, so what is an implementer
>supposed to do, over and above just checking the cryptographic
>correctness of the XMLDSIG? Note1: I'm not asking that all of
>the details of how to construct a PKI for this functionality be
>documented here, somewhere else is fine, but it doesn't seem to
>be in [ICANN-TMCH] that I can see, so I don't know what I'd have
>to implement, that'd get interop. Note2: I'm also not asking for
>a US-DoD-scale super-huge PKI or RPKI to be specified here,
>something simpler should work.
>
>
>----------------------------------------------------------------------
>COMMENT:
>----------------------------------------------------------------------
>
>
>- Please see the secdir review [1] which raises a number of
>significant points (including the DISCUSS above) and which
>hasn't as far as I've seen gotten a response (apologies if I
>missed that).
>
>   [1]
>https://www.ietf.org/mail-archive/web/secdir/current/msg06248.html
>
>- "precudle" nice:-)
>
>