Responses inline... From: Jim Schaad [mailto:[email protected]] Sent: Sunday, July 08, 2012 3:56 PM To: Mike Jones Cc: [email protected] Subject: RE: Comments on draft-ietf-jose-json-web-key-02
Comments on responses and some additional comments as well. If the security sections references the XML DSig document as having important security considerations, then it needs to be normative and not informative. Will do Jim From: Mike Jones [mailto:[email protected]]<mailto:[mailto:[email protected]]> Sent: Friday, July 06, 2012 10:31 AM To: Jim Schaad Cc: [email protected]<mailto:[email protected]> Subject: RE: Comments on draft-ietf-jose-json-web-key-02 Thanks for taking the time to provide the detailed feedback. Responses inline... -----Original Message----- From: Jim Schaad [mailto:[email protected]]<mailto:[mailto:[email protected]]> Sent: Saturday, May 19, 2012 3:34 PM To: Mike Jones Cc: [email protected]<mailto:[email protected]> Subject: Comments on draft-ietf-jose-json-web-key-02 <no hat> My apologies for introducing you to the term algorithm families. We don't use it in the same way and thus I think that you should generally remove it from the text. To me it is a very wide term and somewhat nebulous. Thus I think of all of the DH algorithms as being in a family - but that family could also include the ECDH algorithm as well as DSA depending on how one is using it. Thus for me an algorithm family is not restricted to a specific instance (or small set of instances) such a DH & DSA but could be as large as all key agreement algorithms. As such it does not really match how you are using it in much of the text. Left in for the current draft for lack of a better term. I did remove as many uses of the term as possible. Slightly more detailed: You can define an RSA key You can define an RSA-OAEP key The second one has all of the fields of the first, however it may have additional fields defined that deal specifically with RSA-OAEP. The difference is going to be a question of restriction of usage of the key to a single algorithm vs allowing for all RSA algorithms. Parameters could be defined in the JWA spec to specify parameters enabling those possible restrictions if the working group deems it useful/necessary. The JWK spec already makes it clear that algorithm-specific parameters may be required, so this wouldn't change the model. Here are some more comments Abstract 1. I am not a fan of the word enumerated in the last sentence. This word implies to me that the list is not expandable. I would recommend something along the lines of "An initial set of ... can be found in ..." Done here, plus in JWE, JWS, JWA, JWE-JS, and JWS-JS [JLS] This change was not made in the JWA document. Correct, because you wrote "I do not have a problem with enumerate in this document" in your May 21st message on JWA. I made a typo when I wrote that I applied it to JWA above. (Also, I actually think that in JWA, the word "enumerates" works well.) Section 2 1. The phrase "For the purpose of this document" should be removed unless this term is used in other ways elsewhere. Not changed, because in some other contexts, the same term is used to refer to the non URL safe encoding. [JLS] Is it used in a different way in this document? One can automatically assumed that if you are defining a term, that it is for the purposes of this document and, unless generally accepted, is not applicable to other documents. Purely for curiosity, where is the phrase base64url encoding used to mean something else in a different document? OK, I'll delete the phrase. The term "base64 encoding" often (usually) means something different, but not the term "base64url encoding". Section 4 1. In para #2 - the use of "algorithm family" is incorrect. They members are going to be required for the specific key being represented not to the family - consider the case of RSA and RSA-OAEP - these are both in the same family, but the fields required are different. Reworded to not use the term "algorithm family" [JLS] Suggest "In addition to the common parameters, each JWK will have members that are specific to the key being represented. These members represent the parameters of the key. Section 5 of the JSON Web Algorithm (JWA) specifies a number of public keys and their associated members." Good 2. Do you believe that all of the algorithm members are defined in the JWA document - or only for some algorithms. Text should probably say they are defined for the algorithms defined for the algorithms in JWA. Done 3. I don't believe that para #3 is enforceable by parsers as they have been presented to me. Please prove me wrong. Section 2.2 of http://tools.ietf.org/html/rfc4627 says "The names within an object SHOULD be unique." So this should be enforced by conforming parsers. I'd be interested in data saying that parsers exist that are non-conforming to this RFC 4627 "SHOULD". If so, we should add appropriate warnings to the Security Considerations section. [JLS] Stating that they should be unique is more of a requirement on the generation side and not the parsing side of the specification. I do not believe that this statement in way says that parsers should reject objects for which duplicate member names exist. Parsers that accept input with duplicate member names are violating a SHOULD, as I see it. In any event, tightening this to "MUST be unique" is appropriate in our specs, since I'll grant you that relying on a SHOULD is inappropriate in a security context. If this requires secondary parsing or using a hardened parser to ensure member uniqueness, that's part of the price of having a correct implementation. (And consider the alternative - we *really* don't want to go down the path of having to make statements like "If there are multiple "alg" values, then..."!) We started talking about these security considerations at http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-03#section-8.2. I'll tighten this up. 4. Let's look at the sentence "If present, they MUST be understood by implementations using them." I believe that this is an incorrect assertion. (Not to mention that it is totally uncheckable.) Consider the following situation: Implementation A creates a JWK and files it with Implementation B. A does not understand the "exist-date" property. Implementation B adds the "exist-date" property and puts it at a URL. Implementation C pulls the JWK from the URL, understand the "exist-date" property. According to the MUST, the JWK cannot be used as it is not understood by all of the implementations. The only entity that you can make the requirement on is the consumer. One assumes that the "provider" would/might understand the field or it would not be there but it could have been added in transit and thus that is not the case. I believe that for your example, the text is correct as written, since in context, "them" refers to the additional members, not the JWK as a whole. At no point in your example did an implementation use a JWK with an additional member that it did not understand. [JLS] This is precisely the statement that I made above, the mandating that the field is understood by consumers of the JWK is possible, but it is not possible to mandate that all implementations involved in the transaction understand all of the fields. Maybe we can talk about this in person in Vancouver, because I think I'm still missing something in what you're trying to achieve here. In your example, the JWK created by A and the JWK created by B by adding the "exist-date" property to A are different JWKs, because they have different fields. At no point did any party, producer or consumer, use a JWK whose fields it did not all understand. (I'll grant you that if A were to use B's JWK, the "must understand" would be violated, but that's exactly the intent.) I understand that the assertion may not be enforceable apart from conformance suites that check what implementations do when given new parameters, and I understand that in the general case, programmatic enforcement would be the equivalent of solving the halting problem. That's not an argument, however, that in security contexts, that having this requirement isn't the right thing to do. [JLS] I have not made an argument for removing it, but for stating that it is the consumer on which the restriction is placed on not on all implementations. You don't think that's equally important for producers to understand all the fields of the JWKs they're producing? 5. I find the last sentence of para #4 to be unreadable. I would start by breaking it into two sentences and potentially move the first one into the JWA document (that about parameters for keys). Simplified [JLS] I think it can be simplified even more. For one thing it is not clear if the member name must be unique between kinds of keys. Thus can you have a "x" for both DH and ECDH (or do they fall into the same family?). Agreed. I'll simplify this further to just say "Member names SHOULD ...". I'll also add "Member names used for representing key parameters for different kinds of keys need not be distinct", per your question about uniqueness. [JLS] Given that only fields dealing with either generic items or a specific key are represented in a JWK object. It would make more sense to have the restriction on member names than on generic members and not on members that are specific to a public key. Agreed - I believe my wording above addresses this. Section 4.1 1. Do you want to point to the JWA document or to the registry for the set of defined algorithms? Clarified that some names are defined in JWA whereas all names not containing a collision resistant namespace should be registered. [JLS] OK - let me be more pointed in my comment. I think you should point at the registry and not at the other document for the list of defined algorithms. Additionally, I think you should point at the registry for the set of generic members defined and ignore the set of key specific members defined in this document. OK, I'll reword this (and similar locations) to make the registry be the primary reference and to add, on a secondary basis, that the JWA document provides the initial contents for the registry. (I believe we continue to need the JWA reference to help reviewers of the current specs, especially since the registry won't be created until the specs are approved as RFCs.) 2. In para #1 I would remove the sentence starting "Specific additional..." as this is not part of the definition of the "alg" parameter and is covered in section 4.0 Done 3. The last two sentences in para #1 can be combined together. This is just a personal stylistic thing I suppose, but I prefer two short declarative sentences to a conjunction of the two. [JLS] as oppose to "The "alg" value MUST be a case-sensitive string. OK, I agree that that wording's better. I'll make that change where applicable. Section 4.2 1. Presentation suggestion - if you use a bulleted list for the values it will be easier to see what the list of defined values is. Done 2. See point #3 in section 4.1 Ditto Section 4.3 1. Is there a requirement that the kid be unique in a JWK Set? I think that the answer should be called out in text either way. Good point. Added text saying that it need not be unique, and providing an example providing rationale for that choice. [JLS] Ok - I see documentation on how to handle the situation if there are multiple KIDs that have the same value, but I am missing the rationale that you have stated as being present. A rationale would be WHY one would have multiple keys with the same KID value. The rationale was in the "for instance" text. We could beef up the rationale if you have better suggested wording. As another example, imagine "kid" values like "Current", "Upcoming", and "Deprecated", used for key rollover guidance. You could apply that label to all keys where the classification fits. If there are multiple "Current" keys, then in this example they might be differentiated either by having different "alg" or "use" values, or some combination of both. (There might only be one current RSASA signing key and one current ECDSA signing key, but both would be "Current".) 2. Is the string case sensitive? It is now. :-) 3. Move the sentence "When used..." to a new paragraph. (suggestion) Done Section 6.1 1. Please make things easy for IANA - create a table with the fields across the top and the values down the table. This will allow them to do their job without having to go through the entire document and for us to be able to easily validate that they got it correct. Done here, plus in JWA and JWT [JLS] Section 6.1.1 - Under the Parameter Name: field, you should have a note for IANA that the name is case-sensitive and have a comment that names that match in a case-insensitive manner SHOULD or SHOULD NOT be accepted. (Copy note to all of the reset of the tables as well). Will do (with SHOULD NOT) [JLS] Section 6.1.1 - are there any longevity requirements on the URI that is specified? If we refer to an RFC then we know that it will "always" exist. This is not necessarily true if one refers to a document on a personal website. Is there best-practice text on this issue that anyone is aware of that we can reuse? (The current text is reused from the OAuth Core spec, which has already undergone IETF last call, and so seemed like a good place to start from.) Section 6.2 1. Please put in a registration section for the items you are registering in Section 4 in the JWK table. You can refer to JWA for creation of the table. Done here, plus in JWS, JWE, JWA, and JWT Appendix A 1. I am not sure why this appendix is in this document. To give credit to the inventors of the precursor spec that resulted in the JWK spec. I've added their names to make this intent clearer.
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
