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

From: Stephen Farrell <[email-masked]>
Date: Fri, 4 Mar 2016 16:18:31 +0000

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

---

From: Gustavo Lozano <[email-masked]>
Date: Sat, 5 Mar 2016 16:54:56 +0000

Thank you Stephen,

Comments inline.

Regards,
Gustavo

On 3/4/16, 10:18, "Stephen Farrell" <[email-masked]> wrote:

>>(sections:

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?

>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

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 didn't see any mention of that I-D in [ICANN-TMCH] - are we looking

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.

>>> Please refer to
>>>https://www.ietf.org/iesg/statement/discuss-criteria.html

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 7 Mar 2016 15:57:32 +0000

Hiya,

> I think that this is explained in the introduction, but the text may need

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.

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

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

---

From: Gustavo Lozano <[email-masked]>
Date: Wed, 9 Mar 2016 18:02:20 +0000

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 - 

Regards,
Gustavo

On 3/7/16, 15:57, "Stephen Farrell" <[email-masked]> wrote:

>>>>(<http://newgtlds.icann.org/en/about/trademark-clearinghouse/rpm-requir
>>>>em
>>>> en

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 9 Mar 2016 21:20:59 +0000

> [ICANN-TMCH]), and the PKI is defined in [I-D.ietf-eppext-tmch-func-spec].

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.