Re: [Netconf] Mandatory local configuration in Keystore groupings

[Kent Watsen <[e-mail]>]

>>> We could define a "load-asymmetric-key" action that has that behavior?
>>
>> Yes; if we decide to support this use case.  What do others think?
>>
> Would this action have 'name' and 'private-key' binary input and the 
> purpose to avoid setting the key via configuration and handling it 
> directly in <operational>? Is it an implementation risk to handle 
> the binary input via configuration but not via action?


The proposed "load-asymmetric-key" action would take 4 mandatory 
input parameters (name, alg, pub-key, and priv-key) and have no
output other than the key showing up in <operational> with the
private key "permanently-hidden".

To make things clearer, we might rename these actions to:
  - generate-permanently-hidden-asymmetric-key(...)
  - load-permanently-hidden-asymmetric-key(...)

Yes, use of these actions would be more secure since the private key
is thereafter permanently hidden.  If the goal is to have the private
key in configuration, then the action should not be used.


> In our opinion with Balazs L., we think it would be disadvantageous
> to change the model by ruining the containment relationship between
> certificate and corresponding asymmetric key. 

Can you say some more about this?  Is it mostly that the containment
is really intuitive?  That the relationship is linked both ways, 
whereas a leadref only goes one way?

Martin makes a case for 'B', but he also said that my 'b' was "Better"
but has scaling issues in the general case.  Perhaps we don't worry
about the general case here?


> The action of 'generate-asymmetric-key' is typically something that
> should have effect on the 'running' configuration too (by setting 
> the mandatory leaves) since the user wants to continue working with
> the result by deploying certificates or anything else related to 
> the created asymmetric key that needs configuration. 

Okay, but why use an action at all then?  Everything can be done via
standard configuration, right?


Kent // contributor