OpenPubKey and Sigstore

So clients are responsible for monitoring for leaks [1] and revoking affected keys themselves. What a disastrous architecture: centralized trust in potentially (provably... [1, 2]) negligent IdPs, yet substantial, distributed burden on each client to &quot;do the right thing&quot;. That&#x27;s going to go wrong.<p>Also, abusing OIDC: if this takes off, the hack will be ossified as effectively part of the standard, blocking its further development and adjustment, as to not break OpenPubKey.<p>1: <a href="https:&#x2F;&#x2F;www.wiz.io&#x2F;blog&#x2F;storm-0558-compromised-microsoft-key-enables-authentication-of-countless-micr" rel="nofollow noreferrer">https:&#x2F;&#x2F;www.wiz.io&#x2F;blog&#x2F;storm-0558-compromised-microsoft-key...</a><p>2: <a href="https:&#x2F;&#x2F;infosec.exchange&#x2F;@briankrebs&#x2F;110820474957163710" rel="nofollow noreferrer">https:&#x2F;&#x2F;infosec.exchange&#x2F;@briankrebs&#x2F;110820474957163710</a>

I haven&#x27;t read too much about it yet, but some standing points of confusion I have with OpenPubKey:<p>1. OpenPubKey states that it uses the OIDC `nonce` claim as its public key stuffing mechanism, but I&#x27;m not aware of many (any?) popular OIDC IdPs that allow the user to control the nonce in such a way (for misuse resistance reasons). The closest thing that I&#x27;m aware of is some IdPs&#x27; ability to configure a custom `aud` claim, but this typically comes with substantial restrictions (such as a preset allowlist of audiences, or significant length limits).<p>2. OpenPubKey appears to wave away the problem of key rotation on OIDC IdPs, which is actually a pretty serious one: Google or Microsoft could decide tomorrow to arbitrarily change their rotation periods, which would impact the reliability of any system that relies on OPK signatures. Sigstore essentially dodges this problem by introducing a trusted CA and transparency log; I think OPK could similarly dodge it by introducing a key transparency scheme for keys observed from public IdPs. But doing so would involve running trusted infrastructure, in turn diminishing the value proposition vs. Sigstore.<p>(I also agree with the privacy concerns: JWTs <i>really</i> aren&#x27;t meant to be used in this way, and treating them as a disclosable token has potential privacy and security implications that need to be evaluated. Sigstore has similar privacy problems because of how it embeds OIDC claims, but it doesn&#x27;t leak the JWTs themselves.)

As far as I can tell, you&#x27;re relying on Google, or Microsoft, etc to verify your identity. Lose your relationship with them, and you lose control of everything. You have to remain in their good graces, or lose your identity for a diverse set of transactions where those big players would otherwise have no sway.<p>Would much rather have a truly decentralized identity where you can change providers without losing continuity of your identity. Where your identity provider has to keep you happy, or you transparently move your identity to a new provider.

This seems very poorly thought through. Everything from abusing the nonce as a data channel (and re-using a predictable value in a field that is short for Number used Once), to rejection of transparency for an inherently public value, misunderstanding the threat models here, and putting the responsibility for revocation on to the client (one of the most complicated things to do correctly in a potentially already compromised environment...).<p>I think this one needs to go back to the drawing board.

Why does the Linux Foundation sign up projects like this with what appears to be so little duediligence

Given the many fair criticisms around here, what are some better alternatives?

Aren&#x27;t we all trusting Fulcio and the other Sigstore infra in the same way? This reads like a belittling cope to me