Re: [yang-doctors] Yangdoctors last call review of draft-ietf-netconf-keystore-02

[Kent Watsen <[e-mail]>]

Hi Juergen,

> <snip/>
> Yes, the host-key resides on the server, the public part of the host
> key may be stored on a client in a known-hosts file so that client can
> check whether it talks to the right server. So far so good.
>
> It seems /keystore/trusted-host-keys/trusted-host-key represents
> /etc/ssh/ssh_known_hosts (i.e. a _global_ known hosts list) and there
> is no way to learn the public known host key from a server via the
> YANG module. Can I request creation of a hew host key? There is
> generate-private-key but that seems to be more tied to X.509 stuff.

The 'generate-private-key' action is no way meant to be just for X.509
stuff.  But I acknowledge that there might be a semantic-gap here.
For instance, if one wants to ask an SSH server to generate a new
host-key, one expects an API called something like 'generate-host-key'
(inside an SSH namespace, or as an action to the server instance),
rather than first generating the 'key' and then separately saying that
it's the host-key.  I think that this could be caulked up to saying
that there is a base API layer and then, separately, higher level
layers that use it, but it's worth the discussion if it makes sense
at all...


> Note that this does not model ~/.ssh/known-hosts since the list is not
> on a per user account base. It would actually be the equivalence of a
> global /etc/ssh/ssh_known_hosts file.

Not exactly.  As it is undetermined who, or which models, point to the
keystore host-key lists.  In some data models, it might be global and,
in others, user specific.


>> <snip/>
>> No, your system most likely does not use a keystore mechanism.  For
>> instance, OpenSSL's `ssh-keygen` utility just writes to a local file.
>> We're doing something a little different here, which is a cause for
>> careful review (thanks again).  Taking a step back, one of the drivers
>> for this keystore mechanism is to centralize the /trusted-host-keys
>> and /trusted-certificates, as these lists are referenced from many
>> locations.  Less important to centralize are the private keys, as
>> the keys (always?) have a single use.  The only reason for centralizing
>> the private keys is to give keys created via the generate-private-key
>> action a place to be listed before they are used for some purpose...
>
> The question is whether there is value to centralize beyond the
> differnet key systems. Is there really added value to try to treat SSH
> keys and X.509 in the same list infrastructure or are they at the end
> just different things? What about other keys, i.e., for signing DNS
> zones or RPKI keys? Is it useful to try to put all of these keys that
> serve different purposes into a common structure? The open source
> people maintaining software packages seem to keep things separate. Is
> Junos having such a centralized asymmetric keystore? How about IOS XR?
> Others? If not, why would a standard do this?

JUNOS is not having a centralized keystore.  I can't speak for IOS or
others, but I guess not.  This model is suggesting a *conceptual*
keystore.   As the keystore draft says:

   It is not required that a system has an operating system level
   keystore utility to implement this module.

But to your higher-lever question, is there value to treating such
various keys similarly, all I can say is that all such private keys
should be protected and, as such, the nacm:default-deny-all property
given here is apropos.

Kent