RFC 3161 Timestamping for Audit Evidence

RFC 3161 timestamping lets a Time-Stamp Authority, or TSA, sign a cryptographic message imprint together with a time, serial number, and policy identifier. A valid token can support the claim that the hashed data existed no later than the upper time bound accepted by the verifier: genTime + accuracy when the token carries an accuracy interval, or a bound derived from the applicable TSA policy when it does not. Treating bare genTime as an exact instant overstates the protocol.

RFC 3161 describes a TSA as a trusted third party, but the protocol itself specifies no corporate-independence test. Whether an internally operated TSA is acceptable is therefore a validation-policy and assurance decision. A contracted external TSA can add separation of duties and an external trust anchor, but that is an architecture choice—not a property inferred from the token alone.

That is useful evidence. It is not proof that the underlying event happened, that the file is truthful, that the collector had authority, or that a control complied with NIS2, ISO/IEC 27001, SOC 2, DORA, or eIDAS.

The enterprise problem is therefore larger than obtaining a .tsr file. A defensible system must preserve the exact artifact, request, response, trust material, provider policy, verification result, custody history, and renewal evidence needed for an independent verifier to reach the same conclusion later.

What an RFC 3161 token proves—and what it does not

The RFC 3161 protocol is intentionally narrow. The requester hashes the data locally and sends the message imprint, not the source file, to the TSA. The TSA returns a signed token that binds the imprint to its time and policy.

“The source file is not sent” is not a complete privacy claim. A deterministic imprint can reveal that two submissions cover the same bytes, and an attacker can test guesses when the underlying artifact comes from a small or predictable set. The TSA also observes request timing and transport metadata. Where GDPR applies, the following controls implement data minimization, purpose limitation, storage limitation, and pseudonymisation risk management; they are not RFC 3161 requirements. Classify and minimize artifacts before hashing; avoid timestamping low-entropy personal attributes in isolation; restrict receipt and catalog access; define retention and deletion rules before using immutable storage; and require provider terms that cover purpose limitation, logging, subprocessors, location, retention, and incident handling. Route personal-data or regulated-data designs through privacy and records-management review rather than treating hashing as anonymization. See GDPR Article 5 and Recital 26 and the EDPB anonymisation and pseudonymisation topic portal. The portal can link material at different adoption stages; verify each document’s consultation or final status before treating it as authoritative guidance.

When verification succeeds, the token can support these claims:

1. The response corresponds to the request or original data.
2. The TSA signed the token with a certificate accepted by the verifier’s trust policy.
3. The token carries a particular generation time, serial number, policy object identifier, message-imprint algorithm, and—when present—accuracy interval.
4. The artifact presented later has the same digest as the artifact originally timestamped.

It does not independently prove:

• who created the artifact;
• whether the artifact’s contents were accurate;
• whether the application clock, log source, or operator was trustworthy;
• whether evidence was collected lawfully or with a valid chain of custody;
• whether the TSA service was qualified under eIDAS at the relevant time;
• whether a framework control was suitably designed or operated effectively;
• whether the receipt remains reliable after algorithms, certificates, or trust services age.

This distinction prevents a common category error: cryptographic integrity is not semantic truth.

The protocol mental model

An RFC 3161 exchange has four primary objects:

The basic flow is:

┌────────────────────── Evidence producer trust boundary ───────────────────────┐
│                                                                               │
│  Source event ──> canonical artifact ──> SHA-256 imprint ──> request + nonce  │
│       │                  │                                      │             │
│       └─ provenance      └─ immutable object ID                 └──────┐      │
└────────────────────────────────────────────────────────────────────────┼──────┘
                                                                         │
                                                  imprint + metadata     │
                                                                         v
                                                    ┌─────────────────────────┐
                                                    │ TSA trust boundary      │
                                                    │ policy + UTC time       │
                                                    │ serial + TSU signature  │
                                                    └────────────┬────────────┘
                                                                 │ signed DER
                                                                 v
┌──────────────────────── Evidence platform trust boundary ─────────────────────┐
│                                                                               │
│  response ──> immediate verification ──> evidence envelope ──> WORM archive   │
│                    │                         │                    │           │
│                    ├─ imprint + nonce        ├─ chain + policy    ├─ catalog  │
│                    ├─ signature + purpose    ├─ raw TSQ + TSR     └─ custody  │
│                    └─ service qualification  └─ verifier result               │
│                                               │                               │
│                                               └─> revalidate / renew before   │
│                                                   cryptographic ageing        │
└───────────────────────────────────────────────────────────────────────────────┘

The diagram exposes three separate trust decisions. You must trust the evidence producer to create the right artifact, the TSA to issue a correct time assertion under the claimed policy, and the evidence platform to preserve all required bytes and metadata without substitution.

Qualified and non-qualified timestamps are different services

Under the current consolidated eIDAS Regulation, Articles 41 and 42, an electronic timestamp cannot be denied legal effect or admissibility solely because it is electronic or non-qualified. A qualified electronic timestamp receives an additional presumption of the accuracy of its date and time and the integrity of the data to which they are bound.

A qualified timestamp must bind time to data so undetectable change is reasonably precluded, use an accurate source linked to Coordinated Universal Time, and be signed or sealed by a qualified trust service provider using the required mechanism.

Commission Implementing Regulation (EU) 2025/1929 now supplies the Article 42(2) standards layer. It names ETSI EN 319 421 V1.3.1 and ETSI EN 319 422 V1.1.1, subject to the adaptations in its Annex. Compliance with those listed standards creates a presumption of compliance with the corresponding eIDAS requirements; the Regulation also permits compliance to be demonstrated through other practices. The standards are therefore a privileged assurance route, not the exclusive technical route. This matters operationally: an RFC 3161 token, even one with a valid signature, is not automatically a qualified electronic timestamp. The relying party still needs a validation policy that evaluates the token profile, the service identity and status in the trusted list, the applicable standards or other demonstrated practices, and the receipt’s issuance time.

For the Regulation’s listed-standards route, the adapted ETSI EN 319 422 profile requires both client and server support for RFC 3161 over HTTPS. If the TSA declares a token to be a qualified electronic timestamp, the token must contain one non-critical qcStatements extension with one esi4-qtstStatement-1 statement. Validate those profile requirements explicitly. The statement records the TSA’s declaration; it does not replace cryptographic verification or the service-and-time trusted-list decision. A vendor-published HTTP URL, including the Sectigo candidate below, cannot satisfy that HTTPS profile requirement without a separate contracted HTTPS endpoint.

The vendor’s company-level status is not enough. The European Commission’s Trusted Lists guidance is explicit: a provider and the specific service are qualified only if the service appears in a Member State trusted list. Qualification is therefore a service-and-time decision, not a marketing label.

For every receipt claimed as qualified, record:

• the exact service identity and TSU certificate;
• the trusted-list service entry and status history used for the decision;
• the timestamp policy OID and, for a token declared qualified under the listed-standards route, the non-critical qcStatements extension containing exactly one esi4-qtstStatement-1 statement;
• the evaluation time and validation policy;
• the implementing regulation and standards versions applied by that policy;
• the applicable provider policy and practice statement version;
• the result of cryptographic and service-status validation.

Do not set qualified = true because the endpoint path contains /qualified.

Provider endpoints: verified facts and procurement gaps

Public documentation is useful for interoperability testing, but it is not a substitute for a contract, service-level objective, current trust-list check, or accepted-use policy. The facts below were rechecked against official sources on 2026-08-04.

This table deliberately refuses to turn a hostname collected from a search result into a production trust decision. Camerfirma is not listed because this review did not establish a current service-specific endpoint and policy from an authoritative public source. That is a procurement gap, not evidence that the service is unsuitable.

Synthetic conformance evidence and its limits

The publication workflow uses a network-isolated synthetic conformance harness. It exercises request-bound and artifact-bound verification; rejection of a modified artifact, wrong request, and malformed response; private attempt-local staging of trust inputs plus rejection of source-path substitution; a loopback HTTPS success path; rejection of bad status, media type, redirect, response size, and endpoint pin; read-only same-device hard-link promotion with no overwrite; pre-network failure evidence; incomplete-attempt classification; all shell blocks’ syntax; and selected SQL integrity invariants. The release gate must execute the versioned harness against the exact article source and retain the result with the repository revision, article digest, harness digest, exact tool or container digests, and fixture manifest.

Passing synthetic conformance clears only the reference-example boundary. It does not prove a vendor endpoint, production deployment, qualified status, historical trusted-list processing, legal effect, database authorization, append-only enforcement, object-store retention, disaster recovery, or operational suitability.

A production configuration should encode the assurance contract explicitly instead of inferring it from the URL:

id: fnmt-qtimestamp-candidate-2025
endpoint: https://qets2025.cert.fnmt.es/
transport:
  mode: mtls
  client_certificate_secret: tsa/fnmt/client-certificate
expected_policy_oids:
  - 0.4.0.2023.1.1
qualification:
  source: eu-trusted-list
  expected_service_type: QTimestamp
  on_indeterminate: reject

The trusted-list result must still be computed from authenticated list data and historical service status. The YAML does not make the service qualified; it states what the validator is required to prove.

A provisioned OpenSSL live-probe template

OpenSSL’s current openssl ts documentation covers request creation, response inspection, and response verification. It does not send the request over HTTP; curl or another transport client performs that step.

The live probe is intentionally nondeterministic: OpenSSL generates a fresh nonce, the provider returns a new token, and service state changes over time. A reproducible conformance test must instead use offline, provenance-recorded fixtures and pin the OpenSSL and curl versions or container digests, artifact bytes, request and response DER, validation profile, and SHA-256 digest of every trust input. Record openssl version -a and curl -q --version in live-probe evidence. The probe must copy provisioned trust files into its private attempt directory, verify those copies, and use only the verified attempt-local paths; hashing a mutable provisioning path and reopening it later is a check-to-use bug.

1. Create a stable artifact

umask 077
printf '%s\n' 'Incident Report #123' > incident.txt
openssl dgst -sha256 incident.txt

Production systems need a canonicalization rule before this step. Two JSON documents with different whitespace are different byte sequences even if an application interprets them as the same object. Either timestamp the exact stored bytes or define and version a deterministic canonical form.

2. Retain the artifact before creating the request

The request must be created from the retained artifact inside the unique evidence-attempt directory, not from a mutable working copy. The end-to-end probe below copies incident.txt first, marks that retained copy read-only, and then creates request.tsq from those exact bytes. OpenSSL includes a nonce unless -no_nonce is specified. Preserve the request: the nonce helps bind the response to this exchange and makes accidental or malicious response substitution easier to detect.

3. Submit, validate, and only then promote the candidate

set -eu

: "${TSA_URL:?set the contracted TSA endpoint}"
: "${TSA_URL_SHA256:?set the approved endpoint string SHA-256}"
: "${TSA_ROOTS:?set the provisioned root bundle path}"
: "${TSA_ROOTS_SHA256:?set the expected root bundle SHA-256}"
: "${TSA_INTERMEDIATES:?set the provisioned intermediate bundle path}"
: "${TSA_INTERMEDIATES_SHA256:?set the expected intermediate bundle SHA-256}"
: "${TSA_TLS_CA_BUNDLE:?set the provisioned HTTPS CA bundle path}"
: "${TSA_TLS_CA_BUNDLE_SHA256:?set the expected HTTPS CA bundle SHA-256}"

file_sha256() {
  openssl dgst -sha256 -r "$1" | awk '{print $1}'
}

string_sha256() {
  printf '%s' "$1" | openssl dgst -sha256 -r | awk '{print $1}'
}

evidence_root='./timestamp-evidence'
install -d -m 0700 "$evidence_root/attempts" "$evidence_root/receipts"
work_dir="$(mktemp -d "$evidence_root/attempts/incident.XXXXXX")"
status="$work_dir/result.tsv"
result=FAIL
trap 'code=$?; printf "result\t%s\nexit_status\t%s\n" "$result" "$code" > "$status"' EXIT
trap 'exit 129' HUP
trap 'exit 130' INT
trap 'exit 143' TERM

case "$TSA_URL" in
  https://*) ;;
  *) printf 'only a reviewed HTTPS TSA endpoint is allowed\n' >&2; exit 1 ;;
esac
endpoint_without_scheme="${TSA_URL#https://}"
endpoint_authority="${endpoint_without_scheme.*}"
curl_version_remainder="${curl_version#*.}"
curl_minor="${curl_version_remainder%%.*}"
if test "$curl_major" -lt 8 \
  || { test "$curl_major" -eq 8 && test "$curl_minor" -lt 4; }; then
  printf 'curl 8.4.0 or newer behavior is required; found %s\n' "$curl_version" >&2
  exit 1
fi
grep -Eq '^Protocols:.*:space:https(:space:|$)' "$curl_version_file"
grep -Eq '^Features:.*:space:SSL(:space:|$)' "$curl_version_file"
ln --version > "$work_dir/coreutils-ln-version.txt"
printf '%s\n' \
  'endpoint=exact-sha256-pinned' \
  'endpoint_credentials=forbidden' \
  'protocol=https-only' \
  'proxy=disabled' \
  'tls_ca=attempt-local-digest-pinned-bundle' \
  'verification_trust=attempt-local-digest-pinned-bundles' \
  > "$transport_policy"

unset http_proxy https_proxy HTTP_PROXY HTTPS_PROXY ALL_PROXY all_proxy
unset NO_PROXY no_proxy CURL_CA_BUNDLE SSL_CERT_FILE SSL_CERT_DIR SSLKEYLOGFILE

curl -q \
  --fail-with-body \
  --silent \
  --show-error \
  --connect-timeout 5 \
  --max-time 30 \
  --max-filesize 1048576 \
  --proto '=https' \
  --proxy '' \
  --cacert "$staged_tls_ca_bundle" \
  --header 'Content-Type: application/timestamp-query' \
  --header 'Accept: application/timestamp-reply' \
  --data-binary @"$request" \
  --output "$candidate" \
  --write-out '%{http_code}\t%{content_type}\t%{url_effective}\n' \
  --url "$TSA_URL" > "$transport"

IFS="$(printf '\t')" read -r http_code content_type effective_url < "$transport"
case "$http_code" in 2??) ;; *) printf 'unexpected HTTP status: %s\n' "$http_code" >&2; exit 1 ;; esac
normalized_content_type="$(
  printf '%s' "$content_type" \
    | LC_ALL=C tr '[:upper:]' '[:lower:]' \
    | sed 's/^:space:*//; s/:space:*$//'
)"
test "$normalized_content_type" = 'application/timestamp-reply' || {
  printf 'unexpected media type: %s\n' "$content_type" >&2
  exit 1
}
requested_url="${TSA_URL%/}/"
normalized_effective_url="${effective_url%/}/"
test "$normalized_effective_url" = "$requested_url"

response_size="$(wc -c < "$candidate" | tr -d '[:space:]')"
test "$response_size" -gt 0
test "$response_size" -le 1048576

# DER parsing plus request-bound and retained-artifact-bound verification are mandatory.
openssl ts -reply -in "$candidate" -text >/dev/null
openssl ts -verify \
  -queryfile "$request" \
  -in "$candidate" \
  -CAfile "$staged_roots" \
  -untrusted "$staged_intermediates"
openssl ts -verify \
  -data "$artifact" \
  -in "$candidate" \
  -CAfile "$staged_roots" \
  -untrusted "$staged_intermediates"

chmod 0444 "$candidate"
receipt="$evidence_root/receipts/$(basename "$work_dir").tsr"
ln -T -- "$candidate" "$receipt"
result=PASS

Every attempt receives a unique private directory containing the retained artifact bytes, verified attempt-local trust copies and their digest manifest, a request generated from the retained artifact, the response, transport metadata, and exit status. The original trust paths are never reopened after staging, so replacing a provisioning path after the copy cannot substitute trust material in the current attempt; a concurrent change during copying produces a digest mismatch and fails closed. The 0700 directory and 0444 files protect against other OS users, not a malicious process running as the same account, so production should isolate the probe identity and prefer read-only content-addressed mounts or another stronger immutability boundary.

The EXIT trap is installed immediately after the attempt and status paths exist, so normal shell exits and the handled signals record pre-network failures as well as transport and validation failures. SIGKILL, kernel failure, and power loss are not trappable; a recovery job must mark any attempt lacking result.tsv as incomplete rather than silently treating it as absent. A verified response is changed to its final read-only mode before it is hard-linked into timestamp-evidence/receipts, and promotion occurs only after HTTP status, content type, effective URL, size, DER parsing, request-bound verification, and a separate verification against the retained artifact all pass. ln is atomic and no-clobber when the source and receipt directory are on the same filesystem; if a nested mount separates them, it fails closed and no receipt is promoted. Enforce and test trust-source substitution, pre-network failure recording, permission failure, link failure, crash reconciliation, and the same-device deployment invariant. The read-only mode is an operational guard, not immutable retention; production evidence still belongs in append-only or Object Lock storage with a manifest and custody record.

-q is deliberately the first curl argument, so curl does not load an operator’s default configuration and silently change authentication, proxy, redirect, or output behavior. That is not sufficient by itself. The example also requires an approval-controlled SHA-256 for the exact endpoint string, accepts only HTTPS, clears proxy and CA-related environment variables, disables proxy use explicitly, verifies attempt-local copies of the TLS and timestamp-validation bundles by digest, uses --url so the endpoint value cannot be parsed as another option, and records the transport policy. The endpoint and trust-input digests must come from a separately reviewed deployment profile; letting the runtime choose both a value and its expected digest defeats the control. A provider that supports only HTTP, requires a proxy, or uses mTLS needs a separate adapter with an explicit threat decision and fixtures rather than a relaxed global default.

The endpoint parser also rejects URL userinfo, query strings, and fragments. This keeps usernames, passwords, API tokens, and signed query credentials out of the command line and the retained effective-URL record. Any authenticated provider needs a separate reviewed adapter that supplies secrets through a protected file descriptor, mounted secret, or provider SDK without placing them in arguments or evidence. Curl’s own known-risks guidance warns that command-line arguments can be visible and that URL inputs require careful validation.

--fail-with-body returns a curl failure for HTTP status 400 or greater while retaining the response body in the attempt directory. The nonzero exit prevents promotion, and the quarantined body plus transport record remain available for diagnosis.

Treat curl 8.4.0 as the behavioral floor for this example, not as a security pin. The script now rejects older versions and curl builds that do not report HTTPS plus SSL support. Since 8.4.0, --max-filesize aborts a transfer when received bytes exceed the limit even when the server did not declare a usable Content-Length; earlier versions could only reject based on a reported size. Version 8.4.0 itself has published vulnerabilities, so production must use an approved, currently patched exact build or digest-pinned container that preserves this behavior, with its active curl security advisories reviewed at release time. The explicit byte count remains a second check before promotion. The example also assumes GNU coreutils for ln -T; use an approved exact build or digest-pinned runtime and preserve its version output. Record and fixture-test both tool contracts instead of treating the command as platform-independent.

The strict media-type and effective-URL checks are policy decisions. This example case-normalizes and trims only the outer whitespace of the media type, then requires the exact base type application/timestamp-reply; it deliberately rejects all parameters. A provider-specific adapter may accept documented parameters only after parsing and validating each parameter, never by prefix matching. The URL check normalizes only one trailing slash; it does not authorize a different scheme, host, port, path, or redirect. Lock both behaviors with deterministic adapter fixtures. If a contracted provider documents a different response type or approved redirect, encode that exact behavior in its adapter and tests. Do not weaken the checks globally.

Some providers publish HTTP endpoints. The token’s signature protects the token’s cryptographic contents when verification is performed correctly, but HTTP still exposes transport metadata and permits denial, redirection, and response substitution attempts. Prefer a documented HTTPS endpoint when the contracted service supports it, and always verify the token independently.

4. Inspect—but do not confuse inspection with verification

: "${RECEIPT_PATH:?set a retained receipt path from the live-probe evidence}"

openssl ts -reply \
  -in "$RECEIPT_PATH" \
  -text

Review the response status, policy OID, message-imprint algorithm and value, serial number, generation time, accuracy, nonce, TSA name, and certificate inclusion. Printing those fields proves only that OpenSSL parsed the response.

5. Verify against the original request and a controlled trust store

: "${REQUEST_PATH:?set the retained request path}"
: "${RECEIPT_PATH:?set the retained response path}"
: "${TSA_ROOTS:?set the digest-verified root bundle path}"
: "${TSA_INTERMEDIATES:?set the digest-verified intermediate bundle path}"

openssl ts -verify \
  -queryfile "$REQUEST_PATH" \
  -in "$RECEIPT_PATH" \
  -CAfile "$TSA_ROOTS" \
  -untrusted "$TSA_INTERMEDIATES"

An alternative data-bound check is:

: "${ARTIFACT_PATH:?set the retained artifact path}"
: "${RECEIPT_PATH:?set the retained response path}"
: "${TSA_ROOTS:?set the digest-verified root bundle path}"
: "${TSA_INTERMEDIATES:?set the digest-verified intermediate bundle path}"

openssl ts -verify \
  -data "$ARTIFACT_PATH" \
  -in "$RECEIPT_PATH" \
  -CAfile "$TSA_ROOTS" \
  -untrusted "$TSA_INTERMEDIATES"

OpenSSL requires a trust source such as -CAfile, -CApath, or -CAstore; verification errors produce a failing exit status. The TSA signing certificate must be valid for timestamp signing, and any required intermediate certificates must be available from the response or the untrusted chain file.

This is a cryptographic smoke test, not a complete long-term or eIDAS-qualified validation engine. Qualification, historical service status, revocation evidence, algorithm suitability, and policy processing require additional validation logic.

The evidence envelope

The minimum enterprise record is an immutable envelope, not a row containing a vendor name and base64 token.

{
  "schema": "rfc3161-evidence-envelope-v1",
  "artifact": {
    "object_uri": "s3://evidence/incidents/INC-123/report-v3.json",
    "sha256": "6e0b...",
    "media_type": "application/json",
    "canonicalization": "jcs-rfc8785",
    "provenance_id": "collection-run-018f..."
  },
  "request": {
    "sha256": "5cd1...",
    "object_uri": "s3://evidence/receipts/018f/request.tsq",
    "message_imprint_algorithm": "2.16.840.1.101.3.4.2.1",
    "nonce": "145821901208..."
  },
  "response": {
    "sha256": "1f92...",
    "object_uri": "s3://evidence/receipts/018f/response.tsr",
    "policy_oid": "provider-policy-oid",
    "serial": "provider-serial",
    "gen_time": "2026-08-04T10:15:31.482Z",
    "tsa_certificate_sha256": "9c7a..."
  },
  "validation": {
    "profile": {
      "id": "enterprise-rfc3161-v3",
      "object_uri": "s3://evidence/policies/rfc3161/profile-v3.json",
      "object_version": "immutable-object-version",
      "sha256": "2a44..."
    },
    "verifier": {
      "name": "validator-name",
      "version": "validator-version",
      "artifact_uri": "oci://registry.example/validator@sha256:8d91...",
      "artifact_sha256": "8d91..."
    },
    "verified_at": "2026-08-04T10:15:33Z",
    "cryptographic_result": "pass",
    "qualified_service_result": "not-evaluated",
    "trust_bundle": {
      "object_uri": "s3://evidence/receipts/018f/validation-bundle.tar",
      "object_version": "immutable-object-version",
      "sha256": "b771...",
      "manifest_schema": "rfc3161-validation-bundle-v1"
    }
  }
}

Base64 is a transport encoding, not an integrity mechanism. Preserve the raw DER request and response and hash each stored object. A mutable URI is not an identity: bind the validation profile, verifier executable or container, and trust bundle to content digests and immutable object versions. The trust-bundle manifest should enumerate and hash every certificate, revocation object, trusted-list snapshot, and policy file used by the decision.

A PostgreSQL persistence sketch—not an authorization design

Separate artifacts, receipts, and validation runs. One artifact can have receipts from multiple providers and multiple later revalidations.

-- Install pgcrypto once through the controlled extension-management workflow.
CREATE EXTENSION IF NOT EXISTS pgcrypto;

CREATE TABLE evidence_object_ingest_verification (
    id uuid PRIMARY KEY,
    object_uri text NOT NULL,
    object_version text NOT NULL,
    observed_sha256 bytea NOT NULL CHECK (octet_length(observed_sha256) = 32),
    observed_size_bytes bigint NOT NULL CHECK (observed_size_bytes > 0),
    verifier_artifact_sha256 bytea NOT NULL
        CHECK (octet_length(verifier_artifact_sha256) = 32),
    verified_at timestamptz NOT NULL,
    UNIQUE (id, object_uri, object_version, observed_sha256)
);

CREATE TABLE evidence_artifact (
    id uuid PRIMARY KEY,
    object_uri text NOT NULL,
    object_version text NOT NULL,
    sha256 bytea NOT NULL CHECK (octet_length(sha256) = 32),
    ingest_verification_id uuid NOT NULL,
    media_type text NOT NULL,
    canonicalization text,
    provenance_id uuid NOT NULL,
    created_at timestamptz NOT NULL,
    UNIQUE (object_uri, object_version),
    FOREIGN KEY (ingest_verification_id, object_uri, object_version, sha256)
        REFERENCES evidence_object_ingest_verification
            (id, object_uri, object_version, observed_sha256)
);

CREATE TABLE rfc3161_receipt (
    id uuid PRIMARY KEY,
    artifact_id uuid NOT NULL REFERENCES evidence_artifact(id),
    provider_id text NOT NULL,
    service_id text NOT NULL,
    request_der bytea NOT NULL,
    response_der bytea NOT NULL,
    request_sha256 bytea GENERATED ALWAYS AS (digest(request_der, 'sha256')) STORED,
    response_sha256 bytea GENERATED ALWAYS AS (digest(response_der, 'sha256')) STORED,
    imprint_algorithm_oid text NOT NULL,
    policy_oid text NOT NULL,
    tsa_serial text NOT NULL
        CHECK (tsa_serial ~ '^(0|-?[1-9][0-9]*)$'),
    tsa_time timestamptz NOT NULL,
    tsa_time_raw text NOT NULL,
    accuracy_seconds bigint CHECK (accuracy_seconds IS NULL OR accuracy_seconds >= 0),
    accuracy_millis integer CHECK (accuracy_millis IS NULL OR accuracy_millis BETWEEN 1 AND 999),
    accuracy_micros integer CHECK (accuracy_micros IS NULL OR accuracy_micros BETWEEN 1 AND 999),
    ordering boolean NOT NULL,
    decoder_artifact_sha256 bytea NOT NULL
        CHECK (octet_length(decoder_artifact_sha256) = 32),
    tsa_certificate_sha256 bytea NOT NULL CHECK (octet_length(tsa_certificate_sha256) = 32),
    received_at timestamptz NOT NULL,
    UNIQUE (provider_id, service_id, tsa_serial)
);

CREATE TABLE receipt_validation (
    id uuid PRIMARY KEY,
    receipt_id uuid NOT NULL REFERENCES rfc3161_receipt(id),
    validation_profile_id text NOT NULL,
    validation_profile_uri text NOT NULL,
    validation_profile_object_version text NOT NULL,
    validation_profile_sha256 bytea NOT NULL
        CHECK (octet_length(validation_profile_sha256) = 32),
    verifier_name text NOT NULL,
    verifier_version text NOT NULL,
    verifier_artifact_uri text NOT NULL,
    verifier_artifact_sha256 bytea NOT NULL
        CHECK (octet_length(verifier_artifact_sha256) = 32),
    evaluated_at timestamptz NOT NULL,
    cryptographic_result text NOT NULL CHECK (cryptographic_result IN ('pass', 'fail')),
    qualified_service_result text NOT NULL
        CHECK (qualified_service_result IN ('pass', 'fail', 'indeterminate', 'not-evaluated')),
    trust_bundle_uri text NOT NULL,
    trust_bundle_object_version text NOT NULL,
    trust_bundle_sha256 bytea NOT NULL
        CHECK (octet_length(trust_bundle_sha256) = 32),
    trust_bundle_manifest_schema text NOT NULL,
    findings jsonb NOT NULL DEFAULT '[]'::jsonb
);

CREATE INDEX rfc3161_receipt_artifact_id_idx
    ON rfc3161_receipt (artifact_id);

CREATE INDEX receipt_validation_receipt_id_idx
    ON receipt_validation (receipt_id);

The generated request and response digests are computed by PostgreSQL from the stored DER, so callers cannot insert inconsistent DER/digest pairs. External artifact bytes require a different boundary because a database constraint cannot read an object store safely. Grant no application role direct INSERT on evidence_object_ingest_verification or evidence_artifact. A constrained ingestion worker must read the exact immutable object version, recompute SHA-256 and size from the returned bytes, record its pinned verifier-artifact digest, insert the verification row through a narrowly granted function, and then insert the artifact row referencing the same URI, version, and digest. The composite foreign key prevents the catalog entry from pointing at a different attestation; object-store retention and version immutability prevent later replacement. Test that ordinary runtime roles cannot write either table directly.

The same controlled-insertion rule applies to rfc3161_receipt: revoke direct table writes, parse the retained DER with a digest-pinned decoder, and pass the DER plus decoded fields to one constrained function that independently verifies their correspondence before insertion. tsa_time is a normalized query value; tsa_time_raw preserves the token’s exact GeneralizedTime lexical value so PostgreSQL’s microsecond timestamp precision cannot silently erase additional fractional digits. The accuracy components and ordering flag preserve the corresponding TSTInfo semantics. The decoder digest identifies the parser used to derive policy, serial, time, accuracy, ordering, and certificate metadata. These columns still do not enforce correspondence by themselves; the non-deployable warning remains in force until the controlled function and negative database tests exist.

These columns make a validation run reproducible by identity, not by label. If the object store is content-addressed, the digest may also appear in the URI; storing it in a fixed-length column still gives the database a direct comparison key. The example assumes application-supplied UUIDv7 identifiers; a single-database deployment can use bigint GENERATED ALWAYS AS IDENTITY instead.

tsa_serial uses canonical base-10 text so an ASN.1 INTEGER cannot be stored as a fractional PostgreSQL numeric and is not narrowed to a machine-integer range. The constraint rejects a plus sign, leading zeroes, negative zero, and non-integral forms while retaining a minus sign only for nonzero values. The DER decoder must normalize the integer to that single representation before insertion, and fixtures must prove that equivalent encodings cannot create distinct catalog identities. service_id must identify the TSA or TSU serial-number namespace used by the validator. The uniqueness constraint deliberately excludes policy_oid: RFC 3161 requires each token serial to be unique for the issuing TSA, so changing policy must not make reuse acceptable.

The example is intentionally incomplete as a full authorization model. In production, receipts and validation rows should also be inserted through constrained functions, operators should not be able to rewrite them, and retention should be enforced in the object store as well as the catalog.

Enterprise architecture and control planes

A scalable service separates five planes.

1. Collection plane

Collectors create stable artifacts from source systems and attach provenance: source identity, query or command, collection time, scope, collector version, and authorization context. Timestamping a screenshot without these fields creates weak evidence with a strong cryptographic wrapper.

2. Receipt plane

A provider adapter creates the request, submits it to an allowlisted service, enforces timeouts and response limits, and returns raw bytes plus transport metadata. It has no authority to declare a receipt qualified.

3. Validation plane

An independent validator checks request-response correspondence, imprint, nonce, signature, certificate purpose, chain, policy, service identity, and—when required—qualified status. Separate acquisition from validation so a compromised adapter cannot mark its own output trustworthy.

4. Preservation plane

The artifact, request, response, trust bundle, and validation record are written to immutable storage under independent credentials. The relational catalog stores discoverable metadata and object hashes, not the sole copy of the evidence.

5. Governance plane

Policy decides which artifacts need standard, qualified, dual-provider, or renewed receipts; who may retrieve them; how long they are retained; which exceptions are allowed; and which validation profile an auditor should apply.

The workflow should expose state instead of collapsing acquisition and validation into one boolean:

CAPTURED
   |
   v
STAMP_PENDING --timeout/provider error--> STAMP_DEFERRED --approved retry--> STAMP_PENDING
   |
   v
TOKEN_RECEIVED --DER/imprint/nonce failure-------------------------------> QUARANTINED
   |
   v
CRYPTO_VALIDATED --chain/purpose/signature failure-----------------------> REJECTED
   |
   v
POLICY_VALIDATED --wrong policy or indeterminate qualified status--------> POLICY_HOLD
   |
   v
RETAINED --algorithm or validation-material ageing--> RENEWAL_DUE --> RENEWED

TOKEN_RECEIVED is not success. A dashboard that reports receipt acquisition as validation will produce false assurance during exactly the failures an auditor or incident responder cares about.

Provider strategy that scales

“Call three TSAs for everything” is not an enterprise strategy. It triples failure modes, cost, storage, alert noise, and provider coupling without deciding which risk justifies the redundancy.

Use tiers instead:

Unit tests should use deterministic request and response fixtures. A scheduled integration probe can exercise each contracted provider. Production artifact stamping should run as a separate, observable workflow whose failure does not silently discard the artifact.

Long-term verification is a lifecycle

RFC 3161 was updated by RFC 5816 to support stronger certificate identifiers. That does not remove cryptographic ageing. Hash algorithms weaken, TSA keys are replaced, certificates expire or are revoked, trust-list status changes, and validation software evolves.

RFC 4998 Evidence Record Syntax addresses long-term preservation through archive timestamp chains and renewal. It also states that the certificates, CRLs, or OCSP responses needed to verify timestamps must be preserved and describes renewal before the existing algorithms or timestamp evidence become unsuitable.

A retention policy should therefore define:

1. the algorithm-acceptance policy and review cadence;
2. certificate and revocation material captured at or near issuance;
3. trusted-list snapshots or verifiable service-status references;
4. the renewal trigger and responsible service;
5. how a new archive timestamp covers the earlier evidence;
6. how failed or overdue renewals alert operators;
7. how an independent restore and verification exercise is recorded.

Object Lock or WORM storage prevents ordinary deletion and overwrite. It does not keep cryptography valid. Timestamp renewal preserves a proof chain; it does not repair a missing source artifact or weak provenance.

Compliance use cases without compliance theatre

The mappings below are engineering interpretations. Applicability, control selection, legal effect, and audit sufficiency depend on the organization, jurisdiction, system scope, and engagement.

NIS2 incident-reporting example

NIS2 Article 23 defines a sequence with conditional branches, not a fixed number of packages. After becoming aware of a significant incident, an in-scope entity generally submits the early warning within 24 hours and the incident notification within 72 hours. Article 23(4)(b) shortens the incident-notification deadline to 24 hours when the significant incident affects the provision of trust services. A TSA or other trust service provider must therefore model that branch explicitly rather than reusing the general 72-hour timer. One or more intermediate reports may follow when requested by the CSIRT or competent authority. If the incident is still ongoing when the final report would otherwise be due, the entity submits a progress report at that deadline and the final report within one month after handling the incident. National transposition and sector-specific rules still require jurisdiction-specific review. A simplified evidence tree is:

INC-123/01-early-warning.json
INC-123/02-incident-notification.json
INC-123/03-requested-intermediate-01.json       # zero or more, on request
INC-123/04-final-report.json                    # if no progress branch is needed

# Trust-service-provider branch:
# both 01 and 02 are due within 24 hours when the incident affects trust-service provision

# Or, when the incident is still ongoing at the final-report deadline:
INC-123/04-progress-at-final-deadline.json
INC-123/05-final-after-incident-handled.json

Each package should contain its source-system export manifest, human approval, transmission receipt, and correction history. RFC 3161 receipts can establish that specific bytes existed by the TSA times. Preserve the CSIRT or competent authority’s acknowledgement alongside the timestamped package: the acknowledgement supports delivery, while the timestamp supports existence and integrity of the submitted bytes.

Do not replace delivery evidence with a timestamp. Existence and receipt are different claims.

ISO/IEC 27001 audit example

At quarter end, export the approved Statement of Applicability, risk-treatment plan, access review, vulnerability exception register, and restore-test evidence into a manifest. Timestamp the manifest and store it immutably.

That freezes the audit sample boundary. It does not prove every listed control operated. The auditor still needs source records, sampling logic, ownership, exceptions, and corroboration.

SOC 2 change-control example

For each production release, timestamp a manifest containing:

• Git commit and signed tag;
• artifact digest and SBOM digest;
• required CI gate results;
• approver identity and decision;
• deployment target and change ticket;
• rollback artifact and post-deployment verification.

This makes later substitution detectable. It does not prove the approver reviewed the change competently or that bypass paths were absent during the examination period.

DORA incident example

Timestamp each classification calculation and every submitted version of a major ICT-related incident report. Preserve the facts used to calculate affected clients, service duration, geography, data impact, service criticality, and economic impact under the criteria in Commission Delegated Regulation (EU) 2024/1772.

This supports a review of what management knew and when. The classification method and regulatory thresholds still require separate evidence.

Software release example

Timestamping is especially valuable when attached to a digital signature. The signature identifies the signing key; the timestamp supports the claim that the signature existed while the relevant signing certificate was valid. Preserve the signed artifact, signature, timestamp, certificate chain, revocation evidence, and trust policy as one verification bundle.

Do not timestamp only an unsigned checksum text file and call the release authenticated. Anyone can create a new checksum file for a malicious binary.

Failure modes to test

An acceptance test should deliberately exercise failures, not just collect a successful token.

Procurement and production acceptance checklist

Service identity

• Exact legal provider name, service name, endpoint, policy OIDs, and TSU certificate lifecycle are documented.
• Qualified claims are confirmed against the EU Trusted Lists for the specific service.
• Standard and qualified endpoints cannot be confused by configuration.

Protocol and cryptography

• SHA-256 or a stronger approved imprint algorithm is accepted.
• Nonces are returned correctly.
• Responses include or identify the certificates needed for chain construction.
• The signing certificate has the timestamp-signing purpose required by the validation policy.
• Unexpected algorithms, policies, roots, and response sizes fail closed.

Operations

• Rate limits, timeouts, maintenance windows, support escalation, and service objectives are contractual or documented.
• Requests have idempotent workflow identifiers even though each successful token has a unique TSA serial.
• Provider health is tested separately from application unit tests.
• An outage leaves evidence in a visible pending state rather than silently skipping timestamping.

Preservation

• Raw artifact, request, response, and verification bundle are retained immutably.
• Database and object-store identities are cross-checked by digest.
• Restore and independent verification are rehearsed.
• Renewal occurs before algorithm, certificate, or validation-material expiry makes the proof fragile.

Assurance

• Validation is independent of acquisition.
• Every validation decision records software version, profile, trust material, time, and findings.
• Legal and audit teams approve the intended evidentiary claim; engineering does not infer it from cryptography.

Recommended implementation sequence

1. Define claims. Write down whether each evidence class needs existence proof, authorship, delivery, qualified legal presumption, custody, or long-term preservation.
2. Build deterministic conformance tests. Use fixed RFC 3161 request and response fixtures, including negative cases, without a network dependency.
3. Implement one provider adapter. Keep transport, acquisition, validation, and storage separate.
4. Create the evidence envelope. Preserve raw bytes and controlled trust material before building dashboards.
5. Add a scheduled live probe. Exercise the contracted service at an agreed rate and retain probe evidence separately from business receipts.
6. Add a fallback only after failure semantics work. A fallback that silently changes policy or qualified status is worse than a visible outage.
7. Introduce qualified validation where the claim requires it. Verify trusted-list history and service identity rather than the provider brand.
8. Add risk-tiered dual attestation. Reserve it for evidence where provider or algorithm independence justifies the cost.
9. Implement renewal and restore exercises. Long-term evidence is an operated lifecycle, not a one-time API call.

Final definition

RFC 3161 is a protocol for binding a cryptographic message imprint to a TSA-signed time assertion under an identified policy.

An enterprise timestamping system is the larger control environment that makes that assertion reproducible and defensible: stable artifacts, provenance, request-response correlation, independent validation, service qualification, immutable preservation, custody, monitoring, and cryptographic renewal.

Build the system around the claim you need to defend. The token is one piece of that claim, not the whole case.

References

1. IETF RFC 3161 — Internet X.509 Public Key Infrastructure Time-Stamp Protocol
2. IETF RFC 5816 — ESSCertIDv2 Update for RFC 3161
3. IETF RFC 4998 — Evidence Record Syntax
4. IETF RFC 8785 — JSON Canonicalization Scheme
5. OpenSSL — openssl ts documentation
6. ETSI EN 319 421 V1.3.1 — Policy and Security Requirements for Trust Service Providers Issuing Time-Stamps
7. ETSI EN 319 422 V1.1.1 — Time-stamping Protocol and Time-stamp Token Profiles
8. Regulation (EU) No 910/2014, consolidated 18 October 2024
9. Commission Implementing Regulation (EU) 2025/1929 — Standards and specifications for qualified electronic time stamps
10. European Commission — EU Trusted Lists
11. European Commission — EU/EEA Trusted List Browser
12. Directive (EU) 2022/2555 — NIS2
13. Regulation (EU) 2022/2554 — DORA
14. Commission Delegated Regulation (EU) 2024/1772 — DORA incident-classification criteria and materiality thresholds
15. ISO/IEC 27001:2022 — Information security management systems
16. AICPA — 2017 Trust Services Criteria with revised points of focus 2022
17. Regulation (EU) 2016/679 — GDPR, Article 5 and Recital 26
18. EDPB — Anonymisation and pseudonymisation topic portal
19. curl — Command-line option documentation
20. curl — Published vulnerabilities affecting version 8.4.0
21. curl — Known risks, including visible command-line arguments and untrusted URLs
22. DigiCert — RFC 3161 service note
23. DigiCert — Legal repository
24. DigiCert Europe — Legal repository and current Time-Stamp Policy/Practice Statement
25. Sectigo — Time Stamp Server and Stamping Protocols
26. Sectigo — Document Signing CP/CPS, version 1.0.6
27. Sectigo — eIDAS qualified TSA Policy and Practice Statement, version 1.1.4
28. FNMT-RCM — Qualified Time-Stamping Policy and Practices, version 1.8
29. FNMT-RCM — Qualified Time-Stamping policies, certificates, and terms
30. InfoCert — Qualified timestamp API documentation
31. InfoCert — Time Validation Services general terms, version 2.4
32. InfoCert — Timestamp policy
33. NIST — AI Risk Management Framework