Re: [netconf] ietf crypto types - permanently hidden

[Kent Watsen <[e-mail]>]

Hi Balazs,


> Also validation of required input and output seems more complicated to me.
>  
> How so?
>  
> The ‘value-to-be-generated’ “action” would require both the private-key and public-key set to the same, plus the algorithm be configured. Besides, if there is a must statement on any of these, does the must statement consider the ‘input’ or the ‘output’ values? I got a bit confused while thinking on these.

If I understand correctly, this could be addressed by a 'must' statement to ensure both the public and private key values have the "<value-to-be-generated>" prefix.


> Actually, I view  ‘generate-and-not-hide’ as a very common case.  That is, ask the system to generate the key (because clients are lazy and security best practice), and let standard NACM rules protect the key.   I think that systems supporting user-generated "hidden" keys will be somewhat rare, to the extent that there should feature statements enabling servers to indicate if they support the ability or not.
>  
> Maybe generate-and-not-hide would be widespread, but it is not my preferred choice of key handling due to that it opens up to the client to manage the key blob after first generation. So maybe all of these should be optional with features?

Yes, assuming we go this route...


> [...] 
> This removes the "verbs" (as you call them) and thus leaves open possibility for either "verbs" or action statements to be added in some future revision.   This subset still supports the critical use-case of a manufacturer-generated private key for a secure device identifier (i.e., IDevID).    Unfortunately, it does not support the security best practice use-case of having the device generate the private key.  The IESG (Security Directorate) may or may not be okay with this (obviously the shepherd would have to bring it to their attention), but perhaps it's worth testing their resolve and see what happens?
>  
> If so, can you clarify the configuration use case of client configuring <permanently-hidden>, does that produce a valid end-result?

With the latest no-"verbs" proposal, there would be no ability (defined by this model) for a client to itself create a 'permanently-hidden' key; only the manufacturer could do that.  However, in order for a client to use the manufacturer-generated hidden key, it would need to "copy" it from <operational> to <running>.   In <operational>, the 'algorithm' and 'public-key' values would be visible, but the 'private-key' would have the value 'permanently-hidden'.  So, in order to "copy" the key to <running>, the client would (presumably) copy these three values as they are in <operational>, including the string "<permanently-hidden>" for the private-key's value.  The description of the node would state that this is the only time a client can legally configure the value "<permanently-hidden>" (i.e., when the same key already exists in <operational>)


> Or would that be only an output pattern created as the result of a ‘generate-hidden-key’ action that may be added by an implementation augmenting the model?

It is primarily intended to be an output-only pattern, with the exception being that mentioned above.


> Regarding ‘encrypted by’, would that be only used when the device allows to back up encrypted keys to later restore it to same device (or any other that may get hold of the same encryption key in some way)?

Correct.  For example, TPM chips have the ability to encrypt keys using their "storage root key" (SRK), which 1) enables the key to be safely exported but 2) only the TPM having the SRK can import/decrypt it.   While I don't think it's possible for TPMs to migrate an SRK, other implementations may support that ability and so, as you say, it could possibly be put onto another device.


Kent // contributor