Re: [netconf] ietf crypto types - permanently hidden

[Kent Watsen <[e-mail]>]

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

Yes, the last column is the TPM case, which are very important to support, but there's a subtly between:

a) there exists a TPM that the manufacturer uses to generate a protected private key, e.g., in order to pre-provision the device with an IDevID certificate.  (this is a hyper-critical use case to support)

and

b) there exists a TPM that average clients can use to generate a protected private key.  The motivation behind this is unclear to me, but perhaps because 1) the owner wants to use an LDevID certificate instead of the IDevID certificate, 2) the owner requires that the private key is TPM-protected, and 3) the device is unable to generate a second CSR using the same private key used for the IDevID certificate.  (given that I believe #3 SHOULD be supported, this use case seems less important, bordering on not important).



> 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.

We have to envision different classes of clients: regular-access and special-access.  Regular access clients should be able to ask the system the generate a private key to which they have no read-access.  Special access clients have read (and write) access, but presumably are only ever used to perform backup/restore operations.



> 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.

Yes, this is the goal, to enable not-hidden keys to be migrated to another device (but only by a special-access client).


Kent // contributor