It doesn’t have to be a trusted infrastructure, just a trusted package (Google-OIDC-keys) that can be updated or keys published to an existing Key Server and cross signed by OpenPubKey.
Maybe I’m misunderstanding what you mean, but a package containing previous IdP keys is not likely to be sufficient here: IdPs can rotate keys arbitrarily frequently, so whatever source of ground truth for key authenticity is present needs to be either online or otherwise bound to an offline verifiable root of trust (like a separate PKI, which is why Sigstore uses Fulcio).
Even with a key transparency scheme, a pre-existing key server would effectively be a piece of trusted infrastructure due to “split-world” attacks. The remediation there would be to allow OPK clients to gossip among each other about transparency log state, but now we’re back into the realm of very complicated designs :-)
Yeah, that problem still remains, of course. But you could align the package update cadence to the rotation cadence. If in practice this happens to be a anything beyond a few weeks, I'd say that's not a bad tradeoff.
You go from trusting a central signing server, to somewhat auditable (and probably reproducible) package publishing infrastructure.
We will have to see how OpenPubKey tackles this and whether IdP key rotation ends up becoming a problem in practice, and how they do key distribution. Time will tell but I'm rooting for both.
> Yeah, that problem still remains, of course. But you could align the package update cadence to the rotation cadence. If in practice this happens to be a anything beyond a few weeks, I'd say that's not a bad tradeoff.
Whose rotation cadence? GitHub's is going to be different from Azure's, Google's, etc. JWKS itself doesn't include any expiry or rotation metadata[1] (example here[2]), so it's not clear how OKP (or any scheme) can establish a cadence policy around multiple IdPs without getting their explicit cooperation (which they'll be unlikely to offer, given that it artificially constrains their ability to revoke potentially compromised key material in service of an unintended use case).
> You go from trusting a central signing server, to somewhat auditable (and probably reproducible) package publishing infrastructure.
Again sorry if I'm misunderstanding what you mean, but Sigstore doesn't involve trusting a central signing server. The primary trust members in Sigstore are (1) a free CA, and (2) transparency services for certificates and signatures. Signatures themselves look very similar to what OKP does (ephemeral, client-side keys) but with the OIDC impermanence problem solved by a managed, transparent PKI. This is ugly and complicated, but it is sound; I don't think the same can be said for OKP's current design.
That's all to say that I'm happy if they succeed, and I'll also be happy to be wrong here. But I'm going to be a little miffed if they go through the process of building a "smaller" Sigstore, only to realize that (1) OIDC IdPs aren't going to encourage weird uses of their tokens, and (2) they need an online transparency service anyways :-)
