{"id":"evidence-policy-v1","title":"Preservation evidence policy","version":1,"status":"in_force","in_force_from":"2026-10-11","url":"https://trustbeat.eu/preservation/evidence-policy","markdown":"# Preservation evidence policy, version 1\n\nWritten to ETSI TS 119 511 V1.1.1 §6.5, for profile [`pgd-wst-v1`](profile-pgd-wst-v1.md). Unlike the\nprofile, this policy may change; every version stays public and states the period it applied to\n(OVR-6.4-14).\n\n| | |\n|---|---|\n| **Identifier** | `https://trustbeat.eu/preservation/evidence-policy`, version 1 |\n| **Applies to** | Profile `https://trustbeat.eu/preservation/profile/pgd-wst-v1` |\n| **In force** | From **2026-09-14**, the day TrustBeat began creating RFC 4998 evidence records, until replaced by version 2. It covers records created before the profile was published (see the profile's *Scope*). |\n| **Language** | English. A translation, if any, is informative; the English text takes precedence (OVR-6.5-02). |\n\n## 1. How evidence is created (OVR-6.5-03)\n\n1. **Input.** The subscriber submits the SHA-256 hash of its data (`POST /v1/anchor`). TrustBeat\n never receives the data. The hash is checked to be 64 hexadecimal characters.\n2. **Batching.** Hashes are collected and processed in batches at fixed 10-minute boundaries (UTC).\n3. **Hash tree.** For each batch, the set of distinct submitted hashes is the leaf set of an RFC 4998\n hash tree (SHA-256; values in a node sorted as unsigned byte strings; no leaf or node prefixes).\n4. **Time-stamp.** The tree root is time-stamped with an RFC 3161 time-stamp token from a time-stamping\n authority listed in §3. The token is stored exactly as issued and never modified.\n5. **Validation data.** For batches time-stamped **from 2026-09-19**, TrustBeat then fetches the TSA's\n issuer certificate and an OCSP response (or a CRL) for the TSA's signing certificate. It keeps a\n **copy** of the token with that data added to the token's *unsigned* CMS fields (`certificates`,\n `crls`). The signature and the time-stamp information are unchanged, and the copy is verified to\n carry the same `TSTInfo` and a valid signature. If the data cannot be obtained, records are built\n from the token as issued. Batches time-stamped 2026-09-14 to 2026-09-18 have no such copy.\n **From 11 October 2026** the copy follows the BSI TR-ESOR Basic-ERS-Profile v1.3 (A3.4-2,\n A3.4-7): the complete certificate path up to and including the root — via each certificate's CA\n Issuers URL, or, where a certificate names none, the issuer certificate listed in the EU Trusted Lists\n whose key verifies its signature — and OCSP responses as `BasicOCSPResponse` under\n `id-pkix-ocsp-basic`. Copies made before keep their bytes (full `OCSPResponse` under\n `id-ri-ocsp-response`; EuroCert time-stamps without any copy).\n6. **Evidence record.** For each submitted hash, the RFC 4998 evidence record is built from the stored\n leaf set and the stored token (or its copy): one ArchiveTimeStamp holding the hash's reduced hash\n tree and the token. The record is checked to contain the hash before it is returned. Once served,\n a record's bytes do not change until it is renewed (§4).\n\nThe batch's separate RFC 6962 Merkle tree and its own time-stamp (the \"inclusion proof\") are an\nadditional output, not preservation evidence under this policy.\n\n## 2. Cryptographic algorithms (OVR-6.5-03, 6.5-04)\n\n| Use | Algorithm | Assessment |\n|---|---|---|\n| Submitted hash; hash tree; time-stamp message imprint | SHA-256 | Recommended by ETSI TS 119 312; no end date at the time of writing |\n| TSA signature | As issued by each TSA and stated in its token (§3). At the time of writing: SK ID Solutions ECDSA P-256 with SHA-512; EuroCert RSA 4096 with SHA-256 | Assessed against TS 119 312 at each policy review |\n\nTrustBeat reviews these choices against the current ETSI TS 119 312 and national recommendations at\nleast yearly, and within 30 days of every new version, following its cryptographic monitoring\nprocedure. A change of algorithm for newly created evidence is a new version of this\npolicy.\n\n## 3. Trust service providers used (OVR-6.5-05)\n\n| Role | Provider | Since |\n|---|---|---|\n| Time-stamping authority, primary | SK ID Solutions AS (Estonia), EU qualified TSA; on the Estonian Trusted List as *\"SK Time-Stamping Authority for qualified electronic time stamps\"* | Primary for anchoring since 2026-07-01 |\n| Time-stamping authority, fallback | EuroCert Sp. z o.o. (Poland), EU qualified TSA; on the Polish Trusted List as *\"Time Stamping Authority\"* | Used when the primary is unavailable |\n| Certificate status | The OCSP responders and CRL distribution points named in the TSAs' certificates | — |\n\nThe names above are those of the Trusted List entries (checked 2026-10-11). Every token names the TSA\nthat issued it, so the TSA of any record can be read from the record itself.\n\n## 4. How evidence is renewed (OVR-6.5-07, TS 119 511 §7.15)\n\n- **Time-stamp renewal (RFC 4998 §5.2).** Before the last time-stamp in a record stops being\n verifiable, TrustBeat adds a new one. The trigger is the earlier of: **90 days** before the TSA\n signing certificate in that time-stamp expires, or a TS 119 312 assessment that the TSA's signature\n algorithm or key size is weakening. One new time-stamp covers many batches: its hash tree has one leaf\n per batch (the hash of the batch's last time-stamp token), and each record gets a new ArchiveTimeStamp\n in its existing chain. The renewal time-stamp comes from a TSA in §3, and its certificate must itself\n remain valid beyond the 90-day window. Its validation data is attached to a copy of the token as in\n §1 step 5, and a renewed record is served only once that is settled.\n- **Hash-tree renewal (RFC 4998 §5.3)** re-hashes the preserved data with a stronger algorithm. TrustBeat\n holds only the subscriber's SHA-256 hash, not the data, so it cannot do this alone. Version 1 offers\n no hash-tree renewal. Should SHA-256 weaken, TrustBeat will notify subscribers, and a later version\n may accept new hash values from them, under the conditions of OVR-6.2-07.\n- Each renewal is logged with its date, the TSA used and the batches covered.\n\n## 5. How evidence can be validated (OVR-6.5-06)\n\nAn evidence record can be validated by any RFC 4998 implementation, without TrustBeat software, for\nexample EU DSS (the library behind the European Commission's DSS Demonstration WebApp):\n\n1. Compute the SHA-256 of the data and check that it is the record's data object.\n2. Recompute each ArchiveTimeStamp's hash tree root from its reduced hash tree and check it against the\n message imprint of its time-stamp. For each later time-stamp in a chain, the covered value is the\n hash of the previous time-stamp token.\n3. Validate each time-stamp token's signature and its signing certificate's path, using the validation\n data inside the record where present.\n\n**Trust anchors (OVR-6.5-06):**\n- **Time-stamps:** the TSAs' certificates as listed in the EU Member States' Trusted Lists, reached via\n the EU List of Trusted Lists, whose signing certificates are published in the Official Journal of the\n EU. TrustBeat keeps signed copies of each version of these lists in force on or after 11 October 2026, so\n a TSA's qualified status on a past date can be shown after the live lists have changed.\n- **Digital signatures:** none. The evidence contains no signature by TrustBeat.\n\n## 6. Format of the evidence (OVR-6.5-08)\n\nRFC 4998 `EvidenceRecord`, DER encoded: version 1; `digestAlgorithms` = SHA-256; no `cryptoInfos`, no\n`encryptionInfo`; one `ArchiveTimeStampChain` per algorithm period; the time-stamp in each\n`ArchiveTimeStamp` is an RFC 3161 token (RFC 5816 where the TSA issues it). Served at\n`GET /v1/public/proof/{id}/evidence-record.ers`.\n\n## 7. Information inside the evidence (OVR-6.5-09, 9.2-04)\n\nThe evidence record contains **no** explicit reference to the preservation service, this policy or the\nprofile. They are identified from context: the record is obtained from TrustBeat's API for a\nsubmission made under profile `pgd-wst-v1`, and the profile references this policy. The policy\nidentifier in each time-stamp token is the TSA's own, not TrustBeat's.\n","html":"

Preservation evidence policy, version 1

\n

Written to ETSI TS 119 511 V1.1.1 §6.5, for profile pgd-wst-v1. Unlike the\nprofile, this policy may change; every version stays public and states the period it applied to\n(OVR-6.4-14).

\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
Identifierhttps://trustbeat.eu/preservation/evidence-policy, version 1
Applies toProfile https://trustbeat.eu/preservation/profile/pgd-wst-v1
In forceFrom 2026-09-14, the day TrustBeat began creating RFC 4998 evidence records, until replaced by version 2. It covers records created before the profile was published (see the profile's Scope).
LanguageEnglish. A translation, if any, is informative; the English text takes precedence (OVR-6.5-02).
\n

1. How evidence is created (OVR-6.5-03)

\n
    \n
  1. Input. The subscriber submits the SHA-256 hash of its data (POST /v1/anchor). TrustBeat\nnever receives the data. The hash is checked to be 64 hexadecimal characters.
    2. \n
  2. Batching. Hashes are collected and processed in batches at fixed 10-minute boundaries (UTC).
    3. \n
  3. Hash tree. For each batch, the set of distinct submitted hashes is the leaf set of an RFC 4998\nhash tree (SHA-256; values in a node sorted as unsigned byte strings; no leaf or node prefixes).
    4. \n
  4. Time-stamp. The tree root is time-stamped with an RFC 3161 time-stamp token from a time-stamping\nauthority listed in §3. The token is stored exactly as issued and never modified.
    5. \n
  5. Validation data. For batches time-stamped from 2026-09-19, TrustBeat then fetches the TSA's\nissuer certificate and an OCSP response (or a CRL) for the TSA's signing certificate. It keeps a\ncopy of the token with that data added to the token's unsigned CMS fields (certificates,\ncrls). The signature and the time-stamp information are unchanged, and the copy is verified to\ncarry the same TSTInfo and a valid signature. If the data cannot be obtained, records are built\nfrom the token as issued. Batches time-stamped 2026-09-14 to 2026-09-18 have no such copy.\nFrom 11 October 2026 the copy follows the BSI TR-ESOR Basic-ERS-Profile v1.3 (A3.4-2,\nA3.4-7): the complete certificate path up to and including the root — via each certificate's CA\nIssuers URL, or, where a certificate names none, the issuer certificate listed in the EU Trusted Lists\nwhose key verifies its signature — and OCSP responses as BasicOCSPResponse under\nid-pkix-ocsp-basic. Copies made before keep their bytes (full OCSPResponse under\nid-ri-ocsp-response; EuroCert time-stamps without any copy).
    6. \n
  6. Evidence record. For each submitted hash, the RFC 4998 evidence record is built from the stored\nleaf set and the stored token (or its copy): one ArchiveTimeStamp holding the hash's reduced hash\ntree and the token. The record is checked to contain the hash before it is returned. Once served,\na record's bytes do not change until it is renewed (§4).
    7. \n
\n

The batch's separate RFC 6962 Merkle tree and its own time-stamp (the "inclusion proof") are an\nadditional output, not preservation evidence under this policy.

\n

2. Cryptographic algorithms (OVR-6.5-03, 6.5-04)

\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
UseAlgorithmAssessment
Submitted hash; hash tree; time-stamp message imprintSHA-256Recommended by ETSI TS 119 312; no end date at the time of writing
TSA signatureAs issued by each TSA and stated in its token (§3). At the time of writing: SK ID Solutions ECDSA P-256 with SHA-512; EuroCert RSA 4096 with SHA-256Assessed against TS 119 312 at each policy review
\n

TrustBeat reviews these choices against the current ETSI TS 119 312 and national recommendations at\nleast yearly, and within 30 days of every new version, following its cryptographic monitoring\nprocedure. A change of algorithm for newly created evidence is a new version of this\npolicy.

\n

3. Trust service providers used (OVR-6.5-05)

\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
RoleProviderSince
Time-stamping authority, primarySK ID Solutions AS (Estonia), EU qualified TSA; on the Estonian Trusted List as "SK Time-Stamping Authority for qualified electronic time stamps"Primary for anchoring since 2026-07-01
Time-stamping authority, fallbackEuroCert Sp. z o.o. (Poland), EU qualified TSA; on the Polish Trusted List as "Time Stamping Authority"Used when the primary is unavailable
Certificate statusThe OCSP responders and CRL distribution points named in the TSAs' certificates—
\n

The names above are those of the Trusted List entries (checked 2026-10-11). Every token names the TSA\nthat issued it, so the TSA of any record can be read from the record itself.

\n

4. How evidence is renewed (OVR-6.5-07, TS 119 511 §7.15)

\n\n

5. How evidence can be validated (OVR-6.5-06)

\n

An evidence record can be validated by any RFC 4998 implementation, without TrustBeat software, for\nexample EU DSS (the library behind the European Commission's DSS Demonstration WebApp):

\n
    \n
  1. Compute the SHA-256 of the data and check that it is the record's data object.
    2. \n
  2. Recompute each ArchiveTimeStamp's hash tree root from its reduced hash tree and check it against the\nmessage imprint of its time-stamp. For each later time-stamp in a chain, the covered value is the\nhash of the previous time-stamp token.
    3. \n
  3. Validate each time-stamp token's signature and its signing certificate's path, using the validation\ndata inside the record where present.
    4. \n
\n

Trust anchors (OVR-6.5-06):

\n\n

6. Format of the evidence (OVR-6.5-08)

\n

RFC 4998 EvidenceRecord, DER encoded: version 1; digestAlgorithms = SHA-256; no cryptoInfos, no\nencryptionInfo; one ArchiveTimeStampChain per algorithm period; the time-stamp in each\nArchiveTimeStamp is an RFC 3161 token (RFC 5816 where the TSA issues it). Served at\nGET /v1/public/proof/{id}/evidence-record.ers.

\n

7. Information inside the evidence (OVR-6.5-09, 9.2-04)

\n

The evidence record contains no explicit reference to the preservation service, this policy or the\nprofile. They are identified from context: the record is obtained from TrustBeat's API for a\nsubmission made under profile pgd-wst-v1, and the profile references this policy. The policy\nidentifier in each time-stamp token is the TSA's own, not TrustBeat's.

\n"}