Allow checking OIDC token signatures

[znewman01]

Thanks to @EthanHeilman for the idea and sketch of how it might work.

Proof of concept plan:

1. Write/find code for GQ signatures which can be used as a (non-interactive) zero-knowledge proof of knowledge of a valid RSA signature.
2. When Fulcio gets a JWT and populates the corresponding X.509 extensions, add a new extension for the JWT header/body and copy the raw bytes through. Also create a ZKPoK for the RSA signature over the JWT.
3. In the client, in addition to checking the Fulcio cert chain, check the ZKPoK, and check the JWT. For now, magically assume we have the public keys for all of the OIDC providers we care about. Monitors should do this as well.

Before actually deploying we'll probably want a doc that works through things like:

• Double checking security.
• Privacy implications of exposing the JWT header/payload.
• What do we need to check about the JWT? Seems like we'd need to replicate Fulcio's behavior exactly.
• Is there a better place to stick the tokens? Do we actually want them in the certs?
• How should clients get the identity providers' public keys? See OIDC public key transparency log #1055
• Neat long-run extensions like Use proof-of-possession with OIDC tokens. #1056 . Could we possibly even have a Fulcio-free flow?

[znewman01]

FYI I have implemented a proof of concept in Fulcio ( znewman01#2 ) and Cosign ( znewman01/cosign#118 ). Both janky but seem to work!

[znewman01]

Seems like there's movement on selective disclosure for JWTs: https://www.ietf.org/archive/id/draft-fett-oauth-selective-disclosure-jwt-02.html

They do some nifty tricks to make sure that there's format-compatibility. But it's still a pretty big shift and clients need to be SD-JWT aware before these are useful. Fulcio would be a great candidate client.

[hectorj2f]

@haydentherapper @bobcallaway @priyawadhwa Is there any intention to adopt this approach in the future ? It'd be to use zero knowledge proofs within sigstore.

[haydentherapper]

This is super neat work, but there’s a few things to consider before pursuing this further:

• we need to consider the threat model and address if ZKP actually solves a threat. You’re trusting the identity provider still. You have less trust in the CA since it can only embed a valid identity token, but we already write certs to a transparency log to make issuance auditable.
• there are privacy concerns with having to embed the entire identity token.
• Verifying old token signatures is hard/impossible to do without maintaining a history of keys, this has been discussed more on other blog posts.
• the proposed prototype works only with RSA, which is not sigstores default scheme. Also, this is not forward looking as we start investigating post quantum, and I would rather not invest a bunch to have it be broken in PQC.
• novel crypto implementations would require significant review before it can be integrated.
• selective disclosure requires IDPs to change, which is unlikely.

I do want to see this work explored more!