Explain cosign's Sigstore 'keyless' signing flow: how a CI job signs a container image without holding any long-lived private key, where the resulting signature is stored, and what a verifier must check.

## The problem keyless solves Traditional signing needs a private key that lives somewhere for years: on a build agent, in a secrets manager, in a KMS. It must be protected, rotated, revoked on compromise, and audited. Keyless replaces the long-lived secret with a **short-lived certificate bound to a verifiable workload identity**, so the answer to 'where is your signing key?' becomes 'it existed for a few seconds inside the job that built the artifact'. ## The flow, step by step **1. Identity.** The CI job requests an OIDC token from its platform. On GitHub Actions this needs `permissions: id-token: write`; equivalents exist on GitLab, Buildkite, and for humans via an interactive browser login. The token's subject encodes exactly which workflow, repository and ref is running — that specificity is the whole security value. **2. Certificate.** cosign generates an ephemeral key pair in memory and sends the public key plus the OIDC token to **Fulcio**. Fulcio validates the token against the issuer, then issues an X.509 certificate whose Subject Alternative Name is the workload identity (e.g. `https://github.com/acme/api/.github/workflows/release.yml@refs/tags/v1.4`) with the issuer recorded in an extension. The certificate is deliberately **short-lived** (about ten minutes) — long enough to sign, too short to be worth stealing. **3. Sign.** cosign signs the **image digest**, not the tag, so the signature survives retagging and copying. The signature plus the certificate are pushed into the registry beside the image. **4. Transparency.** The signature, certificate and metadata are appended to **Rekor**, a tamper-evident public log, which returns an inclusion proof and a signed entry timestamp. This is what makes short-lived certificates verifiable *after* expiry: the verifier does not need the certificate to be valid now, only to have been valid **at the time Rekor recorded the signature**. It also gives detection — a compromised identity's signatures are permanently visible. **5. Discard.** The ephemeral private key is thrown away. There is nothing to rotate or leak. ## Where the signature lives Originally cosign stores signatures as an OCI object in the **same repository**, under a tag derived from the subject digest: `sha256-<hex>.sig` (with `.att` for attestations and `.sbom` variants). With **OCI 1.1** and the referrers API, cosign can instead attach them as **referrers** with a `subject` field, discoverable by API rather than by tag convention. Two practical consequences: - **Copying an image does not copy its signature.** Mirroring tools that move only the manifest and layers leave signatures behind; use `cosign copy`, or a copy that follows referrers, when populating mirrors or air-gapped registries. - **Registry garbage collection can delete signatures.** Retention rules like 'delete untagged manifests' or 'keep the last 10 tags' can silently remove the `.sig` objects, and verification then fails on images that were correctly signed. ## What verification must actually check `cosign verify` with no identity flags is close to meaningless — it proves *someone* whom Sigstore's public CA served signed the image. Real verification pins: - `--certificate-identity` or `--certificate-identity-regexp` — the exact workflow/subject allowed to sign; - `--certificate-oidc-issuer` — which OIDC provider issued the identity, so an attacker cannot mint an equivalent-looking subject at another issuer; - optionally the annotations/attestation predicate, when policy demands provenance rather than a bare signature. Under the hood cosign validates the chain to Fulcio's root (distributed via a TUF-managed trust root), checks the Rekor inclusion proof and the signed entry timestamp against the certificate's validity window, and then checks the signature over the digest. ## Operating it Sign in the same job that built the image, immediately after push, using the digest returned by the push. Keep the transparency requirement in mind for restricted networks: verification normally consults Rekor and the TUF trust root, so air-gapped verifiers need bundled material (cosign supports bundles and offline verification) or a self-hosted Sigstore stack. Decide that before mandating enforcement, or the exceptions list will become the policy.