Open JamesGibo opened 4 years ago
Examined on call. Needs further discussion wrt #5.
Should this method be removed in v1.0 of the BCP, to be re-added once tested if required after work on #5 is complete? To prevent performance issues on low power devices, a mitigation was added to the BCP to disable automatic renewals, see #11 for more information.
I suggest removing support for server side key generation from the BCP and adding this issue to it to the v1.1 milestone
The current v1.0-dev now says that the "EST Server SHOULD support" it and "to accommodate low-powered devices, it is RECOMMENDED that this is carried out by the EST Server." So can this issue be closed?
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.