Timestamping

A timestamp authority (TSA) adds trusted time information to a signature.

Without a timestamp, a signature only answers "who signed this?" With a timestamp, it also answers "when was it signed?"

Why timestamps matter

Most signing identities in CI are short-lived. A Fulcio certificate is typically valid for a few minutes; a KMS key may rotate quarterly. Without a timestamp:

• A signature made by a now-expired Fulcio cert looks invalid forever.
• A signature made by a key that was later revoked or compromised cannot be distinguished from a fresh signature made after the compromise.

A trusted timestamp bound to the signature solves both:

• Verifiers can check whether the signing certificate was valid at the time of signing, not just right now.
• Compromise windows can be reasoned about, signatures from before the compromise stay trustworthy.

How CI/lock uses TSAs

CI/lock supports RFC 3161 timestamp authorities. Pass one or more TSA URLs via --timestamp-servers (alias -t). When configured, every signed attestation is timestamped at signing time. The timestamp (type tsp in the DSSE signature record) is included in the attestation envelope so it travels with the evidence.

You can use:

• A public Sigstore-operated TSA (default for keyless workflows when the cilock-action defaults are accepted)
• The TestifySec platform TSA (derived from --platform-url)
• Your own internal TSA, for environments that can't reach the public one
• A commercial TSA such as DigiCert's

TSA URLs must use HTTPS unless the host is local or on a private network. Some public TSAs answer RFC 3161 only over plain HTTP (DigiCert's http://timestamp.digicert.com refuses port 443). For those, pass --timestamp-allow-http (on cilock verify, --vsa-timestamp-allow-http). That loosens the transport and nothing else: CI/lock still checks the token's signature and that it answers this request's digest and nonce, so an attacker on the network can block a timestamp but cannot forge one. The digest being timestamped does travel in the clear.

Verification with timestamps

When cilock verify encounters a timestamped envelope, it:

1. Validates the timestamp against the TSA's trust root.
2. Checks the signing certificate against the timestamped time, not the current time.
3. Reports the signing time alongside the identity in verification output.

This is what makes CI/lock evidence archive-quality rather than only useful while certificates are still fresh.

Requiring a timestamp

A policy does not require a timestamp unless a step says so. What happens to evidence with no timestamp depends on the functionary:

So a policy that signs with a key and lists your TSA still passes a record that was never timestamped. To make the timestamp mandatory, add a timestampConstraint to every step:

"steps": {
  "build": {
    "name": "build",
    "functionaries": [{"type": "publickey", "publickeyid": "<key id>"}],
    "attestations": [{"type": "https://aflock.ai/attestations/material/v0.3"}],
    "timestampConstraint": {"maxAge": "720h"}
  }
}

• maxAge requires a verified timestamp and rejects one older than the duration at verification time.
• To require a timestamp with no age limit, set only notBefore to an early instant, for example {"notBefore": "1970-01-01T00:00:00Z"}. At least one of notBefore, notAfter and maxAge must be set.

A step with a constraint rejects an untimestamped collection with untimestamped evidence cannot satisfy a time constraint (fail-closed). The time checked is the RFC 3161 time on a signature that matched one of the step's functionaries, verified against the policy's timestampauthorities, never a time the signer wrote into its payload. See timestampConstraint in the policy reference.

See also

• Signing & identity — the keys and certificates a timestamp anchors in time.
• Trust model — where long-term, timestamped evidence fits in CI/lock's threat model.
• Policy verification — how verification checks the signing certificate against the timestamped time, not the current time.