Live data from Hacker News

OpenPubKey and Sigstore

blog.sigstore.dev

11–20 of 29 posts

Re: OpenPubKey and Sigstore

#11
post #2

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 continui…

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…

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

Re: OpenPubKey and Sigstore

#12
post #11

Earlier quoted context omitted.

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…

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.

Re: OpenPubKey and Sigstore

#13
post #7

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`…

> 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…

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

Re: OpenPubKey and Sigstore

#14
post #2

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 continui…

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…

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

Re: OpenPubKey and Sigstore

#15
post #4

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`…

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

Re: OpenPubKey and Sigstore

#16
post #11

Earlier quoted context omitted.

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…

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

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.

Re: OpenPubKey and Sigstore

#17

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`…

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.

Re: OpenPubKey and Sigstore

#18
post #2

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 continui…

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.

Re: OpenPubKey and Sigstore

#19

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`…

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…

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.

Re: OpenPubKey and Sigstore

#20
post #11

Earlier quoted context omitted.

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

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. Plu…

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.
Post reply on HN