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

[Stephen Farrell <[e-mail]>]

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" <[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?

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