4 ms·

OpenPubKey and Sigstore

93 points by dlor 3y ago

ta8645 3y ago
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.
- adevopsguy 3y ago
  > 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).
- apitman 3y ago
  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.
- bloopernova 3y ago
  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
  - djbusby 3y ago
    I wanted things like that from Keybase too. What happened to them?
    - sofixa 3y ago
      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.
    - bloopernova 3y ago
      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.
      - woodruffw 3y ago
        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.
        bloopernova 3y ago
        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.
  - rapnie 3y ago
    Keyoxide may be worth checking out as a FOSS alternative: https://keyoxide.org/ https://keyoxide.org/
- dv_dt 3y ago
  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.
- taeric 3y ago
  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?
woodruffw 3y ago
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.)
- captn3m0 3y ago
  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.
  - woodruffw 3y ago
    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 :-)
diarrhea 3y ago
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-enables-authentication-of-countless-micr https://www.wiz.io/blog/storm-0558-compromised-microsoft-key... 2: https://infosec.exchange/@briankrebs/110820474957163710 https://infosec.exchange/@briankrebs/110820474957163710
TrueDuality 3y ago
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.
giantandroids 3y ago
Why does the Linux Foundation sign up projects like this with what appears to be so little duediligence
xpe 3y ago
Given the many fair criticisms around here, what are some better alternatives?
- giantandroids 3y ago
  sigstore it seems
sgammon 3y ago
Aren't we all trusting Fulcio and the other Sigstore infra in the same way? This reads like a belittling cope to me

93 points by dlor 3y ago

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.

adevopsguy 3y ago
> 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).
apitman 3y ago
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.
bloopernova 3y ago
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
- djbusby 3y ago
  I wanted things like that from Keybase too. What happened to them?
  - sofixa 3y ago
    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.
  - bloopernova 3y ago
    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.
    - woodruffw 3y ago
      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.
      - bloopernova 3y ago
        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.
- rapnie 3y ago
  Keyoxide may be worth checking out as a FOSS alternative: https://keyoxide.org/ https://keyoxide.org/
dv_dt 3y ago
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.
taeric 3y ago
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?

woodruffw 3y ago

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

captn3m0 3y ago
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.
- woodruffw 3y ago
  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 :-)

diarrhea 3y ago

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-enables-authentication-of-countless-micr https://www.wiz.io/blog/storm-0558-compromised-microsoft-key... 2: https://infosec.exchange/@briankrebs/110820474957163710 https://infosec.exchange/@briankrebs/110820474957163710

TrueDuality 3y ago

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.

giantandroids 3y ago

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

xpe 3y ago

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

giantandroids 3y ago
sigstore it seems

sgammon 3y ago

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