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 questions
What are the 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?
What are the relaxations currently in use?
Does the current model place trust directly in certificates (along with certificate distribution rules), in CAs that issue them, or both?
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, 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?
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?