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

[Gustavo Lozano <[e-mail]>]

Thank you again Stephen,

I just published version 06 with your suggestions.

‹

Colleagues,

I think that this version solves all the concerns and incorporates the
suggestions received from the community, IESG, etc.


Regards,
Gustavo

On 3/9/16, 21:20, "Stephen Farrell" <[e-mail]> wrote:

>
>
>On 09/03/16 18:02, Gustavo Lozano wrote:
>> Thank you Stephan, I appreciate your input,
>> 
>> I modified the following paragraph in the introduction section based on
>> your suggestion, and added the tmch-func-spec I-D to the informative
>> section. Do you think that the aforementioned changes solve your
>>concerns?
>> 
>> It's worth mentioning that I have not published a newer version of the
>> I-D, because I want to know your thoughts first.
>> 
>> - - start - -
>> The detailed policy regarding the public key infrastructure (PKI),
>> authorized validators, and other requirements must be defined based on
>>the
>> local policy of the entities using this specification. In the case of
>> gTLDs, the detailed policy regarding the use of this specification is
>> defined in the Rights Protection Mechanism Requirements document (see
>> [ICANN-TMCH]), and the PKI is defined in
>>[I-D.ietf-eppext-tmch-func-spec].
>> - - end - 
>
>That's good but needs a little more I think, maybe like:
>
>"The detailed policy regarding the public key infrastructure (PKI),
>authorized validators, and other requirements must be defined based on
>the local policy of the entities using this specification. In the case
>of gTLDs, the detailed policy regarding the use of this specification is
>defined in the Rights Protection Mechanism Requirements document (see
>[ICANN-TMCH]), and the PKI is defined in
>[I-D.ietf-eppext-tmch-func-spec]. Implementations will need to implement
>such a PKI (or an
>equivalent) in order for the signatures defined in this document to
>have any useful semantics."
>
>I think you also need to say something similar in the security
>considerations section where you currently only point to ICANN-TMCH.
>You could do that by pointing back to the above text maybe.
>
>Cheers,
>S.
>
>> 
>> Regards,
>> Gustavo
>> 
>> On 3/7/16, 15:57, "Stephen Farrell" <[e-mail]> wrote:
>> 
>>>
>>> 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-requ
>>>>>>ir
>>>>>> em
>>>>>> 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:-)
>>>>>>>
>>>>>>>
>