Re: Gen-ART Review of draft-ietf-eppext-tmch-smd-04

[Gustavo Lozano <[e-mail]>]

Thank you Russ,

Comments inline.

Regards,
Gustavo

On 2/12/16, 08:57, "Russ Housley" <[e-mail]> wrote:

>I am the assigned Gen-ART reviewer for this draft. The General Area
>Review Team (Gen-ART) reviews all IETF documents being processed
>by the IESG for the IETF Chair. Please wait for direction from your
>document shepherd or AD before posting a new version of the draft.
>
>For more information, please see the FAQ at
><http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
>
>Document: draft-ietf-eppext-tmch-smd-04
>Reviewer: Russ Housley
>Review Date: 2016-02-12
>IETF LC End Date: 2015-12-04
>IESG Telechat date: 2016-02-18
>
>Summary:  Not Ready
>
>
>Major Concerns: 
>
>
>The Security Considerations include this paragraph:
>
>   Signed Marks are used primarily for sunrise domain name registrations
>   in gTLDs, but other third-parties might be using them.  A party using
>   Signed Marks should verify that the digital signature is valid based
>   on local policy.  In the case of gTLDs, the RPM Requirements document
>   [ICANN-TMCH] defines such policy.
>
>The RPM Requirements document [ICANN-TMCH] does not seem to say anything
>at all about validating a digital signature.
>
>Protocols that make use of certificates perform some checks on the
>certificate subject name to ensure that it represents an appropriate
>signer.  That is missing from this document, and it is not contained in
>[ICANN-TMCH] either.
>

Gustavo - I replied to a similar comment from
Stephen, reply here:

https://mailarchive.ietf.org/arch/msg/eppext/cNizylFVKdWXu20OKKlq5gIA1KM



>
>Minor Concerns:
>
>Section 2, second paragraph, I think that use of the phrase "in the
>appropriate objects" ass ambiguity.  I suggest:
>
>   This section defines some elements as OPTIONAL.  If an elements is
>   not defined as OPTIONAL, then it MUST be included in the object.

Gustavo - Fixed in version 5 of the I-D.


See:

https://tools.ietf.org/html/draft-ietf-eppext-tmch-smd-05


>
>The NOTE at the end of Section 2.3 about choosing an algorithm other
>that RSA-SHA256 is better suited for the Security Considerations.
>It would be helpful to say something more about the needed security
>strength.

Gustavo - Fixed in version 5 of the I-D.


>
>Why is RFC5730 a normative reference?  I do not see a dependency.

Gustavo - Fixed in version 5 of the I-D.


>
>
>Other Editorial Comments:
>
>Section 1: s/nothing precudle/nothing precludes/
>

Gustavo - Fixed in version 5 of the I-D.


>