Re: [netconf] ietf crypto types - permanently hidden

[Martin Bjorklund <[e-mail]>]

Hi,

Kent Watsen <[e-mail]> wrote:
> 
> 
> > 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?
> 
> The specifics for how this could work would need to be defined.  Given
> that it is a special case, I think that we could constrain it heavily
> and target simple solution.  Depending how much text is required to
> describe it, it might be good to define an extension statement that
> could be placed on the actions.  While an extension statement may seem
> like it opens the gates for general use, we could further define the
> extension statement as being something that MUST NOT be used when
> general purpose operations are suitable such that, at least with the
> IETF, it could only be used in extraordinary circumstances.

Let's first agree on the issue about whether this action should exist
at all.

> > 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'.
> 
> Okay, but before making the edit, see comment below about lifetimes...
> 
> 
> 
> > 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'.
> 
> Indeed, fixed.
> 
> 
> > 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 'type' statement doesn't have 'description' as a substatement, 
> but, point taken, two updates:
> 
> In leaf private-key:
>   OLD:
>       A binary that contains the value of the private key.
>   NEW:
>       Either a binary that contains the value of the private key or, in 
>       the case of a hidden key, the value 'permanently-hidden'.
> 
> In enum permanently-hidden:
>   OLD:
>        The private key is inaccessible due to being protected by the
>        system (e.g., a cryptographic hardware module).
>   NEW:
>        The private key is inaccessible due to being protected by the
>        system (e.g., a cryptographic hardware module).  Since hidden
>        keys are only ever reported in <operational>, the value
>        'permanently-hidden' never appears in <intended>.

Ok, but perhaps s/<intended>/conventional configuration datastores/?

> > 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?
> 
> This seems like something new (and maybe wrong) and hence needs to be
> explained.  This seems new because we are saying that the lifetime of
> an operational value is tied to the lifetime of a configured value.
> Normally we talk about how operational values exist on their own and
> that, if one wants to override/extend them (e.g., associate a
> certificate to the private key created by the manufacturer),
> configuration would overlay the operational values.  By extension, if
> the configuration is removed, the operational values go back to their
> original state (i.e., existing on their own).  Here we're saying that,
> if the configuration (for the parent node) is removed, the operational
> values are removed as well.
> 
> Note that this statement was added because Juergen asked about how
> hidden keys could be removed/replaced.  We iterated towards not
> wanting to support the "replace" case

But why?  If an operator wants to replace, why should the list entry
first be deleted and then created and then the key can be generated?
This seems like a CLR to me.

> and this seemed like an easy
> way to handle the "remove" case.  Another way to do this would be via
> another action such as 'remove-hidden-key'.  What do you think would
> be best?

Ok, I see.  I think the text needs some clarification; make it more
explicit.  It needs to say that if a "permanently-hidden" private key
exists in <operational> under a parent config true node and this
parent node is deleted, the private key is supposed to be (MUST be?)
deleted from the system as well.

A remove-hidden-key action can be problematic b/c if you forget to
call this action and then delete the config, presumably you have
lingering keys in the system that you can't remove.


/martin