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

From: Kent Watsen <[email-masked]>
Date: Thu, 3 May 2018 16:58:52 +0000

Hi Balazs, and Balazs,

Thanks for permission to forward this thread to the list.  All, please be sure to read the message below too.

Yes, I'm aware and familiar with various key protection strategies.  The current ietf-keystore module was modeled after MacOS's "keychain access", but it didn't define a protection layer (e.g., internally encrypted and with an access-controlled API), though one could be added later.  The keystore module is very much in-line with what you write and, for that, I think it counts as a "no/do not support" of sorts.

The reason why we're proposing to move away from the keystore module was prompted by Juergen, who questioned if any implementations of SSH or TLS use a KMS and are we creating unnecessary complexity.  As it stands, the current proposal still has SSH/TLS implementations referencing a global "trust-anchors" store, so there is still "complexity", at least in terms of there being a dependency.

The current proposal moves the storage of private keys from being in a centralized keystore (where they can be leafref-ed) to each instance of a ssh/tls client/server.  By doing so, we think that it is less complexity, though I'm not convinced, since the definition of the private key itself is the same, it's just now not leafref-ed.  Perhaps this is an incremental step, whereby we next abandon using the private-key groupings altogether for SSH-specific and TLS-specific variants.  This is very possibly needed, and I might add that no one has implemented any of these modules, AFAIAA.

Adding to this discussion, I was yesterday wondering, with the two new drafts, how a client would configure a server to use a TPM-protected private key and its associated IDevID certificate.  Note that this key and cert are "configured" by the manufacturer and thus, somehow, must be *referenced* (not stored locally) by the ssh/tls client/server modules.   I was able to find a way to reference the private key (via its public key), but I was never able to figure out how to reference the DevID cert (IDevID or LDevID?).    I was thinking that, if we don't go back to using the keystore module, we might be able to modify the private-key grouping definition to enable it to either be locally stored  or be a reference to some future TBD thing.  I haven't tried to do this yet, but being able to do this seems important, and therefore may sway my support for disbanding the keystore module/draft…

Kent // contributor

On 5/3/18, 7:08 AM, "Balazs Lengyel" <[email-masked]<mailto:[email-masked]>> wrote:

Hello Kent,
I would like to add that in Ericsson the preferred solution is central storage for keys. It makes administration and enforcement of good security practices simpler for the operator.
regards Balazs Lengyel
(Feel free to forward this to the list.)

-------- Forwarded Message --------
Subject:

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

Date:

Thu, 3 May 2018 11:15:57 +0200

From:

Balázs Kovács <[email-masked]><mailto:[email-masked]>

To:

Balázs Lengyel <[email-masked]><mailto:[email-masked]>

Bocs, bcc lemaradt

-----Original Message-----

From: Balázs Kovács

Sent: Thursday, May 03, 2018 11:16 AM

To: Kent Watsen <[email-masked]><mailto:[email-masked]>

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

Hi Kent,

I know you might prefer me sending this to the list, but I try this way first. I was a bit away from keystore works and did a quick check. I see you have the below poll ongoing, and I've seen the presentation you had in London.

I must say it was a bit surprising to me backing out from centralized keystore model and the statement of centralized keystore being uncommon. Storage of keys is a security sensitive and problematic area. Secret keys at rest usually need to be encrypted. The provisioning or storage of secret encryption keys, the secure storage, and rotation of keys are a complicated enough matter so that it justifies centralized key store implementations. There are centralized key management systems such as Hashicorp Vault, Azure Key Vault, Google Cloud KMS, OpenStack Barbican, etc.. that solve the above matters. These SW can be used by an implementation to outsource the key management issues, and even if it is outsourced, outsourcing from a central implementation does give benefit since the client usually also needs some client credential that is access controlled on KMS server side.

The other aspect I saw as benefit in centralized keystore was on the YANG interface side. As long as only machines are assumed to operate on these IETF modules, I assume distributed management of keys doesn't matter much, but when it starts to drive human interfaces directly then the configurations of protocols that import and use these security groupings become quite complex. Ok for this one you still have the trust anchors, but for keys the central model was dismissed, but for management aspect, I really don't see why is the difference.

Can you clarify? Have you considered KMS implementations when making this proposal of removing keystore?

Br,

Balazs

-----Original Message-----

From: Netconf [mailto:[email-masked]] On Behalf Of Kent Watsen

Sent: Tuesday, May 01, 2018 11:57 PM

To: [email-masked]<mailto:[email-masked]>

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

[I'll get the ball rolling, please, others chime in too]

I support the adoption of these two drafts to replace the existing keystore draft.

Regarding the "certificate-expiration" notification defined in ietf-crypto-types, I would like to discuss removing it, or moving it to be a descendent of the "certificates-grouping" grouping (also in ietf-crypto-types) and maybe also place a copy of the notification in the ietf-trust-anchors module.  That said, I don't like having several otherwise identical notifications in different namespaces, but I do like how the server can incrementally add support for expirations on a feature-by-feature basis.

Kent // contributor

===== original message =====

This is the start of a *two* week poll for adopting the following two drafts as working group documents, specifically to replace draft-ietf-netconf-keystore, which would be removed as a working group document:

  draft-kwatsen-netconf-crypto-types-00

  draft-kwatsen-netconf-trust-anchors-00

This call for adoption is the result of the Keystore draft presentation given in London.  When the various options were discussed, most preferred to move forward with these two drafts, as opposed to looking to do more factoring or extending to scope to include things not needed by our various client/server drafts.  No one expressed interest in moving forward with draft-ietf-netconf-keystore.  While we could separately confirm this result again on the list, we believe that an adoption call more efficiently achieves two goals at once.

Please send email to the list indicating "yes/support" or "no/do not support".  If indicating no, please state your reservations with the document.  If yes, please also feel free to provide comments you'd like to see addressed once the document is a WG document.

Kent (and Mahesh and Ignas)

_______________________________________________

Netconf mailing list

[email-masked]<mailto:[email-masked]>

https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netconf&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=qXS002RrOOkzqTDm70cWjg7eJeWqtpC_anWUcc9a_3I&s=1W689R8ht-U3FoffJ5uTT24SAPRtiQ9a9B3VxQxM_Wg&e=

_______________________________________________

Netconf mailing list

[email-masked]<mailto:[email-masked]>

https://www.ietf.org/mailman/listinfo/netconf<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netconf&d=DwMD-g&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=dy-Dg3ToTuGVBuY3XcOLDkV_tW3vuQDSz6i1wawzjjM&s=4zwr17et_2w1it4jlw_k1ksQ-q-v7_iTSKUI4E_yK4g&e=>

--

Balazs Lengyel                       Ericsson Hungary Ltd.

Senior Specialist

Mobile: +36-70-330-7909              email: [email-masked]<mailto:[email-masked]>

---

From: Kent Watsen <[email-masked]>
Date: Fri, 4 May 2018 18:41:26 +0000

Following up on this, I did think of a way enable configuration to specify, e.g., which DevID cert to use for a factory-defined private key.  The idea is to change the private-key grouping to reference certificates from the "trust-anchors" data tree (as opposed to locally-storing the certificates).  A 'union' or a 'choice' may allow for both options.

What I don't like about this proposal is that it is conceptually muddies what is a "trust anchor".  Currently, trust anchors are exclusively used to authenticate remote devices, whereas the DevID certificates are more about how the device authenticates itself to remote devices; furthermore, DeviD certs are the end-entity half of the certificate-chain (not the issuer-half).  Yes, in both cases, the partial chain is manifested as one or more X.509 certificates, and thus syntactically the same, but it still doesn't seem right to call them "trust anchors".

Perhaps we could define some other top-level data-tree for "identity certificates", which could include both a private key and its associated certificates.  This would be the "future TBD thing" mentioned below.   I can see this working, but is it any better to have separate "trust-anchors" and "identity certificates" trees, or a single "keystore" tree that contains both?   One benefit to having a single keystore module is that then the "certificate-expiration" notification has more value, applying to both identity and trust anchor cert, as it's good to know when either types of certificate is expiring.

Kent // contributer

On 5/3/18, 12:58 PM, "Netconf on behalf of Kent Watsen" <[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> wrote:

Hi Balazs, and Balazs,

Kent // contributor

Hello Kent,

-------- Forwarded Message --------
Subject:

Date:

From:

To:

Bocs, bcc lemaradt

-----Original Message-----

From: Balázs Kovács

Hi Kent,

Br,

Balazs

-----Original Message-----

Kent // contributor

Netconf mailing list

Netconf mailing list

--

Senior Specialist

---

From: Balázs Kovács <[email-masked]>
Date: Mon, 7 May 2018 13:47:53 +0000

Hi Kent,

I believe between SSH/TLS implementations using keys in clear and a persistent storage there has to be some protection layer for the keys, and keystore did a good job representing the management aspects of this layer. Obviously, this layer is possible to get implemented without a keystore model, but then I think the user side of the keys (e.g., Netconf/Restconf) have to be flexible enough to handle keys locally or refer to central point of management (if anyone would implement that in addition).

Regarding your example with TPM, if considering the most simplistic case, wouldn’t referencing a TPM key be adequate just through presenting the public key value? I guess that could be done without a keystore, and at least is shown that a key is operational for the user-side protocol.

To sum up, I have the following concerns:

  *   Centralized management of keys/identity certificates/credentials as standard was appealing to us and we would still prefer it; however, we would be probably ok to have it as future work, if you prefer that. The user side of the keys (e.g., Netconf/Restconf) should be flexible enough to handle keys as both referenced and local data (for example, choice with only one standard case?).
  *   I don’t understand the idea behind keeping the trust anchors in central model versus the keys in local model. What is the rationale behind this split?

Best Regards,
Balazs

From: Netconf [mailto:[email-masked]] On Behalf Of Kent Watsen
Sent: Friday, May 04, 2018 8:41 PM
To: [email-masked]
Subject: Re: [Netconf] Adoption poll for crypto-types and trust-anchors

Kent // contributer

Hi Balazs, and Balazs,

Kent // contributor

Hello Kent,

-------- Forwarded Message --------
Subject:

Date:

From:

To:

Bocs, bcc lemaradt

-----Original Message-----

From: Balázs Kovács

Hi Kent,

Br,

Balazs

-----Original Message-----

Kent // contributor

Netconf mailing list

Netconf mailing list

--

Senior Specialist

---

From: Kent Watsen <[email-masked]>
Date: Mon, 7 May 2018 15:57:53 +0000

Hi Balazs,

Regarding your two concerns:

1) 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!

2) There is a difference, the trust anchors can be a large list that sharable by many modules.  For instance, an admin wouldn't want to configure the same set of trust anchors once for RESTCONF and again for NETCONF.  However, private keys are generally application-specific, each having their own.  Sometimes more than one app might share a private key (e.g., /etc/ssl/private/), but this isn't very common.  Maybe the question isn't how common it is, but if it MUST be supported.  For instance, I know that many services (HTTPS, POPS, IMAPS, anything with `stunnel`, etc.) can all be configured to use the same private key.  MUST ietf-tls-server be able to support this?

Kent // contributor

On 5/7/18, 9:47 AM, "Balázs Kovács" <[email-masked]<mailto:[email-masked]>> wrote:

Hi Kent,

-          Centralized management of keys/identity certificates/credentials as standard was appealing to us and we would still prefer it; however, we would be probably ok to have it as future work, if you prefer that. The user side of the keys (e.g., Netconf/Restconf) should be flexible enough to handle keys as both referenced and local data (for example, choice with only one standard case?).
-          I don’t understand the idea behind keeping the trust anchors in central model versus the keys in local model. What is the rationale behind this split?

Best Regards,
Balazs

Kent // contributer

Hi Balazs, and Balazs,

Kent // contributor

Hello Kent,

-------- Forwarded Message --------
Subject:

Date:

From:

To:

Bocs, bcc lemaradt

-----Original Message-----

From: Balázs Kovács

Hi Kent,

Br,

Balazs

-----Original Message-----

Kent // contributor

Netconf mailing list

Netconf mailing list

--

Senior Specialist

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Tue, 8 May 2018 18:09:59 +0000

From: Kent Watsen, May 7, 2018 11:58 AM

Hi Balazs,

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

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?

Eric

Kent // contributor

Hi Kent,

Best Regards,
Balazs

Kent // contributer

Hi Balazs, and Balazs,

Kent // contributor

Hello Kent,

-------- Forwarded Message --------
Subject:

Date:

From:

To:

Bocs, bcc lemaradt

-----Original Message-----

From: Balázs Kovács

Hi Kent,

Br,

Balazs

-----Original Message-----

Kent // contributor

Netconf mailing list

Netconf mailing list

--

Senior Specialist

---

From: Kent Watsen <[email-masked]>
Date: Thu, 10 May 2018 22:30:56 +0000

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!

<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]

<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?

Kent // contributor

---

From: Balázs Kovács <[email-masked]>
Date: Fri, 11 May 2018 07:40:39 +0000

Hi Kent,

Some comments for 2):

I think it all boils down to how the operator defines an identity. If an identity is a protocol, then there would be separate keys for each, if an identity is a group of protocols, then they use the same key. In the end it could be just the device operating a collection of protocols defined as identity. I think the model cannot really restrict how an identity is defined, but it can certainly make it harder or easier to reach the desired configuration. For example, even with the latest version of the keystore draft with the grouping, I can copy the same binary data (the private key) over to all protocols implementing the grouping. However, I would prefer to not configure it by copying binary data, but rather configuring it once and then just set the leafrefs properly. So my take would be that ietf-keystore should support using the same key from multiple protocols, and support separate keys for each protocol too.

Br,
Balazs

From: Kent Watsen [mailto:[email-masked]]
Sent: Monday, May 07, 2018 5:58 PM
To: Balázs Kovács <[email-masked]>; [email-masked]
Subject: Re: [Netconf] Adoption poll for crypto-types and trust-anchors

Hi Balazs,

Kent // contributor

Hi Kent,

Best Regards,
Balazs

Kent // contributer

Hi Balazs, and Balazs,

Kent // contributor

Hello Kent,

-------- Forwarded Message --------
Subject:

Date:

From:

To:

Bocs, bcc lemaradt

-----Original Message-----

From: Balázs Kovács

Hi Kent,

Br,

Balazs

-----Original Message-----

Kent // contributor

Netconf mailing list

Netconf mailing list

--

Senior Specialist

---

From: Kent Watsen <[email-masked]>
Date: Fri, 11 May 2018 14:10:09 +0000

Hi Balazs,

Good point.  Perhaps we could have something like:

grouping asymmetric-key-grouping {
  leaf algorithm { … }
  leaf private-key { … }
  leaf public-key { … }
  container certificates {
    if-feature certificates;
    list certificate {
      key name;
      leaf name { type string; }
      leaf cert { type ct:x509 }
    }
  }
}

container keystore {
  container keys {
    list key {
      key name;
      leaf name { type string; }
      uses asymmetric-key-grouping;
    }
  }
}

grouping local-or-external-asymmetric-key-grouping {
  choice local-or-external {
    case local {
      uses asymmetric-key-grouping;
    }
    case external {
      leaf reference {
        type leafref {
          path "/keystore/keys/key/name";
      }
  }
}

And then downstream modules can choose to which of the two groupings to use.   Thoughts?

Kent

On 5/11/18, 3:40 AM, "Balázs Kovács" <[email-masked]<mailto:[email-masked]>> wrote:

Hi Kent,

Some comments for 2):

Br,
Balazs

Hi Balazs,

Kent // contributor

Hi Kent,

Best Regards,
Balazs

Kent // contributer

Hi Balazs, and Balazs,

Kent // contributor

Hello Kent,

-------- Forwarded Message --------
Subject:

Date:

From:

To:

Bocs, bcc lemaradt

-----Original Message-----

From: Balázs Kovács

Hi Kent,

Br,

Balazs

-----Original Message-----

Kent // contributor

Netconf mailing list

Netconf mailing list

--

Senior Specialist

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Fri, 11 May 2018 22:12:54 +0000

From: Kent Watsen, May 10, 2018 6:31 PM

<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.

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

Eric

Kent // contributor

---

From: Balázs Kovács <[email-masked]>
Date: Mon, 14 May 2018 08:50:42 +0000

Hi Kent,

Couldn’t you use the existing ‘private-key-grouping’ and  ‘certificate-grouping’ which were in draft-ietf-netconf-keystore-04 instead of this new ‘asymmetric-key-grouping’? Is there any drawback with that? I think it looked better than with having this new certificate feature within the grouping. They also contained some actions that you missed now.

The keystore container looks good to me if it was using ‘private-key-grouping’ and  ‘certificate-grouping’. I assume the trust anchors would be fully separated from this?

Regarding the new ‘local-or-external-asymmetric-key-grouping’, after checking with Balazs L. here, we would suggest that 1) the choice is mandatory 2) the cases are in features, thus an implementation must implement at least one of the cases, and can decide to go for local or external keystore. Regarding the naming, since the external is deliberately pointing out keystore usage, should the grouping be called ‘local-or-keystore-asymmetric-key-grouping’?

Br,

Balazs

From: Kent Watsen [mailto:[email-masked]]
Sent: Friday, May 11, 2018 4:10 PM
To: Balázs Kovács <[email-masked]>; [email-masked]
Subject: Re: [Netconf] Adoption poll for crypto-types and trust-anchors

Hi Balazs,

container keystore {
  container keys {
    list key {
      key name;

Kent

Hi Kent,

Some comments for 2):

Br,
Balazs

From: Kent Watsen [mailto:[email-masked]]
Sent: Monday, May 07, 2018 5:58 PM
To: Balázs Kovács <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Netconf] Adoption poll for crypto-types and trust-anchors

Hi Balazs,

Kent // contributor

Hi Kent,

Best Regards,
Balazs

Kent // contributer

Hi Balazs, and Balazs,

Kent // contributor

Hello Kent,

-------- Forwarded Message --------
Subject:

Date:

From:

To:

Bocs, bcc lemaradt

-----Original Message-----

From: Balázs Kovács

Hi Kent,

Br,

Balazs

-----Original Message-----

Kent // contributor

Netconf mailing list

Netconf mailing list

--

Senior Specialist

---

From: Kent Watsen <[email-masked]>
Date: Mon, 14 May 2018 17:30:58 +0000

Hi Balazs,

Please see <Kent> below.

On 5/14/18, 4:50 AM, "Balázs Kovács" <[email-masked]<mailto:[email-masked]>> wrote:

Hi Kent,

<Kent> As for drawbacks, having the two separate groupings makes them, well, less connected.  I thought that it might be good to bring them together.  That said, so long as the keystore container exists (assuming we bring it back), the consumer doesn't care if it used one or two groupings.  I'm open to discussing this more.  Also, the action statements were only left out to keep things easier to scan, the final module would still have them.

<Kent> great, it's good to get a positive confirmation on the keystore container.  Regarding if trust-anchors would be kept separate (assuming we bring the keystore container back), that is a good question.  On one hand, I like the modularity of keeping them separate but, on the other hand, we may want them together so that a) any protection mechanism used to keep the private keys safe could also be used to ensure that the trust-anchors are immutable and b) the certificate-expiration notification could apply to both.   I don't feel strongly about (a), and it seems that a separate trust-anchors could also be protected.   (b) would be nice, though the same notification could be defined in both modules with no loss of functionality.  Thoughts?

<Kent> yes, mandatory true and feature statements would round it out the grouping nicely.  Good suggestion on the naming too.

Kent // contributor

Br,

Balazs

Hi Balazs,

container keystore {
  container keys {
    list key {
      key name;

Kent

Hi Kent,

Some comments for 2):

Br,
Balazs

Hi Balazs,

Kent // contributor

Hi Kent,

Best Regards,
Balazs

Kent // contributer

Hi Balazs, and Balazs,

Kent // contributor

Hello Kent,

-------- Forwarded Message --------
Subject:

Date:

From:

To:

Bocs, bcc lemaradt

-----Original Message-----

From: Balázs Kovács

Hi Kent,

Br,

Balazs

-----Original Message-----

Kent // contributor

Netconf mailing list

Netconf mailing list

--

Senior Specialist

---

From: "Xialiang (Frank, Network Integration Technology Research Dept)" <[email-masked]>
Date: Fri, 18 May 2018 09:19:10 +0000

Hi Kent and Balazs,
By following all the related discussion, my general comments/questions are as below:

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;

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;

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?

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

B.R.
Frank

发件人: Netconf [mailto:[email-masked]] 代表 Kent Watsen
发送时间: 2018年5月15日 1:31
收件人: Balázs Kovács <[email-masked]>; [email-masked]
主题: Re: [Netconf] Adoption poll for crypto-types and trust-anchors

Hi Balazs,

Please see <Kent> below.

Hi Kent,

Kent // contributor

Br,

Balazs

Hi Balazs,

container keystore {
  container keys {
    list key {
      key name;

Kent

Hi Kent,

Some comments for 2):

Br,
Balazs

Hi Balazs,

Kent // contributor

Hi Kent,

Best Regards,
Balazs

Kent // contributer

Hi Balazs, and Balazs,

Kent // contributor

Hello Kent,

-------- Forwarded Message --------
Subject:

Date:

From:

To:

Bocs, bcc lemaradt

-----Original Message-----

From: Balázs Kovács

Hi Kent,

Br,

Balazs

-----Original Message-----

Kent // contributor

Netconf mailing list

Netconf mailing list

--

Senior Specialist

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Wed, 23 May 2018 12:12:45 +0000

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

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

Eric

Kent // contributor

---

From: Mahesh Jethanandani <[email-masked]>
Date: Wed, 23 May 2018 08:50:38 -0400

Based on the discussion till date, there seems to be support for bringing back -03 version of the ietf-keystore draft, while splitting the crypto-types and trust-anchors into their own modules/drafts.

With that, this closes the poll for adoption of the two new drafts. Kent, can you post the two new drafts as draft-ietf-netconf-crypto-types and draft-ietf-netconf-trust-anchors without changing any of the contents in the draft.

At the same time, please revert the draft-ietf-netconf-keystore draft to its -03 version, and (re)factor as needed, the SSH/TLS Client/Server drafts to use the new modules.

Thanks.

Mahesh Jethanandani
[email-masked]

> On May 23, 2018, at 8:12 AM, Eric Voit (evoit) <[email-masked]> wrote:
> 
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf

---

From: Kent Watsen <[email-masked]>
Date: Thu, 24 May 2018 00:50:42 +0000

Makes sense.  Thanks Eric.
Nothing more below.
Kent

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

Eric

Kent // contributor

---

From: Balázs Kovács <[email-masked]>
Date: Thu, 24 May 2018 07:36:29 +0000

Hi Kent,

I did not respond to your answers. Sorry for the delay.
Please see below.
Br,
Balazs

From: Kent Watsen <[email-masked]>
Sent: Monday, May 14, 2018 7:31 PM
To: Balázs Kovács <[email-masked]>; [email-masked]
Subject: Re: [Netconf] Adoption poll for crypto-types and trust-anchors

Hi Balazs,

Please see <Kent> below.

Hi Kent,

Balazs> How global is a feature statement? SSH implementations might only have private/public key support, but TLS with certificates within same running device. I would still like it to be possible to express certificates for TLS, but keys only for SSH.

Balazs> I tend to lean toward separate modules for keystore and trust anchors, but don’t have a concrete preference.

Balazs> Great.

Kent // contributor

Br,

Balazs

Hi Balazs,

container keystore {
  container keys {
    list key {
      key name;

Kent

Hi Kent,

Some comments for 2):

Br,
Balazs

Hi Balazs,

Kent // contributor

Hi Kent,

Best Regards,
Balazs

Kent // contributer

Hi Balazs, and Balazs,

Kent // contributor

Hello Kent,

-------- Forwarded Message --------
Subject:

Date:

From:

To:

Bocs, bcc lemaradt

-----Original Message-----

From: Balázs Kovács

Hi Kent,

Br,

Balazs

-----Original Message-----

Kent // contributor

Netconf mailing list

Netconf mailing list

--

Senior Specialist