> On Nov 17, 2017, at 14:56, Joel Halpern <jmh@xxxxxxxxxxxxxxx> wrote: > > Reviewer: Joel Halpern > Review result: Ready > > 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-stir-certificates-15 > Reviewer: Joel Halpern > Review Date: 2017-11-16 > IETF LC End Date: 2017-11-30 > IESG Telechat date: 2017-12-14 > > Summary: > > Major issues: > > Minor issues: > Section 4 bullet 4 in naming the crypto algorithms refers quite clearly to > 2 algorithms. It then references one of them as RS256. I assume those > versed in the field will know which one is meant. But it would be better > if the abbreviation RS256 appeared next to the first reference to whichever > algorithm it means. Ah okay I see what’s going on, the two algorithms are introduced in the previous sentence but we use the registered value as opposed to the name in the next sentence. How about I replace “RS256" with the “latter” as it is the 2nd algorithm discussed in the previous sentence. > The security considerations section points to RFC 5280 security > considerations for most issues. I presume that the intention is to use > that section regarding trusting CAs. However, it seems that there is an > issue here much like that of classic web CAs. The number of CAs that must > be trusted seems to be on the order of the number of countries in the > world. That seems to leave a large window for false or misleading > certifications, as I can see nothing which restricts what numbers for which > those top level CAs can provide attestation. I presume we do not want to > go down the path of requiring an uber-CA for all national authorities. I > would expect some explicit recognition of this issue in this document. Two points intertwined here: - uber-CA: The WG explicitly agreed to say nothing about this topic. I agree with you that we should not add any text concerning this point. - Trust Anchor/Delegation: RFC5280’s SecCons already state that determining the Trusted CA (aka Trust Anchor) is out of scope. The same is true here and I guess I could copy that text over, but it seems unnecessary in my mind given that a) half the time I get chastised for copying forward SecCons, and more importantly b) there’s are more specifications required to implement this including but not limited to a CP (Certification Policy) and CPS (Certification Practice Statement); these additional specifications get written/approved/published by National Numbering Authorities. spt