Validation Policy

This Validation Policy (VP) describes how Fidelir S.R.L., operating Fidelir Trust Services, validates European, Moldovan and Ukrainian electronic signatures submitted through the public validation service at trust.fidelir.com. It is intended for relying parties, integrators, auditors, and supervisory review.

1. Introduction

1.1 Purpose

The purpose of this policy is to declare, in auditable form: which validation engine is used; how the trust snapshot is taken and used; that CA certificates are not fetched via AIA; how revocation is evaluated; how qualification is classified; what indications and technical details are returned; and what guarantees and limitations apply to relying parties.

1.2 Applicability

This VP applies to all signature validation performed by Fidelir Trust Services through the public validation interface on the trust site. Supported containers include PAdES (PDF), XAdES (XML and embedded profiles), CAdES (CMS, .p7m, .p7s), and ASiC.

1.3 Relying party obligations

Relying parties shall treat validation output as cryptographic and PKI evidence, not as legal advice on document content, contractual effect, or regulatory qualification status. Before acting on a signature, the relying party shall confirm that the signing certificate policy, jurisdiction, and programme scope match the intended use case.

2. Definitions

• AIA — Authority Information Access (RFC 5280). This service uses AIA OCSP URLs for status checking when OCSP is in scope; it does not fetch CA certificates from AIA.
• QES — Technical classification: qualified certificate + QSCD + CA/QC granted, or a national qualified CA. Distinct from LOTL membership.
• AdES — Advanced Electronic Signature (ETSI AdES baseline), including nationally recognised and non-QSCD qualified certificates.
• Adjunct certificate store — Pool of intermediate and service certificates used to build paths; not necessarily trusted anchors.
• CRL — Certificate Revocation List.
• DSS — Digital Signature Services (EU reference validation library).
• EE — End-entity (subscriber signing) certificate.
• LOTL — List Of Trusted Lists (EU central TL index).
• LTA — Archival validation (archive timestamps and evidence records, EN 319 102-1 §5.6).
• LTV — Long-term validation (revocation and proof-of-existence at reference time).
• OCSP — Online Certificate Status Protocol.
• POE — Proof of existence. An intact covering timestamp is POE; claimed or PDF signing time is not.
• QSCD — Qualified signature/seal creation device (from certificate QC statements or recognised QSCD policy OIDs).
• TL — Trusted List (national trust-service list).
• Trust anchor — Self-signed root certificate configured as trusted for path validation.
• Trust snapshot — The last complete, successfully imported set of trust lists and national programme certificates used at validation time.

3. Service provider identification

Legal entity

Fidelir S.R.L.

Commercial designation

Fidelir Trust Services

Validation service URL

https://trust.fidelir.com/

Trust material repository

https://trust.fidelir.com/repository/

Validation engine

EU DSS 6.4

Trust list synchronisation

EU LOTL (automated); Moldova and Ukraine as governed national snapshots, not LOTL members

4. Validation engine

4.0 Declared validation procedure

The following map is the normative process under this VP. JSON API fields are a human-oriented summary; the optional Signature Validation Report is the normative machine-readable report.

4.1 Software

Validation is performed with EU Digital Signature Services (DSS) version 6.4, the reference open-source validation stack maintained under the EU CEF programme:

• Project: github.com/esig/dss
• Version: DSS 6.4 (EU CEF reference stack)

DSS modules in use include dss-validation, dss-pades-pdfbox, dss-xades, and dss-cms-object for format-specific document validators. Validator routing is explicit (PDF → PAdES, XML/XAdES → XAdES, CMS → CAdES) according to document type.

4.2 Validation level and reference time

4.3 Chain building and AIA

Certificate path discovery uses only material already in the trust snapshot, the published repository, or the submitted document (embedded certificates, CMS, PDF /DSS). CA certificates are not fetched from AIA URLs. A chain that cannot be built without downloading an intermediate is reported as untrusted.

AIA is still read for revocation location: when OCSP is in scope, a single OCSP URL from the certificate AIA is contacted. CRL distribution points on the certificate are used when a CRL is required. That is status checking, not path discovery.

4.4 Qualification

Each signature is given a technical qualification label (QES / AdES / not-qualified, with a type such as QESig or AdESig-QC when applicable). It is independent of trustSource: presence on the EU LOTL is membership of a Member State trusted list, not qualified status by itself.

European Union path. When the validation worker has loaded an EU TrustedListsCertificateSource (LOTL and Member State trusted lists, with TrustProperties), qualification is taken from the EU DSS Simple Report — ETSI TS 119 615 determination at AdES best-signature-time (service history and ASI/qualifier conditions as implemented by DSS). The product maps DSS levels (e.g. QESig, AdESig-QC, indeterminate AdES) into the API fields above. Technical check detail includes the marker DSS/TS 119 615.

If DSS returns no qualification conclusion (N/A) — for example the chain is trusted via the governed JDBC snapshot but does not reach a TL identity for qualification — the service falls back to the national/VP heuristic below rather than reporting a blank not-qualified. Until the EU TL source is fully warmed after worker start, the heuristic is used for all signatures.

National path (MD STISC / UA and other national seeds). Classification uses the certificate QC statements and the issuing CA’s service type and status on the governed trust snapshot (heuristic under this VP), not a claim of EU eIDAS QES effect. Service status (non-qualified / not QVR) is stated in the notice above.

5. Trust material — sources and custody

5.1 Overview

Validation uses a governed trust snapshot: the last complete, successfully imported EU LOTL and Member State trusted lists, plus national programme certificates (Moldova, Ukraine TL-UA-EC, Fidelir repository). Two logical stores:

5.2 European Union — LOTL and national trusted lists

Fidelir Trust Services synchronises the EU List Of Trusted Lists and national trusted list XML documents on a regular schedule (default: every 24 hours), using the official EU LOTL publication as the entry point:

• LOTL source: ec.europa.eu/tools/lotl/eu-lotl.xml
• A list is added to the snapshot only after retrieval and signature verification succeed
• Unchanged TL documents are not reprocessed

Validation uses the last complete snapshot. A Trusted List whose NextUpdate has passed is not discarded at validation time for that reason alone. If a later synchronisation fails, the previous complete snapshot remains in force. Newly granted services appear only after the next successful import; withdrawn services remain until that import.

Trust-service certificates from EU Member State TLs are indexed with service metadata (TSP name, service type, status, territory) for path building and the qualification label in Section 4.4.

5.3 Republic of Moldova — national PKI

Moldova is not published in the EU LOTL. Active and historical Moldovan qualified trust service certificates are curated from the official national publication and loaded into the trust store under Fidelir governance:

• Official publication: stisc.gov.md — public key certificates
• Scope: current national roots, issuing CAs, and related qualified signature services
• Updates follow official publication changes and Fidelir trust-material review

5.4 Republic of Moldova — legacy domestic PKI

Historical domestic certificate generations remain required to validate older signatures. Legacy roots and subordinate CAs are curated from the official legacy publication:

• Official publication: pki.sis.md — issued certificates
• Scope: multiple historical root generations and their subordinate CAs
• Expired certificates are retained deliberately for long-term validation of historical documents

5.5 Ukraine — cross-border Trusted List (TL-UA-EC)

Ukraine is not published in the EU LOTL. Fidelir Trust Services loads Ukrainian trust-service certificates from the official Central Certification Authority (ЦЗО) cross-border Trusted List TL-UA-EC and holds them as a governed national snapshot in the trust store. This is a national-programme trust decision for validation, not eIDAS LOTL recognition of Ukrainian QTSPs.

• Official Trusted List page: czo.gov.ua/en/trustedlist
• List used: TL-UA-EC.xml (cross-border / ETSI TL profile)
• Not used: TL-UA.xml and DSTU-only lists — those are outside this VP
• Scope: current granted trust-service certificates published in TL-UA-EC (CA / QC / TSA as listed)
• Refresh: curated snapshot under Fidelir trust-material review when ЦЗО republishes the list; revocation at validation time uses live OCSP/CRL from the certificates

5.6 Fidelir programme repository

The published trust repository exposes Fidelir-operated trust anchors and revocation services. Repository certificates are part of the trust snapshot. This covers the Fidelir Root CA and Issuing CA published under the CP/CPS for Fidelir-operated trust programmes.

5.7 Refresh and audit

After a successful EU TL synchronisation or national snapshot refresh (Moldova STISC / SIS, Ukraine TL-UA-EC, Fidelir repository), the new complete snapshot becomes the trust material for subsequent validations. Failed or incomplete imports do not replace a previous complete snapshot. Fetch and snapshot events are recorded with publication timestamp and document fingerprint for audit. Operational status is available to authorised operators under separate access controls.

6. Revocation and status checking

6.1 Strategy

6.2 Indication overlays

The default outcome is the DSS indication (EN 319 102-1). Fidelir does not promote an EU, Fidelir-programme, or Ukrainian signature to TOTAL-PASSED solely because OCSP was unavailable and a CRL reports GOOD. If status cannot be obtained, the DSS indication stands (typically indeterminate).

Two overlays are applied only after signed content digests match and the chain anchors in the trust snapshot:

• Post-signing revocation with POE (any PKI except STISC CRL-only) — an intact covering timestamp exists, and the signing certificate is shown revoked only after that best-signature-time, with CRL evidence. This is AdES proof-of-existence, not a substitute for a live OCSP responder.
• Republic of Moldova STISC / SIS — online OCSP is not contacted. CRL is the status source. A DSS indeterminate caused solely by CRL freshness or timing may be reported valid when the certificate is not revoked at best-signature-time.

DSS sub-indications that mean the signature is out of bounds, fails cryptographic constraints, or lacks required POE are not rewritten to valid for non-STISC signatures.

6.3 Documented format exception

One format overlay is defined. It applies only to Moldova STISC / SIS XAdES signatures. The same pattern on any other signature remains a DSS failure.

• XAdES DataObjectFormat / ObjectReference — when a local file path is appended to ObjectReference while the signed digest remains correct, validation may pass with WARN technical details explaining the non-standard reference.

7. Validation outcome and technical details

7.1 Per-document response

Each validation returns, per signature:

• Overall and per-signature valid flag and DSS indication
• Signer distinguished name; subject serialNumber (OID 2.5.4.5) and/or organizationIdentifier (OID 2.5.4.97) when present. Exposed as subjectSerialNumber / organizationIdentifier (opaque CA values; not the certificate serial number). Legal-person / eSeal subjects typically carry organizationIdentifier only.
• Issuing authority (CA / TSP) and country
• Best signature time and AdES format (e.g. PAdES-BASELINE-B, XAdES-BASELINE-T)
• Qualification label (QES / AdES / not-qualified) and type where applicable
• Expandable technical validation checks: Integrity, Certificate chain, Format, Qualification, CRL, OCSP, TSA, LTV, LTA, X.509 validation

On request (svr=true), the product interface also returns an ETSI Signature Validation Report XML (signatureValidationReportXml) produced by EU DSS — TS/EN 319 102-2. The report includes a SignatureValidator block identifying Fidelir Trust Services (TSP name, trade name, MD postal address, and contact / policy URIs). When the worker is configured with the Fidelir SVR eSeal PKCS#12, that XML is sealed with XAdES-B-B and isSigned is true (the seal covers the validator block). The seal is an Advanced electronic seal of the report (see Service status). The public UI offers a download of that XML. The SVR is the normative machine-readable report; the on-screen summary is for UX and may include Fidelir policy overlays (Sections 6.2–6.3, document alteration) that are not rewritten into the SVR. STISC national overlays remain UI/policy overlays; the SVR reflects the DSS CMS validation path used for that signature.

Relying parties that require the ETSI TS 119 442 validation-protocol binding shall use POST /api/v1/etsi/validate (VerifyReq / VerifyResp; JSON or XML). That interface always returns an ETSI TS/EN 319 102-2 Signature Validation Report, Base64-encoded in optOutp.validationReport.etsiTS11910202XMLReport, under this policy (VP-1.1), together with per-signature results in optOutp.resForEachSignature when signatures are present. VerifyReq may supply embedded doc, detached sigObj, docHash, transformed, and attRef resolved via an attachments map (no remote fetch). Augmentation of AdES signatures to Baseline T / LT / LTA is available at POST /api/v1/etsi/augment; combined validation-and-augmentation at POST /api/v1/etsi/validate-and-augment. Full bit-identity with Annex A of TS 119 442 is not asserted.

7.2 Technical check semantics

8. Guarantees

Fidelir Trust Services guarantees that, at the time of validation:

1. Validation is performed with the declared DSS version and configuration in this VP.
2. Trust anchors and adjunct material match the governed trust snapshot and published repository at validation time.
3. Revocation and expiry are evaluated against AdES best-signature-time, not claimed signing time.
4. Returned technical details faithfully reflect DSS diagnostic and detailed reports, subject to declared policy overlays in Sections 6.2 and 6.3.
5. Validation logic is reproducible: the same document and trust-store state yield the same outcome.

9. Limitations and non-guarantees

• Submitted documents are processed in memory for the validation request only; Fidelir Trust Services does not store or retain uploaded files after validation completes.
• Validation does not attest to the accuracy, legality, or authenticity of document content.
• Validation does not fetch CA certificates from AIA; missing intermediates are not downloaded.
• Validation does not treat EU LOTL membership as qualified status. For the EU path, qualification follows DSS / ETSI TS 119 615 when the worker EU TL source is ready (Section 4.4); otherwise the VP heuristic on the governed snapshot applies.
• Validation does not confirm legal effect as a qualified electronic signature in any jurisdiction. QES is a technical classification under this VP.
• If OCSP or CRL cannot be obtained for an EU, Fidelir, or Ukrainian signature, the DSS indication is returned; Fidelir does not promote validity from a later GOOD CRL alone (Section 6.2).
• Completeness of Moldovan legacy coverage depends on curation from official national publications; newly discovered roots may require trust-material update.
• Completeness of Ukrainian coverage is limited to the current TL-UA-EC snapshot under this VP; newly granted ЦЗО services appear after the next governed refresh. Domestic DSTU-only lists are not imported.
• EU TL synchronisation depends on EC LOTL infrastructure. A failed sync leaves the last complete snapshot in force; newly listed services are not visible until the next successful import.
• The public validation interface is provided for reliance at the relying party’s own risk unless covered by a separate service agreement.

10. Normative references

• Regulation (EU) No 910/2014 (eIDAS)
• ETSI EN 319 102-1 (procedures for validation of AdES digital signatures)
• ETSI TS 119 615 (EU trust lists / qualification determination)
• ETSI TS 119 172 (signature qualification vocabulary, via DSS)
• ETSI TS/EN 319 102-2 (Signature Validation Report)
• Law no. 124/2022 of the Republic of Moldova (trusted electronic services)
• EU DSS documentation: DSS documentation
• EU LOTL: eu-lotl.xml
• National Moldova PKI: stisc.gov.md
• Legacy domestic PKI: pki.sis.md
• Ukraine Trusted List (ЦЗО): czo.gov.ua/en/trustedlist
• Ukraine TL-UA-EC: TL-UA-EC.xml