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

[Gustavo Lozano <[e-mail]>]

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

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

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