With keyless signing there is no long lived key to publish. Instead, a signature is tied to an identity, such as an email address, and an issuer, the login provider that vouched for it. When you verify, you state both, and the check passes only if they match.
How keyless signing differs
The Sigstore documentation says cosign supports identity based signing, associating an ephemeral signing key with an identity from an OpenID Connect provider. It calls this keyless signing and uses the sign blob command for files. The signer proves who they are to the provider, receives a short lived certificate, signs, and the key is discarded.
For verification, the documentation shows the verify and verify blob commands taking two flags: the expected certificate identity and the expected OIDC issuer. It lists example issuers, including those for Google, Microsoft, GitHub and GitLab.
What each field tells you
| Field | Meaning | Example shape |
|---|---|---|
| Certificate identity | Who the signature claims to come from | An email address, or for automated builds a workflow identity |
| OIDC issuer | The provider that authenticated that identity | A provider URL |
Both are needed. An identity name alone means little without knowing which provider vouched for it, and an issuer alone says nothing about which account signed.
What verification looks like
The documentation's example for a file uses a bundle containing the certificate and signature, then the expected identity and issuer:
cosign verify-blob file.txt --bundle artifact.sigstore.json \
--certificate-identity=name@example.com \
--certificate-oidc-issuer=https://accounts.example.com
It also notes that for blobs the signature and certificate can be stored in a bundle created at signing time, and that either the bundle or the individual signature and certificate must be given.
The mistake to avoid
If you tell the verifier to accept any identity, you only learn that someone signed it. That is much weaker than learning that your project's release workflow signed it. Always supply the exact identity you expect, taken from the project's verify page, not from the artifact you are checking. See how to write a verify page for your releases.
For publishers
- Decide the identity that signs releases, ideally an automated workflow rather than a person's account.
- Publish that exact identity and issuer string in your docs.
- When it changes, announce the change like a key rotation.
Related: can you verify Sigstore signatures offline and how to sign release files with cosign sign blob.
An analogy that helps
Think of the identity as the name on an identity card and the issuer as the authority that printed it. A card that names the right person but was printed by an unknown shop proves little. A card printed by a trusted authority but naming a stranger proves something different from what you wanted to check. Verification passes only when both the name and the authority match what you expected in advance. That is why your expected values should come from the project's own verify page, written down before you look at the artifact.
Quick check
Why is there no key to publish?
The key is ephemeral and discarded after signing. Trust comes from the identity and issuer recorded in the certificate.
What does a passing check prove?
That the expected identity, vouched for by the expected issuer, signed the file. It does not prove the code is safe.
Sources
Last reviewed: 19 October 2026.
