2 ms·

Sigstore has no idea who the publishers should be, they do automated verification based on a domain or GitHub account. The person owning the GitHub org might be

by remram 4y ago

Sigstore has no idea who the publishers should be, they do automated verification based on a domain or GitHub account. The person owning the GitHub org might be some admin, just like with the domain. The automated process doesn't know and doesn't care.

woodruffw 4y ago
That is where the concept of policies come in: an actual deployment of sigstore for verification purposes would establish the artifact’s identities via another mechanism. That mechanism is going to depend on the sigstore deployment: in the context of most package indices, for example, it probably makes sense to have the verification map to the index’s account metadata, package metadata, etc. That could, in turn, be made into a public commitment via a TUF repository. However, that complexity does not apply to simple cases like the CPython one: for this case, you can verify that the identity matches the one of the public email identities of the CPython release team. This is no more complex that PGP identity verification, and is much more resilient (since anybody can publish a claimant key for an identity in PGP).
- remram 4y ago
  You're comparing Sigstore with the log and assuming ultimate trust in their verification process and CA to GPG without the web-of-trust. This is obviously apples-to-oranges. You also linked to this random python.org HTTPS page which contains the list of people you are supposed to expect to have signed the Python releases. If this is the root of trust... it might has well have had PGP fingerprints. The truth is that you login with OIDC and Sigstore signs your artifacts, giving you an attestation that the owner of that email/GitHub/... identity made that artifact, and publishes that to a persistent log. This makes the whole thing great for automation (both of publishing and verifying), but claiming that this adds to security is false. Their Security Model page clearly outlines the limits of their system and is consistent with my characterization https://docs.sigstore.dev/security/ https://docs.sigstore.dev/security/: > If an OIDC identity or OIDC provider is compromised, Fulcio might issue unauthorized certificates > If Fulcio is compromised, it might issue unauthorized certificates You have to trust OIDC providers, you have to trust the CA, and the presence of logs only allows those people to notice unauthorized issuance, not end users.
  - woodruffw 4y ago
    I think we're going in circles, because I've identified specific ways in which this adds to the security model that self-custodial PGP keys cannot: * Sigstore uses short-lived keys and short-lived certificates, eliminating an entire common risk class where maintainers accidentally disclose their signing keys. This property alone eliminates the single largest source of illegitimate signing events in ecosystems like Windows software. * The logs in question are public CT logs. In other words: anybody can audit them for unauthorized issuance, including the legitimate publishing identity. It's not particularly useful for the end (installing) user to audit the log, but it was never claimed that they would find it useful. For the specific case of CPython, you're missing the point: CPython is an easy case, since the email identities of the release managers are well-known facts that can be cross-checked across python.org, GitHub, etc. Python.org is not currently a root of trust for sigstore, but it is for PGP (again, because anybody can claim an identity in PGP). There are, of course, limitations. But these limitations are no strictly worse than trusting CA and IdP ecosystems that you're already trusting, which makes them strictly better than mystery meat PGP keys.
    - remram 4y ago
      You're just replacing a "mystery meat" PGP key with a "mystery meat" email address or OIDC handle. As you point out, committing to one of those can easily be done by posting it on python.org, GitHub, etc with the major difference that PGP fingerprints are cryptographically tied to an identity rather than require a third-party like Sigstore to attest that the person had control of it at some point in the past. It is also much more likely that someone managed to click one link in a developer's inbox once to complete the automated Sigstore verification, rather than they managed to steal their PGP keyring and passphrase. I am not a fan of having to trust in developer's key-management abilities but this just shifts the problem very slightly, at significant cost. The single advantage is obvious: this allows easy automated signing and verification, allowing enterprises to easily check boxes in their supply-chain-security checklist. This is valuable in itself, and I am all for automation, but I don't know why we have to claim that it is "more secure".
      - 4y ago

by remram 4y ago

woodruffw 4y ago

That is where the concept of policies come in: an actual deployment of sigstore for verification purposes would establish the artifact’s identities via another mechanism. That mechanism is going to depend on the sigstore deployment: in the context of most package indices, for example, it probably makes sense to have the verification map to the index’s account metadata, package metadata, etc. That could, in turn, be made into a public commitment via a TUF repository. However, that complexity does not apply to simple cases like the CPython one: for this case, you can verify that the identity matches the one of the public email identities of the CPython release team. This is no more complex that PGP identity verification, and is much more resilient (since anybody can publish a claimant key for an identity in PGP).

remram 4y ago
You're comparing Sigstore with the log and assuming ultimate trust in their verification process and CA to GPG without the web-of-trust. This is obviously apples-to-oranges. You also linked to this random python.org HTTPS page which contains the list of people you are supposed to expect to have signed the Python releases. If this is the root of trust... it might has well have had PGP fingerprints. The truth is that you login with OIDC and Sigstore signs your artifacts, giving you an attestation that the owner of that email/GitHub/... identity made that artifact, and publishes that to a persistent log. This makes the whole thing great for automation (both of publishing and verifying), but claiming that this adds to security is false. Their Security Model page clearly outlines the limits of their system and is consistent with my characterization https://docs.sigstore.dev/security/ https://docs.sigstore.dev/security/: > If an OIDC identity or OIDC provider is compromised, Fulcio might issue unauthorized certificates > If Fulcio is compromised, it might issue unauthorized certificates You have to trust OIDC providers, you have to trust the CA, and the presence of logs only allows those people to notice unauthorized issuance, not end users.
- woodruffw 4y ago
  I think we're going in circles, because I've identified specific ways in which this adds to the security model that self-custodial PGP keys cannot: * Sigstore uses short-lived keys and short-lived certificates, eliminating an entire common risk class where maintainers accidentally disclose their signing keys. This property alone eliminates the single largest source of illegitimate signing events in ecosystems like Windows software. * The logs in question are public CT logs. In other words: anybody can audit them for unauthorized issuance, including the legitimate publishing identity. It's not particularly useful for the end (installing) user to audit the log, but it was never claimed that they would find it useful. For the specific case of CPython, you're missing the point: CPython is an easy case, since the email identities of the release managers are well-known facts that can be cross-checked across python.org, GitHub, etc. Python.org is not currently a root of trust for sigstore, but it is for PGP (again, because anybody can claim an identity in PGP). There are, of course, limitations. But these limitations are no strictly worse than trusting CA and IdP ecosystems that you're already trusting, which makes them strictly better than mystery meat PGP keys.
  - remram 4y ago
    You're just replacing a "mystery meat" PGP key with a "mystery meat" email address or OIDC handle. As you point out, committing to one of those can easily be done by posting it on python.org, GitHub, etc with the major difference that PGP fingerprints are cryptographically tied to an identity rather than require a third-party like Sigstore to attest that the person had control of it at some point in the past. It is also much more likely that someone managed to click one link in a developer's inbox once to complete the automated Sigstore verification, rather than they managed to steal their PGP keyring and passphrase. I am not a fan of having to trust in developer's key-management abilities but this just shifts the problem very slightly, at significant cost. The single advantage is obvious: this allows easy automated signing and verification, allowing enterprises to easily check boxes in their supply-chain-security checklist. This is valuable in itself, and I am all for automation, but I don't know why we have to claim that it is "more secure".
    - 4y ago