Skip to main content

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 revision 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
I-D 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 M. 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 M. Halpern
State Completed
Request Last Call review on draft-ietf-stir-certificates by General Area Review Team (Gen-ART) Assigned
Reviewed revision 15 (document currently at 18)
Result Ready
Completed 2017-11-16
review-ietf-stir-certificates-15-genart-lc-halpern-2017-11-16-00
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: