Re: [Gen-art] Genart last call review of draft-ietf-stir-certificates-15

[Joel Halpern Direct <[e-mail]>]

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 <[e-mail]> 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
>