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

From: Kent Watsen <[email-masked]>
Date: Thu, 27 Oct 2016 14:28:48 +0000

[picking up on an old thread]

Hi Juergen,

You bring up a good point.  The introduction of the client auth mechanisms added last time definitely seem SSH/TLS or NC/RC specific in places.  The rest of it I think is pretty independent of any specific protocol, but we can double-check that.

In the meanwhile, I’d like to move forward with renaming the draft to draft-ietf-netconf-keystore and changing the module name to ietf-keystore so as to clear up the name-confusion issue, with the understanding that we’ll work towards factoring-out/augmenting-in protocol-specific extensions.  Any objections to this from anyone?

Thanks,
Kent

On 9/22/16, 1:51 PM, "Juergen Schoenwaelder" <[email-masked]> wrote:

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

On Thu, Sep 22, 2016 at 05:09:44PM +0000, Kent Watsen wrote:
> 
> 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:
> 
>     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,
>     > 
>     > 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:
>     > 
>     >    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
>     > 
>     >    On Wed, Sep 21, 2016 at 05:35:40PM +0000, Kent Watsen wrote:
>     >> 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
>     >> 
>     > 
>     >> _______________________________________________
>     >> 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/>
>     > 
>     > 
>     > _______________________________________________
>     > Netconf mailing list
>     > [email-masked]
>     > https://www.ietf.org/mailman/listinfo/netconf
>     
>     Mahesh Jethanandani
>     [email-masked]
>     
>     
>     
>     
> 

-- 
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: t.petch <[email-masked]>
Date: Fri, 28 Oct 2016 12:07:58 +0100

Kent

I dislike changes to a document identifier.  Identifiers should be
stable so that the history and revisions can readily be tracked.
Imbuing the identifier with excessive semantic meaning makes identifiers
unstable and hard to use at least during the life of the I-D.

Module names are a bit different; there I do see a case for getting the
semantics right although again there is a tendency to overload
identifiers with meaning.  An identifer should be unique within what
namespace it occurs, easy to use for whatever uses it has - and stable.

So module name yes, I-D no, for me.

Tom Petch

----- Original Message -----
From: "Kent Watsen" <[email-masked]>
To: "Juergen Schoenwaelder" <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, October 27, 2016 3:28 PM
Subject: Re: [Netconf] rename ietf-system-keychain to ietf-keystore or
ietf-system-keystore?

> You bring up a good point.  The introduction of the client auth
mechanisms added last time definitely seem SSH/TLS or NC/RC specific in
places.  The rest of it I think is pretty independent of any specific
protocol, but we can double-check that.
>
> In the meanwhile, I’d like to move forward with renaming the draft to
draft-ietf-netconf-keystore and changing the module name to
ietf-keystore so as to clear up the name-confusion issue, with the
understanding that we’ll work towards factoring-out/augmenting-in
protocol-specific extensions.  Any objections to this from anyone?
>
> Thanks,
> Kent
>
>
>
> On 9/22/16, 1:51 PM, "Juergen Schoenwaelder"
<[email-masked]> wrote:
> > 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.
> >     > On 9/21/16, 4:01 PM, "Juergen Schoenwaelder"
<[email-masked]> wrote:
> >     >> 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.
> >     >> 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).

---

From: Kent Watsen <[email-masked]>
Date: Sat, 29 Oct 2016 12:47:19 +0000

Hi Tom,

I completely agree for the reasons you mentioned, but I’d like to suggest an exception in this case.  Since the current draft is a -00, it has no history.  So I could just submit it again, with no changes other than the name change.  No history would be lost then, right?

BTW, I’m very much feel bad for not picking the better name in the first place.  I hate having to make this request.  Of course we can keep the draft name as is, even though the model name inside it changes, if that’s what people want.

Kent

On 10/28/16, 7:07 AM, "t.petch" <[email-masked]> wrote:

Kent

Tom Petch

----- Original Message -----
From: "Kent Watsen" <[email-masked]>
To: "Juergen Schoenwaelder" <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, October 27, 2016 3:28 PM
Subject: Re: [Netconf] rename ietf-system-keychain to ietf-keystore or
ietf-system-keystore?

---

From: t.petch <[email-masked]>
Date: Sun, 30 Oct 2016 10:28:13 +0000

----- Original Message -----
From: "Kent Watsen" <[email-masked]>
Sent: Saturday, October 29, 2016 12:47

> Hi Tom,
>
> I completely agree for the reasons you mentioned, but I’d like to
suggest an exception in this case.  Since the current draft is a -00, it
has no history.  So I could just submit it again, with no changes other
than the name change.  No history would be lost then, right?

Kent

mmmm, yes, I had not noticed it was -00.  But it would be wrong to say
it has no history; normally that would be a non-WG I-D but in this case
it is
draft-ietf-netconf-server-model-09

Tools looks after the change from non-WG I-D to WG I-D; I do not know
what it has done in this case.  It is possible to override the tools
view and I would like that in this case, that if you go with a renamed
I-D, then tools shows the renamed I-D as having a predecessor of
server-model.  That might make the forward chain of references somewhat
odd, but it is only ever the backward chain that I use (and see a use
for).

Bear in mind too that the e-mail archive will show the initial split of
server-model into the current name, which might be something that the
IESG look at come review time so there could be confusion there.

Given the history, I do think that this, name change or no, should
appear in the text of the RFC itself, i.e. not the current change log
which the RFC Editor may excise.

Tom Petch

>
> BTW, I’m very much feel bad for not picking the better name in the
first place.  I hate having to make this request.  Of course we can keep
the draft name as is, even though the model name inside it changes, if
that’s what people want.
> > > On 9/21/16, 9:04 PM, "Mahesh Jethanandani"
<[email-masked]>
> wrote:
> > >     > On Sep 21, 2016, at 2:59 PM, Kent Watsen
<[email-masked]>
> wrote:
> > >     >    like ietf-_routing_-keystore or ietf-_system_-keystore
are
> sending the

---

From: Kent Watsen <[email-masked]>
Date: Sun, 30 Oct 2016 14:22:30 +0000

The chairs can configure datatracker to know what other draft a given draft replaces.  In this case, the one server-model draft got split into 5 drafts.  I don’t actually know if the tools can handle multiple drafts replacing one draft.  That said, I like your idea of adding text to explain some of the draft’s history.  I can add similar text into all 5 drafts.  Thanks for the suggestion.

Kent

On 10/30/16, 6:28 AM, "t.petch" <[email-masked]> wrote:

----- Original Message -----
From: "Kent Watsen" <[email-masked]>
Sent: Saturday, October 29, 2016 12:47

Kent

Tom Petch

<[email-masked]>
are