Add multiple SAN support when processing a JWT token in ciprovider

[Meeki1l]

We need to add two values as SAN when integrating with Gitlab:

1. ci_config_ref_uri
2. user_email

This is necessary so that the policy controller can create flexible ClusterImagePolicy. Mono repositories can have different projects and even different teams. We need to check both the validity of ci_config_ref_uri and the validity of user_email when delivering the image

[haydentherapper]

Could you say more about the need for multiple SANs? Conceptually, there should be only one signing identity - a user or a CI platform.

The certificate profile states that only one SAN is present, and all Sigstore clients currently assume this, so this would be quite a significant change in the ecosystem.

[Meeki1l]

@haydentherapper, when deploying images, we need to check not only where they were created, but also who exactly created them. According to the code of the policy controller and Cosign, I saw that it is possible to specify two cluster image policies for one image. If there is support for two SAN, then we can check on the policy controller that a certain user has created an image in a certain project. We have several projects in the mono repository, and we want to reduce the risk that a user not from our team will create and deploy a docker image. We also want to reduce the risk that a user from our team will create an image somewhere and deploy it in a prod environment.

Can you tell me what the problem is if the certificate has two SANs?

[haydentherapper]

There's two concerns, one technical and one conceptual.

In the certificate profile for Fulcio, which clients have coded against, we specify the a certificate should contain one Subject Alternative Name. Some clients have relaxed this constraint, like Cosign, while others support only one SAN like sigstore-go.

Conceptually, there should only be one identity in a certificate. There are not multiple identities who are signing the image.

when deploying images, we need to check not only where they were created, but also who exactly created them

This sounds more like provenance, possibly SLSA provenance for a build, of an image than the identity of a signer. Have you explored creating an attestation with this additional information?