Thanbks Sean. On the first point, using "latter" will fix the problem
nicely.
On the point about CA conflicts, I understand the desire to stay out of
the swamp. Given that calls are frequently international, I am unclear
how National Numbering Authorities can address the issue of
inappropriate assertions from foreign CAs. Each country can protect
itself from folks pretending to be it. But they can't protect
themselves from other-A authorizing numbers within other-B.
I could well understand identifying the problem and saying that this
work does not attempt to resolve it. I would not consider that to be
copying text, given that the referenced section is MUCH vaguer than that.
Having said that, I do consider it minor, and if you feel it would harm
the document then that is more important.
Yours,
Joel
On 11/21/17 10:19 AM, Sean Turner wrote:
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