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

["Manger, James H" <[e-mail]>]

> #16: URI identifying a specific key in a JWK set
> 
> 
> Comment (by [e-mail]):
> 
>  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.

Requiring recipients to try a bunch of extra parameters and heuristics in the hope of witling down a set of keys to the single public key needed to process a JOSE message is a poor "solution" for "jku" not being fit-for-purpose.

The originator knows which specific key is required (ie the pair for the private key the originator used) so why bother only telling the recipient which set contains the key, instead of which specific key to use?

Lets just make "jku" fit-for-purpose (of identifying the public key required to process a JOSE message). 


>  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.

"kty" -- unless there are 2 RSA keys in the set
"use" -- unless there are 2 keys that can be used to sign
"alg" -- unless there are 2 keys that work with "RS256"
[Rollover a key and "kty", "use", and "alg" are all likely to be the same for old and new keys]
"kid" -- works, but 1 fit-for-purpose "jku" field would be much better than 2 jku+kid

>  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.

That's great if it helps an originator discover a key. The recipient shouldn't have to use such heuristics.


>  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.

The item in the issue tracker deliberately focuses on the issue, without being prescriptive about the solution.


>  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.

Trying "jku" + ("kty" or "use" or "alg" or "kid") feels even worse than "two ways".

Drop "kid" in this context (identifying the public key a recipient needs to use to process a JOSE message) and only use "jku" -- that gives one way. This also solves Dick Hardt's point that a "kid" can be ambiguous without an issuer (the URI is effectively the issuer).


--
James Manger