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

Stephen Farrell <stephen.farrell@cs.tcd.ie> Fri, 04 March 2016 16:18 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
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 8A44D1A0016; Fri, 4 Mar 2016 08:18:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.302
X-Spam-Level:
X-Spam-Status: No, score=-4.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, 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 bbPtLMvz0uDd; Fri, 4 Mar 2016 08:18:34 -0800 (PST)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B265D1A0060; Fri, 4 Mar 2016 08:18:34 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 3D979BE51; Fri, 4 Mar 2016 16:18:32 +0000 (GMT)
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ShFLfS1nMOFF; Fri, 4 Mar 2016 16:18:32 +0000 (GMT)
Received: from [134.226.36.93] (bilbo.dsg.cs.tcd.ie [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id A24F9BE4D; Fri, 4 Mar 2016 16:18:31 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1457108312; bh=508UI+olH1FOFHrqAuClux+I92eSr+pqt0mtOgfS0J0=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=G3pviCXlYXA+gLyxxm4G0fwi5mdJOrc+wgmtEIpjDtkKgYhiSXJn5woEJ7Bg9m9Wo wjZmS81dPrm/PL2YhNc+9ep17pvGAT9iVM+fvssEfWc7DeD88sjq8vB81QYITZgLWR 3iDmQ3M+KmfPtFF0sPHS58QlkwFvT03EUkj/D2y0=
To: Gustavo Lozano <gustavo.lozano@icann.org>, The IESG <iesg@ietf.org>
References: <20160215191046.25962.24626.idtracker@ietfa.amsl.com> <D2EB39F0.F50BD%gustavo.lozano@icann.org>
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Message-ID: <56D9B557.3020001@cs.tcd.ie>
Date: Fri, 4 Mar 2016 16:18:31 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
In-Reply-To: <D2EB39F0.F50BD%gustavo.lozano@icann.org>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms090204060907050800010707"
Archived-At: <http://mailarchive.ietf.org/arch/msg/eppext/ElBlVFdzGny5-pS0axWEHq8aOOY>
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: Fri, 04 Mar 2016 16:18:37 -0000

Hi Gustavo,

Sorry for the slow response...

On 18/02/16 17:20, Gustavo Lozano wrote:
> 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).

Sorry, but that is too short a story for me to grok it:-)

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

Right. The issue is what information about that PKI is needed in this
draft. Without any, all we end up knowing is that the signature bits
are ok, but nothing about their meaning. Now that could be a valid
approach to take, but you'd need to say so and why say what else is
needed to make an implementation of this usable.

I'm also puzzled that the func-spec draft you mention above, in
section 5.1.1.3, points to a specific root cert (presumably operated by
icann?). Presumably that means that the func-spec is specific to
what ICANN did and plan to do in future with gTLDs and the func-spec
is not meant to be something generic that can be used by e.g. ccTLDs?

> 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 

I didn't see any mention of that I-D in [ICANN-TMCH] - are we looking
at the right things?

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

Right. The question is what information (about the PKI) is needed for
this to be usable in general.

Cheers,
S.

> 
> 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:-)
>>
>>