Responses inline... From: Jim Schaad [mailto:[email protected]] Sent: Sunday, July 08, 2012 3:55 PM To: Mike Jones; 'Sean Turner' Cc: [email protected] Subject: RE: [jose] I-D Action: draft-ietf-jose-json-web-key-02.txt
Comments below From: [email protected]<mailto:[email protected]> [mailto:[email protected]]<mailto:[mailto:[email protected]]> On Behalf Of Mike Jones Sent: Friday, July 06, 2012 10:33 AM To: Sean Turner Cc: [email protected]<mailto:[email protected]> Subject: Re: [jose] I-D Action: draft-ietf-jose-json-web-key-02.txt Thanks for taking the time to provide the detailed feedback. Responses inline... -----Original Message----- From: [email protected]<mailto:[email protected]> [mailto:[email protected]]<mailto:[mailto:[email protected]]> On Behalf Of Sean Turner Sent: Monday, May 28, 2012 10:36 AM Cc: [email protected]<mailto:[email protected]> Subject: Re: [jose] I-D Action: draft-ietf-jose-json-web-key-02.txt Here's some comments (again I'll try not to duplicate Jim's): 1) s2 & Requirements Language: The RFC editor is going to move the Requirements Language section later on so you might as well save them the trouble and just make it part of s2. Done here, plus in JWE, JWS, JWA, JWT, JWE-JS, JWS-JS, and SWD 2) s3: This is probably a style thing, but I think it's probably better to talk about the structure first and then provide an example. It's just going to make everybody ask you to define/explain x in that section. I tried to do this and couldn't find a better location. The spec is so short, that you're never more than a page from the example to the normative text anyway. :-) Besides, given that all the meaty parts (the actual algorithm specifications) have moved to the JWA spec, the descriptions would probably be pretty abstract without an example to root them in. Left as is, at least for now. 3) s4: Totally agree with Jim's comment #4 on this section. Applies to s5 as well. Addressed, per Jim's comments 4) s4: Same concerns as for algorithms about the collision resistant namespace and how the registry is set up. Addressed, per Jim's comments 5) s4.2: Assume "both" should be defined here. At least for Elliptic Curve keys, I believe that there's a potential vulnerability with using the same key for both signing and encryption. So I'm reluctant to define "both". The simplest way to indicate both may be to omit the parameter. This could also be represented by repeating the key with "use":"sig" and "use":"enc" in the key set. What do others in the working group think about these possibilities? [JLS] If you are asking for input, why is not in the open issues section? I'll add this to the Open Issues section. 6) s7: If the kid is not supposed to be generated in a way to make it unique it's worth pointing this out in s7. Done [JLS] Please point me to the text that does this. I don't see it. http://tools.ietf.org/html/draft-ietf-jose-json-web-key-03#section-4.3 "Key ID values within a JWK Set need not be unique; for instance, in some contexts different keys using the same Key ID value might be present, with the keys being disambiguated using other information, such as the "alg" or "use" values." spt _______________________________________________ jose mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/jose
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
