[...] > Question 6: Copying TPM keys into :running > > This thread started with the realization that "the requirement of copying > keys [and] certificates into running doesn't seem ideal". Clearly, copying > things from TPMs into running is a nuisance for clients, a usability problem > (what if the key changes on the TPM outside of :running?) and a potential > security problem. As far as I can see, there is no requirement in > NETCONF/YANG to do any of this copying. A simple reference to the contents > (not unlike if the keys were inserted hardware) in the TPM should be fine. > It's simply a matter of modeling appropriately in the relevant YANG modules. >
Perhaps Kent can help us by summarizing why he believes copying is needed, i.e., why lazy references by name do not work for credentials stored in TPMs. Concerning the larger discussion about validation of running vs validation of intended: During NMDA developed, it became clear that some not quite relevant NETCONF implementations do actually validate intended when you asked them to validate running. And what happens between running and intended is not covered by any standards as of today. Is this bad? In a way yes and no. It is bad because some vcendors may read this as an invitation to do things that really mess up a client's expectations but it is perhaps also good since the distinction acknowledges reality. The discussion around system config is old (much older than the I-D) and this is a grey area and I assume that every bigger server has some places somewhere where it "cheats" a bit to deal with the problem. There is the option to just leave it like that, i.e., to trust that vendors will understand to not go over board with magic system config "cheats" or to work out solutions that may introduce another datastore or solutions to tag config in running that is not really under the control of a client (immutable flags play in here and perhaps the WG needs to discuss whether really both a system datastore and immutable flags are needed - at the end immutable config is coming from somewhere). The only lazy binding mechanism we have is to refer to resources by name. If the name resolution does not work out, the relevant config is not applied. This kind of works if data models are designed for it but this adds complexity to the modeling process. /js -- Jürgen Schönwälder Constructor University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 <https://constructor.university/> _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
