Validation service practice statement

1. Provider

The service is provided by Edström Business AB, Swedish organisation number 559101-7750. Contact: contact@tindom.se. Responsible for this documentation: Ludvig Edström.

2. Service policy and validation policy

• Service policy: this practice statement together with our terms of use. We do not use ETSI’s service policy identifiers (0.4.0.19441.1.1 and 0.4.0.19441.1.2): they require conformance to all normative requirements of ETSI TS 119 441, including the organisational requirements of ETSI EN 319 401, which we do not yet meet (see section 5).
• Validation policy: "Tindom validation policy 1.0 (ETSI TS 119 172-4 aligned)" is the only policy applied. It is the European Commission’s DSS 6.4 default policy ("QES AES/QC AES TL based") with one addition from ETSI TS 119 172-4, REQ-4.2-03 c) ii): revocation information for the signing certificate is only accepted if it was issued after the best signature time. The machine-readable policy is published at tindom-validation-policy-1.0.xml. Users cannot submit a policy of their own.
• We do not yet have an object identifier (OID) of our own for the service policy or the validation policy.

3. Service components

• Validation engine: the European Commission’s Digital Signature Service (DSS) 6.4, the reference implementation of ETSI EN 319 102-1, with Tindom’s configuration. Hosted on Railway, region europe-west4 (Netherlands). The engine is not open to the public: every request must carry a shared key.
• Application: the website and its API are hosted on Vercel, with server functions in region arn1 (Stockholm).
• Email: Lettermint (EU), for the email pilot and report delivery.
• Database: Supabase, region eu-west-1 (Ireland). It holds no documents.
• Trusted lists: the EU List of Trusted Lists (all EU/EEA national lists), the EU list of third-country lists recognised under eIDAS Article 14 (currently Ukraine and Moldova), and the Swiss and UK national lists, refreshed automatically every hour. In addition the Adobe Approved Trust List (AATL), refreshed manually when Adobe publishes a new version.
• Only the EU Member State trusted lists decide whether a signature or seal is qualified (ETSI TS 119 615). The other sources only show that a signer chains to a recognised regime, which we report separately.

4. Validation

• Algorithm: ETSI EN 319 102-1 as implemented in DSS 6.4. All three validation processes are applied: basic, with time, and long-term.
• Output: one status per signature — TOTAL-PASSED, TOTAL-FAILED or INDETERMINATE, with sub-indication — and a validation report. The checks actually performed, and their results, are listed in the report.
• Qualification: whether a signature is a QES, a qualified seal, an advanced signature with a qualified certificate or an advanced signature is determined per ETSI TS 119 615 against the EU Member State trusted lists at the best signature time.
• Hash computation: always performed by Tindom on the server, from the full document. Users cannot submit a hash instead of the document.
• Same input, same output. The engine configuration, policy and list sources are versioned. A result can change when a trusted list or a certificate’s revocation status changes, or when the policy version changes.
• Expired or obsolete elements (expired or revoked certificates, algorithms past their validity) are handled as specified by ETSI EN 319 102-1: a signature can still pass if proofs of existence (time-stamps, embedded validation data) show it was valid when made.
• Proof of existence is taken from the signature only: signature, document and archive time-stamps and embedded validation data. Users cannot supply proofs of their own.
• Formats: PAdES (signed PDF), XAdES, CAdES and JAdES — enveloped, enveloping and detached (the original document can be supplied with the signature) — and ASiC-S and ASiC-E containers. Baseline profiles per ETSI EN 319 142-1, EN 319 132-1, EN 319 122-1 and TS 119 182-1. Signatures that do not follow an ETSI format are still validated, and the deviation is reported.
• User options: the user selects the document and, for detached signatures, the original document. Users cannot select certificates, the validation policy or trust anchors, nor restrict validation to one signature: every signature in the document is validated.

5. Organisation and operation

Tindom is currently run by one person. ETSI EN 319 401 requires, among other things, trusted roles with separation of duties, a documented information security management system, audits by an accredited conformity assessment body and liability cover. These are not in place. What is in place:

• Documents are never stored. A document is held in memory during validation and then discarded. Only its SHA-256 hash is kept, together with the result.
• Personal data: email addresses of people who ask for a report (24 months) and sender details in the email pilot (12 months). See the privacy policy.
• Access: production systems are accessible only to the founder. The validation engine requires a shared key on every request.
• Monitoring: the validation engine is checked every 10 minutes by a real validation of a known test document. A failure opens an incident automatically and notifies the operator.
• Connections: all traffic uses HTTPS/TLS.
• Cryptographic keys: Tindom currently holds no signing or sealing keys. When reports are sealed, the key will be held in a qualified seal creation device operated by a qualified trust service provider.
• Dependencies: the service depends on the European Commission (DSS and the EU trusted lists), the EU/EEA trusted list operators, Adobe (AATL), Railway, Vercel, Supabase and Lettermint. Their availability and practices affect the service, and we do not control them. Certificate authorities can publish revocation information with a delay.

Not yet in place: risk assessment, information security policy, formal access control policy, vulnerability scanning and penetration testing, a documented incident procedure, business continuity and termination plans, and an audit. This statement is a self-assessment.

6. The validation report

• Every validation produces an ETSI TS 119 102-2 validation report (XML), generated by DSS. It includes the validation process used, the status and sub-indication per signature, the constraints evaluated, the signer, the signed attributes, time-stamp qualification and the origin of each proof of existence. It can be downloaded on the web and is attached, unchanged, to every reply in the email pilot.
• In addition, a human-readable PDF report and a Document Trust Grade. The grade is a separate assessment on top of the validation and does not change the ETSI status.
• Not yet in place: the report does not name Tindom as validator in the validator information field, and it is not signed or sealed. Both require Tindom to acquire a qualified electronic seal, which we are working on.

7. Interfaces

• Web: tindom.se/validate — result on screen, downloadable ETSI report, PDF report by email.
• Email: validate@tindom.se for organisations in the pilot programme, report by reply.
• A machine API per ETSI TS 119 442 is planned but not yet available.