Re: [netconf] ietf crypto types - permanently hidden

[Martin Bjorklund <[e-mail]>]

Kent Watsen <[e-mail]> wrote:
> Hi Rob,
> 
> > Why is a separate action required to create the keys? 
> > 
> > Why is the configuration to generate a hidden key not sufficient for the device to automatically allocate a key in the TPM module?
> 
> 
> I seem to be failing with words. 
> Hopefully a picture will do the trick...
> 
> 
> 
> THIS IS WHAT WE HAVE CURRENTLY
> ==============================
> 
>                          |  Client is okay with the      |  Client is NOT okay with the  |
>                          |  private key being in config  |  private key being in config  |
>                          |  w/ nacm:default-deny-all.    |  i.e., wants "hidden" key.    |
>                          |  (doc model not impacted.)    |  (doc model impacted!)        |
>                          |  (this col more important)    |  (this col less important)    |
>                          |                               |                               |


I don't think the last column is less important.  That's the TPM case, right?


> -------------------------+-------------------------------+-------------------------------+
>                          |                               |                               |
> Client is okay with      |                               |                               |
> generating the private   |  <edit-config> can be used.   |  use <install-hidden-key>     |
> key (not best practice)  |                               |                               |
>                          |                               |                               |
> -------------------------+-------------------------------+-------------------------------+
>                          |                               |                               |
> Client is NOT okay with  |                               |                               |
> generating the private   |  Currently no solution !!!    |  use <generate-hidden-key>    |
> key (best practice)      |                               |                               |
>                          |                               |                               |
> -------------------------+-------------------------------+-------------------------------+


For the "no solution" case, it means that the client doesn't want to
write the private key, but it wants to read it.  Why should it read it
if it never writes it?  The whole point would be to be able to
re-generate the config on another device - but this would mean that
the client would use <edit-config> to pass the key, and it would be in
the upper left cell in table above.


> PROPOSAL: move "hidden" from action names to an input parameter, and let an action gen config
> =============================================================================================
> 
>                          |  Client is okay with the      |  Client is NOT okay with the  |
>                          |  private key being in config  |  private key being in config  |
>                          |  w/ nacm:default-deny-all.    |  i.e., wants "hidden" key.    |
>                          |  (doc model not impacted.)    |  (doc model impacted!)        |
>                          |  (this col more important)    |  (this col less important)    |
>                          |                               |                               |
> -------------------------+-------------------------------+-------------------------------+
>                          |                               |                               |
> Client is okay with      |  Either <edit-config> or      |  Use <install-key> with       |
> generating the private   |  <install-key> with input     |  input "hidden".              |
> key (not best practice)  |  NOT "hidden".                |                               |
>                          |                               |                               |
> -------------------------+-------------------------------+-------------------------------+
>                          |                               |                               |
> Client is NOT okay with  |  Use <generate-key> with      |  Use <generate-key> with      |
> generating the private   |  with input NOT "hidden".     |  with input "hidden".         |
> key (best practice)      |                               |                               |
>                          |                               |                               |
> -------------------------+-------------------------------+-------------------------------+

An option could perhaps be to let the "generate-key" with option
"not-hidden" create the private key in <operational> (still with
nacm:default-deny-all).  To re-create the key on another device, the
client would use install-key.


/martin