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.
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.
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.
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
Part 1: Policy requirements for TSPs issuing Web Site Certificates
Part 2: Policy requirements for TSPs issuing Public Key Certificates
EN 319 412Certificate Profiles
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,
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: https://joinup.ec.europa.eu/software/tlmanager/release/all. In addition, ETSI provides a "TSL Conformance Checker" See http://portal.etsi.org/Services/CentreforTestingInteroperability/Activities/ElectronicSignature/TSLConformanceproject.aspx .
For Trust List Lookup, implementations have been done by LSPs PEPPOL and SPOCS. These should be considered for adoption by e-SENS.
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.
Klaus Vilstrup Pedersen
First version completed
|1.1||11.06.2015||Editorial Updates||Cagatay Karabat|