OIDC public key transparency log

[znewman01]

Fulcio is in a good position to record the public keys of the OIDC identity providers in a (separate?) transparency log. This would be nice to have for historical reasons.

[haydentherapper]

I think building a claimant model would help to convince us if this adds value.

Who are the actors that will consume the entries in the log? As the OIDC token verifier (Fulcio), it could query the log for every token to verify that the keys are in the log. I'm not sure this works though:

• Who uploads the keys to the log? It can't be the OIDC provider without them interacting with this ecosystem (which is beneficial! I just don't expect them to). If it's Fulcio (or some cronjob in the same trust domain as Fulcio), does this improve anything? If Fulcio is compromised, it could also lie about which keys it saw from the providers.
• Verifying every request obviously doesn't scale too.

Who are the actors in this system that would verify the keys? I'm not sure there is anyone who can authoritatively say whether a key is valid or not, besides the OIDC providers (which aren't a part of this system). Additionally, tokens are never persisted or logged anywhere, so there's no way to link a certificate to a token to a key.

The only benefit I see is if the OIDC providers want to audit key rotation events. Sigstore operates an OIDC provider, but this is effectively the same trust domain as Fulcio.

[znewman01]

My thinking here is mostly "someone's gotta do it and it's pretty easy." It feels wild to me that this doesn't exist, and just having this data in one place could be useful for incident response/analysis, checking past vulnerability to new crypto bugs, etc. It could also enable the "double-check the OIDC-provider" scenario if we figure out the crypto.

Agreed that it doesn't buy much for the security of Fulcio. The transparency aspect helps a tiny bit. Realistically this should be a separate service anyway, I just think this repo is a reasonable place to track it. And this feels really easy to scale up/deploy, way less config (just a list of OIDC providers).

[haydentherapper]

I want to pushback a little because while logs aren’t too hard to spin up, they are harder to maintain and create an ecosystem around them with witnessing and monitoring.

Some entity must be reliant on the log for it to have value. If no one keeps tokens around, then post-issuance analysis isn’t possible. If providers themselves don’t keep keys around, then they also can’t audit records. Cryptoanalysis on old keys doesn’t offer much benefit if tokens are short lived. Also, there’s the question of authenticating to the log to prevent anyone from uploading any key.

A proposal akin to certificate transparency, where tokens must include a proof of inclusion to be valid, and some privacy-conscious representation of the token is in the log, adds more value than logging just the public keys. This is a big shift of course, with privacy implications, and would require cooperation from providers.