Re: [Netconf] Mandatory local configuration in Keystore groupings

[Martin Bjorklund <[e-mail]>]

Kent Watsen <[e-mail]> wrote:
> > 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.

Yes.  The lifecycle of keys are not handled fully in the current
draft.  But I think that if this is done properly, separating the
config of keys and certificates would not change the lifecycle of how
keys.  So let's first discuss how we want to handle creation and
removal of the hidden keys (configured keys are not a problem).

With the current draft, a hidden key is created in <operation> with an
action and may not be present in <running> and <intended>.  There is
no way to delete such a key.  We would have to create a new action to
remove it.

An alternative design could be to move the action
"generate-asymmetric-key" into the "asymmetric-key" list (and maybe
rename it to "generate-hidden-key").  A client would then first have
to configure an entry in the "asymmetric-key" list, and then it can
generate the hidden key.  If the asymmetric-key list entry is removed
from <intended>, then presumably the corresponding hidden key is
removed as well.

With this design, a separate "certificate" list could have normal
leafref (require-instance true) into the "asymmetric-key" list.
However, with this new design my original issue with how certificates
are handled goes away, so having them contained in the
"asymmetric-key" list works fine.

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

Here's the new alternative:

(C)

  container keystore {
    container asymmetric-keys {
      list asymmetric-key {
        key name;

        leaf name { ... }
        leaf algorithm { mandatory true; ... }

        leaf public-key { ... }
        leaf private-key { ... }

        // ensure that both or none are given
        must "(public-key and private-key)
              or not (public-key or private-key)";

        action generate-hidden-key { // no input params }

        container certificates {
          list certificate { ... }
        }
    }
  }

A possible extension to this would be to add anoter action next to
"generate-hidden-key":

   action install-hidden-key {
      leaf public-key { ... }
      leaf private-key { ... }
   }


One case to consider is that there may exist an entry in <intended>
that has been configured but no hidden key has yet been generated.
Such an entry would then not exist in <operational>, and the action
"generate-certificate-signing-request" would fail.



/martin



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