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?



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



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

Reply via email to