Re: [Gen-art] Genart last call review of draft-ietf-lamps-rfc5750-bis-05

[Jim Schaad <[e-mail]>]

> -----Original Message-----
> From: Ines Robles <[e-mail]>
> Sent: Friday, April 27, 2018 4:28 AM
> To: [e-mail]
> Cc: [e-mail]; [e-mail]; [e-mail]
> Subject: Genart last call review of draft-ietf-lamps-rfc5750-bis-05
> 
> Reviewer: Ines Robles
> Review result: Ready with Issues
> 
> Hello,
> 
> 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 treat these comments just like any other last call
> comments.
> 
> For more information, please see the FAQ at
> 
> <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.
> 
> Document: draft-ietf-lamps-rfc5750-bis-05
> Reviewer: Ines Robles
> Review Date: 27-04-2018
> IETF LC End Date:  27-04-2018
> IESG Telechat date: ---
> 
> Summary:
> 
> I believe the draft is technically good. This document is well written and clear
> to understand. Some minor concerns are mentioned that should be resolved
> before publication.
> 
> Major issues: No major issues found.
> 
> Minor issues:
> 
> Section 1.6:
> 
>     It would be nice to start the section with some text like "This document
>     obsoletes 5750 due to the addition of the following information...."

This is missing information, however I think it should go into section 1 - Introduction and not be buried here.  The new text does point to this section.

> 
> Section 2.3:
> 
>     "but SHOULD use some other mechanism to determine ...." => It would be
> nice
>     to mention some examples of the other mechanism
> 
>     "...but SHOULD use some other mechanism (such as ....) to determine..."

I am not sure that this would be a useful addition.  I can see two different outcomes from this which neither of which is helpful.

*  People will complain about implementations which do not implement all of the items in the list
*  People will complain that something should not be implemented because it is not on the list

One of the problems is that this will be a list that is not very useful.  Items can range anywhere from use the set of trust points you already have and don't let it be expanded to call the other person up and get them to read you a hash value to look at various trusted locations for root certificates, including some types of transparency logs.  I cannot really say that any of these is what I would recommend.  The knowledge of how trust configuration is handed is an extremely application and implementation specific function.

> 
> Section 4:
> 
>     Related to this:
>     "Another method under consideration by the IETF is to provide certificate
>     retrieval services as part of the existing Domain Name System (DNS)"
> 
>     - This text seems to be out of the date (since belongs as well to RFC5750
>     (2010)), maybe it would be nice to re-write it (e.g. method under
>     consideration => method approved) and add a reference of the proposed
>     methods. Would it be RFC 8162 [1] a good reference for this topic?
> 
> [1] https://tools.ietf.org/html/rfc8162:  Using Secure DNS to Associate
> Certificates with Domain Names for S/MIME

This was raised during the rfc5751-bis review as well.  I have replaced that sentence with a pointer to the experimental DANE draft.

> 
> Nits/editorial comments:
> 
> Section 2.3: CertificateSet --> Certificate Set
> 
> Section 4.4.1: basicConstraints --> basic Constraints
> 
> Thanks for this document!
> 
> Ines.
>