Subject: [Netconf] rename ietf-system-keychain to ietf-keystore or ietf-system-keystore?

From: Kent Watsen <[email-masked]>
Date: Wed, 21 Sep 2016 17:35:40 +0000

All,

You may recall that we previously renamed the YANG module from “ietf-keychain” to “ietf-system-keychain” to disambiguate it from the routing area’s “ietf-key-chain” module (in Acee’s draft).  Acee was going to rename his module to “ietf-routing-keychain”, but then didn’t.    But the current two names are still too close for comfort and so I’ve been thinking to rename ours to “ietf-keystore” or “ietf-system-keystore”.  FWIW, “keystore” is perhaps even a more apt name than “keychain” for this purpose.  In discussing this with the WG chairs, we can update the draft’s name to be inline with whatever we choose.

What do people think?  Is there a preference between ietf-keystore and ietf-system-keystore?

If no objections are received within a week’s time, I’ll assume to use “ietf-keystore” and update the draft’s name accordingly (i.e., draft-ietf-netconf-keystore-00).

Thanks,
Kent

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 21 Sep 2016 22:01:58 +0200

As I said several times, choose names that indicate what the models
really do. As far as I can tell, one deals with symmetric keys, the
other deals with asymmetric keys.

I think we do not want for different classes of protocols or
subsystems to define different keystores or keychains. Hence, names
like ietf-_routing_-keystore or ietf-_system_-keystore are sending the
wrong signal.

/js

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

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Kent Watsen <[email-masked]>
Date: Wed, 21 Sep 2016 21:59:14 +0000

Hi Juergen,

So are you advocating ietf-keystore or ietf-asymmetric-keystore?

FWIW:
 - Andriod and Java call it "keystore".
 - MacOS and iOS call it "keychain".
 - Windows doesn’t seem to have an equivalent.

Thanks,
Kent

On 9/21/16, 4:01 PM, "Juergen Schoenwaelder" <[email-masked]> wrote:

    
    /js

---

From: Mahesh Jethanandani <[email-masked]>
Date: Wed, 21 Sep 2016 18:04:09 -0700

I agree with Juergen. It would make more sense to name it as ietf-asymmetric-keystore.

> On Sep 21, 2016, at 2:59 PM, Kent Watsen <[email-masked]> wrote:
> 
> Hi Juergen,
> 

Mahesh Jethanandani
[email-masked]

---

From: Kent Watsen <[email-masked]>
Date: Thu, 22 Sep 2016 17:09:44 +0000

I prefer “ietf-keystore”, as I’m not 100% sure the module won’t ever contain symmetric keys.  Case in point, the current draft has a password field in it, for password-based SSH authentications.   Gary added the password field last time to support the ietf-ssh-client and ietf-netconf-client modules.  That said, I don’t think it’s received significant review yet.   Still, a password is a form of a symmetric key, so calling the module an “asymmetric keystore” wouldn’t be quite right in this case.

Kent

On 9/21/16, 9:04 PM, "Mahesh Jethanandani" <[email-masked]> wrote:

    
    Mahesh Jethanandani
    [email-masked]

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 22 Sep 2016 19:51:30 +0200

I really see only two good approaches:

a) A single well thought-out keystore for all needs to store and
   manage keys. This may take time to get right and I would expect
   that the natural home for this would actually be the security area
   and not OPS or RTG.

b) The alternative is to design N different keystores that are all
   designed for specific security protocols/mechanisms. A keystore for
   SSH keys, a keystore for X.509 certificates, a keystore for plain
   symmetric keys, a keystore for SASL mechanisms, ...

I think what we are doing right now is a somewhat arbitrary mix in the
middle between these two alternatives. Perhaps an approach worth
exploring is to define a core keystore model that defines a core
structure and naming system and that can be augmented with models
providing extensions that are security protocol/mechanism specific.
Yes, this will take more time to work out but then it provides
(ideally) a more general solution, i.e., one where at least the
naming and the overall structure is consistent.

Well, given that the IETF is usually better in doing smaller things,
perhaps a generic keystore is just a dream of an idealist and smaller
specific security protocols/mechanisms specific keystores are the
short-time most effective direction. If so, we should split the
system-keychain into even smaller units.

/js