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.

Scope of this document. This VP governs signature validation (validation of third-party signatures). It is distinct from the Certificate Policy & CPS, which governs certificates issued by Fidelir Trust Services and programme reliance on those certificates. A valid validation outcome here does not extend contractual or programme authorization to rely on a Fidelir-issued certificate outside CP/CPS scope. Validation outcomes do not, by themselves, constitute a qualified validation report under Regulation (EU) No 910/2014 (eIDAS) unless expressly agreed in a separate engagement.

1. Introduction

1.1 Purpose

The purpose of this policy is to declare, in auditable form: which validation engine is used; where trust anchors and intermediate certificates are sourced; how revocation is evaluated; 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

  • AdES — Advanced Electronic Signature (ETSI AdES baseline).
  • 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).
  • LTV — Long-term validation (revocation and proof-of-existence at reference time).
  • OCSP — Online Certificate Status Protocol.
  • TL — Trusted List (national trust-service list).
  • Trust anchor — Self-signed root certificate configured as trusted for path validation.

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.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:

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

ParameterValue
Validation levelLONG_TERM_DATA (ETSI long-term validation scope)
Reference timeDerived from the signature — claimed signing time and/or embedded timestamp token; not the server wall clock
Indication sourceDSS Simple Report + Detailed Report; Fidelir policy overlays where declared below

4.3 Chain building

Certificate path discovery uses only material present in the configured trust store. Authority Information Access (AIA) fetching is disabled — intermediate certificates are not downloaded from the network at validation time. Paths must be constructible from adjunct material already held in the governed trust store and the published repository.

5. Trust material — sources and custody

5.1 Overview

Trust material is maintained under Fidelir governance, loaded into the validation engine at service start, and refreshed on a defined schedule or after trust-material updates. Two logical stores are maintained:

StoreContentRole
Trusted anchors Self-signed root certificates and Fidelir repository trust anchors Path validation termination; signature chain must anchor here
Adjunct pool Intermediate and service certificates (including expired CAs where required for LTV) Chain construction for legacy signatures signed while a CA was still valid

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:

Qualified and non-qualified trust service certificates from EU Member State TLs are indexed with service metadata (TSP name, service type, territory). This enables validation of signatures created under eIDAS and ETSI trust frameworks across the European Economic Area.

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 merged into the trusted store at refresh. 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 trust-material updates, EU TL synchronisation, or national snapshot refresh (Moldova STISC / SIS, Ukraine TL-UA-EC), the validation engine refreshes its in-memory store. TL 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

StepBehaviour
OCSP Tried first for end-entity certificates only; skipped for CA certificates and certs with OCSP No Check
CRL Canonical source for overall validation outcome when OCSP is unavailable, unknown, or inconclusive
Timeouts OCSP 5 s; CRL 15 s per request
OCSP URL selection Single URL from certificate AIA (no multi-endpoint fan-out)
OCSP cache In-process cache per validation run to avoid duplicate requests

6.2 Fidelir CRL-primary policy

Where DSS returns a failed or indeterminate indication solely because OCSP could not be obtained, but the signing certificate CRL status is GOOD, integrity is intact, the chain anchors in the trust store, and no certificate in the chain is REVOKED, Fidelir Trust Services may treat the signature as valid with indication TOTAL-PASSED. This reflects operational reality in Moldova and neighbouring regions where OCSP endpoints are intermittently unavailable while CRL publication remains authoritative.

6.3 Documented format exceptions

Known domestic tooling quirks that do not affect cryptographic integrity may be accepted under explicit policy overlay. Currently documented:

  • Domestic 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 and national identifier where present in the certificate
  • Issuing authority (CA / TSP) and country
  • Best signature time and AdES format (e.g. PAdES-BASELINE-B, XAdES-BASELINE-T)
  • Expandable technical validation checks: Integrity, Certificate chain, Format, CRL, OCSP, TSA, LTV, X.509 validation

7.2 Technical check semantics

StatusMeaning
OKCheck passed
WARNNon-blocking issue or policy overlay; inspect detail text
FAILCheck failed; typically causes invalid overall outcome unless policy overlay applies
N/ANot evaluated or not applicable (e.g. OCSP skipped when CRL validated)
INFOInformational (format label)

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 index and published repository at refresh time.
  3. Revocation and expiry are evaluated against the signature reference time, not an arbitrary server clock.
  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 confirm that a signature satisfies qualified electronic signature requirements in any jurisdiction unless the certificate and policy explicitly indicate qualification and the trust list entry supports it.
  • Network retrieval of CRL/OCSP may fail; unknown revocation status is reported and may affect DSS indications before policy overlay.
  • 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 sync depends on availability of EC LOTL infrastructure and correct DSS TL parsing; stale TL may delay recognition of newly trusted services until the next successful sync.
  • 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