Preservation profile pds-wst-v1

Written to ETSI TS 119 511 V1.2.1 (2025-10) §6.4. Once published, this text does not change (OVR-6.4-13): changes go into the evidence policy or the signature validation policy, or into a new profile.

Description

The subscriber keeps its signed files. TrustBeat preserves the signatures in them, the validation data needed to validate those signatures later, and the digests that bind each signature to the data it signs. The signed file itself is never sent to TrustBeat.

• Submission without the file. The subscriber runs TrustBeat's extractor (trustbeat-signature), a program on its own computer. The extractor reads a signed file, takes out each signature, computes the digests of the signed data and of the whole file, checks that the signatures cover the data they claim to cover, and sends only that (the submission) to TrustBeat. TS 119 511 allows a detached signature with only a hash of the signed data (OVR-9.3-05). The extractor is open source (MIT) and published, with its releases, at https://github.com/TrustBeat/trustbeat-signature; how to obtain and check it is in the practice statement.
• Checks by TrustBeat. TrustBeat re-derives, from inside each signature, the digests the submission declares and rejects the submission if they differ. It validates each signature with EU DSS under the signature validation policy, collects the certificates, OCSP responses and CRLs needed to validate it (OVR-9.3-01) and records the result as found on the day. A signature is preserved whatever the result: the record says what the validation found, it does not decide whether a signature is acceptable.
• Preservation Evidence Object (PEO). All of it — the signatures byte for byte, the declared digests, the validation data, the validation result, and references to the EU Trusted Lists in force — goes into one canonical JSON document per submission, the PEO. TrustBeat stores the PEO.
• Evidence. The PEO's SHA-256 digest is time-stamped in the same way as a document anchor: combined with other digests of the same 10-minute cycle in an RFC 4998 hash tree whose root is time-stamped by an EU qualified time-stamping authority. The resulting RFC 4998 evidence record proves that the PEO, and so each signature and its validation data, existed at that time and has not changed since.
• What is proven about the signed data. The evidence covers the signatures and the digests of the signed data, not the data. It extends to the signed data only while the hash algorithms of the signatures and of the declared digests stay collision-resistant, and only for the data the subscriber kept. The digests are computed by the extractor on the subscriber's side: TrustBeat cannot check that they were computed from the real file (OVR-9.3-07, 6.2-08).
• Preservation period. 30 years from submission, on every plan. A subscriber agreement may set a different period. Time-stamp renewal keeps the evidence verifiable for the whole period.
• Renewal (augmentation). As for document anchors: RFC 4998 time-stamp renewal (§5.2) before the last time-stamp stops being verifiable. Because TrustBeat holds the PEO, it can also renew the hash tree (§5.3) by re-hashing the PEO with a stronger algorithm; the PEO already carries SHA-512 and SHA3-512 digests of the signed file for that case. When and how: evidence policy §4 and §8 (OVR-6.5-07).
• Missing validation data (OVR-6.2-06). If some validation data cannot be obtained (for example an OCSP responder does not answer), the signatures are preserved anyway and the PEO lists what is missing. The submission is not refused.
• End of the preservation period. As for document anchors: TrustBeat notifies the subscriber and makes the record's package available; 30 days later it deletes the PEO, the record's metadata and its link to the subscriber, and stops serving its evidence. Renewal stops at the end of the period (OVR-6.1-09). Before that, the subscriber can delete a record at any time (below).

Accepted signatures (OVR-6.4-04 b, OVR-9.3-06, OVR-9.3-08)

Not accepted in this profile (the extractor refuses the file and says why): JAdES; files without a signature; signed data that no longer gives the digest inside its signature; detached signatures or containers whose signed data is missing; XML with a DOCTYPE, XML transforms other than enveloped-signature, C14N 1.0 / 1.1 / exclusive, base64 and the XPath patterns that remove signatures; encrypted PDFs; signers without signed attributes. A PDF changed after its last signature is accepted: the record states which signatures do not cover the whole file. One submission per signed file, with at most 100 signatures, 100 time-stamps and 10 000 data objects.

Hash functions of the declared digests (OVR-9.3-06). Every file and data object: SHA-256, SHA-512 and SHA3-512, all three, hexadecimal. The digests inside a signature use whatever algorithm the signature uses, as long as the signature validation policy can process it. TrustBeat checks every digest's identifier and length (OVR-9.3-08) and treats the declared digests as general data (OVR-9.3-07).

A file signed again later is a different file. A record covers the signatures the file had when it was submitted. If the file is signed again afterwards, preserve it again after its last signature.

Supported operations (OVR-6.4-04 b, PRP-8.1)

TrustBeat uses its own REST API, documented at https://api.trustbeat.eu/docs, rather than the TS 119 512 protocol (PRP-8.1-02 is a recommendation).

Export-import package (§7.16). GET /v1/signature-preservation/{id}/package, one per record: a ZIP with the PEO exactly as stored, every preserved signature, ASiCManifest and time-stamp in its native format, the certificates, OCSP responses and CRLs, the RFC 4998 evidence record once ready, the signed EU Trusted Lists the PEO refers to, a manifest.json with the SHA-256 of every file, and a README.txt with the verification steps. Format and verification: practice statement §5.

Verification without TrustBeat. The package and the original file can be verified offline with the extractor (trustbeat-signature verify <file> --package <zip>) or with standard tools, step by step (practice statement §2.3).