TSA & eIDAS Qualified Timestamps

ANKASecure can embed qualified, independently-verifiable timestamps into the signatures it produces by contacting an external RFC 3161 Time-Stamping Authority (TSA). This document maps that capability to the eIDAS framework for Qualified Electronic Timestamps and the underlying international standards (RFC 3161, RFC 5816, and JAdES / ETSI TS 119 182-1).

Scope. This page describes the standards ALIGNMENT of the timestamp evidence artifact. The qualified status of a specific timestamp ultimately depends on the external TSA the deployment configures — ANKASecure produces standards-conformant tokens and embeds them correctly; the TSA that signs them must itself be a Qualified Trust Service Provider for the result to be a qualified timestamp under eIDAS.

Standards Mapping

What a Qualified Timestamp Provides

Under eIDAS Article 41, a qualified electronic timestamp benefits from a presumption of the accuracy of the date and time it indicates and of the integrity of the data to which they are bound. The ANKASecure implementation delivers the technical foundation for that presumption:

• Independent authority — the time assertion is made and signed by an external TSA, not by ANKASecure. The signer of the data and the asserter of the time are separated.
• Cryptographic binding — the timestamp is issued over the message imprint of the produced signature, so it is bound to that exact signature.
• Long-term evidence — the DER-encoded TimeStampToken is a durable, self-contained artifact that can be verified independently, later, by any RFC 3161-aware verifier.

Evidence Format — JAdES sigTst

When timestamping is active for a signing operation, ANKASecure emits a flattened JWS JSON Serialization and carries the RFC 3161 TimeStampToken in the unprotected header as a JAdES signature timestamp (sigTst, under the etsiU unsigned-properties array, ETSI TS 119 182-1). The original signature is not re-computed — the qualified timestamp is added over the existing signature.

When timestamping is not active, the output remains a standard compact JWS, byte-identical to a non-timestamped signature. This preserves full backward compatibility: enabling the feature never changes the format of signatures that are not timestamped.

Whether a signature is timestamped is backend-authoritative — decided per tenant by the deployment ceiling/floor usage policy, with no per-request client flag (see the internal architecture document referenced below).

Verification & Long-Term Validation

On verification, ANKASecure extracts any embedded sigTst, validates the TSA certificate chain against the DB-backed, Redis-projected, console-managed trust anchor set (§66; the retired disk PKCS12 store no longer exists), checks revocation via a cached CRL (OCSP is not used), and confirms the generation-time coherence — then reports the qualified-timestamp outcome (VALID, UNTRUSTED, REVOKED, EXPIRED, or TIME_ANOMALY) alongside the signature result. Verification is entirely offline (it never contacts the TSA) and is never gated by the usage policy — the trust store is decoupled from usage, so disabling timestamping never breaks verification of already-issued stamps.

The timestamp verdict is orthogonal to the signature verdict. A corrupt, untrusted, revoked, or time-anomalous timestamp is reported for the caller's awareness but never flips the underlying signature's validity — a still-cryptographically-valid signature remains valid even if its embedded timestamp is not trustworthy, and vice versa.

Governance & Deployment Considerations

Achieving qualified status for production signatures requires operational choices beyond the platform:

• Choose a Qualified TSA — configure TSA_ENDPOINT_URL to a TSA operated by a Qualified Trust Service Provider on your national eIDAS Trusted List.
• Enforce usage where required — set the deployment TSA usage policy to REQUIRED (the absolute floor — every tenant MUST stamp), or, under an OPTIONAL ceiling, set the per-tenant level to ON, so that every signature MUST carry a qualified timestamp and a TSA outage fails closed rather than silently producing an unstamped signature.
• Maintain the trust anchors — keep the TSA trust anchors current from the admin console's Trust Anchors tab (upload the new CA cert alongside the current one, then retire the old one), using the rotation-overlap window when the TSA rotates its issuing certificate. Anchors are DB-backed and propagate cluster-wide with no node access or redeploy (§66); see TSA Trust Anchor Management^*.
• Retain the token — preserve the embedded TimeStampToken as part of the long-term evidence record; it is independently verifiable without ANKASecure.

The connection parameters, the ceiling/floor deployment tier (DISABLED / OPTIONAL / REQUIRED) with the reduced per-tenant level (ON / OFF / inherit), the backend-authoritative resolution, and the fail-closed runtime gate are described in the internal TSA RFC 3161 External Time-Stamping — Three-Plane Architecture document (02-architecture/integrations/timestamping-tsa.md).

Path to qualified LTV (backlog — not implemented). Long-Term Validation (LTV — JAdES-LT/-LTA embedding of the certificate chain and revocation data at signing time) and OCSP revocation are on the backlog. The current implementation embeds the RFC 3161 sigTst and validates revocation with cached CRLs only. LTV is the technical path toward long-term preservation of a qualified-timestamp's validity beyond the TSA certificate's lifetime; OCSP was evaluated and discarded in favour of CRL caching.

Business Value

• eIDAS readiness — a standards-conformant path to qualified electronic timestamps for EU-regulated signing workflows, without custom integration code.
• Regulatory flexibility — timestamping is opt-in per tenant and per deployment; a single platform serves both timestamp-mandated and timestamp-exempt workloads simultaneously.
• Independent auditability — every qualified timestamp is a self-contained artifact verifiable by any RFC 3161 tool, decoupled from the ANKASecure platform for long-term archival.
• Future-proof evidence — RFC 3161 + RFC 5816 + JAdES is the same evidence chain used by ETSI advanced/qualified signature formats, aligning with long-term signature preservation profiles.