Re: [secdir] sector review of draft-ietf-jose-jwk-thumbprint-05

[Mike Jones <[e-mail]>]

The registration instructions don't appear to be stored with the registry at http://www.iana.org/assignments/jose/jose.xhtml.  The closest there is there is the Reference field, which specifies [RFC7515], which I assume is how the designated experts are expected to retrieve the instructions.

Does anyone on the thread know if it's possible to add a copy of the registration instructions in the registry itself?  If so, then we'd have a mechanism by which we could update them, as Jim suggested.

				-- Mike

-----Original Message-----
From: Jim Schaad [mailto:[e-mail]] 
Sent: Thursday, June 11, 2015 3:36 PM
To: Mike Jones; 'Adam W. Montville'; 'The IESG'; [e-mail]; [e-mail]
Cc: [e-mail]
Subject: RE: sector review of draft-ietf-jose-jwk-thumbprint-05



> -----Original Message-----
> From: Mike Jones [mailto:[e-mail]]
> Sent: Thursday, June 11, 2015 2:25 PM
> To: Adam W. Montville; The IESG; [e-mail]; draft-ietf-jose-jwk- 
> [e-mail]
> Cc: [e-mail]
> Subject: RE: sector review of draft-ietf-jose-jwk-thumbprint-05
> 
> Hi Adam,
> 
> Thanks for the secdir review.
> 
> > From: Adam W. Montville [mailto:[e-mail]]
> > Sent: Monday, June 08, 2015 8:46 AM
> > To: The IESG; [e-mail]; 
> > [e-mail]
> > Subject: sector review of draft-ietf-jose-jwk-thumbprint-05
> 
> > 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.
> 
> Earlier drafts had included fields whose names were intended to 
> communicate the information about the hash function used - see the 
> "jkt" field definitions in
> http://tools.ietf.org/html/draft-ietf-jose-jwk-thumbprint-01#section-4 
> - but several working group reviewers suggested that these fields were 
> unnecessary and that the typical usage would be as "kid" (key ID) 
> field values.  With that removal, it falls onto the application to 
> specify the hash algorithm for its particular usage.
> 
> This isn't as bad as you might think, however, because typically the 
> consumer of the "kid" doesn't need to know the algorithm because it 
> won't be reproducing the computation.  It just relies on the fact that 
> a unique key ID value was generated for the key and compares "kid" 
> values as opaque strings to find the appropriate key.  In this usage, 
> the producer of the key is the only party that needs to know the hash algorithm that it is using.  I hope this helps.
> 
> > 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.
> 
> For the other JOSE specifications, our chair Jim Schaad took the 
> position that RFC 2119 keywords should be reserved for testable 
> protocol behaviors and that other uses of the English word "should" 
> should not use "SHOULD".  The authors followed that convention in this 
> document.  I do understand that other authors and working groups have 
> taken different positions in this regard.  If there are particular 
> uses that you still feel should be changed to use RFC 2119 keywords, please call them out.

If we really wanted to make sure that the recommendation was followed, then it would make sense to adjust the IANA reviewers instructions for the registry.  Putting a SHOULD or a MUST in this document would not have any effect since it does not define a protocol and might not be seen by anybody defining a new header field.

Jim

> 
> > Kind regards,
> > Adam
> 
> 				Thanks again!
> 				-- Mike