OpenPubKey and Sigstore
blog.sigstore.dev
OpenPubKey and Sigstore
1–10 of 29 posts
Re: OpenPubKey and Sigstore
#2As 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.
Re: OpenPubKey and Sigstore
#3I 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.)
Re: OpenPubKey and Sigstore
#4I 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.
Re: OpenPubKey and Sigstore
#5As 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…
> 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).
Re: OpenPubKey and Sigstore
#6As 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…
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.
Re: OpenPubKey and Sigstore
#7I 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 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...
Re: OpenPubKey and Sigstore
#8So 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...
Re: OpenPubKey and Sigstore
#9This 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.
Re: OpenPubKey and Sigstore
#10As 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 endorsements from team leads etc