Sub-appendix 4.9

Description of the PKI service for TACHOnet

1. Introduction

A PKI (Public Key Infrastructure) is a set of roles, policies, procedures and systems needed to create, manage, distribute and revoke digital certificates (3). The CEF PKI service of eDelivery enables issuance and management of digital certificates used to ensure confidentiality, integrity and non-repudiation of the information exchanged between Access Points (AP).

The PKI service of eDelivery is based on the Trust Centre Services TeleSec Shared Business CA (Certification Authority) for which the Certificate Policy (CP)/Certification Practices Statement (CPS) of TeleSec Shared-Business-CA of T-Systems International GmbH (4) apply.

The PKI service issues certificates that are suitable for securing various business processes within and outside of companies, organisations, public authorities and institutions that require a medium security level to prove the authenticity, integrity and trustworthiness of the end-entity.

2. Certificate Request Process

2.1. Roles and responsibilities

2.1.1. ‘Organisation’ or ‘national authority’ requesting the certificate

2.1.1.1. The national authority shall request the certificates in the context of the TACHOnet project.

2.1.1.2. The national authority shall:

(a) request the certificates from the CEF PKI service;

(b) generate the private keys and the corresponding public keys to be included in the certificates issued by the Certification Authority;

(c) download the certificate when approved;

(d) sign and send back to the Registration Authority: (i) the contact persons and trusted couriers identification form, (ii) the signed individual Power of Attorney (5).

2.1.2. Trusted Courier

2.1.2.1. The national authority shall appoint a Trusted Courier.

2.1.2.2. The Trusted Courier shall:

(a) hand over the public key to the Registration Authority during a face-to-face identification and registration process;

(b) get the corresponding certificate from the Registration Authority.

2.1.3. Domain Owner

2.1.3.1. DG MOVE shall be the Domain Owner.

2.1.3.2. The Domain Owner shall:

(a) validate and coordinate the TACHOnet network and the TACHOnet trust architecture, including the validation of the procedures for the issuance of the certificates;

(b) operate the TACHOnet central hub and coordinate the activity of the parties regarding the functioning of TACHOnet;

(c) perform, along with national authorities, the tests of connection to TACHOnet.

2.1.4. Registration Authority

2.1.4.1. The Joint Research Centre (JRC) shall be the Registration Authority.

2.1.4.2. The Registration Authority shall be responsible for verifying the identity of the trusted courier, for registering and approving the requests of issuance, revocation and renewal of digital certificates.

2.1.4.3. The registration authority shall:

(a) assign the unique identifier to the national authority;

(b) authenticate the identity of the national authority, its contact points and trusted couriers;

(c) communicate with the CEF Support regarding the authenticity of the national authority, its contact points and trusted couriers;

(d) inform the national authority about the approval or rejection of certificate.

2.1.5. Certification Authority

2.1.5.1. The Certification Authority shall be responsible for the provision of the technical infrastructure for the request, issuing and revocation of digital certificates.

2.1.5.2. The Certification Authority shall:

(a) provide for the technical infrastructure for certificate requests by national authorities;

(b) validate or reject certificate request;

(c) communicate with the Registration Authority for the identity verification of the requesting organisation, when required.

2.2. Certificate issuance

2.2.1. The certificate issuance shall be carried out in accordance with the following sequential steps, represented in Figure 1:

(a) Step 1: Trusted Courier identification;

(b) Step 2: Certificate request creation;

(c) Step 3: Registration at RA;

(d) Step 4: Certificate generation;

(e) Step 5: Certificate publication;

(f) Step 6: Certificate acceptance.

Figure 1 — Certificate issuance workflow

2.2.2. Step 1: Trusted Courier identification

The following process shall be carried out for the Trusted Courier identification:

(a) The Registration Authority shall send to the national authority the contact persons and trusted couriers' identification form (6). This form shall also include a power of attorney (PoA) that the organisation (AETR Authority) shall sign.

(b) The national authority shall send back the completed form and signed PoA to the Registration Authority.

(c) The Registration Authority shall acknowledge the good reception and completeness of the form.

(d) The Registration Authority shall provide an updated copy of the list of contact persons and trusted couriers to the domain owner.

2.2.3. Step 2: Certificate request creation

2.2.3.1. The request and the retrieval of the certificate shall be done on the same computer and with the same browser.

2.2.3.2. The following process shall be carried out for the certificate request creation:

(a) The Organisation shall navigate to the user web interface to request the certificate via the URL https://sbca.telesec.de/sbca/ee/login/displayLogin.html?locale=en:, and shall enter the username ‘sbca/CEF_eDelivery.europa.eu’ and the password ‘digit.333’ Figure 2

(b) The Organisation shall click on ‘request’ on the left side of the panel and shall select ‘CEF_TACHOnet’ in the dropdown list. Figure 3

(c) The Organisation shall populate the certificate request form laid down in Figure 4 with the information in Table 3, clicking on ‘Next (soft-PSE)’ to finish the process. Figure 4 Requested Fields Description Country C = Country Code, location of certificate owner, verified using a public directory; Constraints: 2 characters, in accordance to ISO 3166-1, alpha-2, Case Sensitive; Examples: DE, BE, NL, Specific cases: UK (for Great-Britain), EL (for Greece) Organisation/Company (O) O = Organisation name of the certificate owner Master domain (OU1) OU = CEF_eDelivery.europa.eu Area of responsibility (OU2) OU = CEF_TACHOnet Department (OU3) Mandatory value per ‘AREA OF RESPONSIBILITY’ The content must be checked using a positive list (white list) when the certificate is requested. If the information does not correspond to the list, the request is prevented. Format: OU=<TYPE>-<GTC_NUMBER> Where ‘<TYPE>’ is replaced by AP_PROD: Access Point in Production environment. And where <GTC_NUMBER> is GTC_OID-1.3.130.0.2018.xxxxxx, where Ares(2018)xxxxxx is the GTC number for the TACHOnet project. e.g.: AP_PROD-GTC_OID-1.3.130.0.2018.xxxxxx First name (CN) Must be Empty Last name (CN) Must start with ‘GRP:’, followed by a common name. Format: CN = GRP:<AREA OF RESPONSIBILITY>_<TYPE>_<COUNTRY CODE>_<UNIQUE IDENTIFIER> e.g.: GRP:CEF_TACHOnet_AP_PROD_BE_001 Email E = CEF-EDELIVERY-SUPPORT@ec.europa.eu Email 1 (SAN) Must be Empty Email 2 (SAN) Must be Empty Email 3 (SAN) Must be Empty Address Must be Empty Street Must be the official address of the Organisation of the Certificate Owner. (Used for the Power of Attorney.) Street no. Must be the official address of the Organisation of the Certificate Owner. (Used for the Power of Attorney.) Zip Code Must be the official address of the Organisation of the Certificate Owner. (Used for the Power of Attorney.) Attention : if the ZIP code is NOT a 5-digit ZIP code, leave the ZIP code field empty and put the ZIP code in the City field. City Must be the official address of the Organisation of the Certificate Owner. (Used for the Power of Attorney.) Attention : if the ZIP code is NOT a 5-digit ZIP code, leave the ZIP code field empty and put the ZIP code in the City field. Phone no Must be Empty Identification data The email address must be the same as the one used for registering the Unique Identifier. + Must be the name of the person representing the organisation. (Used for the Power of Attorney) + Commercial Register No (only mandatory for private organisations) Entered at the Local Court of (only required for German and Austrian private organisations) Revocation password Mandatory field chosen by the requestor Revocation password repetition Mandatory field chosen by the requestor repeated Table 3. Complete details of each requested field

(d) The selected key length shall be 2 048 (High Grade). Figure 5

(e) The Organisation shall record the reference number to retrieve the certificate. Figure 6

(f) The CEF Support Team shall check for new requests of certificates and verify if the information in the certificate request is valid, i.e. that it conforms to the naming convention specified in Appendix 5.1 Certificate Naming Convention.

(g) The CEF Support Team shall verify that the information entered in the request is in a valid format.

(h) When either check from points 5 or 6 above fails, the CEF Support Team shall send an email to the email address provided in the ‘Identification data’ of the request form, with the Domain Owner in cc, in which the Organisation is requested to start the process again. The failed certificate request shall be cancelled.

(i) The CEF Support Team shall send an email to the Registration Authority about the validity of the request. The email shall include: (1) the name of the Organisation, available in the field ‘Organisation (O)’ of the certificate request; (2) the certificate data including the name of the AP for which the certificate is to be issued, available in the field ‘Last Name (CN)’ of the certificate request; (3) the certificate reference number; (4) the address of the Organisation, its email and the name of the person representing it.

Figure 7 – Certificate request process

2.2.4. Step 3: Registration at Registration Authority (Certificate approval)

2.2.4.1. The Trusted Courier or contact point shall make an appointment with the Registration Authority via email exchange, identifying the Trusted Courier who will proceed to the face-to-face meeting.

2.2.4.2. The Organisation shall prepare the documentary package consisting in:

(a) the filled-in and signed power of attorney;

(b) a copy of the valid passport of the trusted courier who will perform the face-to-face. This copy must be signed by one of the step 1 identified Organisation points of contact;

(c) the certificate request paper form signed by one of the points of contact of the Organisation.

2.2.4.3. The Registration Authority shall receive the Trusted Courier after identity screening at the building reception. The Registration Authority shall conduct the face-to-face registration of the certificate request by:

(a) identifying and authenticating the Trusted Courier;

(b) verifying the trusted courier physical appearance against the passport presented by the Trusted Courier;

(c) verifying the validity of the passport presented by the Trusted Courier;

(d) verifying the validated passport presented by the trusted courier against the copy of the valid passport of the trusted courier signed by one of the identified points of contact of the Organisation. Signature is authenticated against the original ‘trusted courier and contact points identification form’;

(e) verifying the filled-in and signed power of attorney;

(f) verifying certificate request paper form and its signature against the original ‘trusted courier and contact points identification form’;

(g) calling the signatory contact point to double check the identity of the trusted courier and the content of the certificate request.

2.2.4.4. The Registration Authority shall confirm to the CEF Support Team that the national authority is indeed authorised to operate the components for which it is asking the certificates and that the corresponding face-to-face registration process was successful. The confirmation shall be sent using a ‘CommiSign’ certificate secure email, attaching a scanned copy of the authenticated face-to-face documentary package and of the signed process check list carried out by the Registration Authority.

2.2.4.5. If the Registration Authority confirms the validity of the request, the process shall carry on as set out in 2.2.4.6 and 2.2.4.7. Otherwise the certificate issuance shall be rejected and the Organisation shall be informed.

2.2.4.6. The CEF Support Team shall approve the certificate request and shall notify the Registration Authority the approval of the certificate.

2.2.4.7. The Registration Authority shall notify the Organisation that the certificate can be retrieved via the user portal.

Figure 8 — Certificate approval

2.2.5. Step 4: Certificate generation

Upon approval of the certificate request, the certificate shall be generated.

2.2.6. Step 5: Certificate publication and retrieval

2.2.6.1. Following approval of the certificate request, the Registration Authority shall retrieve the certificate and hand over a copy to the Trusted Courier.

2.2.6.2. The Organisation shall receive the notification from the Registration Authority that the certificates can be retrieved.

2.2.6.3. The Organisation shall navigate to the user portal at https://sbca.telesec.de/sbca/ee/login/displayLogin.html?locale=en and shall log in with the username ‘sbca/CEF_eDelivery.europa.eu’ and the password ‘digit.333’.

Figure 9

2.2.6.4. The Organisation shall click on the ‘fetch’ button on the left-hand side and shall provide the reference number recorded during the certificate request process;

Figure 10

2.2.6.5. The Organisation shall install the certificates by clicking on the install button;

Figure 11

2.2.6.6. The certificate shall be installed on the Access Point. As this is implementation-specific, the Organisation shall refer to its Access Point provider to obtain the description of this process.

2.2.6.7. The following steps are needed for the certificate installation on the Access Point:

(a) export the private key and the certificate,

(b) create the keystore and the truststore,

(c) install the keystore and the truststore on the access point.

Figure 12 — Certificate retrieval

3. Certificate revocation process

3.1. The Organisation shall submit a revocation request through the user web portal;

3.2. The CEF Support Team shall execute the certificate revocation.

Figure 13 — Certificate revocation

4. General Terms and conditions of the CEF PKI service

4.1. Context

In its capacity as Solution Provider of the eDelivery Building Block of the Connecting Europe Facility, DIGIT shall make available a PKI service (7) (‘CEF PKI service’) to the AETR Contracting Parties. The CEF PKI service shall be used by national authorities (‘end-users’) participating in TACHOnet.

DIGIT is a PKI tenant within the TeleSec Shared-Business-CA solution (‘SBCA’) operated in the Trust Centre of the Group unit T-Systems International GmbH (‘T-Systems’ (8)). DIGIT plays the role of Master Registrar of the ‘CEF_eDelivery.europa.eu’ domain of the SBCA. In this role, DIGIT creates sub-domains within the ‘CEF_eDelivery.europa.eu’ domain for each project using the CEF PKI service.

This document provides details on the terms and conditions of the TACHOnet sub-domain. DIGIT plays the role of sub-Registrar of this sub-domain. In this capacity, it issues, revokes and renews the certificates of this project.

4.2. Disclaimer on liability

The European Commission accepts no responsibility or liability whatsoever with regard to the content of the certificate which lies exclusively with the certificate owner. It is the responsibility of the certificate owner to check the accuracy of the certificate content.

The European Commission accepts no responsibility or liability whatsoever with regard to the use of the certificate by its owner being a third legal entity outside the European Commission.

This disclaimer is not intended to limit the liability of the European Commission in contravention of any requirements laid down in applicable national law or to exclude its liability for matters which may not be excluded under that law.

4.3. Authorised/prohibited uses of certificates

4.3.1. Permitted usage of certificates

Once the certificate is issued, the certificate owner (9) shall use the certificate only in the context of TACHOnet. Within this context, the certificate can be used to:

— authenticate the origin of data,

— encrypt data,

— ensure detection of integrity breaches of data.

4.3.2. Prohibited usage of certificates

Any usage not explicitly authorised as part of the permitted usages of the certificate is prohibited.

4.4. Additional obligations of the certificate owner

The detailed terms and conditions of the SBCA are defined by T-Systems in the Certificate Policy (CP)/Certification Practice Statement (CPS) of the SBCA service (10). This document includes security specifications and guidelines regarding technical and organisational aspects and describes the activities of the Trust Centre operator in the roles of Certification Authority (CA) and Registration Authority (RA) as well as the Registration Authority's (RA) delegated third party.

Only entities authorised to participate TACHOnet can request a certificate.

Regarding certificate acceptance, clause 4.4.1 of the SBCA Certificate Policy and Certification Practice Statement (‘CP/CPS’) applies, furthermore the terms of use and provisions described in the present document are deemed accepted by the organisation to which the certificate is issued (‘O=’) when first used.

Regarding publication of the certificate, clause 2.2 of the SBCA CP/CPS applies.

All certificate owners shall comply with the following requirements:

(1) protect their private key against unauthorised use;

(2) refrain from transferring or revealing their private key to third parties, even as representatives;

(3) refrain from continued use of the private key following expiry of the validity period or revocation of the certificate, other than to view encrypted data (e.g., decrypting emails);

(4) the certificate owner is responsible for copying or forwarding the key to the end-entity or entities;

(5) the certificate owner must obligate the end-entity/all end-entities to comply with the present terms and conditions, including the SBCA CP/CPS, when dealing with the private key;

(6) the certificate owner must provide the identification of those authorised representatives who are authorised to request revocation of certificates issued to the organisation with the details of events that lead to revocation and the revocation password;

(7) for certificates associated to groups of persons and functions and/or legal persons, after a person leaves the group of end-entities (e.g. termination of the employment relationship), the certificate owner must prevent misuse of the private key by revoking the certificate;

(8) the certificate owner is responsible and shall request revocation of the certificate under the circumstances referred to in clause 4.9.1 of the SBCA CP/CPS.

Regarding renewal or rekey of certificates, clause 4.6 or 4.7 of the SBCA CP/CPS applies.

Regarding amendment of certificate, clause 4.8 of the SBCA CP/CPS applies.

Regarding certificate revocation, clause 4.9 of the SBCA CP/CPS applies.

5. Contact persons and trusted couriers identification form (sample)

I, [name and address of the organisation representative], certifies that the following information are to be used in the context of the request, generation and retrieval of public key digital certificates for TACHOnet access points supporting the confidentiality, integrity and non-repudiation of the TACHOnet messages:

Contact person information:

— Contact person #1 — Contact person #2 — Name: — Name: — First names: — First names: — Mobile phone: — Mobile phone: — Telephone: — Telephone: — Email: — Email: — Specimen handwritten signature: — — Specimen handwritten signature: — — —

Trusted courier information:

— Trusted courier #1 — Trusted courier #2 — Name: — Name: — First names: — First names: — Mobile phone: — Mobile phone: — Email: — Email: — Passport issuing country: — Passport issuing country: — Passport number: — Passport number: — Passport validity end date: — Passport validity end date:

Place, date, company stamp or seal of the Organisation:

Signature of the authorised representative:

6. Documents

6.1. Individual Power of Attorney (sample)

A sample of the individual Power of Attorney that must be signed and presented by the trusted courier during face-to-face registration at RAO can be found here:

6.2. Certificate request paper form (sample)

A sample of the certificate request paper form that must be signed and presented by the trusted courier during face-to-face registration at RAO can be found here:

7. Glossary

The key terms used in this Sub-appendix are defined in the CEF Definitions section on the CEF Digital Single Web Portal:

https://ec.europa.eu/cefdigital/wiki/display/CEFDIGITAL/CEF+Definitions

The key acronyms used in this Component Offering Description are defined in the CEF Glossary on the CEF Digital Single Web Portal:

https://ec.europa.eu/cefdigital/wiki/pages/viewpage.action?spaceKey=CEFDIGITAL&title=CEF+Glossary