3 ms·

So in addition to getting the file from python.org over HTTPS, you get a certificate attesting that sigstore automatically checked that it was released by the p

by remram 4y ago

So in addition to getting the file from python.org over HTTPS, you get a certificate attesting that sigstore automatically checked that it was released by the people who owned python.org? What security does this add? PGP has a web-of-trust aspect, allowing people to trust people. What is the point of something doing automated verification of identity, on top of the one done for HTTPS certificate issuance?

woodruffw 4y ago
Not the people who own python.org, but the CPython release maintainers. They’re different groups of people, which points to one of the potential benefits to sigstore verification here: people who download CPython from python.org can now additionally verify that the artifact was not tampered with on the server. They can, furthermore, mirror the artifact and its signing material on their own. In short, TLS provides delivery authenticity while sigstore providers publisher authenticity.
- 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.
di 4y ago
The certificate specifically demonstrates that the <release-manager>@python.org identity signed the artifact. So there's a) no long-lived private key for them to lose (because it's never stored after signing) and b) a consumer doesn't need to find the right key PGP ID, verify (somehow) that that key ID is associated with a given release manager -- they can just trust that the release manager is in control of their @python.org identity. Additionally, with PGP, you have no idea if your private key is being used somewhere else to generate valid signatures maliciously. With Sigstore, in order for the signature to be valid, it must be published in a transparency log, which is continuously monitored. So in the event of if the key/identity is compromised, the identity owner can be made aware immediately and the signature revoked. More details are here: https://www.python.org/download/sigstore/ https://www.python.org/download/sigstore/ and here: https://docs.sigstore.dev/ https://docs.sigstore.dev/
NavinF 4y ago
> PGP has a web-of-trust aspect, allowing people to trust people Must be great for the 5 people on the planet that maintain a personal web of trust with PGP while the rest of us just run whatever "curl|gpg --import" command the download page tells us to run, thus adding zero security on top of https.
- remram 4y ago
  The alternative is this, you get a nifty certificate from Sigstore that allows you to be sure that "somerando@outlook.com" has indeed authored the lib you depend on. How do you check if that's what you want? How much security do you get from knowing that the email is definitely correct for a person you know nothing about?

by remram 4y ago

woodruffw 4y ago

Not the people who own python.org, but the CPython release maintainers. They’re different groups of people, which points to one of the potential benefits to sigstore verification here: people who download CPython from python.org can now additionally verify that the artifact was not tampered with on the server. They can, furthermore, mirror the artifact and its signing material on their own. In short, TLS provides delivery authenticity while sigstore providers publisher authenticity.

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.

di 4y ago

The certificate specifically demonstrates that the <release-manager>@python.org identity signed the artifact. So there's a) no long-lived private key for them to lose (because it's never stored after signing) and b) a consumer doesn't need to find the right key PGP ID, verify (somehow) that that key ID is associated with a given release manager -- they can just trust that the release manager is in control of their @python.org identity. Additionally, with PGP, you have no idea if your private key is being used somewhere else to generate valid signatures maliciously. With Sigstore, in order for the signature to be valid, it must be published in a transparency log, which is continuously monitored. So in the event of if the key/identity is compromised, the identity owner can be made aware immediately and the signature revoked. More details are here: https://www.python.org/download/sigstore/ https://www.python.org/download/sigstore/ and here: https://docs.sigstore.dev/ https://docs.sigstore.dev/

NavinF 4y ago

> PGP has a web-of-trust aspect, allowing people to trust people Must be great for the 5 people on the planet that maintain a personal web of trust with PGP while the rest of us just run whatever "curl|gpg --import" command the download page tells us to run, thus adding zero security on top of https.

remram 4y ago
The alternative is this, you get a nifty certificate from Sigstore that allows you to be sure that "somerando@outlook.com" has indeed authored the lib you depend on. How do you check if that's what you want? How much security do you get from knowing that the email is definitely correct for a person you know nothing about?