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

[Jari Arkko <[e-mail]>]

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 <[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.
> 
> 
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/gen-art