sigstore / fulcio

Sigstore OIDC PKI
Apache License 2.0
643 stars 136 forks source link

Email claims: store unique user id in addition to email #973

Open vlsi opened 1 year ago

vlsi commented 1 year ago

Description

See https://github.com/sigstore/fulcio/issues/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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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)