Re: [Netconf] Adoption poll for crypto-types and trust-anchors

[Kent Watsen <[e-mail]>]

Makes sense.  Thanks Eric.
Nothing more below.
Kent



On 5/23/18, 8:12 AM, "Eric Voit (evoit)" <[e-mail]<mailto:[e-mail]>> wrote:

From: Eric Voit, May 11, 2018 6:13 PM


From: Kent Watsen, May 10, 2018 6:31 PM
Kent writes, in response to Balazs:
You're right about that, if added later, it may not be widely implemented.  Back to the technical discussion, some important points have been raised.  Perhaps it is better after all to keep ietf-keystore, the -03 version, before the private key was converted to being a grouping.  Right now, the adoption poll is showing weak support, and this seems to be the core issue.  Hearing from others on this point would be very helpful!

<Eric> I do like providing grouping which allow key-pairs to be defined and used in various models.

<Kent> It's possible to both have groupings (for those that want them) and to use those groupings in a keystore data model.  The only question then would be if the ietf-[ssh/tls]-[client/server] modules use one, or the other, or both?  [I think the idea of bringing back the keystore module would be then to just use it in our modules]

<Eric2> I don’t have a very strong opinion on this.  I see this more of a preference question of how much modularity do we want.  My assumption is that in the security space, solid modular identities & group definitions might play a role similar to that of RFC 6021 for common YANG types.

<Eric> One question on this, leaf public-key in draft-kwatsen-netconf-crypto-types-00 has a must constraint for a private key, which is fine for the purpose of this grouping.  But do you see a case where other YANG modules might want to pick up using the schema definition of public key and the various key algorithm identities defined?  Maybe for someone who just wants to store decryption keys?  If yes, perhaps an extra grouping definition?

<Kent> Potentially.  If I understand you correctly, the public-key-only grouping wouldn't be used in any current modules (e.g., in the keystore module), but merely be available for anyone who might want just a public-key in the future?

<Eric2>  Yes.  As your module is being designed for such reuse already, it would seem a natural extension at low cost.

<Eric3>  Based on the set of discussions, I support adoption.  This is worthwhile topic for the WG.
Eric

Eric

Kent // contributor