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 revision 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 B. Jones
I-D last updated 2014-09-03
Completed reviews Genart Last Call review of -31 by Scott W. Brim (diff)
Secdir Last Call review of -31 by Stephen Kent (diff)
Assignment Reviewer Scott W. Brim
State Completed
Request Last Call review on draft-ietf-jose-json-web-key by General Area Review Team (Gen-ART) Assigned
Reviewed revision 31 (document currently at 41)
Result Ready
Completed 2014-09-03
review-ietf-jose-json-web-key-31-genart-lc-brim-2014-09-03-00
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