Subject: [Netconf] regarding keystore and related drafts

From: Kent Watsen <[email-masked]>
Date: Mon, 5 Mar 2018 22:01:03 +0000

As I recall, we left off with a general dissatisfaction with the keystore module's name and scope of content.  A couple of the larger issues were:

  - why call it "keystore" when it no longer stores keys?
  - should we factor out the crypto types into a module of its own?

So, with this in mind, I just submitted the following two I-Ds as candidate replacements for draft-ietf-netconf-keystore:

  https://tools.ietf.org/html/draft-kwatsen-netconf-trust-anchors-00
  https://tools.ietf.org/html/draft-kwatsen-netconf-crypto-types-00

Comments?  We can also discuss this idea some during the meeting in London.

Kent  // contributor

---

From: Qin Wu <[email-masked]>
Date: Thu, 8 Mar 2018 01:26:37 +0000

Hi, Kent:
Interesting drafts, for crypto types, is it designed for application requiring asymmetric key. I see RFC8177 works for application requiring symmetric key.
Would it be great to see crypto types covers all application requiring asymmetric key.

For trust anchors, I think this draft is more related to certificates, Do we need to consider certificate file format, e.g., PEM(text format), DER(Binary format)
Have we considered different certificate-type,e.g., built in ca certificate, ca issued certificate, local stored certificate, etc.

-Qin
-----邮件原件-----
发件人: Netconf [mailto:[email-masked]] 代表 Kent Watsen
发送时间: 2018年3月6日 6:01
收件人: [email-masked]
主题: [Netconf] regarding keystore and related drafts

Kent  // contributor

_______________________________________________
Netconf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netconf

---

From: Kent Watsen <[email-masked]>
Date: Sat, 17 Mar 2018 20:19:53 +0000

Hi Qin,

> Interesting drafts, for crypto types, is it designed for application
> requiring asymmetric key. 

Yes, the "private-key-grouping" grouping in crypto-types-00, like the
top-level "/keys" container in keystore-04, is for asymmetric keys.

> I see RFC8177 works for application requiring symmetric key.

Correct.

> requiring asymmetric key.

What do you mean by "all application"?

> For trust anchors, I think this draft is more related to certificates

It will likely be used mostly for certificates, but the model enables
SSH host keys can be configured as well.

> Do we need to consider certificate file format, e.g., PEM(text format), 
> DER(Binary format)

The typedefs for "x509" and "cms" both state that it is the DER encoding
of the ASN.1.  The DER can be converted to a PEM using standard tools, in
case a PEM is needed by the software internally. 

> Have we considered different certificate-type,e.g., built in ca 
> certificate, ca issued certificate, local stored certificate, etc.

It is the intent that any kind of x509 certificate can be stored.
Currently the draft shows that a single X.509 certificate is stored,
but this should be updated to allow a chain of certificates, in case
the trust-anchor cert is not a self-signed root certificate.  
I'm not sure, does this answer your question?

Thanks,
Kent