Re: [netconf] ietf crypto types - permanently hidden

[Kent Watsen <[e-mail]>]

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


Kent // contributor