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 <[email protected]> On Behalf Of Anders Rundgren
Sent: Tuesday, February 6, 2018 10:03 PM
To: [email protected]
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
[email protected]
https://www.ietf.org/mailman/listinfo/jose
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
