...

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?

...

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?

...

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.

...