docs: clarify OIDC token identity vs certificate SAN

[jku]

I seem to regularly get confused about this so maybe others are too:

The documentation (at least https://github.com/sigstore/fulcio/blob/main/docs/how-certificate-issuing-works.md) states that the signing certificate is constructed by...

Setting the certificate's subject alternative name (who the certificate is issued for) to match the subject from the OIDC ID token. This could be an email, SPIFFE ID, or GitHub Actions workflow identity.

This is untrue as described in length elsewhere like https://github.com/sigstore/fulcio/blob/main/docs/oidc.md: The certificate SAN is based on the token contents but the mechanism is more complicated and essentially a Fulcio implementation detail.

The significance of this is that if the Fulcio using application/user wants to really know who they are signing as (and consequently who they should be verifying as the signing identity), they would need to request a signing certificate and look at the SAN -- parsing the OIDC token is possible but requires reimplementing the logic fulcio uses.

[haydentherapper]

We should update documentation to state that the SAN will not match the subject and comes from a value defined by the provider implementation or configuration.

In thinking about Fulcio v2 and what, if any, changes we want to make to the certificate profile, should we standardize on the SAN matching the subject? And if we do, in what cases is the SAN still meaningful?

For CI workflows, the SAN is typically a copy of the Build Signer URI, so we could easily put another value in the subject. In this case, I'm not sure anyone would look at the subject since it doesn't necessarily uniquely represent a builder. I think this is heavily dependent on the CI provider. For example, for GitHub, their example OIDC claims show repo:octo-org/octo-repo:environment:prod as the subject, which does not uniquely represent a builder.

For email, if we use the sub claim, one question would be if we want to still include the email. The sub should be a unique, immutable identifier for the user, but is less "human readable" than an email when it comes to building verification policies.