Re: [netconf] ietf crypto types - permanently hidden

[Kent Watsen <[e-mail]>]

> 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.


> 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>.


> 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, 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?


Kent // contributor