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

[Stephen Farrell <[e-mail]>]

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.

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

> In the
> case of new gTLDs, the [ICANN-TMCH]
> (<http://newgtlds.icann.org/en/about/trademark-clearinghouse/rpm-requiremen
> 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?

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