Page Comparison

MISP2 is used in Estonia, and Finland has piloted it in 2021. The current implementation is designed for Estonia and includes a lot of Estonia specific details. Removing the details and making the implementation country neutral would require a significant effort.

Therefore, NIIS is conducting a study whether a similar component is still needed and what are its requirements coming from current and potential future X-Road users and EU policies (e.g., supported authentication methods on the EU level). Based on the results, either MISP3 or a totally new extension replacing MISP in its current form could be designed and developed. The aim of this task is to conduct a user research to collect requirements for MISP3. The study will be conducted online and it will take place in January-February 2023.

NIIS is looking for members of the X-Road Community to participate in the study. If you're interested in participating in the study, please contact NIIS by email (info@niis.org) or Raido / Petteri in the X-Road Community Slack.

NIIS HAS further studied supporting ACME for both AUTH and SIGN certificates for Security Servers. Since ACME is designed for TLS certificates, it expects that the certificates are directly tied to a domain. This means that while AUTH certificates are easier to support, SIGN certificates require changes in the certificate profiles. Specifically, CN, which in many cases currently contains the member code, should contain the DNS instead.

The main change requirements that we have determined are:

• In the CA metadata on the Central Server it should be possible to specify if a CA supports ACME (global configuration change) and optionally specify the CA-s ACME API path.
• The Central Server could optionally verify that the CA supports ACME.
• Certificate profiles need to be updated to support ACME (CN field mapped to DNS/IP). There are three different options:
  1. Create a new root / sub CA with a new certificate profile.
     • Clear separation between the old and new profile, the most straight forward to implement on the X-Road's side.
     • Not fully backward compatible (old Security Servers don't support the new certificate profile), CA must create a new root / sub CA that's associated with the new certificate profile, implementing a new certificate profile is required.
  2. Have one CA support multiple certificate profiles.
     • The current root / sub CA can be used
     • Not fully backward compatible (old Security Servers support one certificate profiles per CA), the most complex to implement on the X-Road side, implementing a new certificate profile is required.
  3. Have the existing profile support both the ACME and old format.
     • The current CA / sub CA can be used, no need to implement a new certificate profile.
     • Not fully backward compatible (old Security Servers don't support the updated format of the certificate profile), the current certificate profile must be updated, there's no clear separation between the current and new profile.
• Security Servers should support the ACME challenge:
  • HTTP - this requires that port 80 is used and open to the CA to send the challenge, supports both DNS and IP. Currently, on Ubuntu systems, port 80 is reserved for the local proxy client endpoint. This would mean that we have to move that to a different port. For new installations, the local proxy client endpoint could be changed to a different port by default, but existing installation would require manual configuration change IF they want to use ACME.
  • DNS - this requires changing TXT records in the DNS configuration. Changing the DNS configuration might be difficult or impossible to automate depending on the DNS provider which would mean that the configuration must be updated manually by the Administrator.

In addition, we need to agree how the CA-s would support this:

• They of course need to support the standard ACME protocol.
• keyUsage and extKeyUsage needs to be handled for SIGN certificates. This means that the CA needs to know which type of certificate it needs to generate:
  • It could be defined in the CSR, but CA-s usually have their own templates and will ignore this information.
  • The CA could have multiple templates, and will determine which one to use based on an attribute.
  • We could have different CA-s for AUTH and SIGN certificates.
• Public ACME CA-s probably won't support SIGN certificates due to the requirements.

Security:

• By default, ACME CA-s will accept any new account and will tie the public key to future orders.
• There is also an option to have external account binding, but it is an extension so the CA-s would need to implement this. More details are available here: https://www.rfc-editor.org/rfc/rfc8555.html#section-7.3.4
• The HTTP challenge endpoint should be implemented so that it can not be intercepted by a man-in-the-middle attack.

In November, the X-Road Working Group decided that that alternatives 2 and 3 will be looked into further, with the preference being on alternative 3. The implementation of the ACME support will most likely begin during the second half of 2023 and the feature could be available in X-Road during the first half of 2024.

• Meeting 8, January 11, 15:00-16:00 (EET, UTC +2)
• Meeting 9, February 15, 15:00-16:00 (EET, UTC +2)
• Meeting 10, March 15, 15:00-16:00 (EET, UTC +2)