Thanks again for your hard work on this draft. I do have some comments and questions listed below. I know we still have at least one or two outstanding issues from the last review, so hopefully they can get addressed soon.
1. Introduction, 2nd paragraph: Goals for this specification do not include representing certificate chains, representing certified keys, and replacing X.509 certificates. I see that you actually do address this is section 3.6. Could you clear up the text int he introduction and add something to say that the appropriate references will be provided? It seems like a wording mis-match that is easy enough to address and make clear from the start. Here is the text from 3.6 (bottom of p6): The identified resource MUST provide a representation of the certificate or certificate chain that conforms to RFC 5280 [RFC5280] in PEM encoded form [RFC1421]. 2. Terminology: The definitions for JWK and JWK set are not clear in this section alone. It seems to be explained at the start of section 3, so could you clean up the definition a bit for each and reduce the redundancy? For instance the JWK represents a cryptographic key and contains the properties and value of the key. The JWK Set definition doesn't explain the use of "keys" here to make the definition clear. Maybe just stating it more basically would help, where the term member is understood as an object member when you describe the array of JWK values. This should be an easy enough fix that will assist with readability and understanding before diving deeper. The start of section 4 reads better with this explanation once again in the draft. 3. Section 3. Paragraph 3 also appears in the JWS document and I am noting it here as there is an ongoing discussion. Adjustments to language may be needed here as well. 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]. 4. Section 3.6 COuld you include an example of a common representation and what would be required if PKI X.509 certificates are not used? It could help interoperability to spell out what is required rather than just saying include what is required. I suspect developers may come up with very different representations left to their own devices. For instance, if the "use" member is present, then it needs to allow for only a subset of the usages that are permitted by the certificate. Similarly, if the "alg" member is present, it should represent an algorithm that the certificate allows. 5. Section 3.8 You should add another one for SHA-2 if this will be used by the XMPP community since they are trying to drop the use of SHA-1. (2nd paragraph changes somehow depending on how you do this.) 6. Section 4 If the text from the following paragraph is updated from the discussion resulting from the JWS review, it should get updated here as well. Included so it's not forgotten. The member names within a JWK Set MUST be unique; recipients MUST either reject JWK Sets 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]. 7. Section 6, first sentence. Not sure "contexts" is the right word here: JWKs containing non-public key material will need to be encrypted in some contexts to prevent the disclosure of private or symmetric key values to unintended parties. If the goal is to prevent disclosure (if you don't care about that, you don't do it), shouldn't this read: JWKs containing non-public key material will need to be encrypted to prevent the disclosure of private or symmetric key values to unintended parties. 8. Section 6 This question really starts from the JWS draft, but I am mentioning it here as I am not sure how a developer would know how/when to use "cty" and "typ". I find the language a little confusing and then how the possibilities are spread throughout various drafts rather than in one place (JWS 4.1.8 & 4.1.9, JWK 6) and Oauth (JWT 5.1 and 5.2), and maybe more? The initial description in 4.1.8 and 4.1.9 could be crisper and how it refers to the IANA MIME Media Type registry. They are also optional, so the point of using them isn't clear enough to me. Can you fix the language in the drafts to address this? A "cty" (content type) Header Parameter value of "jwk+json" MUST be used to indicate that the content of the JWE is a JWK, unless the application knows that the encrypted content is a JWK by another means or convention. >From "cty" 4.1.9 of JWS: This parameter has no effect upon the JWS processing. Use of this Header Parameter is OPTIONAL. I'm not sure why you would use it then and if it is there, why would you process it? The language in these drafts may need to be cleaned up a bit, otherwise, It's not clear why this is defined. If you know it is a JWK – do you ignore the value of cty if present or should you still check it and fail if it is not “jwk+json” Then in JWT (I know t is Oauth and not this WG), they have you use upper case instead of lower case letters to represent the value. How does a developer track this if it is not in one place? Section 5.1 While media type names are not case-sensitive, it is RECOMMENDED that "JWT" always be spelled using uppercase characters for compatibility with legacy implementations. I guess it is all in the media type definitions, but seems odd that the recommendations switch from upper to lower case depending on what tag is used. I'm guessing that there is some history here that explains it and probably can't be changed without causing issues… but it could cause confusion. 9. Security Considerations I know you are aware, but this should be updated similar to the other drafts, addressing additional concerns specific to this draft. If this should just reference the security considerations of one, that's fine and just add what's needed for this draft. People don't mind reading something only once when reviewing a set of drafts :-) -- Best regards, Kathleen
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
