How does a Fulcio certificate for a CI job differ from one issued to a human maintainer?

## Same certificate, two very different subjects Fulcio does not have two products. It has one issuance path, and the difference between a "human" and a "workload" certificate is entirely a consequence of which OIDC token was presented and what claims that token contained. ### Human identity A person running a signing command interactively is sent through a browser login against an identity provider. The token that comes back asserts an **email address** (or, for some providers, a stable account subject). Fulcio puts that in the certificate's subject alternative name and records the issuer — say a corporate directory, or a consumer account provider — in its own extension. So a human certificate reads, in effect: *the identity provider at this issuer confirmed that the holder of this ephemeral key was this email address, at this moment.* ### Workload identity A CI job has no browser and no human to authenticate. Instead the CI platform itself acts as an OIDC issuer and mints a token describing the job: which project, which pipeline configuration file, which ref, which commit, sometimes whether the runner was platform-hosted or self-managed. Fulcio turns that into a certificate whose subject alternative name is a **URI describing the pipeline** rather than an email — the project path, the path to the job configuration, and the ref it ran from — with the CI platform as issuer, and with additional Sigstore-defined extensions carrying the surrounding build context. A workload certificate reads: *this CI platform confirmed that the holder of this ephemeral key was this pipeline, running from this ref, at this moment.* ## Why the distinction matters in a real release history Picture a crate whose releases are normally cut by a GitLab CI job. Over a year, the published release record contains a mix: most versions signed by the pipeline's workload identity, two signed by a maintainer's personal Google account because a release had to go out during an outage. Nothing about the artifacts differs. Both signatures are cryptographically sound. Both certificates chain to the same authority. The **only** place the difference is visible is in the certificate's identity and issuer: one says "this pipeline on this ref", the other says "this human at this provider". If nobody looks at those fields, a maintainer signing outside the pipeline and an attacker who has taken over that maintainer's account are the same event in your records, and neither will look unusual. That is why the identity fields are the audit surface, not a formality. A release history is only trustworthy to the extent that somebody can say what *should* have appeared there. ## The ref is part of the workload identity, and that surprises people Because the workload subject embeds the pipeline configuration path and the ref, the same release cut from a hotfix branch produces a materially different identity string than the same release cut from the main line. This is honest — the two builds really did run under different conditions — but it means process changes silently change identity. A team that moves a release job to a new file, renames a branch, or introduces a release-branch strategy will find that the identity in the certificate is not the one they were expecting, and the change shows up at verification time rather than at the moment the process changed. Treat the identity string as a contract with a lifecycle, not as a constant. ## Granularity: what identity does a matrix build produce? A build that fans out across many targets — say a dozen platform variants of one release — will have each job obtain its own certificate, but the identity those certificates carry is determined by the claims the platform puts in the token, not by anything the job chooses. If the token describes the workflow and ref, twelve jobs from one workflow produce twelve certificates with the *same* identity, and a single compromised job among them is indistinguishable in the certificate from its eleven siblings. Knowing at what granularity your platform asserts identity — per repository, per pipeline configuration, per ref — is what tells you how much a certificate actually narrows down the origin of an artifact. ## What neither kind of certificate does Neither says the signer was *entitled* to sign. Both are simply an authority repeating what an identity provider said. Human or workload, the certificate names a signer; deciding whether that signer is the right one is a separate act performed by whoever consumes the artifact. ## Frequent confusion Engineers often expect a CI certificate to carry a service-account email, because that is how cloud service identities usually look. In the keyless flow it typically does not: the CI platform describes the *job*, and that description — not a mailbox — is the identity.