In the current Virtual Workshop, many vendors noticed the OpenXPKI Server and Cisco Server had an interoperability issue.

• OpenXPKI does not have any newlines \n
• Cisco follows the block newline encoding scheme

There may need to be clarification for EST servers to follow one or for clients to support both. Should there be an identifier for clients to know which?

The EST RFC defines a mechanism where EST clients can request that the EST Server generates the key pair for them, which is useful for EST Clients that are unable to generate a key pair with the required entropy in a reasonable time frame or without affecting the primary operation of the device.

However while researching EST Server implementations and testing during virtual workshops, limited support for EST Server side key generation has been found. And currently, no testing has been performed of additional security of the private key on top of TLS, as defined in RFC 7030 (https://tools.ietf.org/html/rfc7030#section-4.4).

Currently in BCP-003-03 we state that EST Servers & Clients MAY support this process.

Is it appropriate for some EST Clients to rely on the endpoint existing when there appears to currently be limited support for it?
In the BCP, there is provision for devices that cannot generate their own key pair to instead have the key pair and/or certificate loaded by an out of band method.

The question is more to do with visibility of which nodes implement BCP-003-03 in an NMOS system. If you assume your entire system is BCP-003-03 but in fact you still have manually configured nodes which required certificates to be manually provisioned then you might end up in a situation where some endpoints fail because of expired certificates. Having some means of identifying which nodes implement BCP-003-03 seems beneficial as you would immediately also know which ones don't and require manual intervention.

AMWA-TV/nmos-parameter-registers#20

Consolidating discussion about the reasons for a reload configuration endpoint and its API design from (https://basecamp.com/1791706/projects/15357148/messages/92126983) so they can be discussed on the call.

The primary reason for this endpoint at the moment is to trigger the renewal of a devices' TLS certificate at a defined point in time when the device is not in use, but this API could also be used; to trigger software updates, other configuration changes or support for monitoring data export eg. Prometheus.

Issue

1. Some devices may not be able to replace the existing certificate without affecting the devices primary operation (eg. Having to restart the application to install the certificate leading to loss of control and video)

• All possible steps should be taken to avoid this, such as being able to reload just the NMOS module (SIGHUP), Apache has a feature to reload a new config without restarting called ‘graceful’ (https://httpd.apache.org/docs/2.4/stopping.html)

2. Some devices may be unable to generate a new key pair (RSA or ECDSA) without affecting the devices primary operation.

• All possible steps should be taken to avoid this, such as using key algorithms that are less resource intensive and appropriate hardware acceleration.

Ultimately if a certificate expires, the device should perform the renew, regardless of if this will affect the primary operation of the device.

Practical Examples

• mbed TLS (https://tls.mbed.org/), cannot replace certificate without reload and generating RSA key creates an exception. Not tested generating ECDSA keys.

Proposal
The proposal is to add a new endpoint to the NMOS Specs /reload-config.

The /reload-config endpoint will cause the device to trigger the certificate renewal process of all its certificates, during this time the primary operation of the device maybe affected.

The /reload-config endpoint must have authentication, as the effect of calling it is disruptive to the operation of the device.

Prometheus has a similar feature for triggering the reload of new configurations using an API: sending a HTTP POST request to the /-/reload endpoint https://prometheus.io/docs/prometheus/latest/configuration/configuration/

If the certificate renewal operation is unsuccessful, the device should carry on using the original certificate if still valid and the operation should be re-tried again at an appropriate time.

An automatic or manual check should be perform after issuing the command to check the certificate has been renewed.

HTTP POST 
https://<hostname>/x-nmos/<TBC>/<version>/reload-config
Response:
HTTP 202: The request has been received but not yet acted upon
HTTP 403: Forbidden, client does not have the required access rights to perform this actions

Outstanding Questions:

• Is this API really required or could alternative work around be found? If just to allow key generation on low power devices EST server side key generation could be used, although support for the server side generation endpoint in EST implementations is limited.

If it is decided that the endpoint is required, further design decision are required

• Should a Node poll an endpoint on a controller or the controller send a request to an endpoint? The preference seems to be push based from a controller, discussion here: https://basecamp.com/1791706/projects/15357148/messages/92126983
• If running on Nodes, should it be its on API or added to an existing API spec eg. Node API
• How would you discover this endpoint?
• Security consideration of an API that can restart your application?

On the next call I would like to come to a decision as to whether this API is required.
Could anyone with practical examples of why this API is required please get in contact and I can anonymously add it to the list of practical examples

Another item that came up from the Virtual Workshop compare the OpenXPKI and Cisco EST servers.

• Cisco: supports sha1 and sha256
• OpenXPKI: supports sha256

I believe the limitation on the OpenXPKI is because of the security consideration when using low sha with ecdsa.

Due to SHA1's smaller bit size, it has become more susceptible to attacks which therefore led to its deprecation from SSL certificate issuers in January 2016. An example of the difference in size between SHA1 vs SHA256 can be seen in the following example hashes:
SHA1 - da39a3ee5e6b4b0d3255bfef95601890afd80709
SHA256 - e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855

Here https://www.keycdn.com/support/sha1-vs-sha256

In the Security Considerations section it maybe worth adding a note to recommend the following in a future release.

• EST Server's should limit the domains and hostnames which they will issue certificates for, to prevent certificates being issued for domains outside of the of private network, eg. google.co.uk, this maybe controlled using Name Constraints or via an implementation specific method.

https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1.10

In the BCP is specifies the use of the GeneralizedTime value of 99991231235959Z

The EST Client manufacturer SHOULD issue a unique TLS Client Certificate for every device. It is RECOMMENDED that the notAfter value be set to the GeneralizedTime value of 99991231235959Z

https://github.com/AMWA-TV/nmos-certificate-provisioning/blob/v1.0-dev/docs/1.0.%20Certificate%20Provisioning.md#est-client-1

This has not been tested in practice at any of the workshops and should be tested before the publication of any specifications. Some CA's may have trouble generating them, but primarily EST Server implementations should be tested to see if they accept client certificates with the never expire timestamp.