Subject: [jose] #16: URI identifying a specific key in a JWK set

From: "jose issue tracker" <[email-masked]>
Date: Mon, 25 Mar 2013 00:40:54 -0000

#16: URI identifying a specific key in a JWK set

 When a public key is required to process a JOSE message, providing a URI
 for the key is a useful alternative to providing the actual key or a
 certificate. The URI needs to identify the specific individual public key
 required for the specific JOSE message. A URI that merely identifies a set
 of keys (one of which is the correct one) is not sufficient.

 Given that a "jku" field holds a URI pointing to a set of keys, we need to
 define how to use the fragment part of those URIs to identify a specific
 key in the set.

 Using the "kid" (key id) in the fragment would be a sensible choice.

-- 
-------------------------+-------------------------------------------------
 Reporter:               |      Owner:  draft-ietf-jose-json-web-
  [email-masked]    |  [email-masked]
     Type:  defect       |     Status:  new
 Priority:  major        |  Milestone:
Component:  json-web-    |    Version:
  key                    |   Keywords:
 Severity:  -            |
-------------------------+-------------------------------------------------

Ticket URL: <https://tools.ietf.org/wg/jose/trac/ticket/16>
jose <http://tools.ietf.org/jose/>

---

From: Brian Campbell <[email-masked]>
Date: Mon, 25 Mar 2013 06:31:22 -0600

I'd always just assumed that, short of some other means of figuring it out,
a kid header would accompany a jku to identify the specific key in the set.

On Sun, Mar 24, 2013 at 6:40 PM, jose issue tracker <
[email-masked]> wrote:

> _______________________________________________
> jose mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/jose
>

---

From: Richard Barnes <[email-masked]>
Date: Mon, 25 Mar 2013 18:12:24 -0400

+1

Would be good to have a MUST here to clarify.

On Mon, Mar 25, 2013 at 8:31 AM, Brian Campbell
<[email-masked]>wrote:

> I'd always just assumed that, short of some other means of figuring it
> out, a kid header would accompany a jku to identify the specific key in the
> set.
>
>

---

From: "Manger, James H" <[email-masked]>
Date: Tue, 26 Mar 2013 09:46:51 +1100

> I'd always just assumed that, short of some other means of figuring it out, a kid header would accompany a jku to identify the specific key in the set.

Indeed, “jku” needs to be accompanied by “kid” to work in general — but this is a crappy solution. 99% of the time that a “jku” is used you want to identify a single specific key so “jku” should be capable of doing that without requiring an extra field.

A JOSE header does have room for “kid” as well as “jku”. However, many contexts that use URIs as identifiers expect a URI to be THE identifier. Needing two fields to do one task is inevitably awkward.

Finally, identifying 1 item from a set is a perfect match for the whole purpose of URI fragments so merely by the principle of least astonishment JWK should specify how the fragment picks 1 key.

--
James Manger

From: [email-masked] [mailto:[email-masked]] On Behalf Of Brian Campbell
Sent: Monday, 25 March 2013 11:31 PM
To: jose issue tracker
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [jose] #16: URI identifying a specific key in a JWK set

I'd always just assumed that, short of some other means of figuring it out, a kid header would accompany a jku to identify the specific key in the set.

On Sun, Mar 24, 2013 at 6:40 PM, jose issue tracker <[email-masked]<mailto:[email-masked]>> wrote:
#16: URI identifying a specific key in a JWK set

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

_______________________________________________
jose mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/jose

---

From: Richard Barnes <[email-masked]>
Date: Tue, 26 Mar 2013 13:58:12 -0400

How about this change to Section 4.1.5 of JWE (and corresponding text in
JWS):  "If the JWK Set referenced by the URI contains more than one key,
then the JWE object MUST contain a "kid" parameter to identify which key
should be used."

Also, while we're on the topic of "jku": The following text should be
removed:
"""
   The
   protocol used to acquire the resource MUST provide integrity
   protection; an HTTP GET request to retrieve the certificate MUST use
   TLS [RFC2818] [RFC5246]; the identity of the server MUST be
   validated, as per Section 3.1 of HTTP Over TLS [RFC2818].
"""
TLS does not need to be mandatory here.  The only thing an adversary can do
by changing the key set is cause decryption or signature validation to
fail. [1]  At most, these MUSTs should be SHOULDs.

--Richard

[1] Under the assumption that the attacker cannot modify the JWS.  If this
assumption is false, there's not reason to protect "jku" dereferences
either.  For JWS, the only reason an attacker would modify "jku" is to make
it point to a key for which the attacker controls the private key.  If the
attacker controls the private key and can modify the JWS/JWE, then he could
just as well remove the "jku" and replace it with a "jwk", and recompute
the signature under his key. So "jku" protections add nothing.  For JWE,
it's not clear that there's any useful objective for the attacker at all.

On Mon, Mar 25, 2013 at 6:46 PM, Manger, James H <
[email-masked]> wrote:

> set. ****
> ** **
> Indeed, “jku” needs to be accompanied by “kid” to work in general — but
> this is a crappy solution. 99% of the time that a “jku” is used you want to
> identify a single specific key so “jku” should be capable of doing that
> without requiring an extra field.****
>
> ** **
>
> A JOSE header does have room for “kid” as well as “jku”. However, many
> contexts that use URIs as identifiers expect a URI to be THE identifier.
> Needing two fields to do one task is inevitably awkward.****
>
> ** **
>
> Finally, identifying 1 item from a set is a perfect match for the whole
> purpose of URI fragments so merely by the principle of least astonishment
> JWK should specify how the fragment picks 1 key.****
>
> ** **
>
> --****
>
> James Manger****
>
> ** **
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf
> Of *Brian Campbell
> *Sent:* Monday, 25 March 2013 11:31 PM
> *To:* jose issue tracker
> *Cc:* [email-masked]; [email-masked];
> [email-masked]
> *Subject:* Re: [jose] #16: URI identifying a specific key in a JWK set****
>
> ** **
>
> set. ****
> ** **
> [email-masked]> wrote:****
>
> https://www.ietf.org/mailman/listinfo/jose****
>
> ** **
>

---

From: "Peck, Michael A" <[email-masked]>
Date: Tue, 26 Mar 2013 18:36:12 +0000

I'm confused about how the jku and jwk public key dereference mechanisms will be used safely.
An attacker can obviously put any public key at an attacker-controlled URI and point the recipient there (jku). I already complained about jwk.

The recipient needs to do something to associate the public key with the sender's identity / decide to trust it - I guess this would be an out-of-band list of trusted public keys, trusted public key fingerprints, or whatever - though in that case, why does the recipient need to fetch the public key? Just store it and refer to it with "kid"?

I suppose I agree with Richard that TLS doesn't add value, unless the trust mechanism is based on the URI (i.e. I trust public keys from https://example.com), in which case it would add value - the whole picture isn't in here though maybe it doesn't need to be.

I would think there are also security considerations around forcing the recipient to go to arbitrary URIs in order to verify the signature, but I suppose this risk already exists on the web in general so maybe it's not worth complaining about.

From: [email-masked] [mailto:[email-masked]] On Behalf Of Richard Barnes
Sent: Tuesday, March 26, 2013 1:58 PM
To: Manger, James H
Cc: Brian Campbell; [email-masked]
Subject: Re: [jose] #16: URI identifying a specific key in a JWK set

How about this change to Section 4.1.5 of JWE (and corresponding text in JWS):  "If the JWK Set referenced by the URI contains more than one key, then the JWE object MUST contain a "kid" parameter to identify which key should be used."

Also, while we're on the topic of "jku": The following text should be removed:
"""
   The
   protocol used to acquire the resource MUST provide integrity
   protection; an HTTP GET request to retrieve the certificate MUST use
   TLS [RFC2818] [RFC5246]; the identity of the server MUST be
   validated, as per Section 3.1 of HTTP Over TLS [RFC2818].
"""
TLS does not need to be mandatory here.  The only thing an adversary can do by changing the key set is cause decryption or signature validation to fail. [1]  At most, these MUSTs should be SHOULDs.

--Richard

[1] Under the assumption that the attacker cannot modify the JWS.  If this assumption is false, there's not reason to protect "jku" dereferences either.  For JWS, the only reason an attacker would modify "jku" is to make it point to a key for which the attacker controls the private key.  If the attacker controls the private key and can modify the JWS/JWE, then he could just as well remove the "jku" and replace it with a "jwk", and recompute the signature under his key. So "jku" protections add nothing.  For JWE, it's not clear that there's any useful objective for the attacker at all.

> I'd always just assumed that, short of some other means of figuring it out, a kid header would accompany a jku to identify the specific key in the set.

Indeed, "jku" needs to be accompanied by "kid" to work in general - but this is a crappy solution. 99% of the time that a "jku" is used you want to identify a single specific key so "jku" should be capable of doing that without requiring an extra field.

A JOSE header does have room for "kid" as well as "jku". However, many contexts that use URIs as identifiers expect a URI to be THE identifier. Needing two fields to do one task is inevitably awkward.

--
James Manger

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Brian Campbell
Sent: Monday, 25 March 2013 11:31 PM
To: jose issue tracker
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [jose] #16: URI identifying a specific key in a JWK set

---

From: "jose issue tracker" <[email-masked]>
Date: Sat, 30 Mar 2013 23:19:14 -0000

Comment (by [email-masked]):

 First, having just a "jku" value is often sufficient to determine which
 key to use, as other parameters in the JWK Set such as the "use" or "alg"
 parameters may be used to unambiguously determine which key to use.  There
 may also be only one key in the set.

 Second, we already support more than one means of disambiguating keys
 within JWK Sets, including using the "kty", "kid", "use", and "alg" values
 as inputs to this decision.  And once the spec says that other fields must
 be ignored if not understood, I'm sure that people will use other key
 properties they'll invent such as ("current": true) to aid in the key
 selection process for their applications.

 I understand that the request may seem simple on the face of it, but doing
 this in a general way would involve more than just using a "kid" value as
 a fragment identifier for a "jku" value.  As such, the proposal seems
 underspecified to me.

 Furthermore, if all that's being conveyed is a "jku" value and a "kid"
 value pair - we already have a straightforward way of doing that - include
 both parameters in the header.  Whereas requiring implementations to
 support two ways of accepting the same information doesn't seem like a
 good cost/benefit tradeoff.

  key                    |  Resolution:
 Keywords:               |

Ticket URL: <http://trac.tools.ietf.org/wg/jose/trac/ticket/16#comment:1>
jose <http://tools.ietf.org/jose/>

---

From: Dick Hardt <[email-masked]>
Date: Sat, 30 Mar 2013 16:48:54 -0700

A related issue is that a 'kid' may not be enough to uniquely identify the key in symmetric systems.

If a recipient (A) accepts tokens from multiple parties (B and C), and 'kid' is managed at those parties (B and C), then there is no guarantee that the 'kid' value will be unique at A. Knowing the issuer is required unless you force B and C to use a URI like mechanism for 'kid'

On Mar 25, 2013, at 3:46 PM, "Manger, James H" <[email-masked]> wrote:

> On Sun, Mar 24, 2013 at 6:40 PM, jose issue tracker <[email-masked]> wrote: