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

[Stephen Farrell <[e-mail]>]

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