Hi, I'm in the process of AD reviewing Kent's keystore and truststore drafts in NETCONF.
In both of these drafts, there is a desire to be able to use keys or certificates that are managed on the device, potentially as part of a TPM, and yet be able to reference those keys/certificates from the device configuration. There is also some reference to how this configuration may work with the system datastore. https://www.ietf.org/archive/id/draft-ietf-netconf-keystore-27.html#name-support-for-built-in-keys gives an example. Looking at the current version of the system datastore, https://datatracker.ietf.org/doc/draft-ietf-netmod-system-config/01/, my understanding is that this draft reinforces the requirement that <running> is always valid. Hence any data nodes in the <system> datastore, that are referenced from the configuration in the <running> datastore, MUST also be copied into <running>, so that it validates. Unreferenced descendant configuration (that won't stop <running> from validating) can be left in system, which is then merged with <running>, and validated as part of <intended>. This is the approach that the keystore/truststore explains. However, there is separately the issue that the build in keys and certificates may be updated via an out of band process, such that the current keys/certificates are stored on the device, and a stale copy of the keys/certificates ends up in the running configuration. The keystore/truststore draft mitigates this by stating that if the key/certificate config differs between <running> and <system>, then the values in <running> are ignored and the values in <system> take priority. However, my understanding is that this behaviour is the reverse of what we normally expect when merging configuration in the <running> and <system> datastores, where configuration in <running> overrides configuration in <system>. Ultimately, I think that this means that we would need special handling for key/truststore configuration rather than just following the normal behaviour. Hence, I wonder whether we are making this more complex than necessary. Rather than requiring that <running> is always independently valid from <intended>, then would it not be simpler to allow <running> to have invalid configuration but always require that whenever <running> is changed then <intended> is updated and must always be valid. This would allow <running> to reference configuration in <system> without requiring it to be copied into <running>. I still think that we should allow the configuration to be copied into <running> for clients that also want <running> to be validate independently from <intended>, but otherwise, the requirement of copying keys are certificates into running doesn't seem ideal. Any thoughts? Regards, Rob _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
