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

Stephen Farrell <stephen.farrell@cs.tcd.ie> Mon, 07 March 2016 15:57 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 5C37B1B4346; Mon, 7 Mar 2016 07:57: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 hEjTSGB3QbSh; Mon, 7 Mar 2016 07:57:35 -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 BFEB51B4288; Mon, 7 Mar 2016 07:57:34 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 6930EBE4D; Mon, 7 Mar 2016 15:57:33 +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 0AL6APwaTDRD; Mon, 7 Mar 2016 15:57:33 +0000 (GMT)
Received: from [134.226.62.192] (cswireless62-192.scss.tcd.ie [134.226.62.192]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id E1BEEBE33; Mon, 7 Mar 2016 15:57:32 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1457366253; bh=OMchDTl25WhPjhRon1Nq4V6/6lP8JoXG+7iMU9V8pis=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=KhIBDECRruSKwAHMv9s6+HxNN1y9kHxFP6DHTSx4MATapY6rtkTq8JxwBcB2jTbhN 8Z0EKJTtnH/6inDoTvGzwgZq8etZ20xWyR/2uOzk733XsgNdAgxe0PbKSNwIdXIz2+ btgCsWWRCYSXiMbbFQqEZhbtKynyCbXz3QpLpdsY=
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> <56D9B557.3020001@cs.tcd.ie> <D300AC67.F8C28%gustavo.lozano@icann.org>
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Message-ID: <56DDA4EC.7040402@cs.tcd.ie>
Date: Mon, 7 Mar 2016 15:57:32 +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: <D300AC67.F8C28%gustavo.lozano@icann.org>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms070205040802090307050507"
Archived-At: <http://mailarchive.ietf.org/arch/msg/eppext/0uKDmkxtAVckoCi5e_-xZVwOYxs>
Cc: "draft-ietf-eppext-tmch-smd@ietf.org" <draft-ietf-eppext-tmch-smd@ietf.org>, "nkong@cnnic.cn" <nkong@cnnic.cn>, "eppext@ietf.org" <eppext@ietf.org>, "eppext-chairs@ietf.org" <eppext-chairs@ietf.org>
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: Mon, 07 Mar 2016 15:57:37 -0000

Hiya,

On 05/03/16 16:54, Gustavo Lozano wrote:
> Thank you Stephen,
> 
> Comments inline.
> 
> Regards,
> Gustavo
> 
> On 3/4/16, 10:18, "Stephen Farrell" <stephen.farrell@cs.tcd.ie>; wrote:
> 
>>
>> 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.
> 
> draft-ietf-eppext-tmch-smd-04 defines the format of the XML blob. In other
> words, it should be enough to syntactically validate the XML blob (with or
> without digital signatures). The definition of the PKI is an exercise for
> a party that wants to use this format, and digitally sign the XML blob. In
> the case of the ICANN-TMCH, the PKI is defined in
> draft-ietf-eppext-tmch-func-spec-00.
> 
> 
> I think that this is explained in the introduction, but the text may need
> to be tweaked?

Yes. Both the abstract and intro say that this document defines a thing
called a "digitally signed mark" - some people would consider that to
define such a thing, you do need to say how it relates to a PKI, or, in
this case, to say that that is defined elsewhere and point at an example
of such an elsewhere.

> 
>>
>> 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?). 
> 
> Correct, the root cert mentioned in section 5.1.1.3 of
> draft-ietf-eppext-tmch-func-spec is used for validating the SMDs generated
> by the ICANN-TMCH.
> 
>> 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?
> 
> Correct, draft-ietf-eppext-tmch-func-spec is specific to what ICANN did
> for the new gTLD program. An SMD generated by the ICANN-TMCH basically
> says: a validator using ICANN policies, validated that X is the holder of
> the mark Y. A ccTLD may want to use the same policies, and use the root
> cert provided by ICANN for validating the SMDs generated by the
> ICANN-TMCH. A ccTLD may want to use different policies, use the format
> defined in draft-ietf-eppext-tmch-smd-04, and if interested in using
> digital signatures, define its own PKI.

I think you need that information or an equivalent in this document.
The func-spec reference can be informative and not normative if you need
to have this document as an RFC before the func-spec. (In that case
you'd need to say something like "a PKI for using this with new gTLDs
will also be defined by the EPPEXT WG in [func-spec]".) But I think
it'd be better if this RFC and the func-spec one popped out together.

>>> In the
>>> case of new gTLDs, the [ICANN-TMCH]
>>>
>>> (<http://newgtlds.icann.org/en/about/trademark-clearinghouse/rpm-requirem
>>> en
>>> 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?
> 
> The draft is mentioned as draft-lozano-tmch-func-spec (see section 2.4.1).
> The draft was renamed as draft-ietf-eppext-tmch-func-spec when the EPPEXT
> WG accepted it as a WG document.

As I suggested above, I think you need to refer to func-spec from this
draft. Doing so via the ICANN doc, via an expired I-D seems like a bad
idea when you can do it directly.

Cheers,
S.

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