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