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.

On Mon, Mar 25, 2013 at 6:46 PM, Manger, James H <
James.H.Manger@team.telstra.com> 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. ****
>
> ** **
>
> 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:* jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] *On Behalf
> Of *Brian Campbell
> *Sent:* Monday, 25 March 2013 11:31 PM
> *To:* jose issue tracker
> *Cc:* draft-ietf-jose-json-web-key@tools.ietf.org; jose@ietf.org;
> james@manger.com.au
> *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 <
> trac+jose@trac.tools.ietf.org> wrote:****
>
> #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-
>   james@manger.com.au    |  key@tools.ietf.org
>      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/>
>
> _______________________________________________
> jose mailing list
> jose@ietf.org
> https://www.ietf.org/mailman/listinfo/jose****
>
> ** **
>
> _______________________________________________
> jose mailing list
> jose@ietf.org
> https://www.ietf.org/mailman/listinfo/jose
>
>