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

[Neil Madden <[e-mail]>]

>> On 7 Feb 2018, at 07:18, Anders Rundgren <[e-mail]> wrote:
>> 
>> 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.

Can you clarify why? You can just try each applicable key. 

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

Remember that the “kid” parameter is only integrity protected by the same signature that you are verifying so it should only be a hint. If an attacker can forge a signature for any key in the set then they can almost certainly also forge a kid value to go with it.

A bigger problem with “jku” would be the potential for SSRF (https://cwe.mitre.org/data/definitions/918.html) and similar attacks based on getting the server to access arbitrary URLs before it has validated the signature. 

— Neil