Last Call Review of draft-ietf-stir-certificates-15
review-ietf-stir-certificates-15-genart-lc-halpern-2017-11-16-00

Request Review of draft-ietf-stir-certificates
Requested rev. no specific revision (document currently at 18)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2017-11-30
Requested 2017-11-16
Authors Jon Peterson, Sean Turner
Draft last updated 2017-11-16
Completed reviews Genart Last Call review of -10 by Ralph Droms (diff)
Genart Last Call review of -15 by Joel Halpern (diff)
Opsdir Last Call review of -15 by Sheng Jiang (diff)
Secdir Last Call review of -10 by Klaas Wierenga (diff)
Assignment Reviewer Joel Halpern
State Completed
Review review-ietf-stir-certificates-15-genart-lc-halpern-2017-11-16
Reviewed rev. 15 (document currently at 18)
Review result Ready
Review completed: 2017-11-16

Review
review-ietf-stir-certificates-15-genart-lc-halpern-2017-11-16

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: