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

[Balázs Kovács <[e-mail]>]

Hi Kent,

Yes, sorry. This addition of symmetric-key is still to new to me. I meant the equivalent of clear and NACM protected key under symmetric keys. Which is just called ‘key’ in draft-ietf-netconf-keystore-12.

The reasons could be: the TPM or equivalent key may not exist or may not be present in keystore (which are roughly the same); or since the encryption of the operator-key is all up to the client, the client may just not implement encryption with the TPM or equivalent hidden public key as the client does not see extra security gains with that (the operator-key was created outside anyhow so it is already known by the client).

Br,
Balazs

From: Kent Watsen <[e-mail]>
Sent: Monday, August 5, 2019 8:46 PM
To: Balázs Kovács <[e-mail]>
Cc: [e-mail]
Subject: Re: [netconf] latest update to crypto-types and keystore drafts




On Aug 5, 2019, at 3:58 AM, Balázs Kovács <[e-mail]<mailto:[e-mail]>> wrote:

Hi Kent,

Yes, it makes.

I assume the “secret” symmetric key could be just equally configured as normal private-key since the key is coming from outside, depending on the taste of the client if it is just a NACM protected normal private-key or an encrypted key.

Since a symmetric key have "secret" value more so than "private" value, if we replace "private-key" with "secret-key" above, then yes, I agree.  Stated more plainly, a platform that doesn't have a TPM (or equivalent) protected asymmetric key, could instead protect the operator's symmetric key using NACM (i.e., only the crypto-officer/ restore-session can access it).  Is this what you mean?




Br,
Balazs


Kent