Skip to main content

Last Call Review of draft-ietf-jose-jwk-thumbprint-05
review-ietf-jose-jwk-thumbprint-05-secdir-lc-montville-2015-06-10-00

Request Review of draft-ietf-jose-jwk-thumbprint
Requested revision No specific revision (document currently at 08)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2015-06-11
Requested 2015-06-05
Authors Michael B. Jones , Nat Sakimura
I-D last updated 2015-06-10
Completed reviews Genart Last Call review of -05 by Joel M. Halpern (diff)
Genart Telechat review of -06 by Joel M. Halpern (diff)
Secdir Last Call review of -05 by Adam W. Montville (diff)
Opsdir Last Call review of -05 by Sarah Banks (diff)
Assignment Reviewer Adam W. Montville
State Completed
Request Last Call review on draft-ietf-jose-jwk-thumbprint by Security Area Directorate Assigned
Reviewed revision 05 (document currently at 08)
Result Has issues
Completed 2015-06-10
review-ietf-jose-jwk-thumbprint-05-secdir-lc-montville-2015-06-10-00
Hi,

I have reviewed this document as part of the security directorate's ongoing
effort to review all IETF documents being processed by the IESG. These comments
were written primarily for the benefit of the security area directors. Document
editors and WG chairs should treat these comments just like any other last call
comments.

I believe the document is ready with (potential) issues.  The “with issues”
might be due to ignorance on my part.  The draft does a very good job of
explaining the canonical form of a JSON Web Key that can be used for
establishing a thumbprint under varying circumstances, complete with what I
found to be helpful examples.

The primary issue I have is that it’s unclear how relying parties are going to
know which hash algorithm has been used.  The examples use SHA-256, but I’m not
seeing where SHA-256 might be specified as a MUST or even a SHOULD.  Moreover,
the example output ultimately shows only the Base-64 encoding of the resulting
hash, which says nothing about the algorithm used to identify a key.

Additionally, in Section 4, “JSON and Unicode Considerations” some “should”s
are used, but I’m not reading them as SHOULDs.  Should they be SHOULDs?  For
example, the start of the third paragraph in that section: “if new JWK members
are defined that use non-ASCII member names, their definitions should specify
the exact Unicode code point sequences used to represent them.”  It’s not clear
to me whether this is a strong statement or just a recommendation - it seems
that this draft could help the future by making stronger statements to
encourage future interoperability.

Kind regards,

Adam