How can a Sigstore keyless signature still verify years after its short-lived certificate expired?
answer
- wrong question: valid now
- right question: valid when logged
- the log carries the time
- signed entry timestamp plus inclusion proof
- bundle makes it work offline
basics
~20 sVerification asks whether the certificate was valid when the signature was logged, not whether it is valid now. The Rekor entry supplies that moment as a log-signed timestamp, plus an inclusion proof binding it to the log.
solid answer
~40 sFulcio certificates live for minutes, which is far shorter than the shelf life of a released binary. So verification shifts the question from `is this certificate valid now?` to `was it valid at the instant this signature was recorded?`. Rekor answers that: the entry carries an integration time signed by the log — the signed entry timestamp — and a Merkle inclusion proof tying the entry to a published checkpoint. A verifier checks the signature over the artifact digest, checks the certificate chains to Fulcio's root, checks the inclusion proof, and then checks that the log's timestamp falls inside the certificate's validity window. The log, not the certificate, carries time. `cosign` can package the certificate, signature and proof into a bundle so a consumer three years later verifies offline, without the log being reachable.
go deeper
Recall that the signing certificate is deliberately short-lived and that the transparency log records when the signature happened, so expiry is normal rather than an error. You are not expected to walk the Merkle proof.
Be able to state the reframing — was the certificate valid at logging time, not now — and name the two pieces that supply it: the log-signed integration time and the inclusion proof against a published checkpoint.
Demonstrate the full verification sequence including the identity and issuer pin, and explain how you would make it work offline and at scale with bundles and a cached trust root.
Be ready to argue why short-lived certificates plus a public log is a better organisational bet than long-lived signing keys plus revocation infrastructure, and what you accept in exchange.
## The problem Keyless signing removes long-lived private keys by issuing an ephemeral signing key with a certificate that is valid for roughly ten minutes. That is excellent for the signer — there is no key to steal, store, rotate or escrow — and it looks fatal for the consumer. A CLI binary sitting in a distribution archive for three years is downloaded long after every certificate in its chain expired. Under ordinary TLS-style rules, an expired certificate means *reject*. If that rule applied here, keyless signing would produce signatures with a ten-minute shelf life. ## The reframing The resolution is to change the question being asked. For a server certificate, `valid now` is the right question because you are deciding whether to talk to a live peer that might have been compromised since issuance. For a signature over an immutable artifact, the right question is **was the signer's certificate valid at the moment the signature was made?** A signature is a statement made at a point in time; it does not need the certificate to remain live any more than a notarised document needs the notary's commission to still be current. That reframing only works if you have a trustworthy answer to *when*. A timestamp the signer puts in their own payload is worthless — an attacker with a stolen identity would simply write whatever time suits them. You need a timestamp from a party that is not the signer. ## What Rekor supplies When an entry is uploaded, Rekor returns a **signed entry timestamp (SET)**: the log's signature over the entry body together with the time the log integrated it. Because it is signed with the log's key, the signer cannot forge or backdate it; doing so would require the log's private key or the log's cooperation. The log is acting here as a timestamping authority as well as a public record. (Sigstore deployments can additionally use a dedicated RFC 3161 timestamp authority where a separate, purpose-built time source is wanted.) Alongside the timestamp, the verifier wants proof that the entry is genuinely part of the log rather than a one-off signature the log handed to it privately. That is the **inclusion proof**: the sibling hashes along the path from the entry's leaf up to the Merkle root, plus the signed checkpoint (root hash and tree size) it should match. Recompute the root from the leaf and the path; if it equals the signed checkpoint's root, the entry is in that log at that size. ## The verification sequence A complete keyless verification is a chain of checks, and each one is load-bearing: 1. **Signature check.** The signature is valid over the artifact's digest, using the public key in the certificate. 2. **Certificate chain.** The certificate chains to a Fulcio root that the verifier trusts, obtained from the Sigstore trust root rather than from the artifact. 3. **Identity check.** The identity in the certificate matches the identity you expect, and was issued by the OIDC issuer you expect. Skipping this accepts a signature from anyone on the internet, which is the single most common misuse of keyless signing. 4. **Log check.** The inclusion proof verifies against a signed checkpoint, and the entry's own signature material matches the certificate you just validated. 5. **Time check.** The log's integration time falls inside the certificate's `notBefore`/`notAfter` window. Only step 5 is about expiry, and note what it does *not* do: it never asks whether the certificate is valid *today*. Expiry is expected, not exceptional. ## Why this removes the revocation problem Long-lived signing keys drag revocation infrastructure behind them: if a key is stolen, every consumer must learn to stop trusting it, and must decide what happens to signatures already made. Ten-minute certificates make revocation largely moot — by the time you could distribute a revocation, the certificate has expired on its own. The compromise question becomes a *log* question instead: which entries were made under this identity during the window the identity was in someone else's hands? That is answerable because the log is public, complete and time-ordered. ## Offline verification Making every consumer call a public service at verify time is bad for availability and bad for privacy — it tells the log operator who is downloading what, and it breaks in air-gapped environments. Sigstore's answer is the **bundle**: the certificate, the signature, the log entry and its inclusion proof travel with the artifact in one file, and the trust root (Fulcio and Rekor public keys) is cached locally. Verification then needs no network at all. Everything above still holds; the verifier is simply reading proofs it already has instead of fetching them. ## Where this can still fail The timestamp is only as trustworthy as the log's key and the log's honesty. A log that served different views to different clients could, in principle, show one party an entry it hides from another. That risk is managed outside the single verification: consistency proofs prove the log only appended, and independent witnesses and monitors compare checkpoints so a forked view would be caught. For the individual consumer verifying a three-year-old download, the practical answer stands — the certificate expired, and it does not matter, because the log recorded when it was still alive.
- Why can't the signer just include a timestamp in the signed payload?Because the signer is the party you are trying not to have to trust blindly. Anyone who steals the identity can write any time they like into their own payload, including a time inside a window when the identity was legitimately in use. The timestamp has to come from a third party — here, the log's own signature over the integration time.
- If certificates expire in minutes, what replaces certificate revocation?Almost nothing needs to: a certificate is dead long before a revocation list could propagate. Compromise response moves to the log instead — you enumerate every entry made under the affected identity during the exposure window, tell consumers which digests not to trust, and re-release. The question becomes forensic and communicative rather than a revocation-distribution problem.
- What breaks if a verifier checks the signature but skips the identity check?Everything that matters. Fulcio will issue a certificate to any successfully authenticated identity, so an attacker signs their own malicious artifact, logs it, and produces a perfectly valid signature. Valid-signature-therefore-trusted accepts the whole internet; the policy must pin the expected identity and issuer.
- Does verification require the log to be online?Not if the artifact ships with a bundle. The bundle carries the certificate, signature, log entry and inclusion proof, and the Sigstore trust root can be cached, so the verifier recomputes the Merkle root and checks the timestamp locally. Online lookup is a convenience, not a dependency — which matters for air-gapped and high-volume consumers.
saying these in an interview costs you the question
- Insists an expired certificate must be rejected outright
- Believes a timestamp inside the signed payload is sufficient
- Thinks Sigstore needs certificate revocation lists to work
- Assumes verification always requires calling the log
- Says the inclusion proof proves the artifact is trustworthy