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