Many thanks for your reviews, Russ. I have looked at the document as well, looked up the reference, and agree with Russ’ comment that there is something missing. I would have wanted to talk about this issue wrt this document on tonight’s IESG telechat, but Stephen Farrell has already raised this point. I am interested in the matter being resolved, however. Also, Gustavo, did you get a chance to look at Russ’ editorial comments? Those seem worthwhile to be addressed as well. Thanks, Jari On 12 Feb 2016, at 18: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. > > > 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. > > 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. > > Why is RFC5730 a normative reference? I do not see a dependency. > > > Other Editorial Comments: > > Section 1: s/nothing precudle/nothing precludes/ > > _______________________________________________ > Gen-art mailing list > Gen-art@xxxxxxxx > https://www.ietf.org/mailman/listinfo/gen-art
Attachment:
signature.asc
Description: Message signed with OpenPGP using GPGMail