Re: [Netconf] Mandatory local configuration in Keystore groupings

[Martin Bjorklund <[e-mail]>]

Hi,        

Kent Watsen <[e-mail]> wrote:
> 
> There are two solutions being discussed here.  
> 
> The first regards how to enable a certificate to be configured for a key
> in <operational> (e.g., an LDevID cert for a preexisting key).  Both
> solution (A) and (C) give us this - a la RFC 8342 Section C.3.2.
> 
> The second is how to delete a "hidden key" created by a client (note here
> that I'm distinguishing this case from hidden keys not created by a client,
> i.e., in <operational>, which cannot be deleted).  Here's where the ideas
> diverge:
> 
>   - with (A), we keep the "generate" action outside the list entry (thus
>     results are in <operational>, and add a new "delete-asymmetric-key"
>     action is needed.
> 
>   - with (C), the action is moved inside the list entry, thus the list
>     entry node itself in <intended>, and hence can be removed from
>     <intended> via a normal config operation (no special action needed).
> 
> I don't see an issue configuring certificates in either case.  As I wrote
> above, both solution (A) and (C) give us this. (C) still has to handle
> the case where the key is in <operational> same as (A).  With (C), it's
> the 1% case, whereas with (A) it’s the 100% case.

How can a key be in operational but not in config in (C)?  I.e., what
is the 1% case?

> They seem close.  For the purpose of creating a key, (C) is more
> complicated.  For the purpose of deleting a key, (C) seems easier.

For the purpose of creating a certificate (A) is more complicated.

Depending on the answer above, (C) has the advantage that references
(leafrefs) to a key can be require instance true.  With (A) they have
to be require instance false, since some keys only exists in
operational, which means that whenever there is a reference to a key,
that model and code must be able to handle the case that the key
doesn't exist.





/martin


> 
> If the action is brought inside the list entry, then renaming it to
> "generate-hidden-key" makes sense.
> 
> Kent // contributor
> 
> 
> 
> -----Original Message-----
> 
> Hi Martin,
> 
> I prefer your alternative (C) with some comments.
> 
> I'd keep the name of the action as 'generate-asymmetric-key'. I think the word 'asymmetric' gives a hint on its intended use case, so it is important (though it is already in an asymmetric-key list). The word 'hidden' is not that important for me since the action in itself hints that the key in this case is not provided by the operator, thus its binary value won't appear either. If operator needs to provide it, it has to go via the 'private-key' leaf. Or the action could be just called 'generate-key'.
> 
> A question still: it is unclear to me what the difference is between calling the action vs just configuring the 'private-key' to enum 'hidden'.
> 
> Br,
> Balazs
> 
> 
> > -----Original Message-----
> > From: Martin Bjorklund <[e-mail]>
> > Sent: Monday, September 3, 2018 12:18 PM
> > To: [e-mail]
> > Cc: Balázs Kovács <[e-mail]>; Balázs Lengyel
> > <[e-mail]>; [e-mail]
> > Subject: Re: [Netconf] Mandatory local configuration in Keystore groupings
> > 
> > Kent Watsen <[e-mail]> wrote:
> > > > Balazs> The certificates in keystore are useless without a
> > > > Balazs> 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
> 
>