Thank you Russ, Comments inline. Regards, Gustavo On 2/12/16, 08:57, "Russ Housley" <housley@xxxxxxxxxxxx> 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. >
Attachment:
default[11].xml
Description: XML document
Attachment:
default[12].xml
Description: XML document
<<attachment: smime.p7s>>