Re: [netconf] ietf crypto types - permanently hidden

[Balázs Kovács <[e-mail]>]

Hi,

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

I might back off from this one. I guess mismatched key pairs can occur with regular configuration case too, so it all depends on the operator to provide the right pair, and it should be the operator's decision to do a graceful key switch by creating a new key instance or do an instant renewal on the same instance. If the peer device does not have to be reconfigured, the renewal on same instance could be a better choice.

Br,
Balazs

From: Kent Watsen <[e-mail]>
Sent: Thursday, May 2, 2019 6:19 PM
To: Martin Bjorklund <[e-mail]>
Cc: Balázs Kovács <[e-mail]>; [e-mail]
Subject: Re: [netconf] ietf crypto types - 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/?

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




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