How does Sigstore's keyless flow make an npm provenance attestation verifiable years later?

## The problem keyless was invented to solve Traditional package signing gives a maintainer a long-lived private key. That key has to live somewhere for years: on a laptop, in a CI secret, in a password manager. It leaks, it gets lost when the maintainer moves on, and nobody can tell a signature made by the maintainer from a signature made by whoever took the key. Revocation, when it happens at all, reaches almost nobody. Keyless signing removes the artifact at the centre of all those failures — the durable private key. ## The three pieces **OIDC identity.** A CI job can prove what it is. The CI provider issues an OpenID Connect token asserting claims like the repository, the ref, and the workflow file that is running. That token is short-lived and is minted for that specific job. It is the seed of the whole chain: the thing being authenticated is a *workload*, not a person. **Fulcio, the certificate authority.** The signing client generates a fresh key pair in memory, presents the OIDC token and the public key, and Fulcio returns an X.509 certificate binding that public key to the identity claims from the token. The certificate's validity window is measured in minutes. The private key is used once and thrown away — it never touches disk. **Rekor, the transparency log.** The signature, the certificate, and a digest of what was signed are submitted to an append-only, publicly auditable log. Rekor returns an inclusion proof and a signed timestamp. Note carefully what is logged: metadata about the signing event, **not the package itself**. Rekor is not a package registry and does not store your tarball. These three are bundled together and published alongside the artifact so a verifier has everything it needs offline. ## Why expiry does not break verification This is the point interviewers push on, because the naive objection is obvious: if the certificate expired ten minutes after publication, how can anyone verify the signature a year later? The answer is that verification does not ask "is this certificate valid *now*". It asks a different question: **was this signature made while the certificate was valid?** The chain of reasoning is: 1. The certificate chains up to Fulcio's trusted root, so it was genuinely issued by the CA to the identity it names. 2. The Rekor entry carries a timestamp from an independent party — the log, not the signer. 3. That timestamp falls inside the certificate's validity window. 4. Therefore the signature was produced by a key that Fulcio had, at that moment, bound to that workload identity. The short window is a feature, not a problem it has to work around. It means a certificate stolen after the fact is worthless: there is no window left to sign in. ## What the transparency log buys you beyond timestamping Rekor is a **detective** control. It does not stop a bad signature from being made; it makes one impossible to make *quietly*. Because the log is append-only and public, a maintainer can monitor it for entries claiming their identity that they never produced. If an attacker who can mint an OIDC token for your workflow signs a malicious release, the entry is there, dated, for anyone to find. Without the log, a valid-looking signature from a stolen credential leaves no trace at all. ## Where the threat model moves Keyless does not abolish the crown jewels; it relocates them. There is no key file to steal, so the attacker's target becomes the identity and the build: - Anyone who can make your CI run their code gets a legitimate certificate for your workflow. - Anyone who can cause an OIDC token to be minted for that identity — a misconfigured trust relationship, an over-permissive job — can sign as you. - A compromised build system produces attestations that verify perfectly and describe a build that really did happen. So hardening the pipeline matters *more* after adopting keyless signing, not less. The signature is now exactly as trustworthy as the workload identity behind it, which means the interesting question stops being "who has the key" and becomes "who can cause that workflow to run, and with what inputs". ## The verifier's remaining job One last trap: a technically valid Sigstore signature only proves *somebody* was authenticated by an OIDC provider and got a certificate. Fulcio will happily issue a certificate to any identity that authenticates — that is what makes the ecosystem open. The consumer must therefore state which identity it will accept. Verifying without pinning an expected repository and workflow is verifying that a stranger signed something.