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

A URI pointing to a JWK Set (jku) plus a key-id (kid) is sufficient to identify one specific key. But you should be able to point to a single key with a single URI. You can't with RFC7517 JWK, and that is a flaw. The sensible solution would be to define how to put a kid in the fragment portion of a URI that points to a JWK Set (application/jwk-set+json). For example, https://example.com/keys.jwks#2011-04-29 to identify the 2nd key from RFC7517 Appendix A.1.

I assume we can define the fragment format specific to application/jwk-set+json. Unless the +json suffix means it must use a generic JSON fragment format?

Then you can authorize a set of keys that will change over time with key roll-over by giving a URI to a JWK Set. And you can identify the specific key used in a specific transaction with a URI-with-fragment.

--
James Manger

-----Original Message-----
From: jose [mailto:jose-bounces@ietf.org] On Behalf Of Mike Jones
Sent: Wednesday, 7 February 2018 5:23 PM
To: Anders Rundgren <anders.rundgren.net@gmail.com>; jose@ietf.org
Subject: Re: [jose] JOSE dependence on "Key Guessing"

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.

				-- 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
_______________________________________________
jose mailing list
jose@ietf.org
https://www.ietf.org/mailman/listinfo/jose