Page Comparison

1

Summary of development activities

Summary of ongoing development activities.

2

Changes to the X-Road support model

Up until recently, all of the support requests and feature requests for both our NIIS members and the X-Road community

went through the X-Road Service Desk in JIRA. This

limited the interaction opportunities and also visibility of common issues for the community. To improve the situation, the following changes have been implemented:

• All support requests from the community go to X-Road GitHub repository issues.

• All feature requests from the community go to X-Road GitHub repository discussions.

• All support and feature requests from the NIIS members and partners continue going through the X-Road Service Desk.

The changes provide a few benefits over the previous model:

• More community involvement on the open-source side with regards to feature requests, as it’s possible to have a public discussion there where everyone can chime in. It’s also possible to gague interest in the feature by taking a look at the interaction with the posts.

• More visibility for the community into common issues users come across and how to solve them.

• Gathering troubleshooting information into a public place to create a naturally growing knowledge base.

• Publicly available information on known-issues for releases.

• The NIIS members and partners still have a private line.

3

Publish global configuration over HTTPS

There are three alternative approaches how publishing global configuration over HTTPS could be implemented:

Alternative 1

• Publish global configuration over HTTPS using a TLS certificate issued by a trusted CA.

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

• Each Central Server and Configuration Proxy node needs their own TLS certificate (=one TLS certificates per node).

• The same TLS certificate is used for both internal and external configuration.

  • Internal and external configuration can be served from the same port.

• The TLS key is generated automatically during installation/upgrade, but the TLS certificate must be applied and configured manually by the X-Road Operator.

  • The TLS key and certificate must be rotated manually.

• For test and development purposes the TLS certificate validation can be disabled on the Security Server.

• Federation is supported since certificates issued by trusted CAs are used.

• Implementation complexity: low.

Alternative 2

• Publish global configuration over HTTPS using TLS certificates issued by the global configuration sign keys.

  • The Security Server trusts the TSL certificates since the global configuration sign key is present in the configuration anchor.

• Each Central Server and Configuration Proxy node needs their own TLS certificates (=two TLS certificates per Central Server node, one TLS certificate per each published configuration per Configuration Proxy node).

• Internal and external configuration have different TLS certificates which means that they must be published in different ports, e.g. internal configuration on port 443, external configuration on port 4443.

• On the Central Server, the TLS key and certificate generation, configuration and rotation (when global configuration sign keys are rotated) are automated.

  • Configuration Proxy requires manual configuration (initial configuration + rotation).

• Federation is supported since the Security Server already trusts the external sign key of federated instances.

• Implementation complexity: medium.

Alternative 3 (prerequisite: the configuration anchor is signed)

• Publish global configuration over HTTPS using a TLS certificate issued by the configuration anchor sign key.

  • The Security Server trusts the TSL certificate since the configuration anchor sign key is included in the configuration anchor.

• Each Central Server and Configuration Proxy node needs their own TLS certificate (=one TLS certificates per node).

• The same TLS certificate is used for both internal and external configuration.

  • Internal and external configuration can be served from the same port.

• The TLS key and certificate generation, configuration and rotation (when configuration anchor sign key is rotated) are automated on the Central Server and Configuration Proxy.

• A new web service endpoint to query configuration anchor sign certificates is needed on the Central Server and Configuration Proxy.

  • The endpoint is used by the Security Server to query configuration anchor sign certificates - both local and federated instances.

  • The endpoint URL must be configured on the Security Server manually during the initialization or automatically using country-specific meta packages.

• Supporting federation is possible, but the implementation is complicated.

• Implementation complexity: high.

The X-Road Technical Committee has decided that publishing global configuration over HTTPS will be implemented using alternative 1.

4

Open topics

• X-Road Catalog has been published in a new GitHub repository owned by NIIS. However, installation packages (binary) are not available in NIIS Artifactory yet. The X-Road Catalog backlog is available in JIRA.

• The Security Server security assessment will be conducted by a third party in Q4 / 2023.

• X-Road Community Event takes place online on Friday 22nd September. Registration is now open!

Next meetings

• Meeting 16, October 19 2023, 15:00-16:00 (EEST, UTC +3)

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

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

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

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