Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

OpenPubKey and Sigstore

blog.sigstore.dev

Post reply on HN
Print view View original

21–29 of 29 posts

Re: OpenPubKey and Sigstore

#21

Post by captn3m0 »

woodruffw wrote: post #15
captn3m0 wrote: post #4

Earlier quoted context omitted.

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

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

Re: OpenPubKey and Sigstore

#22

Post by woodruffw »

captn3m0 wrote: post #21
woodruffw wrote: post #15

Earlier quoted context omitted.

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

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

> 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

Re: OpenPubKey and Sigstore

#26

Post by bloopernova »

woodruffw wrote: post #20
bloopernova wrote: post #16

Earlier quoted context omitted.

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.

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.

Re: OpenPubKey and Sigstore

#27

Post by taeric »

ta8645 wrote: 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 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?

Re: OpenPubKey and Sigstore

#28

Post by SahAssar »

bloopernova wrote: post #10
ta8645 wrote: 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…

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?

Post reply on HN