Re: [netconf] ietf crypto types - permanently hidden

[Kent Watsen <[e-mail]>]

> What I object to is a third use case, where the action would modify
> the config with the generated keys.

What is your proposal for how to address the best practice and, in some cases, 
government requirement, that a private key never exists outside of a device 
(controlled backups aside)?


From https://revocent.com/best-practices-for-securing-private-keys: <https://revocent.com/best-practices-for-securing-private-keys:>

    "It’s crucial that the generation of the key be done on the same system and the same
     local filesystem as the storage location.  Generating the key on a server and then
     transferring the key back to the local system and storing it just adds multiple points
     of vulnerability.  Why would you want to increase the chance of your private key
     being compromised?"


Additionally, SC-12(3) of NIST 800-53 says:   (note: the word "produce" is key here)

    "Produce, control, and distribute asymmetric cryptographic keys using [Selection: 
     NSA-approved key management technology and processes; approved DoD PKI
     Class 3 certificates; prepositioned keying material; approved DoD PKI Class 3 or
     Class 4 certificates and hardware security tokens that protect the user’s private
     key; certificates issued in accordance with organization-defined requirements]."


Many networking devices include an SSL-protected web-interface.

    1) Typically the interface is initially secured via a self-signed certificate, which
         causes the browser to display a nagging message when connecting,
         thus prompting remediation.

    2) Almost all products include an ability to upload the 2-tuple of a private key
         and a signed certificate.  This resolves the self-sign cert issue, but the
         best practice and government compliance concerns are not addressed.

    3) The better products have an ability to:
          a) let the device generate the private key
          b) let the device generate a certificate signing request using its private key
          c) upload to the device a certificate generated by an external CA signing the CSR.   
          [FWIW, Juniper's SRX device introduced this ability in 2011.]

The current model supports (2), as well as (3b) and (3c), we're just missing (3a), 
which is what the original `generate-asymmetric-key` action was for.


FWIW, from a product perspective, supporting (3a) is more important then supporting
`generate-hidden-key` or `install-hidden-key` (so long as manufacturer-generated
hidden keys are still supported, e.g., for IDevID certificates).   While client-generated
permanently-hidden keys is goodness, it's not widely implemented.


Kent