Re: [Netconf] Mandatory local configuration in Keystore groupings

[Balázs Kovács <[e-mail]>]

Hi Kent,

See below.
Br,
Balazs

> -----Original Message-----
> From: Kent Watsen <[e-mail]>
> Sent: Thursday, August 30, 2018 11:15 PM
> To: Balázs Kovács <[e-mail]>; Martin Bjorklund
> <[e-mail]>; Balázs Lengyel <[e-mail]>
> Cc: [e-mail]
> Subject: Re: [Netconf] Mandatory local configuration in Keystore groupings
> 
> 
> 
> 
> > 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.
>

I meant the state in operational datastore is not reflected in some way in the configuration datastore. This was a confusion from my side.

> 
> > 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?
> 

Yes it makes, see below (also related to the 'hidden' enum discussion below).

> > 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).
> 

Ok, I follow.

> 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.
> 

With the containment approach, does it still mean that the operator must read the key names in <operational> and create a key and certificate in the configuration datastore, where key name must match a right key stored in <operational>? How can a key be removed?

> > 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.
> 

Ok.

> > 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?
> 

Well, ok, let's keep it as it is in the new must statement you proposed.

> > ...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!
> 

If it is 'hidden', then is there a need to set the real private key raw data? It can just be drawn as it was when invoking generate-asymmetric-key.  Or what is the difference between generate-asymmetric-key vs. setting 'hidden' enum (regardless of the user not being able to provide public key in 'hidden' case--which is currently a must)?

> > 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?
> 

What is the procedure to remove a key that was created via generate-asymmetric-key?

> Kent // contributor
> 
> 
>