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

From: Joel Halpern <[email-masked]>
Date: Thu, 16 Nov 2017 22:56:14 -0800

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.

    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.

Nits/editorial comments:

---

From: Sean Turner <[email-masked]>
Date: Tue, 21 Nov 2017 10:19:12 -0500

> On Nov 17, 2017, at 14:56, Joel Halpern <[email-masked]> wrote:
> 
> Reviewer: Joel Halpern
> Review result: Ready
> 

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.

>    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

---

From: Joel Halpern Direct <[email-masked]>
Date: Tue, 21 Nov 2017 10:24:54 -0500

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

---

From: "Gorman, Pierce A [CTO]" <[email-masked]>
Date: Wed, 22 Nov 2017 14:55:19 +0000

FWIW...

+1 @ "I could well understand identifying the problem and saying that this work does not attempt to resolve it."

-----Original Message-----
From: Joel Halpern Direct [mailto:[email-masked]]
Sent: Tuesday, November 21, 2017 9:25 AM
To: Sean Turner <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [stir] Genart last call review of draft-ietf-stir-certificates-15

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:
>> 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.
>>

________________________________

This e-mail may contain Sprint proprietary information intended for the sole use of the recipient(s). Any use by others is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the message.