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

["Xialiang (Frank, Network Integration Technology Research Dept)" <[e-mail]>]

Hi Kent,
Thanks for the quick response, and I am with all your plan, which I think is a good design and easy to achieve.

Keystore and related management drafts are very important for netconf implementations for us, very happy to see it's in progress.

B.R.
Frank

-----邮件原件-----
发件人: Kent Watsen [mailto:[e-mail]] 
发送时间: 2018年5月19日 9:27
收件人: Xialiang (Frank, Network Integration Technology Research Dept) <[e-mail]>; Balázs Kovács <[e-mail]>
抄送: [e-mail]
主题: Re: 答复: [Netconf] Adoption poll for crypto-types and trust-anchors

Hi Frank,

I recall your speaking at the mic after my presentation in London.  You introduced yourself as being from the security area, thanks for jumping in here.


> 1. I second Balazs’s opinion of centralized keystore has more benefits 
> for us as a vendor, which is more easy, secure and efficient in the 
> management aspect;

Agreed, this is what I was thinking about originally.


> 2. My preference is to roll back to keystone -03 version for the 
> design of centralized keystore, and at the same time, defining the 
> asymmetric-key-grouping and local-or-keystore-asymmetric-key-grouping 
> (as below email) with better modelling reusability, more importantly, 
> support both centralized and local identity implementation. In 
> addition, the new trust-anchors draft is necessary as one individual 
> model;

I'm also of this opinion now.  By moving the trust-anchors out of keystore into its own module, the remainder of what would be in the keystore module would truly be just for the storing of keys.  Also, as discussed earlier, it makes little difference to implementation complexity, on either the client or server sides.  Lastly, the individual that expressed concern for keystore before has since expressed non-interest in this topic, so I think that fully clears the way to do this.  To be clear, what's being discussed is to adopt the two new drafts and *keep* the keystore draft, but with all the drafts being changed in ways described below.


> 3. The relation with other netconf/ssh/tls client-server drafts: there 
> are still a lot of duplicated key pair, certificate and trust-anchors 
> definitions in these drafts, should they directly reference the 
> uniformly defined models in these keystore related drafts in future?

Please note that the current versions of those drafts were updated to reflect the change in keystore from -03 to -04.  When we talk about rolling back the keystore draft, we're implicitly also rolling back those drafts to their previous versions, though perhaps we might use the new "local-or-keystore" key grouping (thoughts?).  Could you please check and confirm that this is what you're looking for?


> 4. For the crypto-types draft, maybe in further versions, we can 
> consider more key algorithms, such as: DSA, ECDSA.

Absolutely, in the fullness of time.  Be aware that the current draft crypto-types draft is just what's needed to support the various client/server drafts, and I'd like to keep it close to that goal for its first publication.  I understand that you have some drafts in SACM that could/should also import the crypto-types module.  To this end, let's ensure the first publication of this module is in line with our/your plans for how it needs to be extended to support your drafts.  


Summarizing the changes to the various drafts:

a) the keystore draft would essentially rollback to its -03 version with the trust-anchor part deleted, while retaining the "asymmetric-key" grouping introduced in -04, and introducing a new "local-or-keystore" key grouping.

b) the crypto-types draft would remove the asymmetric-key grouping and also the certificate-expiration notification (both moved to the resurrected keystore draft).  This means that it would only have identities and typedefs remaining.

c) the trust-anchors draft would have just a small change, to import and use the crypto-types module.

d) all the client/server drafts would be updated to either only reference keystore keys or, maybe use the new "local-or-keystore" grouping discussed above.

In my view, upon doing this, all these drafts should then be ready for Last Call.

Could folks comment on this plan?   Would it help if I posted updates to all the drafts as described above?


Kent  // contributor