Re: [OAUTH-WG] Signed JWK Sets

Just to be clear, this is *not* a call for adoption at this time.

So, please focus on discussing the concept described in this individual
draft.

Regards,
 Rifaat

On Wed, Apr 17, 2024 at 1:43 PM John Zila <john@jzila.com> wrote:

> On 11 Apr 2024, at 21:15, Neil Madden <neil.e.madden@gmail.com> 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
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>