Re: [netconf] ietf crypto types

Hi Martin,

> -----Original Message-----
> From: netconf <netconf-bounces@ietf.org> On Behalf Of Martin Bjorklund
> Sent: 01 May 2019 22:06
> To: j.schoenwaelder@jacobs-university.de
> Cc: netconf@ietf.org
> Subject: Re: [netconf] ietf crypto types - permanently hidden
> 
> Hi,
> 
> Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
> > On Tue, Apr 30, 2019 at 02:49:30PM +0200, Martin Bjorklund wrote:
> > > Kent Watsen <kent+ietf@watsen.net> 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?

Thanks,
Rob

> 
> 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
> _______________________________________________
> netconf mailing list
> netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf