Summary

  • A valid signature proves a relationship between bytes, a signing operation and an accepted verification policy; it does not independently prove continuing release authority.
  • Durable acceptance joins artifact integrity to identity, role authority, trusted time, transparency inclusion and preserved revocation evidence.
  • The decisive control is a release authority record that can be re-evaluated without rewriting the historical decision.

The green check that outlives the job

Take a release produced on a Friday afternoon. Its digest matches. Its signature validates. The certificate chain terminates at an accepted trust anchor, and the signing event appears in a transparency log. On Monday, the maintainer changes role. Weeks later, the credential is revoked after an unrelated incident. The artifact on the mirror has not changed, so the verifier continues to report the same mathematical relationship between the signature and those bytes.

That result is useful, but it is narrower than the sentence people often attach to it. It does not say that the maintainer was authorised to publish that particular release. It does not say whether the project required a second approval. It does not say whether the certificate was acceptable at the signing time rather than only at the verification time. It does not say how later revocation should affect an earlier acceptance decision.

The common error is to compress four records into one icon: integrity, identity, authority and time. A durable release decision must keep them separate.

What the standards actually establish

RFC 5280 describes certificate-path validation as a decision made against defined inputs: a trust anchor, policy constraints, name constraints and time. A successful path therefore answers a bounded question. It does not create a permanent statement that the subject retained an organisational role.

The same standard treats revocation as separate evidence. Certificate revocation lists and online status services have publication times, freshness limits and failure modes. If a release record retains only the signature but not the status material and validation policy used at acceptance, a later reviewer may be unable to reproduce the original decision.

RFC 3161 adds another distinct property. A time-stamping authority can bind a hash imprint to a trusted time. That is valuable when a verifier must establish that data existed before a certificate expired or a key was revoked. Yet a trusted timestamp does not know the project's release policy. It cannot prove that the signer had authority to ship version 4.2 rather than merely access to a valid credential.

RFC 6962's Certificate Transparency model supplies append-only observability through signed tree heads, inclusion proofs and consistency proofs. Transparency can expose unexpected certificate issuance and make omission harder. Log inclusion still does not encode a project's approval matrix. Public evidence that a credential existed is not the same as evidence that a release was authorised.

Sigstore makes these separations unusually visible. Fulcio issues short-lived certificates tied to identities supplied by an identity provider. Rekor provides a transparency log. Verification policy can constrain the expected identity and issuer. The system reduces the burden of long-lived signing keys, but it does not eliminate the relying party's need to decide which identity, workflow and issuer are acceptable for a given artifact.

The authority gap

The gap appears when a technically valid artifact is detached from the release process that authorised it. An engineer's identity may be genuine while the engineer lacks release authority. A workload identity may be expected while the workflow ran from an unapproved branch. A certificate may have been valid when issued while the approval behind the release was later withdrawn. A transparency entry may be authentic while the corresponding event should never have occurred.

These are not failures of cryptography. They are failures to preserve the control context around cryptography.

A project can close the gap with a compact authority record. For each accepted release, bind the artifact digest to the signature bundle, signer identity, issuer, approved role or workload, approval reference, certificate chain, validation policy and time, trusted timestamp where used, transparency-log entry and proof, revocation material, and accountable decision owner. The record should distinguish facts observed at acceptance from later facts learned during re-evaluation.

That distinction matters. If a credential is revoked after publication, the organisation should not silently rewrite the past as though the earlier decision never existed. It should preserve the original acceptance evidence, record the new revocation fact, apply the governing policy, and issue an explicit continued-use, withdrawal or replacement decision.

Sources