Signature validation policy, version 1

Written to ETSI TS 119 511 V1.2.1 (2025-10) §6.6, for profile pds-wst-v1. Human-readable (OVR-6.6-01). Like the evidence policy, it may change; every version stays public and states the period it applied to.

1. Purpose: record, never judge

TrustBeat validates each submitted signature to collect its validation data and to record what the validation found on the day. The result does not decide whether a signature is preserved: every signature the validator can parse is preserved, with its result (profile, Accepted signatures). Whether a signature is acceptable for a given purpose is for the subscriber and the relying party to decide.

What is recorded per signature, in the Preservation Evidence Object (PEO):

• the validator's indication (TOTAL_PASSED, INDETERMINATE, TOTAL_FAILED) and sub-indication, as defined in ETSI EN 319 102-1;
• the signature level found (for example PAdES-BASELINE-LT, XAdES-BASELINE-B);
• the qualification under eIDAS (for example QESig, QESeal, AdESig-QC, AdES), as defined in ETSI TS 119 172-4, and the signing certificate's qualification at issuance and at signing time;
• the signer certificate (subject, issuer, serial number, SHA-256, validity), the claimed signing time, and every time-stamp found (type, time, issuer, integrity);
• the countries of the trust services the certificate chain reaches;
• the validation data used (§4) and what could not be obtained (§5);
• the validator, its version and this policy, and the validation time.

2. Validator and constraints (OVR-6.6-03)

A change of validator version, constraints or model for new submissions is a new version of this policy, published before it applies. Records keep the policy version and validator version they were made with.

3. Trust anchors (OVR-6.6-03)

• EU List of Trusted Lists (LOTL) at https://ec.europa.eu/tools/lotl/eu-lotl.xml, accepted only if its signature verifies against the LOTL signing certificates published in the Official Journal of the EU. If it does not, no Trusted List is used until a LOTL that verifies is loaded: signatures validated meanwhile reach no trust anchor and are recorded so.
• Through the LOTL, the national Trusted Lists of the EU and EEA Member States. The signature of each is checked against the certificates the LOTL lists for it. A national list whose signature does not verify is still used, as EU DSS does by default; the validator reports the failed list signature as a warning, and TrustBeat logs it. The PEO names each list version used (below), and TrustBeat keeps its signed copy, so whether that list's signature verified can be checked at any later time.
• The lists are refreshed every hour; the PEO says which versions were in force.
• No other trust anchors. A certificate that does not chain to a service on an EU Trusted List is validated as far as possible and recorded as not reaching a trust anchor (INDETERMINATE / NO_CERTIFICATE_CHAIN_FOUND). Such signatures are preserved too; their record says so.
• The PEO names each Trusted List version in force (territory, sequence number, issue time, SHA-256 of the signed list), and TrustBeat keeps a signed copy of each such version for the preservation period, so the trust status on the day can be shown after the live lists have changed.

4. Validation data (OVR-9.3-01, 9.3-02)

TrustBeat collects the validation data itself:

1. Certificates, OCSP responses and CRLs already inside the signature are used and kept.
2. Missing certificates of the chain are fetched from the certificates' CA Issuers (AIA) addresses.
3. Revocation status of each certificate is fetched online from the OCSP responder or CRL distribution point the certificate names, at the validation time (a fresh response, preferring OCSP).
4. Every certificate, OCSP response and CRL used is stored in the PEO in its original encoding.

Validation data submitted by the subscriber is accepted only as part of the signature (inside the CMS or XAdES structure, or in the ASiC container); it is validated like any other.

Network limits: 5 seconds to connect, 15 seconds for a response. A source that does not answer in time counts as unavailable (§5).

5. When validation data cannot be obtained (OVR-6.2-06)

The signature is preserved anyway, and the PEO lists what is missing (for example "no revocation data for certificate …"). The submission is not refused, so that a temporary outage of a responder does not prevent preservation. A signature whose validation data is incomplete will usually show INDETERMINATE; its record cannot be completed later — the subscriber can submit the file again to obtain a new record with the data available then.

6. Signatures the validator cannot judge without the signed data

TrustBeat never receives the signed data, only its digests. For CAdES, PAdES and ASiC this gives the same result as validating the whole file (the digests are what the signature covers). For XAdES enveloped and enveloping signatures it does not: their references point into content TrustBeat does not hold, so EU DSS cannot confirm them. For those signatures:

• the validator's overall verdict is recorded but marked not applicable (verdict_applicable: false);
• TrustBeat verifies the SignatureValue over the canonical SignedInfo itself, with the certificate in KeyInfo, and records the result (valid, invalid, not-checked);
• the signing certificate is validated on its own at the best known signing time, so its chain, revocation status and qualification are still recorded;
• that the content gives the reference digests was checked by the extractor only, and is recorded so (checked_by: extractor).

7. Checks that only the extractor can make

The digests of the signed file and of each signed data object, and that the data produces the digests the signatures cover (PDF byte range, XML references after their transforms, ASiC data files), are computed by the extractor on the subscriber's side. TrustBeat checks that every declared binding digest equals the one inside the signature, but cannot check that the data produces it. The PEO marks these facts checked_by: extractor; anyone holding the file can re-check them (practice statement §2.3, steps 1–2).

8. Validation at a later date

POST /v1/signature-preservation/{id}/verify runs the same validator offline at the original validation time, with only what the PEO holds — its certificates, OCSP responses and CRLs, and the Trusted List versions it names — and reports each result beside the one recorded at preservation. A relying party can do the same with any EN 319 102-1 validator from the export-import package.