Re: [netconf] ietf crypto types - permanently hidden

[Martin Bjorklund <[e-mail]>]

"Rob Wilton (rwilton)" <[e-mail]> wrote:
> Hi Martin,
> 
> > -----Original Message-----
> > From: netconf <[e-mail]> On Behalf Of Martin Bjorklund
> > Sent: 01 May 2019 22:06
> > To: [e-mail]
> > Cc: [e-mail]
> > Subject: Re: [netconf] ietf crypto types - permanently hidden
> > 
> > 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".
> 
> Why is a separate action required to create the keys? 
> 
> Why is the configuration to generate a hidden key not sufficient for
> the device to automatically allocate a key in the TPM module?

This is a very good question.  Why don't we have actions for
"create-interface', "create-user" or "create-acl"?  In all these cases
we have config that a device internally parses and translates to
some internal procedure (perhaps ifconfig, adduser, iptables etc).

In a way, this case is different b/c the client needs control of
*when* the key is generated.  We cannot copy & paste some config to
another device and expect it to work exactly the same.  OTOH that
probably is true for other things as well; if a user has been created
in the config there might be files owned by that user stored in the
home directory.

Also, we might need the option to re-generate the key (even though the
current version doesn't support this).  But *this* could be done w/ an
action (if we need to support it).

What did I miss; what makes this case special so that it can't be
handled like other config?


/martin