Email claims: store unique user id in addition to email

[vlsi]

Description

See #955

The same goes for email: emails could be reused. For instance, suppose someone drops their gmail account, and somebody else creates an account with exactly the same username. In that case, Fulcio certificates would look like valid ones because they store only email.

I guess we should store unique user ids in certificates.

[haydentherapper]

For what we currently support, google and Microsoft don’t allow email reuse. One of the requirements from another issue for OIDC providers was disallowing reuse. Unsure about GitHub, but I think it’d be reasonable to switch over to usernames rather than email for it.

The tricky thing is building verification policies based on user IDs. Most email providers don’t expose user IDs except by querying various APIs.

[arianvp]

For what we currently support, google and Microsoft don’t allow email reuse.

Can give you a concrete counter-example.

Create a GCP project; create a service account; delete the project

wait 30 days. Claim the GCP project-id again; recreate the same service account

[haydentherapper]

If a user deletes their project or an email account that can be resurrected, I think there should be an expectation that the user convey that they are no longer in control of that account. It's effectively giving up their "signing key". If they are still supposed to be in control of their identity but erroneously deleted their identity/project, they should be monitoring transparency logs to see unexpected issuances with their identity.

That said, it should be simple to add an extension with a custom OID for the subject. I do expect users to probably not use the ID when creating verification policies since it's not typically known without querying an API, but it can be tracked over time to make sure that it remains stable (suggestion from @asraa for how SLSA uses IDs vs mutable references)