The purpose of this page is to collect information on how the OpenNCP project should take into account the PKI used in epSOS. This includes integration or interaction of protocol terminators with TSLSync, management of certificates used for establishing VPN connections, and other certificate-management procedures such as handling expired or revoked certificates.

General PKI model description

The main documents defining the selected PKI model are D3.7.2 Section II and D3.4.2 v. 2.2.

Currently certain relaxations are applied to these rules. The security relaxations are valid until 31/12/2012 and they are listed in D3.10.1 App.7: https://service.projectplace.com/pp/pp.cgi/r730057798. The summary of the relaxations is the following:

1. Certain certificates can be merged/combined. Instead of 5 certificates an NCP can use only 3.
2. CAs are not required to be authorized by the national authorities listed on the European TSL list.
3. The previous relaxation has caused that NCP operators / TSLSync import certificates from the central services without their validity/revocation checks.
4. SHA-1 can be used instead of SHA-2
5. Some attribute deviations by some countries
6. No proper signature verification of NSL lists
7. NCP 2 NCP messages are not signed (signatures are only applied to the assertions)

Open questions

What are the other documents which describe the selected PKI model?

In D3.7.2 Section II four options for implementing the PKI service were described. Is the currently used model the same as 1 (Using a different PKI for each epSOS-NCP with a repository of root certificates in each epSOS-NCP), recommended by the document or another one?

Are there any other relaxations currently in use?

Does the selected normative PKI model place trust directly in certificates (along with certificate distribution rules), in CAs that issue them, or both?

 SB Within the epSOS specification, the trust is not bound to either a single CA, nor the individual certificates. A comprehensive trust framework around the ETSI NSL/TSL provisions has been chosen in order to:

• leave the ultimate responsibility and management of certificate and CA aspects at the national authoritative bodies 
• ensure the appropriateness of the certificate design, operational & environmental security, and legal stability of the CA and certificate (only accredited TSP's are reflected within NSL/TSL)
• enable an automatic compilation (and de-compilation) of an epSOS-wide trust chain without manual interactions and potential for human error
• ensure appropriate liability and due-diligence provisions
• benefit from the signature-related aspects that are imposed through regulations, directives, and their national instrumentation
• avoid im-/exporting national concerns/specifics into other epSOS partners by abstracting into the common European layer  

What is the impact of the EU Trusted Lists of Certification Service Providers? http://ec.europa.eu/information_society/policy/esignature/eu_legislation/trusted_lists/index_en.htm The understanding of France and Finland is that these apply only to personal certificates, not to server certificates? Turkey, Switzerland and Norway are outside the scope of the list.

What are the trusted CAs in the selected PKI model, if any?

• TSLSync and connection to the central services

TSLSync is a utility for updating the truststores in NCPs. It fetches XML-formatted TSL lists from the central services and updates the truststore used by the NCP by adding there the extracted certificates.

• Open questions

What are the documents which describe the PKI-related functionality of the central services?

Do central services analyze the contents of the TSL files (XML) or extract/analyze certificates from them?

Does TSLSync check the validity of the certificate or check certificate revocation lists before placing the certificate in the truststore?

Does TSLSync place multiple copies of the same certificate to the truststore?

What is the standard procedure of importing the certificate of the central services to the NCP's truststore?

• Certificate revocation lists (CRL)

In TConf on 27.9. it was mentioned that NCPs must check certificate revocation lists. We need to understand how this should be implemented in OpenNCP. At least two questions must be answered:

• How CRL updates are fetched from CRL maintainers?
• How CRLs are used (and if necessary) stored in the NCP?

The following options could be used for CRL fetching:

• Integration of CRL checks into TSLSync
• New certificate management component with TSLSync and other functionality

Further analysis of the second question requires better understanding of the PKI model used in epSOS.

• Open questions

What is/are the CRL distribution points that must be used by OpenNCP? Options:

• All CRLs published by all CAs on European TSL lists (question related to this option: performance issues/too many CRL addresses, where to get the list?).
• The CRL address given in the certificate (question related to this option: why OpenNCP should trust this address, if the intention is to validate this very certificate?).
• Some predefined CRL addresses (question related to this option: how to define a trustworthy way of sharing this list?)
• Other option.

How are CRL checks implemented in FET solution?

• TLS connections

Trust stores and keystores are used for establishing TLS connections between NCPs. The configuration of keystores and truststores is done by configuration manager

• Open questions

Is there some duplication in configuration files epsos-srdc.properties and epsos.properties? 

In case the national connector uses other certificates for communicating with the NI, how this should be taken into account? TSLSync seems to overwrite the javax.net.ssl.keystore and other similar properties in Java environment with each synchronization.

• VPN connections

VPN certificates are distributed along with TSL lists from central services. They are fetched by TSLSync and placed in the directory specified in epsos.properties file. The certificates must be after that be imported into certificate database used by ipsec. In case certificates change, some Linux distributions (like RHEL) expect that ipsec must be restarted (with all VPN tunnels broken).

Currently ipsec is configured directly with certificates used by connection endpoints. Another potential way of configuring ipsec is to define a list of trusted CA certificates. This way ipsec would check the certificate of the other connection endpoint against this list. As CA certificates do not change very often, ipsec restart problem (and some other problems) would be solved.

• Open questions

Is there a trustworthy way of automatically propagating VPN certificate updates from the directory used by TSLSync to ipsec configuration in the current solution?

What is the role of VPN client certificate, if it is separate from VPN server certificate? It is not used in ipsec configuration.

How to propagate CRL-based certificate revocation to ipsec/VPN tunnels?

• A proposal/discussion startpoint

It can be discussed whether the following changes could be applied to the current PKI model implementation. The proposal places trust in root/intermediary CA certificates. It has the goal of more precise control over the local truststores, at the same making it easier to handle the updates of the certificates.

• Truststores should only include CA certificates.
• TSLSync may fetch signature, tls and vpn certificates from NSL lists in central services and check them, but should not place them in the truststore.
• TSLSync should fetch endpoint addresses from NSL lists in central services and use them for NCP configuration by placing them in the epsos.properties file.
• TSLSync may have an option of fetching the root and intermediate CA certificates from central services, but normally they are managed locally by NCPs.
• CRLs published by the root and intermediate CAs are kept by NCPs up-to-date and all used certificates are checked against them.
• VPN configuration of the NCP is done using the root and intermediate CA certificates.
• For HTTPS communication, in TLS handshake certificates presented by the parties are checked by verifying the chain up to the trusted root CA certificate.
• In signature verification (assertions or NCP signatures) the signature certificate is checked by verifying the chain up to the trusted root CA certificate.
• NCP certificates are created according to the rules listed in D3.4.2 v. 2.2. The VPN client certificate is not mandatory.
• NSL lists are created according to the rules listed in D3.4.2 v. 2.2.