See the "Algorithm Usage Location(s)" entries in the registry entries at
http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-03#section-6.1.2
for the very thing you asked for in 5. :-)
Best wishes,
-- Mike
-----Original Message-----
From: Sean Turner [mailto:[email protected]]
Sent: Tuesday, July 10, 2012 7:23 AM
To: Mike Jones
Cc: [email protected]
Subject: Re: [jose] I-D Action: draft-ietf-jose-json-web-key-02.txt
Sorry about this but disregard the response to #5 I was thinking about the
algorithms draft.
spt
On 7/10/12 10:18 AM, Sean Turner wrote:
> 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
>
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
