Re: [netconf] ietf crypto types - permanently hidden

[Martin Bjorklund <[e-mail]>]

Hi,

Juergen Schoenwaelder <[e-mail]> wrote:
> On Tue, Apr 30, 2019 at 02:49:30PM +0200, Martin Bjorklund wrote:
> > Kent Watsen <[e-mail]> wrote:
> > > 
> > > Correct, as I didn’t think there was consensus yet.  Perhaps there is
> > > rough-consensus, and it may be that the only way to gauge that is to
> > > try and see how much push back there is.
> > > 
> > > Okay, so how about this, based on this thread, there appears to be
> > > support to add a flag to control if a key should be “permanently
> > > hidden” or not, in which case configuration is created.
> > 
> > I (still) object to this.  Actions shouldn't create config.  We
> > already have generic protcol operations to do this.  We go from a
> > document-oriented configuration model towards a command-oriented
> > model.  Not good.  In RESTCONF, the generic methods support things
> > like ETags, which I suspect you don't want to replicate in this
> > action?   Will the action support all error-options of edit-config,
> > like rollback-on-error?
> >
> 
> Martin,
> 
> do you have any proposal how to support the requirement to generate a
> key on the device that is workable with a document-oriented
> configuration model? Do you propose that the action/rpc returns the
> public key information as result data that then needs to be written
> back to the server and somehow matched to the key that is cached on
> the device? Perhaps you have other ideas I can't think of?
> 
> I think I would be happy to not have this special hack but then we
> need a workable alternative. Key generation on devices is something
> that is being used - and may be even more used in the future the more
> we get special hardware support for storing keys.

So the current draft supports two use cases:

  1.  The client configures the private and public keys explicitly
      (simple case).  Both keys are availible in the config and
      operaional state.

  2.  The client asks the device to generate a "hidden" key which may
      be a key in special TPM hardware.

For 2, the client configures the name of the key (in <running>).  Then
the client invokes the action (in <operational>).  The device
generates a new key pair (perhaps in tpm-hw).  In <operational>, the
public key is now visible and the private key has the special enum
"permanently-hidden".

A device that doesn't have special hardware can still implement 2, but
store the keys in the filesystem.  Perhaps this info needs to be
visible for the client, or even controlled by the client.

What I object to is a third use case, where the action would modify
the config with the generated keys.


/martin