Re: [OAUTH-WG] Signed JWK Sets

[John Zila <[e-mail]>]

On 11 Apr 2024, at 21:15, Neil Madden <[e-mail]> wrote:

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

I am also supportive of this draft. Chain of Trust is a real problem in JWT
issuance, and it's nice to see a simple solution that addresses it.
Regarding Neil's attack above, rather than requiring clients to separately
do OCSP or CRL, you could envision an OCSP stapling-like approach that
could include a signature over a timestamped PIKA as a "staple" in a JWT,
which moves up the proof of issuer validity to the time of issuance of the
JWT, rather than just the last time you retrieved the PIKA. If you see a
new PIKA staple, you know you need to fetch again. If you see a staple for
a PIKA you've already cached, then you know it hasn't been revoked.

You could additionally layer this approach by stapling the PIKAs
themselves, where the PIKA staples are periodically updated to assert
continued validity of the signing certificate. With such a system, you can
provide guarantees regarding validity latency down the entire signature
chain.

- John