Subject: Re: [jose] I-D Action: draft-ietf-jose-json-web-key-02.txt

From: Mike Jones <[email-masked]>
Date: Fri, 6 Jul 2012 17:32:35 +0000

Thanks for taking the time to provide the detailed feedback.  Responses inline...

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]<mailto:[mailto:[email-masked]]> On Behalf Of Sean Turner
Sent: Monday, May 28, 2012 10:36 AM
Cc: [email-masked]<mailto:[email-masked]>
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-masked]<mailto:[email-masked]>

https://www.ietf.org/mailman/listinfo/jose

---

From: "Jim Schaad" <[email-masked]>
Date: Sun, 8 Jul 2012 15:55:26 -0700

Comments below

From: [email-masked] [mailto:[email-masked]] On Behalf Of Mike
Jones
Sent: Friday, July 06, 2012 10:33 AM
To: Sean Turner
Cc: [email-masked]
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-masked] [mailto:[email-masked]] On Behalf Of Sean
Turner
Sent: Monday, May 28, 2012 10:36 AM
Cc: [email-masked]
Subject: Re: [jose] I-D Action: draft-ietf-jose-json-web-key-02.txt

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.

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.

s5 as well.

4) s4: Same concerns as for algorithms about the collision resistant
namespace and how the registry is set up.

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?

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.

spt

jose mailing list

 <mailto:[email-masked]> [email-masked]

 <https://www.ietf.org/mailman/listinfo/jose>
https://www.ietf.org/mailman/listinfo/jose

---

From: Sean Turner <[email-masked]>
Date: Tue, 10 Jul 2012 10:18:57 -0400

On 7/6/12 1:32 PM, Mike Jones wrote:
> inline…
> From: [email-masked] <mailto:[email-masked]>
> [mailto:[email-masked]] <mailto:[mailto:[email-masked]]>
> On Behalf Of Sean Turner
> Cc: [email-masked] <mailto:[email-masked]>
> Requirements Language section later on so you might as well save them
> the trouble and just make it part of s2.
>

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

> Addressed, per Jim’s comments

ack

> Addressed, per Jim’s comments

ack

> 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

> [email-masked] <mailto:[email-masked]>
>

---

From: Sean Turner <[email-masked]>
Date: Tue, 10 Jul 2012 10:22:58 -0400

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:
> [email-masked]

---

From: Mike Jones <[email-masked]>
Date: Tue, 10 Jul 2012 18:34:10 +0000

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-masked]] 
Sent: Tuesday, July 10, 2012 7:23 AM
To: Mike Jones
Cc: [email-masked]
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:
>> 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 
>> So I'm reluctant to define "both".  The simplest way to indicate both 
>> 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:

---

From: Mike Jones <[email-masked]>
Date: Fri, 13 Jul 2012 21:19:34 +0000

Responses inline...

From: Jim Schaad [mailto:[email-masked]]
Sent: Sunday, July 08, 2012 3:55 PM
To: Mike Jones; 'Sean Turner'
Cc: [email-masked]
Subject: RE: [jose] I-D Action: draft-ietf-jose-json-web-key-02.txt

Comments below

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]<mailto:[mailto:[email-masked]]> On Behalf Of Mike Jones
Sent: Friday, July 06, 2012 10:33 AM
To: Sean Turner
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [jose] I-D Action: draft-ietf-jose-json-web-key-02.txt

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]<mailto:[mailto:[email-masked]]> On Behalf Of Sean Turner
Sent: Monday, May 28, 2012 10:36 AM
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [jose] I-D Action: draft-ietf-jose-json-web-key-02.txt

s5 as well.

I'll add this to the Open Issues section.

Done

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