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

[Gustavo Lozano <[e-mail]>]

Thank you Stephen,

Comments inline.

Regards,
Gustavo

On 3/4/16, 10:18, "Stephen Farrell" <[e-mail]> 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?

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


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


>
>> 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" <[e-mail]> 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:-)
>>>
>>>
>