Re: [netconf] ietf crypto types - permanently hidden

[Martin Bjorklund <[e-mail]>]

Kent Watsen <[e-mail]> wrote:
> 
> >> 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/?
> 
> Fixed in my local copy.
> 
> 
> >> 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.
> 
> https://mailarchive.ietf.org/arch/msg/netconf/ZwXll9BtAv61EvVXtFDLLzTkljE
> <https://mailarchive.ietf.org/arch/msg/netconf/ZwXll9BtAv61EvVXtFDLLzTkljE>
> 
> 
> 
> > 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.
> 
> Added, with a MUST.
> 
> 
> > 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.
> 
> I don't think this is true.  Even if an asymmetric key only exists in
> <operational> (i.e., the corresponding "config true" parent node is
> deleted), it seems that a 'remove-hidden-key' could still remove it.
> In fact, this is the most consistent thing, to have an 'action' act on
> values in <operational>.

You're right.  If we have "create" action it makes sense to have a
"delete" action.  But see the mail from Rob W.  Perhaps we shouldn't
have these actions at all?


/martin