This Trust Establishment Model is based on using a single PKI issuing Certificates for all members of a Trust Domain (TD). The PKI may be a hierarchical one, having different sub CAs for different types of Trust Services Providers (TSPs) allocated to the Trust Domain. For an example, see e-SENS D6.1 Enterprise Interoperability Architecture n°1, section Open PEPPOL Trust Network

Certificates are used for digital signatures on service–request and –response messages for purposes of authentication and integrity, for client authentication (e.g. SSL / TLS) and may optionally also be used for encryption of messages. Different from the Mutual Exchange of End Entity (Subject) Certificates, in this model only Issuer certificates are exchanged between all members of a Trust Domain (TD) and kept in a trusted Key Store by all TD nodes which mutually must authenticate each other.

For Subject certificates presented for authentication of Service–requests and –responses, a check, achieved by looking up the TD Certificate Trust Store for the Issuer Certificate, is carried out to determine if the Certificate Issuer is a trusted one.

The Policy that the Subject is bound to, can be derived from the Certificate Issuer Name (CA and respective sub CA), as such a Certificate is issued on a respective contractual basis and policy agreement between the Subject (the Trusted Service) and the CA.


Interoperability Level:



Requirement description



e-Signature validation services must be trustable

(Special case of requirement below. Note that every TD member which is validating signatures must have the Certificates of Validation Services in its trust store, and conversely Validation Services must include the Certificates of all the other TD Members, if these services require client authentication and use the same Direct Trust Model.)



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.

(Note: For this Trust Model based on dedicated PKI(s), TD Members' policy conformance is implied, as policy conformance validation has to take place before Certificates are issued.)


Application view

Exchange of Issuer Certificates inside Trust Domain

Figure 1: Issuer Certificate Exchange using TD Trusted Key Sore

Note that the validity of Issuer Certificates held in the TD Trust Store should be checked on a periodically basis according to the underlying Trust Domain Policy. Invalidated or revoked Certificates shall be removed from the TD Trust Store the updated TD Trust Store shall be replicated to local copies immediately in a secure and authorized manner. Irrespective of using "up to date" Trust Stores, End Entity certificate validation by means of OCSP/CRL should be used in any case during when verifying Authentications.

More sophisticated implementations also support LDAP directory servers as a trusted certificate repository. In this case, the TD Trust Store may be accessed directly; no replicated local instance is needed.

Trusted Certificate Validation

Figure 2: Trusted Certificate Validation

As described above, depending on the implementation, the local Trust Store or the central TD one is used for lookup. The lookup is made for verifying the Certificate of the issuing CA indicated in the End Entity Certificate contained in the Trust Store.

Actual End Entity Certificate validity should be checked by using the issuing CA's OCSP/CRL service; if SSL/TLS is used, OCSP stapling Formally known as the TLS Certificate Status Request extension should be activated.
No additional Policy adherence is checked, as Certificate owners' Policy is implicitly bound to the Certificate Issuer.

Information view

Figure 3: Involved Data Objects

As mentioned above, implementations may use a central TD Trust Store directly or a local copy of it.

Technology view


Author note

I restrain here from listing all the PKIX-specifications (most of them referenced in ETSI ESI Rationalized Framework


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 412 Certificate 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
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)

Implementation Guidelines

This ABB Functionality mostly is given by infrastructure components implementing SSL/TLS and/or SOAP Message Security (according to the OASIS specification WS-Security 1.1).

Related ABBs

For Certificate Validation, see ABB e-Signature Verification Service.
This ABB is used by all ABBs/SBBs which use mutual authentication on base of a dedicated PKI. It's a decision of Trust Domains to decide on this model.




Governikus KG



Üstündağ Soykan














Changes made

Modified by




Klaus Vilstrup Pedersen




Jörg Apitzsch



First version completed

Jörg Apitzsch



Text in section 1.2.1 changed – look up trust store for issuer instead of end entity certificate

Jörg Apitzsch



Proof reading

Damien Magoni



Final Review

Jörg Apitzsch UpdatesCagatay Karabat
  • No labels