Re: [Netconf] Mandatory local configuration in Keystore groupings

[Kent Watsen <[e-mail]>]

> Balazs> I preferred the original short name and for me it was clear
> that this action produces a 'hidden' key. I actually like the idea 
> of changing the 'hardware-protected' enum literal to 'hidden'.

okay


> Balazs> I myself just started to realize that you intend to maintain 
> an operational tree that is out-of-sync with the configuration tree. 

unsure what you mean here.


> For example, a public key can be determined from the private key. It 
> is ok to require an instance of public key (with must) for a private
> key, but why is it mandatory to configure it? 

In most asymmetrical crypto system implementation, the only fact that 
is ensured is that you cannot find the private key from the public key.
The other way around, finding the public key from the private key is
trivial, but not guaranteed, in most cases.


> I did expect the public key filled in either by generate-asymmetric-key
> action, or by configuring private key. 

You want the public key to be automatically computed from the private
key, right?   It might be possible, but it's always possible that the
client can pass both, so the thinking is just do that - makes sense?


> Also the private-key, the public-key, and the algorithm leaves need to
> be in sync (all valid in respect to the other)

True.  I think you're making a case for letting the server derive the
public key, as the client might pass a mismatched set.  Deriving the
pubkey vs verifying a passed pubkey: both ops require crypto clue,
but only one is guaranteed to always work.


>>> 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?
>
> Balazs> The certificates in keystore are useless without a corresponding
> private key, so certificates of a key cannot be in the configuration 
> tree once the corresponding key is removed. By the way, how would a 
> private key be removed from <operational> if it does not exist in 
> configuration? If you do it with an action too, how would the 
> corresponding certificates be removed from the configuration?

Good points.


>> 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?
>
> Balazs> Was it so? I saw an A and B model, A containing 
> must "(algorithm and public-key and private-key)
>              or not (algorithm or public-key or private-key)";
> and B containing the keys and the certificates in separate container,
> and a note "I think model B is cleaner".

Right, but if you scroll up higher, I had previously had an (a) and (b)
[note lowercase] to which he said (b) was "better".  Maybe it's moot,
since his (A) was effectively my (b).

My point is that the containment approach 1) does resolve the he primary
goal (configuring a cert for a key in <operational> and 2) I'm not concerned
about the general scaling problem.  By "perhaps we don't worry about the
general case here?", I mean to say that I prefer keeping the containment
approach.


> If I got it well, model A would keep the containment and produce
> the key name after invoking the action (affecting the configuration 
> tree!?) at least covering the key removal use case properly.

Invoking the generate/load-asymmetric key actions, as thus far dscribed,
would NOT affect the config tree (i.e., <intended>), only <operational>.


> Balazs> If the key generation and load only affects the <operational>
> only, I would rather vote for model A having the containment relationship
> between key and certificate(s). 

This is my preferred approach as well.


> Plus, I would also think about the mandatory statements in the
> configuration tree whether all 4 leaves (name, private-key,
> public-key, alg) or just name and private key needs to be configured.

I'm think all four are needed.  Only public-key is possibly not needed,
but it's trivial to ask a client to pass it, so why not?


> ...but why use an action at all then?  Everything can be done via 
> standard configuration, right?
>
> Balazs> That is actually a good question. Until the enum had the 
> literal 'hardware-protected' only the configuration use case of 
> the private-key was a bit unclear. Now I assume configuring the 
> private-key as 'hidden' could do the same as generate-private-key,
> but in that case the operator has no means to configure the public
> key (the removal of the mandatory condition for the public key
> could solve this). Regarding 'alg', I guess if hidden private key
> is asked, then algorithm is an input, but if binary private-key
> is configured, then it is rather implicit. Would the action be
> needed then?

There are a few things off in what you write, but the most important
thing is that there is no way to *configure* (via <intended>) a hidden
key.  Trying to do so, by passing the "hidden" enum, means that the
real private key raw data would NOT be set!


> Balazs> The action in this case seem to make sense only if the 
> purpose of the actions is really to only affect <operational>. 

Yes, that is the intent.


> But based on the above, I doubt yet how affecting configuration 
> can be avoided (even with alt A -> to maintain consistent composition
> of key and cert) I think this question goes back to some YANG 
> principles and is beyond my YANG competence.

I'm not following, can you say a different way?


Kent // contributor