Re: [Netconf] Mandatory local configuration in Keystore groupings

[Kent Watsen <[e-mail]>]

 
> > BTW, all private keys should have nacm:default-deny-all.

Updated in my local copy.  Added to the "asymmetric-key-pair-grouping"
grouping, so all downstream users inherit it as well.



> I think that the operation "generate-asymmetric-key" only affects
> "permanently-hidden" keys, doesn't it?  If the client wants visible
> keys, it will configure them in the config datastores.

It wasn't so locked down before.  How about the following two changes?

1. Updated the action's description statement:

      action generate-asymmetric-key {
        description
          "Requests the device to generate an asymmetric key using
           the specified asymmetric key algorithm.  This action is
           used to request the system the generate a key that is
           'permanently-hidden', perhaps because it is protected
           by a cryptographic hardware module.  The resulting
           asymmetric key is considered operational state and
           hence present only in <operational>.";

2. updated the enum's description statement:

          enum "permanently-hidden" {
            description
             "The private key is inaccessible due to being
              protected by the system (e.g., a cryptographic
              hardware module).  It is not possible to 
              configure a permanently hidden key, as a real
              private key value must be set.  Permanently
              hidden keys cannot be archived or backed up.";
          }   



> > Regarding the name, s/hardware-protected/permanently-hidden/?
>
> I think this is better.

Okay, but maybe it should be just "hidden"?



>> Now you have me second-guessing this.  Maybe a device, without special
>> hardware, could present the illusion of a permanently-hidden private
>> key - it's completely inaccessible from the device's supported 
>> interfaces, though actually present on the filesystem.
>
> This is what I would like to support.

Okay.



>> >> Unsure what you mean.  Currently all these values are configurable.
>> >> Or are you trying to find a way to only "configure" them in 
>> >> <operational>?
>> >
>> > Yes, *if* my use case of not exposing the private keys is supported,
>> > then it would be useful to be able to generate the keys off-box, and
>> > install them into <operational>.
>> 
>> Hmmm, sounds like *configuration*, not something goes into <operational>.
>> 
>> And, even if you did, that doesn't mean the keys are permanently-hidden.
>> I suppose the model could let the client set that parameter as well,
>> but it somewhat defeats to goal of *never* having the private key exposed,
>> not even as a once in a lifetime kind of thing.  That’s just my opinion,
>> we should ask for more opinions if you're not convinced.
>
> I'm not convinced either way, actually ;-)  It would be good to hear
> other opinions as well.

We could define a "load-asymmetric-key" action that has that behavior?



> This is what I would expect as well, but the model is not quite
> designed for this currently.  For example, suppose I generate a
> HSM-protected key with "generate-asymmetric-key".  It is then present
> in <operational>, with a public key etc.  Now I want to configure a
> certification for this key, so I have to create an entry in the
> "asymmetric-key" list, where I have to set both the
> private-key and public-key leafs (they are both mandatory); so I
> assume I have to use the exact values reported in <operational>?

Hmmm, using the same value could work, but it doesn't seem intuitive
and, from a general modelling perspective, doesn't scale e.g., what 
if there were 100 descendants?

A couple other options:

 a) make each leaf (algorithm, public-key, private-key) type be a
    union having an enumerated value like "in-operational"

 b) replace the three "mandatory true" with three "must" expressions
    that assert either all or none of the leafs are set.


> Another design could be to have the certificates in a separate list,
> with leafrefs (require-instance false) into the "asymmetric-key"
> list.

Perhaps, but let's see if we can make this work first.


Kent // contributor