Re: [jose] JOSE dependence on "Key Guessing"

On 2018-02-07 07:22, Mike Jones wrote:
> Anders, you misunderstand the feature and its purpose.  The ability to reference a set of keys is essential to performing key roll-over - a critical security function.  The "kid" (key ID) value is typically used to indicate which member of the key set was employed.  There is no "key guessing".
> 
> For an example of how JWK sets are used for key roll-over in a production system, see http://openid.net/specs/openid-connect-core-1_0.html#Signing.

    "If there are multiple keys in the referenced JWK Set document,
     a kid value MUST be provided in the JOSE Header"

This is what I was referring to. JKU as a standalone property is useless unless the set of keys is restricted to 1.

This is not mentioned in the JOSE specifications but fundamental for interoperabiity and testing.
The OpenID scheme does not only presume that there's an additional "kid" in the header, but that the referred key set also contains matching "kid"s.

Maybe the "right" solution is providing an interoperability section with a reference to JKU as well?

My (strong) wish is getting away from any kind of key guessing as a part of a test suite and reference implementation.  Yes, the are indeed JOSE implementations that support key guessing.

BTW, the spec you are referring to doesn't appear to actually use JKU:

    "ID Tokens SHOULD NOT use the JWS or JWE x5u, x5c, jku, or jwk Header Parameter fields.
     Instead, references to keys used are communicated in advance using
     Discovery and Registration parameters, per Section 10"

Anders

> 
> 				-- Mike
> 
> -----Original Message-----
> From: jose <jose-bounces@ietf.org> On Behalf Of Anders Rundgren
> Sent: Tuesday, February 6, 2018 10:03 PM
> To: jose@ietf.org
> Subject: [jose] JOSE dependence on "Key Guessing"
> 
> Dear list,
> 
> Believe or not but there is a new multi-party IETF effort in the workings for dealing with "clear text" versions of JWS and JWE.  Our BOF request was though turned down due to lack of published drafts and "customers" so issues will have to go through the mailing list only.
> 
> The goal is reusing as much as possible of the existing specifications, essentially limiting the work to repackaging.
> 
> However, it turned out that I wasn't fully up-to-date on the JOSE concept "Key Guessing":
> https://tools.ietf.org/html/rfc7515#appendix-D
> 
> As far I can tell they only way you would ever need to do "Key Guessing" as described in appendix-D is if you have a scheme where the sender doesn't inform the receiver which key it actually used which sounds like a poor idea as well as highly unlikely to be used anywhere in practice.
> 
> Therefore I didn't bother too much with that until I had implemented support for JKU where the sender supplies a URL to a set of keys for the receiver to try out.  That is, "Key Guessing" is not only a possibility, it is an intrinsic part of the JOSE specifications.
> 
> So the question simply boils down to: Should derived standards-to-be, inherit obvious design flaws as well? IMO, they should not.  JKU could be redefined to point to a single JWK, removing the need for "Key Guessing" altogether.  Yes, there are "workarounds" like requiring additional key identification properties...
> 
> thanx,
> Anders
> 
> _______________________________________________
> jose mailing list
> jose@ietf.org
> https://www.ietf.org/mailman/listinfo/jose
> 