TSA & eIDAS Qualified Timestamps

ANKASecure obtains RFC 3161 time-stamp tokens from an external Time-Stamping Authority (TSA) chosen by the deployment, binds each one to the signature it protects, and embeds it in the signed output. This document maps that capability to the eIDAS framework for qualified electronic time stamps and the underlying standards (RFC 3161, RFC 5816, and JAdES / ETSI TS 119 182-1).

Scope. ANKASecure is a time-stamping client: the TSA issues the token; ANKASecure requests, validates, embeds and reports it. When the TSA is a qualified trust service provider operating a qualified time-stamping unit, the embedded token is a qualified electronic time stamp — the qualification comes from the provider that signs it.

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.
• Self-contained evidence — the DER-encoded TimeStampToken is a durable artifact that any RFC 3161-aware verifier can check independently of ANKASecure.

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 Reporting

On verification, ANKASecure extracts any embedded sigTst and judges it against the signature it is presented with. The checks run in a fixed order and the first one that fails decides the reported trustStatus:

1. The token's own CMS signature verifies, and its ESSCertID / ESSCertIDv2 identifier names the certificate that verified it — nothing in the token is relied on before this.
2. The token's message imprint is the digest of the presented signature value, recomputed with the hash algorithm the token itself declares.
3. The TSA certificate is judged as it stood at the token's genTime, in this order: the critical id-kp-timeStamping extended key usage as the signer's sole purpose; the signer's validity at genTime (EXPIRED otherwise); a configured trust anchor and a certificate path ending at it, every certificate of which was valid at genTime; and, when the deployment checks revocation (the default), revocation from CRLs as RFC 3161 §4 defines it — a revocation for key compromise, or without a reason code, invalidates the token; a routine revocation after genTime does not.

The token's generation time, serial number and policy OID are reported only when the token is authenticated and covers the presented signature. A token's time is compared with the platform clock once, when the TSA's reply is received at signing; a stamp that was timely then verifies VALID however long ago it was issued.

Verification 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. When the CRL covering a certificate of the path is not cached, it is fetched from that certificate's distribution point.

The timestamp verdict is orthogonal to the signature verdict. A timestamp that is not VALID is reported for the caller's awareness but never flips the underlying signature's validity — a 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; see TSA Trust Anchor Management^*.
• Choose the imprint hash — TSA_HASH_ALGORITHM accepts SHA-256 (default), SHA-384 and SHA-512 and must be one the TSA supports. Where resistance to quantum-assisted attacks is required, ECCG Agreed Cryptographic Mechanisms v2.0, section 2.3, Note 4-QuantumThreat, states that "it is recommended to not use hash functions with output length smaller than 384 bits".
• Retain the token — preserve the signed output carrying the TimeStampToken; 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 Timestamping (TSA) — Configuration^*.

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.