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

[Sean Turner <[e-mail]>]

> 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