Thanks for your review, Pete. I've added the working group to the thread so they're aware of your comments.
> -----Original Message----- > From: Pete Resnick [mailto:[email protected]] > Sent: Wednesday, October 01, 2014 9:54 PM > To: The IESG > Cc: [email protected]; [email protected] > Subject: Pete Resnick's Abstain on draft-ietf-jose-json-web-key-33: (with > COMMENT) > > Pete Resnick has entered the following ballot position for > draft-ietf-jose-json-web-key-33: 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: > ---------------------------------------------------------------------- > > Given my concerns with the other documents in this series, I'm not yet > willing to > ballot No Objection on this document. So I will Abstain, at least for the > moment. > We'll see how the rest of the discussion goes. > > Comments directly on this document: > > 4/5: > > The member names within a JWK MUST be unique; recipients MUST either > reject JWKs with duplicate member names or use a JSON parser that > returns only the lexically last duplicate member name, as specified > in Section 15.12 (The JSON Object) of ECMAScript 5.1 [ECMAScript]. > > That first MUST is bogus. You are allowing them not to be unique in the rest > of > the sentence. And it's not clear what you mean by "recipients" > here. Sounds like you mean "parsers" or "interpreters". If it were me, I'd > stick to > the "MUST be unique" and be done with it, but either way this paragraph needs > fixing. The first MUST is a requirement on producers; the second is a requirement on consumers. I propose to reword this text to make this more explicit. This language has been extensively discussed in the working group and again as a result of Stephen Kent's secdir review. For instance, see the thread "JWK member names, was: [jose] SECDIR review of draft-ietf-jose-json-web-key-31" in the JOSE mailing list archives, beginning on 9/12/14. There was a whole JSON working group that created a new standards-track JSON spec (RFC 7159) that that decided *not* to prohibit parsers from accepting inputs with duplicate names. JOSE doesn't have sufficient influence to change the JSON parsers that are actually deployed and available to developers. As Richard Barnes pointed out during the telechat, the point of JOSE is to enable crypto with tools that people actually have and use. If we rule out the use of existing parsers, we will have failed to meet that basic goal. > 4.1: The second paragraph is redundant given the first paragraph; I'd delete > it. Actually, it's not. The second paragraph says where the initial values are defined (Section 6.1 of JWA). > And why do you need "use" at all given that you've got "key_ops"? They are for different use cases. Use is for public-key-only use cases and mirrors what other specs do in this regard. key_ops was later added for WebCrypto, and is for use cases where any of public, private, or symmetric keys may be present. The "use" member predates "key_ops" by several years and was already in widespread use before we added key_ops late in the game. We talked about removing "use" but the working group was very much in favor of retaining it. > 4.5: > > The structure of the "kid" value is > unspecified. > > You should at least mention that this is a string. "The 'kid' value is a text > string, > but it's structure is otherwise unspecified." Or something like that. It actually already does say "The "kid" value is a case-sensitive string". > 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. 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? 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. It describes a requirement of the JWK Set data format this is not otherwise described. > 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. The sentences you would like to move are introductory material motivating the descriptions of encrypted JWKs and JWK Sets and the recommendations to use them under these 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. This specific 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, -- Mike _______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
