Peculiarità delle Trust List nazionali

Ultimo aggiornamento: 13 luglio 2026

Questo documento approfondisce un punto lasciato solo accennato in guida-firme-elettroniche.html (sezione 5, Trust List e LOTL): le singole Trust List (TL) nazionali che la LOTL aggrega non sono cataloghi uniformi di "CA affidabili". Ogni Stato Membro pubblica la propria seguendo lo standard ETSI TS 119 612, ma con margini di discrezionalità che producono differenze concrete — rilevanti quando un risultato di validazione sembra anomalo o inatteso.

Se non hai familiarità con trust anchor, catena di fiducia o LOTL, parti da guida-firme-elettroniche.html prima di leggere questo documento.

1. Cosa contiene davvero una voce di Trust List

Una TL non è un semplice elenco di certificati "fidati/non fidati": ogni voce (Trust Service) descrive un servizio erogato da un Trust Service Provider (TSP), con diversi attributi strutturati (in DSS: TrustServiceWrapper, esposto da CertificateWrapper.getTrustServices()):

Il tipo di servizio e i qualifier insieme sono ciò che determina se una firma risulta QESIG/QESEAL (qualificata) oppure solo ADESIG_QC/non qualificata nel campo qualification del report di StackSign — non basta che il certificato sia "nella TL", conta quale voce lo copre e con quali attributi.

2. Il caso AgID: qualificato e non qualificato nella stessa lista

La TL italiana (competenza di AgID) è un buon esempio delle differenze pratiche tra Stati: oltre ai TSP che erogano certificati qualificati (ArubaPEC, InfoCert, Aruba, Namirial, ecc. — i nomi che si incontrano più spesso validando documenti bancari italiani), pubblica anche voci con Svctype/CA/PKC o qualifier NotQualified: CA riconosciute/sorvegliate a livello nazionale che non emettono certificati con valore legale eIDAS pieno.

DSS carica tutte queste voci nello stesso TrustedListsCertificateSource (vedi TrustConfiguration in CLAUDE.md): un certificato può quindi risultare trusted (la catena si chiude su un trust anchor riconosciuto) senza essere qualificato. Prima di questa distinzione un report poteva mostrare solo l'esito aggregato (qualification: NOT_ADES o simile) senza spiegare perché — la firma non è debole crittograficamente, semplicemente il servizio che ha emesso il certificato non ha lo status richiesto da eIDAS art. 3(12).

Dal punto di vista implementativo, ValidationReportMapper.resolveTrustServices() risale la catena di certificazione della firma (DiagnosticData.getSignatureCertificateChain()) fino al primo certificato marcato da DSS come trust anchor, e ne espone i trust service associati nel campo certificateTrustServices di SignatureLayerReport (vedi TrustServiceInfo): TSP, paese, tipo di servizio e stato — così un'analisi di conformità può distinguere a colpo d'occhio "qualificato da un QTSP italiano" da "trusted ma non qualificato".

3. Altre peculiarità che variano da Stato a Stato

• Servizi storici (withdrawn): una TL non rimuove mai una voce quando un servizio cessa — la marca come withdrawn e la mantiene, perché firme prodotte mentre il servizio era granted devono restare validabili anche dopo (principio del "punto nel tempo", point in time). Un certificato coperto solo da una voce withdrawn alla data di firma indica un servizio decaduto prima che la firma fosse apposta.
• Nomi multilingua: TspNames/ServiceNames sono elenchi (uno per lingua ufficiale dello Stato che pubblica la TL), non un singolo valore — StackSign oggi prende il primo disponibile (TrustServiceInfo.tspName), che in alcuni Stati può non essere l'inglese.
• MRA (Mutual Recognition Agreement): alcuni Stati extra-UE con accordi di riconoscimento reciproco (es. Regno Unito prima della Brexit, o accordi bilaterali) fanno apparire servizi "equivalenti" con proprie regole di validità temporale (getMraTrustServiceEquivalenceStatus* in TrustServiceWrapper) — StackSign non li considera: TrustConfiguration carica solo la LOTL ufficiale UE (vedi CLAUDE.md, "niente Regno Unito, niente trust list nazionali extra").
• Granularità diversa: alcuni Stati pubblicano una voce per ogni singolo certificato di CA intermedia, altri raggruppano più CA sotto lo stesso TSP con AdditionalServiceInformation per distinguerle — non c'è un livello di dettaglio uniforme imposto dallo standard.

4. Come leggere un caso anomalo

Se una validazione dà un esito inatteso legato alla trust list (es. certificato che sembra di un TSP noto ma risulta non qualificato, o non trusted):

1. Guarda certificateTrustServices nel report — se è vuoto, il certificato (o la sua catena) non è coperto da nessuna voce di alcuna TL nazionale: non è un problema di qualificazione, è un problema di trust anchor mancante (adesValidationDetails riporterà tipicamente NO_CERTIFICATE_CHAIN_FOUND).
2. Se non è vuoto, controlla serviceType/serviceStatus di ogni voce: Svctype/CA/QC + Svcstatus/granted è il caso "tutto qualificato e attivo"; Svctype/CA/PKC o qualifier NotQualified spiega perché la qualificazione non è piena pur essendo la catena trusted.
3. Per un'ispezione più approfondita della TL di uno specifico Stato (oltre a quanto StackSign espone), il Trusted List Browser ufficiale della Commissione UE permette di cercare TSP e servizi per paese e nome.

5. Riferimenti

• ETSI TS 119 612 — Trusted Lists (lo standard che definisce Service Type Identifier, Service Status e i qualifier usati sopra)
• Regolamento eIDAS (UE) n. 910/2014, art. 3(12) e art. 3(20) — definizioni di "certificato qualificato" e "prestatore di servizi fiduciari qualificato"
• eu.europa.esig.dss.diagnostic.TrustServiceWrapper (DSS) — l'API da cui StackSign legge questi dati
• guida-firme-elettroniche.html, sezione 5 — introduzione a Trust List e LOTL per chi parte da zero