Yes, thank you. Kathleen Sent from my iPhone
> On Jun 22, 2015, at 9:18 PM, Mike Jones <[email protected]> wrote: > > I’d be glad to add the explanation below to the draft and to also include an > IANA considerations section that states we are updating the expert review > instructions for a registry, as Jim Schaad had suggested. Chairs and > Kathleen, do you want Nat and I to proceed to publish an updated draft? > > -- Mike > > From: Adam W. Montville [mailto:[email protected]] > Sent: Friday, June 12, 2015 5:07 AM > To: Mike Jones > Cc: The IESG; [email protected]; [email protected]; > [email protected] > Subject: Re: sector review of draft-ietf-jose-jwk-thumbprint-05 > > > On Jun 11, 2015, at 4:25 PM, Mike Jones <[email protected]> wrote: > > Hi Adam, > > Thanks for the secdir review. > > > From: Adam W. Montville [mailto:[email protected]] > Sent: Monday, June 08, 2015 8:46 AM > To: The IESG; [email protected]; [email protected] > 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. > > Yes, this does help, thank you. It seems like something that could be easily > added to the draft to explain why the generating algorithm needn’t be > disclosed so that slow folk like myself get the picture straight away. > > > > > > 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. > > This is all good, too. I was simply pointing out that there are “should”s > around that may need to be considered as “SHOULD”s. I also see Jim’s (and > others’) subsequent notes on the subject, so this is good from my perspective. > > > > > Kind regards, > Adam > > Thanks again! > -- Mike >
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
