On 7/6/12 1:32 PM, Mike Jones wrote:
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
Thanks. I know this seems silly, but it's nice to save them some time.
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.
ack
3) s4: Totally agree with Jim's comment #4 on this section. Applies to
s5 as well.
Addressed, per Jim’s comments
ack
4) s4: Same concerns as for algorithms about the collision resistant
namespace and how the registry is set up.
Addressed, per Jim’s comments
ack
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?
Okay so I think I was a little confused here. Implementations will know
the context of "alg" etc. based on which JW* they're in. Both really
wouldn't make sense in that case. But, that makes me think that the
registry needs to be clear about which JW* the algs apply to and that
means adding a new column/bullet in 6.1.1 and then filled out for all in
6.1.2 for:
Usage:
Indicate which JW* construct the algorithm applies to. For
example: JWS.
I suspect there will be some people who will just look at the registry
and not at the tables in s4.
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
ack
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
