[pre-RFC] Using Sigstore for signing and verifying crates

[bascule]

@Eh2406 asymmetric tokens and Sigstore should work well together with proper domain separation.

If integrated successfully, you should be able to leverage Rektor to maintain an audit log of an ephemeral asymmetric key tied to a particular OIDC principal (which in the case of crates.io might be limited to GitHub users to get started) which can be tied both to an asymmetric token and used for codesigning (where Rektor applies to the latter).

[mathstuf]

@bascule

GitHub encourages this for enterprises and even offers first-class features for using enterprise identity systems for SSO with automatic user provisioning:

Given the pricing and that I need none of the Enterprise features…

[Eh2406]

@bascule

with proper domain separation

I'm glad they can be made to work well together, but so can plane tokens and code signing. I don't think I see what the difference in domains are, it feels like they both carry the same information. If on publish cargo is sending an Asymmetric Token and signing the code using the same key, what information is the asymmetric token adding to the interaction? crates.io can ignore the token and just read all the same information out of the codesigning or its associated transparency log and metadata.

[lulf]

@woodruffw

Yeah, this is something that would need to be defined and included in the final RFC: Sigstore itself is flexible in terms of allowing multiple identities (or even threshold schemes, although that's probably not desirable in this case), so the integration point needs to decide how/whether it allows that.

For something like crates.io, I can see a few reasonable approaches:

1. In crates.io's own account settings page(s), allow users to enable their verified email address as a signing identity. Supplementally, allow users to configure multiple verified email addresses, a la PyPI (although this might require larger changes to crates.io).
2. Add a package/crate configuration view for each uploaded crate, where crate owners can configure accepted signing identities. This allows multiple owners to coordinate on valid signing identities.
3. Develop a notion of "trusted metadata," e.g. for the package.repository and package.authors fields. In this case, these fields would be considered valid signing identities, under either a TOFU scheme (first upload to crates.io determines that they're trusted, subsequent changes need to be manually validated on the website) or a fully manual scheme (first upload to crates.io does not expose any associated signing materials until the user logs into the website and explicitly marks one or more identities as valid).

We're still working out the best choice (in terms of UX) for PyPI, so I expect that cargo and crates.io will be able to glean some decisions from what we end up doing .

I'm wondering if for shared ownership, since a crate owner can be a GitHub team within an organizations, the UI could derive the possible signing identities from team members and then select which ones would be allowed.

[lulf]

The discussion on e-mail as identities is really interesting, thanks to everyone contributing to that!

To summarize: The problem with e-mail identities is not whether or not we require them for signing, but if we can delete them from the transparency log to comply with right to be forgotten. E-mail is personal data, ergo it must be deleteable or 'masked' if added to the transparency log.

So I think we could do one of three options going forward:

1. Bet on the transparency log/Rekor to gain support for anonymization and/or removing entries?
2. Rely on some way to hide/mask the e-mail in a secure way? I see Key Transparency as a way to do that.
3. Not use e-mail, but instead require CI/CD claims from systems like GitHub actions?

My impression is that 1. and 2. is a blocker for e-mail as identities.

So maybe instead starting with supporting 3. (similar to NPM) would give some time to adopt signing and verification process for users. IMHO it would cover a lot of the needs for those who care about signing and verification to begin with.

[bascule]

@lulf

• Bet on the transparency log/Rekor to gain support for anonymization and/or removing entries?
• Rely on some way to hide/mask the e-mail in a secure way? I see Key Transparency as a way to do that.

FWIW I've been asking the Sigstore people about this. A verifiable random function can be used to deterministically tokenize email addresses into a random-looking string ala Key Transparency.

[Eh2406]

@Eh2406

crates.io can ignore the token and just read all the same information out of the codesigning or its associated transparency log and metadata.

I brought this suggestion up on the SigStore slack, where an interesting conversation was had. Slack TLDR: there would be practical problems with a registry that used SigStore as it's only kind of identity, and even more practical problems with using TUF as the only kind of authorization. But it makes sense in theory, and a lot of people are experimenting with how to make it feasible in practice.

On a different note, a bunch of useful links were gathered together at Produce cryptographic signing guide for package managers · Issue #10 · ossf/wg-securing-software-repos · GitHub about how to adopt SigStore and related tools.

[lulf]

Thank you all for the feedback! I've taken note of the following to be improved in the RFC:

• How PII is handled using workload identities and anonymized e-mail as identities, with alternatives discussed.
• Authorization: How to deal with authorization on crates.io and showing how this can be done in a future enhancement with TUF.
• Future enhancement on using TUF for additional signatures from crates.io itself and signing the index.
• Advice on why crates.io should use a separate identity from GitHub in addition to the Sigstore identity.

I'll notify once it's ready for another look. Anyone who'd like to improve the RFC are welcome to do so by submitting a PR to the repo!

[Eh2406]

For reference a RFC was posted at https://github.com/rust-lang/rfcs/pull/3403