2023-01-11

1

Summary of development activities

Summary of ongoing development activities.

2

Handling of ocspFreshnessSeconds configuration value on the Security Server

Currently, the Security Server uses the smallest ocspFreshnessSeconds value that's available through global configuration. In practise, the Security Server reads the ocspFreshnessSeconds value of its own instance and all the federated instances, and picks the smallest one. It means, that if one of the federated instances has a smaller ocspFreshnessSeconds value than the Security Server's own instance, the ocspFreshnessSeconds value of the federated instance is used when checking a validity of an OCSP response.

For example, the ocspFreshnessSeconds value of the instance A is 84600 seconds (23,5 hours). Instead, the ocspFreshnessSeconds value of the instance B is 28800 seconds (8 hours). The Security Servers registered in the instance A that have enabled federation with the instance B use the ocspFreshnessSeconds value 28800. Instead, the Security Servers registered in the instance A that have not enabled federation with the instance B use the ocspFreshnessSeconds value 84600. The Security Servers registered in the instance B use the value 28800 regardless of the status of federation (enabled / disabled).

When looking at the Security Server source code, the current behavior is rather a feature than a bug. However, the current behavior is not logical and therefore, it should be changed. There are two alternative approaches to change the current behavior.

1. Use the ocspFreshnessSeconds value of the Security Server's own instance

When evaluating the validity of OCSP responses, the Security Server could always use the ocspFreshnessSeconds value of its own instance. This applies to all OCSP responses, including 1) OCSP responses related to Security Servers / Members of the same instance and 2) Security Servers / Members of federated instances. In other words, the ocspFreshnessSeconds value of the Security Server's own instance should always be used. The same principle must apply to the verifyOcspNextUpdate and ocspFetchInterval parameters too (this is already true).

Pros

• The X-Road Operator has full control over parameters that affect certificate validity within the instance.

  • For example, data is exchanged over federation between the instances A and B. The instance A's Security Servers accept the instance B's OCSP responses that are up to 23,5 hours old and the instance B's Security Servers accept the instance A's OCSP responses that are up to 8 hours old.

• Straightforward and easy to debug and understand since the same value is always used.

Cons

• Two federated instances may use different values that can be conflicting.

  • For example, in instance A the ocspFreshnessSeconds value is 1 hour and the ocspFetchInterval value is 20 minutes. Instead, in instance B the ocspFreshnessSeconds value is 24 hours and the ocspFetchInterval value is 2 hours. In instance B the Security Server refreshes its OCSP responses every two hours, but the cached OCSP responses are not valid in instance A after one hour of their issuance since the ocspFreshnessSeconds value of instance A is 1 hour.

• In federation, certificates are validated using some parameters that they were not designed for.

2. Use the ocspFreshnessSeconds value of the certificate owner's instance

Alternatively, the Security Server could use the ocspFreshnessSeconds value of the certificate owner's instance. For example, when data is exchange over federation with a member of a federated instance, the ocspFreshnessSeconds value of the federated instance is used. Instead, when data is exchanged with a member of the same instance, the ocspFreshnessSeconds value of the local instance is used. In this way, the ocspFreshnessSeconds value that is used is always defined by the certificate owner's instance. In this case, the verifyOcspNextUpdate value should probably follow the same logic for consistency. Instead, the ocspFetchInterval value should always be defined by the Security Server's own instance.

Pros

• Different (and potentially conflicting) values in two federated instances don't cause problems.

• Certificates are always validated using parameters that they were designed for.

Cons

• The X-Road Operator doesn't have full control over parameters that affect certificate validity within the instance.

  • For example, when data is exchanged over federation, Finnish Security Servers accept Estonian OCSP responses that are up to 8 hours old and Estonian Security Servers accept Finnish OCSP responses that are up to 23,5 hours old.

• Debugging is challenging since applied configuration values vary between local and federated data exchange partners.

• The verifyOcspNextUpdate parameter isn't currently shared with federated instances and sharing it would require bigger changes to the global configuration distribution logic.

  • Technically, the ocspFreshnessSeconds parameter is included in the shared parameters part of the global configuration that is shared with federated instances.

  • Instead, the verifyOcspNextUpdate and ocspFetchInterval parameters are shared as configuration parts that are accessible to the direct members of an instance only.
    

3

Open topics

Discussion on open topics.

Next meetings

• Meeting 9, February 15, 15:00-16:00 (EET, UTC +2)

• Meeting 10, March 15, 15:00-16:00 (EET, UTC +2)