Re: [netconf] crypto-types fallback strategy

["Rob Wilton (rwilton)" <[e-mail]>]

From: Kent Watsen <[e-mail]>
Sent: 18 September 2019 18:03
To: Rob Wilton (rwilton) <[e-mail]>
Cc: Salz, Rich <[e-mail]>; [e-mail]; Rifaat Shekh-Yusef <[e-mail]>
Subject: Re: [netconf] crypto-types fallback strategy

[moving Russ and Sean to BCC, per Rich's action]



Minor: Does the “string” in the description above mean “ASCII string” or “binary string”, RFC 4251 seemingly uses both definitions?

I don't know, but this is the language found for the "key-data" leaf in RFC 7317 (i.e., we've been living with this definition for awhile)



Is putting the encrypted keys into DER-encoded OneSymmetricKey obviously the right thing to do?  Are there other choices?


Yes, if there was one thing that came out of my discussion with Russ and Sean is that OneSymmetricKey and OneAsymmetricKey SHOULD be used for encrypting key data.   Anything else would be a BIG effort.
[RW]
OK.

The real question is if we should also use the One*Key structures for unencrypted keys, which could help some ways, but I think that it's better to use the values provided by OpenSSL command line.  This approach pushes the complexity of using the One*Key structures to just the "advanced" case of when encryption is needed and, besides, it would primarily be for the NC/RC server to generate/parse; clients would rarely encrypt a key themselves, the only case I can think of when they might would be for the RMA workflow we discussed a few weeks back.

[RW]
I would suggest only using the One*Key structures for the encrypted key data.

Thanks,
Rob


Kent