Re: [netconf] ietf crypto types - permanently hidden

[Martin Bjorklund <[e-mail]>]

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?


Some comments on the new text:

In action generate-hidden-key, it should be stated that the public-key
will be populated, and that the private-key will exist but report
'permanently-hidden'.

In action install-hidden-key, shouldn't both public-key and
private-key be mandatory?  Also state that the private-key will report
'permanently-hidden'.

In leaf private-key, the type binary part of the union doesn't have a
description, and the description for the leaf itself says:

       A binary that contains the value of the private key.

which is not quite correct.

I think we should state that the enum 'permanently-hidden' is only
reported in operational state.

The new descriptions say:

            [...] present only in
            <operational> and bound to the lifetime of the parent
            'config true' node.

Aren't all nodes bound to the lifetime of their parent?
The action is invoked in a node that exists in <operational> and it
creates a key.  What does the statement tell me?


/martin



> 
> This change will be in the next update, in about a week’s time, if no
> objections are raised.
> 
> Kent // contributor
> 
> 
> > On Apr 30, 2019, at 7:30 AM, Balázs Kovács
> > <[e-mail]> wrote:
> > 
> > Hi Kent,
> >  
> > I don’t see the your proposal below addressed in latest update
> > (keystore-09). Was it missed?
> >  
> > My recommendation is to modify the "generate/install-hidden-key"
> > (renamed to just "generate/install-key") actions to have a flag
> > indicating if
> > the key should be "permanently hidden" (perhaps by using a TPM) or
> > not, in
> > which case configuration is created, same as if the client had used
> > <edit-
> > config>, but without needing to touch the key.
> > 
> > 
> > I agree that having a flag to control the behavior is useful and I
> > think there should be explicit text how the action fails in case the
> > requested action cannot be performed.
> >  
> > Br,
> > Balazs