2023-10-19

Date and Location

Oct 19, 2023 at 15:00-16:00 (EEST, UTC+3)

Location: Microsoft Teams

Attendees

  • Petteri Kivimäki (NIIS)

  • Raido Kaju (NIIS)

  • Aivar Meisterson

  • Jalmar Jerlei

  • Juhani Nuorteva

  • Oleksii Danyliuk

  • Teemu Theqvist

  • Tõnis Pihlakas

Discussion items

#

Item

Notes

#

Item

Notes

1

Summary of development activities

Summary of ongoing development activities.

2

Adding/removing Central Server nodes and rotating configuration sign keys without uploading a new configuration anchor to the Security Server manually

Currently, adding/removing Central Server nodes and rotating configuration sign keys requires generating a new configuration anchor and uploading it to the Security Server manually. This is not optimal since the new anchor must be uploaded by each and every Security Server admin before the changes are applied to all the Security Servers. It is possible to get rid of having to upload the new configuration anchor manually by publishing the anchor online and making the Security Server download it regularly (e.g., once a day).

Alternative A

  • Publish configuration anchor online on an external host (not on the Central Server).

    • Publishing the configuration anchor on an external host is a manual task. When a new anchor is generated on the Central Server, it’s not synchronized to the external host automatically. Instead, the X-Road Operator syncs the new anchor to the external host manually.

    • The external host must have a TLS certificate issued by a trusted CA.

      • The CA must be trusted by the Security Server's Java installation.

      • However, for test and development purposes the TLS certificate validation can be disabled.

  • The anchor download URL can be defined in country-specific meta packages so that the Security Server admin doesn't need to define it manually.

    • When the anchor is available online and the download URL is defined in the county-specific meta package, the “Import configuration anchor” step can be skipped in the Security Server initialization process.

  • Importing the anchor manually to the Security Server is still supported too, e.g., the anchor is not published online, the download URL is not reachable for some reason.

  • Publishing the configuration anchor online is optional and can be configured for each X-Road ecosystem separately. If the anchor is not published online, then it must be uploaded manually just like now.

  • The Security Server uses the anchor download URL to download the configuration anchor regularly (e.g., once a day) and applies the changes.

    • The configuration download interval can be configured for each X-Road ecosystem just like the global configuration download interval can be configured now.

Publishing the configuration anchor online exposes the anchor for DNS-related threats. There are two options ways to mitigate the threats:

  1. Use DNSSEC to secure data exchange in DNS.

    1. Is configured by the X-Road Operator using the platform of the DNS provider who hosts the domain where the configuration anchor is published.

    2. Does not require changes to X-Road.

    3. Implementation complexity: low.

  2. The Central Server signs the configuration anchor and the Security Server verifies the signature when the anchor is imported.

    1. Requires changes to X-Road.

      1. Implement a new configuration anchor sign key and certificate on the Central Server.

      2. The anchor sign certificate can be either included in the configuration or it can be imported separately to the Security Server.

    2. Implementation complexity: medium.

Alternative B

Keep the configuration anchor as it is and do not publish it online. Instead, the information regarding Central Server nodes and global configuration sign keys is added to the global configuration. In this way, the Security Server gets the initial Central Server node URL(s) and global configuration sign key(s) from the configuration anchor when it's uploaded for the first time during the Security Server initialisation. As soon as the Security Server starts downloading the global configuration after initialisation, the Security Server starts using the information available in the global configuration. In this way, the Security Server has always up-to-date information since the information in the global configuration gets updated as soon as the Central Server configuration changes. Also, it's still possible to upload the configuration anchor to the Security Server manually too.

Summary of the alternative B:

  • Keep the configuration anchor as it is now and don't publish it online.

  • Keep the Security Server initialisation process as it is now.

  • Add the information regarding Central Server nodes and global configuration sign keys to the global configuration.

  • After uploading the configuration anchor, the Security Server starts using the information available in the global configuration.

  • The Security Server has always up-to-date information since the information in the global configuration gets updated as soon as the Central Server configuration changes.

  • Uploading the configuration anchor to the Security Server manually any time is supported as it is now.

The X-Road Technical Committee has decided that adding/removing Central Server nodes and rotating configuration sign keys without uploading a new configuration anchor will be implemented using alternative B.

3

X-Road High Level Road Map 2024-2031

An online presentation recorded at the X-Road Community Event 2023 is available here.

4

Open topics

  • X-Road Metrics version 1.2.0 has been released. The release notes are available here.

  • X-Road Community Event 2023 recordings are available on YouTube.

  • Harmony Access Point version 2.2.0 has been released. The release notes are available here.

    • The biggest change in the new version is Docker support for Harmony Access Point.



Next meetings

  • Meeting 17, November 15 2023, 15:00-16:00 (EET, UTC +2)

  • Meeting 18, December 13 2023, 15:00-16:00 (EET, UTC +2)

  • Meeting 19, January 17 2024, 15:00-16:00 (EET, UTC +2)

  • Meeting 20, February 14 2024, 15:00-16:00 (EET, UTC +2)