Thanks for taking the time to provide these comments, Pete. Descriptions of the actions that were taken in the -38 drafts in response to them are included inline below.
> -----Original Message----- > From: Pete Resnick [mailto:[email protected]] > Sent: Tuesday, December 02, 2014 8:37 PM > To: The IESG > Cc: [email protected]; [email protected] > Subject: Pete Resnick's Abstain on draft-ietf-jose-json-web-key-37: (with > COMMENT) > > Pete Resnick has entered the following ballot position for > draft-ietf-jose-json-web-key-37: Abstain > > When responding, please keep the subject line intact and reply to all email > addresses included in the To and CC lines. (Feel free to cut this introductory > paragraph, however.) > > > Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > http://datatracker.ietf.org/doc/draft-ietf-jose-json-web-key/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I've got some suggestions for improvements below, but overall I cannot > support this document, so I'm entering an ABSTAIN. I don't think this WG has > actually fulfilled its charter with regard to this document set. The WG was > supposed to produce a "JSON syntax that can be used by applications to > describe secure data objects". I don't believe it did that. Instead, it > produced > a compact serialization for a particular purpose and then backed into a JSON > syntax. The compact serialization drove the effort and produced IMO a > substandard JSON serialization. I don't believe that (reliable) interoperable > implementations of the JSON serialization will be possible using this > document set. However, there is at least rough consensus that these > documents are usable as-is, and I don't think there's anything to be gained by > holding them up any further. > > I hope the WG will adopt some of the remaining comments, but my intention > is not to discuss this any further. If you wish to address any of the comments > and need clarification, I'm glad to help with that. > > ------ > > 4/5: > > There was a discussion about the "The member names within a JWK MUST > be unique" paragraphs, and a proposal to fix them. No fixing was done. In response to your and others' comments on -33, the wording was changed in -34 to no longer refer to "recipients" and instead to talk about "parsers". As for the larger semantic issue, the current language is there to encourage consumers to use strict parsers, if available, while allowing them to use JSON parsers as they exist in the marketplace if not. Producers MUST always produce valid inputs. This has probably been the most discussed spec issue, including substantial input by the chair and editor of the JSON working group that produced RFC 7159. I believe that the current semantics are the best that we can practically specify at this time. > 4.1: The second paragraph is unnecessary and should be removed. Repeatedly implementers have shown to be confused by us having moved parts of the definitions that are essential to implementing JWS, JWE, and JWK into a different spec - JWA. Telling them where they can find the missing information seems like the least we can do. (All implementers are not experts at reading RFCs and using IANA registries!) > Also, > "use" is unnecessary given "key_ops" and should be removed. As previously discussed, both are in widespread use for different use cases. > 4.6 (and 4.7-4.9): > > If other members > are present, the contents of those members MUST be semantically > consistent with the related fields in the first certificate. > > This is a pretty silly use of MUST. If the answer to the question, "Why might > someone do otherwise?" is "Because they're an idiot", you probably don't > need the MUST. As previously discussed, Jim Schaad and others were in favor of adding this language when the "x5u", etc. parameters were added ... so that idiots aren't free to be idiots. :-) > 5: > > Implementations SHOULD ignore JWKs within a JWK Set that use "kty" > (key type) values that are not understood by them, are missing > required members, or for which values are out of the supported > ranges. > > I don't understand that SHOULD. This is completely dependent on what the > implementation is doing. Unknown key types might be ignorable, but they > might be vitally important. Why is this not a MAY? As previously discussed, this language also came from Jim Schaad. The point is that when RSA and Elliptic Curve keys are eventually replaced by new key types, implementations should be prepared to have new key types appear in the set of advertised keys without breaking because they don't yet understand them. > 5.1: Strike the last sentence. It's silly. This was done in draft -34. > 7: The first two sentences of the first paragraph and the first sentence of > the > second paragraph should be moved under Security Considerations; that's > what this is. I'd delete the rest, as the encryption of any JSON object is > handled by JWE. As previously discussed, the sentences you are suggesting be moved are introductory material motivating the descriptions of encrypted JWKs and JWK Sets and the recommendations to use them under particular circumstances. > You might mention the content type somewhere, but the way it is in the > document now is way overdone, with the whole "MUST...unless > construction. Simply make it: > > The content type of "jwk+json" can be used for "cty" header of the JWE. > > if you must have something. As previously discussed, this language, using the "must ... unless" construction, was a result of a specific working group discussion on this topic, so I'm reluctant to tinker with it. For instance, your "can" language loses the "must ... unless" sense that some working group members insisted upon. Thanks again, Pete! -- Mike _______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
