Trusted Lists (TL) were established by the Commission Decision 2009/767/EC as amended by the Commission Decision 2010/425/EU. TLs aim at supporting the validation of Qualified Electronic Signatures (QES) and Advanced Electronic Signatures (AdES) supported by a Qualified Certificate (AdESQC) in the meaning of Directive 1999/93/EC as EUMS are obligated to expose actual and historical status information on supervised/accredited CSPs established in their country offering qualified certificates. TLs enable EU-wide validation of service supervision/accreditation status and hence quality of Trust Service Providers (TSPs) issuing (qualified) certificates.  

Now the eIDAS regulation gives a legislative base to expand TL usage to cover the mutual recognition and acceptance at EU level of notified electronic identification schemes and other essential related electronic Trust Services.

“Trusted lists … enable in practice any interested party to determine whether a trust service is or was operating in compliance with relevant requirements, currently or at some time in the past (e.g. at the time the service was provided, or at the time at which a transaction reliant on that service took place). In order to fulfil this requirement, trusted lists necessarily contain information from which it can be established whether the TSP’s service is, or was, known by the Trusted List Scheme Operator (TLSO) and, if so, the status of the service. Trusted lists therefore contain not only the service's current status, but also the history of its status.” (ETSI TS 119 612 “Trusted Lists”, page 8).

TL entries expose a number of dedicated TSP and TS attributes (e.g., the TSP governing policy and actual quality of TS supervision); for a complete description of information carried in Trusted List TSP/TS entries, see ETSI TS 119 612.

Independent from the aims of the eIDAS regulation to extend the “official national TLs” to cover more types of Trusted Services, TLs can be set up at a community level – which could be an e-SENS wide TL or even different instances on domain level, which then may have different TL Scheme Operator policies in effect, if needed.

By exposing TSPs and services offered by them in one or more TLs, in a more general sense TLs can be used as a mechanism of trust federation. To be listed in a TL, TSPs must conform to the TLSO policy in effect (requiring a contractual agreement between the TSP and the TLSO). Basically, this is the Trust Domain policy in effect for TSPs belonging to this TD.

TL entries include a security token (element "Service digital identity"), which can be used to authenticate service items provided by such Trust Services; in the case of e-SENS, X509 Certificates issued to TSPs will be used. 

When validating authentication of service-requests and –responses, the Certificate can be used to identify the TSP in the TL, and in the case where this TSP listed in the TL making the TSP's TL attributes available for a more granular authentication decision (e.g. fulfilment of a certain policy, service quality/supervision status, etc.). 

Unsuccessful TL lookup will be treated as a non-trusted Certificate case and lead to authentication validation failure.
Main advantages of using the TL for trust establishment are:

  • TSPs/TSs may have dedicated policies, policy is not implicitly derived from the Certificate used for authentication;
  • TSPs may decide to choose Certificate Issuers of their choice, as their respective national or domain regulations will be in effect for them eventually.


 A TL shall not be seen as the ultimate trust anchor and does not replace PKI mechanisms behind. When verifying authentication, actual End Entity Certificate validity shall be checked in any case using the CA's OSCP/CRL service. But ongoing discussion at ETSI ESI on the role of TL as trust anchor in context of eIDAS requirements imposed on TL and TSP should be observed. 


Interoperability Level:



Requirement description


e-Signature validation services must be trustable


Shared central services and nodes used to interconnect national/application domain trust circles must be recognizable as trustworthy; their underlying trust and service quality status, operational policy, governance model must be verifiable by all actors involved at any time.

Application view

Domain Trust List

Figure 1: Domain specific trust List Maintenance

End Entity X509 Certificates are issued for Trust Service Providers and must be added as "Service digital identities" to the TL record of this TSP and maintained here together with all the other TSP attributes according to the Domain Policy in effect. Note that each TSP's respective TS could be assigned a specific policy, depending on its role.

As CAs themselves are TSPs, they may be listed in the same TL; in this case their Issuer Certificate is their service digital identity. The policy depicted in their TL record should correspond to this specific role.
The Trust Service Status List specification foresees a pointer to other TLs, enabling interlinking of the different TL instances used (e.g., for different TSP types or even to interlink TLs from different domains and/or specific ones used by TSPs / TSs shared by all domains such as for e-Delivery or directory services).

Note that the validity of End Entity Certificates held in the Domain TL should be checked on a periodical basis according to the underlying Trust Domain Policy. Revoking or invalidating an End Entity Certificate should lead to a corresponding status change of the TL entry of the respective service.

Common e-SENS Trust List

This application view is very similar to the Domain Trust List one, it's just using one central TL for all domains.

Figure 2: Domain specific trust List Maintenance

One central TL is set up and maintained for the whole project. This may in the future be covered by the official EUMS Trust Lists, once the respective eIDAS implementing acts will be requiring this from the EUMS. But it will have to be awaited for, if the future "MS official" Trust List will cover all types of TS types and their providers involved in e-SENS piloting domains. Actually, eIDAS only mentions a rather restricted list of public administration service types which are seen as ones which must be trusted and thus should be covered by official EUMS Trust Lists.

Concerning the Central Trust List maintenance, same remarks apply as depicted for the Domain Trust List above.

Trusted Certificate and Policy adherence Validation

Note that for using a TL for Certificate and Policy Validation, this service must have access to the Certificate presented for authentication. In case of using SSL/TLS only, this may not be the case as authentication mostly is handled by off-the-shelf SSL/TLS implementations not able to deal with TL's, and SSL/TLS authentication is often allocated to a dedicated proxy in real network topologies. For Web services, means of WS-Security must be used to authenticate Requests and Responses (i.e., to be able to gain access to the Certificate using the WS-Stack implementation).

Figure 3: Trusted Certificate and Policy adherence Validation

Depending on the authentication mechanisms used by a service, initially it will involve a lookup of the local respective TD central store of trusted certificates (e.g., when using SSL/TSL authentication).

Lookup of TL is done to determine whether the service and its certificate to be authenticated is listed in the TL; if the case, a corresponding TL record is given to the requesting application, which is responsible to check for the required TS quality status and policy adherence. Depending on the scenario, it may be the Issuer and not the End Entity Certificate that is used for lookup (e.g., in case of validating adherence of an End Entity Signature Certificate used for non-repudiation, the quality of this Certificate is given by the Issuing CA), thus the Issuer Certificate determines the Trust Service in question here. Note that such End Entity Certificates are not subject to be listed in TLs, as TLs are only about Trusted Services.
To determine the actual certificate validity, OCSP/CRL verification of the certificate must be done in any case; it may only be omitted if using TLS with OSCP stapling is activated.

Information view

Figure 4: Involved Data Objects

Implementations may use a central TD Trust Store directly or a local copy of it. For the Trust List, it must be decided either to establish instances per domain and/or classes of service types or to use a central one for the whole project.
For TSP being CAs issuing qualified signature certificates, the usage of the official EUMS TLs is mandatory by EC regulation.

Technology view


Author note

I restrain here from listing all the PKIX-specifications (most of them referenced in ETSI ESI Rationalized Framework); may be amended later. 

ETSI ESI Standards for Trust Service Providers Supporting Electronic Signatures:

EN 319 401General Policy Requirements for Trust Service Providers
EN 319 411Policy & Security Requirements for TSPs Issuing Certificates
In particular:

Part 1: Policy requirements for TSPs issuing Web Site Certificates
Part 2: Policy requirements for TSPs issuing Public Key Certificates

EN 319 412Certificate Profiles
In particular:

Part 1: Overview and common data structures
Part 4: Certificate profile for Web Site Certificates issued to organisations

TS 119 312Cryptographic Suites
EN 319 102Procedures for Signature Creation an Validation
EN 319 403Trust Service Provider Conformity Assessment – requirements for conformity assessment bodies assessing Trust Service Providers

ETSI ESI Standards for Trust Service Status Lists Providers 

TR 119 600Business Driven Guidance for Trust Service Status Lists Providers
EN 319 601General Policy & Security Requirements for Trust Service Status Lists Providers
EN 319 611Policy & Security Requirements for Trusted List Providers
TS 119 602Trust Service Status Lists Format
TS 119 612Trusted Lists
EN 319 603General requirements and guidance for Conformity Assessment of TSSLPs
EN 319 613Conformity Assessment of Trusted List Providers

Other related international standards, as far as not already referenced / profiled by the ETSI Standards

RFC 5246 The Transport Layer Security (TLS) Protocol Version 1.2
RFC 6066 Transport Layer Security (TLS) Extensions: Extension Definitions
RFC 4510 Lightweight Directory Access Protocol (LDAP)


Web Services Security SOAP Message Security Version 1.1.1, 18 May 2012
WS-Security Policy 1.2, 1 July 2007
Web Services Security X.509 Certificate Token Profile 1.1.1, 18 May 2012,

Implementation Guidelines

Parts of this ABB's functionality are given by infrastructure components implementing SSL/TLS and/or SOAP Message Security (according to the OASIS WS-Security 1.1.1 specification).
For the Trust List Maintainer, a "TLManager" is made available by the EC Available from Joinup: In addition, ETSI provides a "TSL Conformance Checker" See .
For Trust List Lookup, implementations have been done by LSPs PEPPOL and SPOCS. These should be considered for adoption by e-SENS.

Related ABBs

For Certificate Validation, see ABB e-Signature Verification Service.
This ABB may be used by all ABBs/SBBs which deal with mutual authentication. It's a decision of Trust Domains to decide on this model.
Editors note: List of these ABBs to still be detailed later.




Governikus KG



Üstündağ Soykan














Changes made

Modified by




Klaus Vilstrup Pedersen




Jörg Apitzsch



First version completed

Jörg Apitzsch



Draft completed

Jörg Apitzsch



Proof reading

Damien Magoni



Final Review

Jörg Apitzsch UpdatesCagatay Karabat
  • No labels