Re: [Netconf] Mandatory local configuration in Keystore groupings

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

Hi Kent and Martin,

I agree with the comments of Martin. If you look at the whole use case of key and certificate provisioning, (C) is simpler for both creation and removal. The issue of leafrefs adds even more on the side of (C).

Br,
Balazs

-----Original Message-----
From: Martin Bjorklund <[e-mail]> 
Sent: Tuesday, September 11, 2018 9:54 AM
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

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