OpenPubKey and Sigstore | Hacker News Reader

OpenPubKey and Sigstore

blog.sigstore.dev

93 pointsdlor28 comments

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 "do the right thing". That's going to go wrong.

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.

1: https://www.wiz.io/blog/storm-0558-compromised-microsoft-key...

2: https://infosec.exchange/@briankrebs/110820474957163710

I haven't read too much about it yet, but some standing points of confusion I have with OpenPubKey:

1. OpenPubKey states that it uses the OIDC `nonce` claim as its public key stuffing mechanism, but I'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'm aware of is some IdPs' 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).

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.

(I also agree with the privacy concerns: JWTs really aren'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't leak the JWTs themselves.)

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 :-)

> IdPs can rotate keys arbitrarily frequently.

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 :-)

[1]: https://auth0.com/docs/secure/tokens/json-web-tokens/json-we...

[2]: https://token.actions.githubusercontent.com/.well-known/jwks

> OpenPubKey states that it uses the OIDC `nonce` claim as its public key stuffing mechanism, but I'm not aware of many (any?) popular OIDC IdPs that allow the user to control the nonce in such a way

Doesn't the nonce the client provides have to be passed through unmodified[0] for the authorization server to be compliant?

> If present in the Authentication Request, Authorization Servers MUST include a nonce Claim in the ID Token with the Claim Value being the nonce value sent in the Authentication Request.

[0]: https://openid.net/specs/openid-connect-core-1_0.html#IDToke...

That’s my read as well, but my experience with OIDC providers (especially machine identity providers) is that they don’t provide any mechanism for configuring the nonce (because they aren’t doing a traditional OAuth2 authentication request). Specifically, GitHub Actions, GCP, and GitLab don’t support this (to my knowledge).

Stuffing the nonce is the kind of "clever" shit that always comes back to bite you in the ass.

Just like with HTTPS, we should rethink the centralized trust model and instead condition users to verifying and manually approving trust for entities. Work on better UX for investigating and scrutinizing trust claims. Stop shipping CAs, let the users validate their own stuff. The current status quo is not protecting users the way it claims to, it's just making naive, dumb marks for folks to socially engineer.

I agree that stuffing keys into a nonce field is excessively clever.

I don’t agree with your evaluation of centralized PKIs: to a first approximation, the CA PKI model is the only PKI model that has demonstrated any amount of longevity and misuse resistance. This doesn’t mean it’s good or historically flawless, but that on an empirical level it’s done better than everything else that’s been tried (including expecting end users to establish independent trust relationships).

Expecting people with no technical background to safely bootstrap trust for the services that facilitate their personal information is not only unrealistic on a practical level, but (cynically) unworkable on an expectation level: users will not want their lives made worse because technologists dig their heels into solutions that they consider superior.

As far as I can tell, you'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.

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.

> 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 sounds like my dreams. Is there anything that exist now that does this?

For Azure, could you use a 1:1 mapping of Managed Identities and use Federated Credentials? (OIDC).

We need a few popular OIDC providers that will allow you to bring your own email address. That way you can use a custom domain if desired, and achieve the portability you're talking about.

I really wanted KeyBase to be an open identity source.

I had a daydream about bob@bobhome being hired at alicecorp. Instead of a new ID bob@alicecorp being created, bob@bobhome is invited to the project-devs@alicecorp. Once a member, that user ID is automatically granted access to jira/git/artifactory/AWS/etc etc

Your ID becomes part of your resume, with a record of who bob@bobhome has worked for, with crypto signed endorsements from team leads etc

I wanted things like that from Keybase too. What happened to them?

They got acquired by Zoom in 2020 for the cryptography and since then have been gutted to the extent that there have been zero announcements or movement.

Their leadership didn't seem to know what to do and chased a few passing fads for new features, and didn't address the tech debt they had to improve the UX of their tool.

They added a wallet with Stellar Lumens when that should have been entirely separate. Git repo hosting that should have been left to Github/Gitlab. etc etc.

My opinion is that they should have focused on integration with 3rd parties like github. Plus working on tech debt and UX issues. Created lots of docs on integrating KeyBase with your internal tooling, stuff like that.

I don't think is the reason Keybase faded (although I agree that they shouldn't have chased blockchain fads). I'm pretty sure it's because they were bought by Zoom and had all of their engineering talent repurposed.

It's my personal opinion that they had lost their way before getting bought by Zoom. Mostly gut feeling from the actions and words from senior leadership.

But you're correct, Zoom's purchase was the death knell.

Keyoxide may be worth checking out as a FOSS alternative: https://keyoxide.org/

Wouldn't that just put KeyBase in control of being able to validate your identity? What would happen if they banned you?

The parent talks about decentralized (or perhaps federated) solutions which I can understand but I don't get why everyone would want to put all their eggs in the KeyBase basket?

Another layer of indirection often solves things in software engineering. You need a key store that allows use control via multiple identity sources so a backup path can add remove or update allowed sources. If google locks a particular account, drop it as an allowed source, add a different one.

This of course expands the attack surface - indirection comes at a cost.

I struggling to understand the concept of a decentralized identity. You are basically exposing the concept of identity to partitioning problems, at that point. Right?

That is, I don't disagree with the idea that the system we have now ties you to a company. But indirection and decentralization only works to a point. As an example, how do you manage disputes of your identity? Assume whatever system you have can be spoofed successfully somehow. What is the procedure to clarify the factually intended identity of someone?

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...).

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?

sigstore it seems

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

Reply on news.ycombinator.com