Last Call Review of draft-ietf-jose-json-web-key-31
review-ietf-jose-json-web-key-31-genart-lc-brim-2014-09-03-00

Request Review of draft-ietf-jose-json-web-key
Requested rev. no specific revision (document currently at 41)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2014-09-03
Requested 2014-08-21
Authors Michael Jones
Draft last updated 2014-09-03
Completed reviews Genart Last Call review of -31 by Scott Brim (diff)
Secdir Last Call review of -31 by Stephen Kent (diff)
Assignment Reviewer Scott Brim 
State Completed
Review review-ietf-jose-json-web-key-31-genart-lc-brim-2014-09-03
Reviewed rev. 31 (document currently at 41)
Review result Ready
Review completed: 2014-09-03

Review
review-ietf-jose-json-web-key-31-genart-lc-brim-2014-09-03

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
<

http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please wait for direction from your document shepherd or AD before
posting a new version of the draft.

Document: draft-ietf-jose-json-web-key-33
Reviewer: Scott Brim
Review Date: 2014-09-28
IETF LC End Date: 2014-09-03
IESG Telechat date: 2014-10-02

Summary: ready with possible minor issues

Major issues:

Minor issues:

  More than once it is said that members that are not understood
  should or must be ignored. Wouldn't this depend on context? Couldn't
  there be uses of the data structure where a negative reply would be
  needed if something is not understood, so the sender can adapt?

  In Section 4.3, you give the general principle that multiple
  unrelated key operations shouldn't be specified for a key, and give
  an example. Since this is a security issue of unknown magnitude (the
  future isn't here yet), what do you think of removing uncertainty by
  being more exhaustive in the principles and/or examples?

Nits/editorial comments:


... Scott