Re: Genart last call review of draft-ietf-stir-certificates-15

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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





[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]