Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

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

The short version

The OpenPeppol network is migrating to a new PKI infrastructure.

  • After 2018-09-03 00:00:00 all Access Points in the network MUST entrust both the current PKI infrastructure and the new PKI infrastructure. Transactions can still be sent using ANY PKI infrastructure.
  • After 2018-11-30 23:59:59 all Access Points in the network MUST only send and receive transactions using the new PKI infrastructure.

Background

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

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

Dictionary

TermClarification

AP

Peppol Access Point
SMPService Metadata Publisher
T1Date when PKI migration starts
T2Date when PKI migration ends
C1Internal
date for when no certificated for PKI v2 Infrastrcuture can
date when issuing of PKI v3 certificates will commence
C2Internal date when PKI v2 certificates can no longer be issued
exchange
Exchange transactionsAbility for
an
a PEPPOL Access Point to both send and receive transactions
PKI v2
InfrastructureThe current PKI infrastructure that is used and from which we aim at migrating
Certificates

The PKI certificates that are currently in use, that we are migrating from

PKI v3
Infrastructure
CertificatesThe PKI
infrastructure which is currently being put in place and at which we aim at migrating
certificates being implemented, that we are migrating to

Process implementation and timeline

Refer to the graph below;

  1. After C1 the operational office of OpenPeppol will commence issuing of PKI v3 certificates.
  2. Up until date T1;
    1. All APs MUST be able to exchange transactions using the PKI v2 Infrastructurecertificates
    2. All SMPs MUST support PKI v2 Infrastructurecertificates.
    3. SML MUST support PKI v2 Infrastructurecertificates.
    4. PEPPOL Directory MUST support PKI v2 Infrastructurecertificates.
  3. After date T1 and until date T2;
    1. All APs MUST be able to initiate a transaction (send) using ANY of the two available PKI infrastructures certificates (v2 or v3).
    2. All APs MUST be able to support receiving transactions initiated using BOTH available PKI infrastructure certificates (v2 and v3).
    3. All SMPs MUST support BOTH available PKI infrastructure certificates (v2 and v3).
  4. Before C1C2;
    1. All (operational before T1) AP and SMP providers will have been issued certificates from the PKI v3 infrastructure (this is an internal OpenPeppol deadline).
  5. After date T2;
    1. All APs MUST only be able to exchange only exchange transactions using PKI v3 Infrastructurecertificates.
    2. All SMPs MUST only support PKI v3 infrastructure..certificates.

C1 = 2018-04-18 00:00:00

T1 = 2018-09-03 00:00:00

C1 C2 = 2018-10-31 23:59:59

T2 = 2018-11-30 23:59:59

Image Added

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.

...

  1. Before T1. Prepare your implementation so that it will be able to entrust transactions/signatures using the PKI v3 Infrastructurecertificates.
  2. Between T1 and T2 (and before C1). You will be issued a client certificate from the PKI v3 infrastructure. Replace For your Peppol Access Point implementation, replace the current client certificate with the new one. Remember to update all participants in your SMP with public part of the new Any receivers (participants) you might have registered in an SMP must also be updated with the public key of the issued PKI v3 certificate.
  3. After T2. Patch your implementation so it no longer entrusts transactions/signatures using the current (then old) PKI infrastructurecertificates.

For SMP providers;

  1. Between T1 and T2. You will be issued a client certificate from the PKI v3 infrastructure. Replace the current client certificate with the new one. (we need to add more documentation here, there is a process for this part of the migration that has been documented by CEF)

The needed Root and Intermediate CAs are available for download here. 



Access PointSMP

PEPPOL Directory

SMLOpenPEPPOL

SendingReceivingServerClient


No later than T1
  • Must be able to validate MDNs signed with PKI v3.
  • MUST accept an incoming transaction signed with either PKI v2 or PKI v3.

  • Must accept responses signed with PKI v2 and v3
  • MUST accept SMP client certificates for both PKI v2 and v3.
  • MUST accept SMP client certificates for both PKI v2 and v3.
After T1 only v3 certificates will be issued.
After C1





All service providers should have a v3 certificate.

No later than T2
  • MUST be able to sign transactions with PKI v3.
  • Must use PKI v3 to sign MDNs
  • MUST update AP configuration with AP certificate PKI v3.
  • Provide PKI v3 SMP certificate to SML operator so they can update their entry.
  • Update all SMP entries to use a PKI v3 AP certficate
  • Must use PKI v3
  • Must use PKI v3
  • Must use PKI v3

After T2
  • Disable PKI v2 support
  • Disable support for receiving transactions signed with PKI v2.
  • Disable PKI v2 support
  • Disable PKI v2 support
  • Disable PKI v2 support
  • Disable support for SMP client PKI v2 certs.

...

ProviderIn PROD before T1In TEST before T1In TEST after T1Enter TEST after T1Certificate expire expires before T2Certificate expire expires after T2Recommendation
AP/SMPYES---YES
You will be prioritized in the process for being issued a PKI v3 certificate before T1. If you still believe you will not have time to install it can't install it before end of expiry of PKI v2 certificate certificates, then renew PKI v2 certificate and follow matching recommendation for that situationscenario.
AP/SMPYES---
YESBefore C1 you will have been issued a PKI v3 certificate. Make sure to implement this certificate into your platform before T2.
AP/SMP-YES

--If you complete your tests and become eligible for a PROD certificate before T1. You will be prioritized in the process for being issued a PKI v3 PROD certificate before T1.
AP/SMP-
YES
--If you complete your tests and become eligible for a PROD certificate before T2, you will be issued a PKI v3 PROD certificate. If you fail to complete your tests before T2, you will have to reapply for a PKI v3 TEST certificate.
AP/SMP-

YES--You will use a PKI v3 TEST certificate for your testing .You will be issued a PKI v3 PROD certificate when you complete tests and become eligible for a PROD certificate.

...