Subject: Re: [jose] JWK: comments on jku, kid, use, mod..

From: Mike Jones <[email-masked]>
Date: Fri, 6 Jul 2012 18:24:42 +0000

Thanks for the comments, James.  Responses inline...

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]<mailto:[mailto:[email-masked]]> On Behalf Of Manger, James H
Sent: Sunday, May 20, 2012 7:12 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [jose] JWK: comments on jku, kid, use, mod..

A "jku" value is a URL pointing to a 1 or more JSON Web Keys. A "kid" value (key id) is really needed to pick the right key from the set. Consequently the spec should say [in JWS section 4.1.2 "jku" (JWK Set URL) Header Parameter]:

    Producers MUST include a "kid" parameter when including a "jku" parameter.

Per the new text in Section 4.3, there are many potential ways for applications to select the right key(s), including the "use" parameter, the "alg" parameter, and yes, the "kid" parameter.  Applications can also simply try all the keys and see if any of them work.  As such, mandating the use of the "kid" parameter when one is often not needed, would be overkill.

"jku" makes sense for a JWS -- the receiver uses the "jku" URL to get the public key to verify the JWS signature. I'm not sure it makes sense in a JWE, though. The receiver needs a private key to decrypt, not the public key that "jku" points to. At best, "jku" in a JWE acts as an key id -- but we have a separate "kid" field. I think we should drop the "jku" parameter from the JWE spec.

You're correct about the difference between uses for JWS and JWE.  Per a comment from Jim Schaad, added the language "this can be used to determine the private key needed to decrypt the JWE".

The "use" (key use) parameter [JWK 4.2] should be a JSON array of strings, not a single string. It is nice crypto hygiene to have only 1 use for a key. However, multiple uses are common in practise and are not so atrocious that we should forbid it at a syntax level. Particularly given that "other values [than "sig" and "enc"] MAY be used".

See my response to Sean Turner's related comments on the "use" parameter.  Also as background, in XMLDSIG this value is a singleton - not a set - and the use that you would express as ["sig", "enc"] there is instead expressed as omitting the value.  (Not that we need to always follow XMLDSIG, by any means. :))

I would add the word "unsigned" when defining the "mod" and "exp" fields for an RSA key[JWA sections 5.3.1 and 5.3.2] to explicitly avoid confusion given that other specs use signed representations (eg 2's complement) for these keys:

   It is represented as the base64url encoding of the value's

   *unsigned* big endian representation.

Done

I am not sure if adding "unsigned" would clarify the definitions of "x" and "y" for elliptic curve keys since they are not always integers (depends on the type of curve).

Do others in the working group have authoritative information in this regard?  If so, can you please provide us a reference?

--

James Manger

_______________________________________________

jose mailing list

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

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

---

From: "Manger, James H" <[email-masked]>
Date: Sat, 7 Jul 2012 22:20:50 +1000

Mike,

> Per the new text in Section 4.3, there are many potential ways for applications to select the right key(s), including the “use” parameter, the “alg” parameter, and yes, the “kid” parameter.  Applications can also simply try all the keys and see if any of them work.  As such, mandating the use of the “kid” parameter when one is often not needed, would be overkill.

> try all the keys and see if any of them work

What!!
In a JWS, the signer knows the right verification key so it should unambiguously identify it.  Just pointing to a set of keys and saying "its one of those, you work it out" is silly.

When creating a JWE an app can use "alg" and "use" to pick a public key for a recipient (assuming it has a jku URI for the recipient -- though how it gets that is probably out-of-scope for the JWE message syntax). The sender should tell the recipient which specific key it chose. Using the recipient's labels for its own key (ie the kid value) sounds like a sensible choice.

   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.
   [draft-ietf-jose-json-web-key-03]

Allowing the same kid to be used for multiple keys defeats the point of the field. This is a completely unnecessary degree of freedom.

> You’re correct about the difference between uses for JWS and JWE.  Per a comment from Jim Schaad, added the language “this can be used to determine the private key needed to decrypt the JWE”.

jku cannot be used to "determine the private key needed" since it points to a set of keys, not a specific key. 

If you really want to use jku, instead of kid, perhaps we need to define a fragment id for jku URIs to identify one key in the set.

--
James Manger