[netconf] latest update to crypto-types and keystore drafts

[Kent Watsen <[e-mail]>]

I started off trying to create a variation of "#2" but, as got into it, I realized that *encrypting* the keys would solve most problems.  Note that we really don't want "hidden" keys at all, as them not being part of configuration causes backup/restore problems.  What we want are values that can be treated like config, but are non-sensical without the decryption key.  Values MAY be encrypted using a manufacturer-generated key (which locks the value to the device), or a key generated by a *privileged* admin, which opens up the possibility for the key to float between devices.  

Specifically, imagine the following:

Precondition:
1) devices are shipped from manufacturer with a hidden asymmetric key in <operational>

Post-SZTP Onboarding:
2) privileged admin copies manufacturer generated key from <operational> to <running>
3) privileged admin encrypts a well-known (secret to the organization) symmetric key using the public key from the manufacturer generated asymmetric key, and stores the result (i.e., <edit-config> into keystore.

Device Swap:
4) if replacing a device, load previous configuration.  Since all keys should be encrypted to the same symmetric key, it should load without error.  [note: one issue here with the secret symmetric key itself being loaded again, but since it was encrypted using to old device's manufacturer generated asymmetric key, the logic should be able to handle it.]

Runtime:
5) whenever a regular admin wishes to use a new key, they call the generate-symmetric-key or generate-asymmetric-key RPC, requesting the device to generate a key for them, encrypting the result using the secret organization key.  
6) The RPC output returns the key value (encrypted).
7) The regular admin uses e.g., <edit-config> to store the key into <running>.


Use cases: 
  0: normal (just NACM-protected) keys:  supported.
  1: manufacturer-generated permanently hidden keys: supported.
  2: device-generated keys: supported.
  3: device-generated keys in config: supported
  4: permanently hidden keys: not recommended nor directly
     supported, but one could always encrypt a key with the
     device's public key, thus generating a key that only the
     device can decrypt, and hence effectively permenently
     hidden.


Please let me know soon if you object to any aspect of this or, better, support it, as I need to update the remaining drafts to reflect these changes at some point soon.


Below are the change log entries.

crypto-types:

   o  Removed the 'generate-key and 'hidden-key' features.

   o  Added grouping symmetric-key-grouping

   o  Modified 'asymmetric-key-pair-grouping' to have a 'choice'
      statement for the keystone module to augment into, as well as
      replacing the 'union' with leafs (having different NACM settings.

   o Diffs: https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-crypto-types-08 <https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-crypto-types-08>


keystore:

   o  Replaced typedef asymmetric-key-certificate-ref with grouping
      asymmetric-key-certificate-ref-grouping.

   o  Added feature feature 'key-generation'.

   o  Cloned groupings symmetric-key-grouping, asymmetric-key-pair-
      grouping, asymmetric-key-pair-with-cert-grouping, and asymmetric-
      key-pair-with-certs-grouping from crypto-keys, augmenting into
      each new case statements for values that have been encrypted by
      other keys in the keystore.  Refactored keystore model to use
      these groupings.

   o  Added new 'symmetric-keys' lists, as a sibling to the existing
      'asymmetric-keys' list.

   o  Added RPCs (not actions) 'generate-symmetric-key' and 'generate-
      asymmetric-key' to *return* a (potentially encrypted) key.

   o  Diffs: https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-keystore-11 <https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-keystore-11>




Kent // contributor