PKI Certificate Migration 2018

Please find below information related to activities needed as part of the migration to a new version of the PEPPOL PKI Certificate.

For information about the Certificate issuing process please refer to the OpenPEPPOL public space  for /wiki/spaces/Public/pages/191496224

Background

The decision why this migration is necessary and why it cannot wait until current PKI infrastructure expires is based on several reasons;

• Improved security. The current PKI infrastructure is based on SHA-1 cryptography which not long time ago was announced as not recommended to use due to discovered exploits. The new PKI infrastructure will issue certificates supporting SHA-256 cryptography which currently is the recommended web standard.
• Responsible organization. In current PKI infrastructure the issuing agency organization is "DIGST" (Danish Agency for Digitisation) and it has been requested that this responsibility is migrated to the correct organization.
• Minor improvements. Some smaller changes to the naming convention of the certificates will make it easier to maintain the certificates and also utilize a more cost effective pricing which will not be based on issued certificate but on taken seat.

Process implementation and timeline

Refer to the graph below;

1. Up until date T1;
   1. All APs MUST support current PKI infrastructure. (clarify what 'support' really means for sending/receiving)
   2. All SMPs MUST support current PKI infrastructure.
   3. SML MUST support current PKI infrastructure
   4. PEPPOL Directory MUST support current PKI infrastructure
2. After date T1 and until date T2;
   1. All APs MUST initiate a transaction using ANY of the two available PKI infrastructures.
   2. All APs MUST support receiving transactions initiated using BOTH current PKI infrastructure AND the new.
   3. All SMPs MUST support BOTH current PKI infrastructure and the new.
3. Before C1;
   1. All (operational before T1) AP and SMP providers will have been issued certificates from the new PKI infrastructure. (Update: OpenPEPPOL internal deadline)
4. After date T2;
   1. All APs MUST only support new PKI infrastructure.
   2. All SMPs MUST only support new PKI infrastructure.

T1 = 2018-04-03 00:00:00 (Suggestion Rune: too early)

C1 = 2018-08-15 23:59:59 (Suggestion Sven: 2018-09-15)

T2 = 2018-09-30 23:59:59 (Suggestion Sven: 2018-10-30)

Technical implementation

How to implement this from a technical point of view is dependent on the AP or SMP platform used. There will not be a guideline available for every platform, but the general approach is as follows.

For AP providers;

1. Before T1. Prepare your implementation so that it will be able to entrust transactions/signatures using the new PKI infrastructure.
2. Between T1 and T2 (and before C1). You will be issued a client certificate from the new PKI infrastructure. Replace the current client certificate with the new one. Remember to update all participants in your SMP with public part of the new certificate.
3. After T2. Patch your implementation so it no longer entrusts transactions/signatures using the current (then old) PKI infrastructure.

For SMP providers;

1. Between T1 and T2. You will be issued a client certificate from the new PKI infrastructure. Replace the current client certificate with the new one.

The needed CAs are available for download here.

v2: current PKI version.

v3: new PKI version

How to act as a service provider?

Please refer to this matrix to identify which situation applies to you.