Re: [OAUTH-WG] Signed JWK Sets

[Neil Madden <[e-mail]>]

On 11 Apr 2024, at 01:12, Ethan Heilman <[e-mail]> wrote:
> 
> I want to voice my support for this draft: Proof of Issuer Key Authority (PIKA). The ability to reason about the past validity of JWKS is extremely useful for using OIDC in signing CI artifacts and e2e encrypted messaging.This includes what we are building at OpenPubkey (github.com/openpubkey/openpubkey <http://github.com/openpubkey/openpubkey>) and also proposed security improvements to software supply chain systems like SigStore (https://arxiv.org/pdf/2307.08201.pdf <https://arxiv.org/pdf/2307.08201.pdf>).
> 
> I want to underscore the value of PIKA to increase the security of JWKS URIs and OpenID Connect. Currently if an attacker compromises an OpenID Provider's JWKS URI the attackers can substitute their own public keys and impersonate any user to any relying parties who depend that OpenID Provider. The effects of Google, Microsoft or Okta's JWKS URI being controlled by a malicious party for even a few minutes could be devastating. The widespread deployment of PIKA would remove this risk and require that attackers compromise not only the JWKS URI but also the PIKA signing keys.

I'm still digesting this draft, and generally supportive of it. However, I don't think it stops the attack you mention here, which sounds similar to threats that Ryan Sleevi discussed for FastFed in [1]. Essentially, in the current OIDC model, an attacker that briefly compromises the jwks_uri of an OP (e.g. through a mis-issued TLS cert) can serve a JWK Set containing public keys under their own control with a long Cache-Control header. Clients then might blindly cache that key set even beyond the time when the certificate is revoked and the rightful owner restored.

But I think this attack is basically the same even with PIKA. The attacker in this case just uses their mis-issued cert to sign the PIKA and serve that instead, perhaps putting a really long "exp" claim in it so that clients cache it for a really long time. The only thing that would stop that is if the draft insisted that clients regularly perform an OCSP or CRL lookup on the cert in the x5c chain to make sure it hasn't been revoked. But that would completely negate the benefits of avoiding clients all hitting the OP jwks_uri: we've just shifted the burden from the OP to the CA.

Perhaps I'm missing something?

[1]: https://docs.google.com/document/u/1/d/e/2PACX-1vQQ-FhNjW0ZhZVTnK1VG_87IBNZKBaJmweYZb1VBRdQCMAWXekqKfxdNl8wL6FWFDJ9pxXxpr66-GZp/pub?utm_source=illuminatedsecurity&utm_medium=email <https://docs.google.com/document/u/1/d/e/2PACX-1vQQ-FhNjW0ZhZVTnK1VG_87IBNZKBaJmweYZb1VBRdQCMAWXekqKfxdNl8wL6FWFDJ9pxXxpr66-GZp/pub?utm_source=illuminatedsecurity&utm_medium=email> 

-- Neil