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

[Juergen Schoenwaelder <[e-mail]>]

On Fri, Jul 28, 2017 at 03:01:26PM +0000, Kent Watsen wrote:
> >> >> - I am not sure I understand trusted-host-keys. On systems that have
> >> >>   multiple user accounts, you usually have a per account list of
> >> >>   trusted host keys in addition to a global system wide list. Perhaps
> >> >>   make it clear that this models the global known hosts list only?
> >> >> 
> >> >> <KENT> it's a list of lists, so there can be many different
> >> >> sets a host-keys defined, with each application/use pointing
> >> >> to its own entry.  The ietf-ssh-client module's grouping has
> >> >> a leafref to a specific entry.  FWIW, this grouping is
> >> >> used by ietf-netconf-client module.  At the moment, there
> >> >> no other uses of this grouping.  I think that you may be
> >> >> getting confused between the key the server presents (the
> >> >> host-key) versus the key user presents.
> >> >> .
> >> >
> >> > I though these are the authorized host keys? Yes, I am confused. If
> >> > these are user public keys, they should not be called host keys. But
> >> > yes, I am confused (but I started to read the other documents).
> >> 
> >> This leaf encodes an SSH public key (RFC4253, 6.6), same as used in 
> >> /ietf-system/system/user/authorized-key/key-data (and I have changed
> >> this leaf's type to match it in my local copy already), but the uses
> >> are different.  In ietf-system, the authorized-key is configured on
> >> a server in order to authenticate subsequent SSH-client connections.
> >> Here, we're taking about the key that that SSH-server presents to
> >> the client.  These are the host keys that OpenSSL often puts into the 
> >> ~/.ssh/known-hosts file.
> >
> > I understand what you are modeling is /etc/ssh/ssh_host_rsa_key.pub
> > and friends. Make sure it is described clearly. Or do you actually
> > mean the clients cache of authenticated keys that goes into an
> > account's known-hosts file? In this case, the keystore may be the
> > wrong place.
>  
> /keystore/trusted-host-keys/trusted-host-key is in fact like the
> known-hosts file.  That is, these are the host-keys that a client has
> "pinned" or "trusted".  The ietf-ssh-client has a leafref to one of
> these entries.  We could rename "trusted-host-key[s]" to 
> "pinned-host-key[s]" if that helps. Ditto for trusted-certificate[s])
> 
> By contrast, /keystore/keys/key/name is referenced by ietf-ssh-server
> to identify the host-key(s) the SSH server presents to SSH clients.
> This is analogous to /etc/ssh/ssh_host_rsa_key.pub and friends.  This
> node isn't called e.g. /keystore/keys/key/ssh-host-key because, AFAICT,
> the system should be able to generate its host-key from the private-key
> itself.  Thus, referencing the name is equivalent.  If there were a
> /keystore/keys/key/ssh-host-key node, it would be a gratuitous config
> false value that somehow encoded the host-key in a more SSH friendly
> format.  But, it may have a subtler value in that, I think that your
> confusion may be because it was NOT there and so, in its absence, 
> you may have thought that the "trusted-host-keys" must serve that 
> function.  Thoughts?
> 
> BTW, "host key" has a specific meaning, defined in RFC4251#4.1, not to
> be confused with authorized keys.

I do not really follow you. I think I do understand what a host key
(pair) is and that it is different from a users key (pair). Yes, I did
not understand from reading the ID that the private SSH host key is to
be found in /keystore/keys/key/name (likely because of all the
certificate stuff around it that I have never seen used with SSH host
keys).

I guess I am not a big fan of bundling the way X.509 keys and certs
work together with how SSH keys work (because I am not used to this
and the systems I tend to use do not do this either). Anyway, if this
is the direction to go, I think this needs explanatory text somewhere.
 
> >> >> - Should the document title be aligned with other YANG module
> >> >>   definitions, so it is easier to spot it?
> >> >> 
> >> >> <KENT> I don't understand, what do you mean?
> >> >
> >> > We often use "[A] YANG Data Model for ....".
> >> >
> >> > https://en.wikipedia.org/wiki/YANG#Usage_in_Standards
> >> >
> >> > The current name does not say YANG (sometimes I search for YANG 
> >> > in the RFC index) and Keystore is also pretty broad given the
> >> > related work we have.
> >> 
> >> Gotcha, how about "YANG Data Model for Keystores"?
> >
> > Yes, except that 'keystores' leaves readers unclear about the scope. I
> > commented several times that the names of this module and the other
> > module for symmetric keys are unfortunate. Concerning the SSH keys, I
> > am still concerned that we would be better off to have a separate SSH
> > module that takes care about managing an SSH server's host keys and
> > then this module would be X509 certificate specific, i.e., a 'YANG
> > Data Model for Managing X.509 Keys and Certificates' would be a clear
> > and well defined scope.
> 
> From a refactoring perspective, we could have a base module and then
> two augmenting modules, one for SSH and the other for X.509.  I would
> think to define all three modules in the same draft, but that wouldn't
> help your draft-name issue.  We could put each module into own draft
> (e.g. +2 drafts), but is it worth it for renaming sake?  Maybe an even
> longer title?  "YANG Data Model for Managing Asymmetric Private Keys,
> X.509 Certificates, and SSH Host Keys'?  Naming aside, what do you 
> think about the module-factoring idea?

Perhaps it is simpler to have one data model to manage X.509 keys and
certs and another data model to manage SSH keys. I do not know how
much commonality there is. At the end, I also do not mind if
everything is lumped together as long as it is clear how to implement
things and key formats etc match with what implementations typically
do.
 
> >> In another thread, we concluded that we might want to ask SecDir.
> >
> > Or just acknowledge that in the longer term an IANA solution may be
> > needed but we do this later.
> 
> Maybe, and really I wonder who is in a better position to make the
> call.  Sure, SecDir can confirm that there are common algorithms
> used in cryptography, but they may not necessarily have a crystal
> ball to know how many YANG modules will be coming in the near 
> future for which it matters.  Is the NETCONF/NETMOD WGs more
> able to make this call?  I'm personally unaware of any other 
> work-in-progress having a need for these algorithm identities
> such as are defined here, nor do I have a crystal ball for 
> predicting the future.

Crypto algorithms have changed in the past and they will change in the
future. So we will need flexibility here, sooner or later. Getting this
right requires to have the right people involved (i.e., not me).
 
> >> >> - Since the certs of a key do not contain a signature, where are signed
> >> >>   certificates stored or are they outside the scope of the model?
> >> >> 
> >> >> <KENT> I'm confused, certificates are signed structures already...
> >> >
> >> > Well, the description of certificates/certificate/value says:
> >> >
> >> >   An unsigned PKCS #7 SignedData structure, as specified
> >> >   by Section 9.1 in RFC 2315, containing just certificates
> >> >   (no content, signatures, or CRLs), encoded using ASN.1
> >> >   distinguished encoding rules (DER), as specified in
> >> >   ITU-T X.690.
> >> >
> >> > Yes, I am confused how this works.
> >>  
> >> Okay, now I understand your confusion.  I believe the text is 
> >> accurate.  Think of the PKCS#7 structure being a little like a 
> >> TAR file that contains a directory structure like this:
> >> 
> >>  pkcs7:
> >>   /signed-info
> >>   /signature   - this sig is only over 'signed-info' ...
> >>   /extra-certificates
> >>   /extra-revocation-objects
> >> 
> >> So, in this case, we're using a degenerate form of the pkcs7
> >> structure that has no content (signed-info), signature, or CRLs 
> >> (revocation-objects), it only contains the certificates. Perhaps
> >> my use of the word "unsigned" isn't clear enough?
> >
> > So why pkcs7, is this what implementations use? The certificates
> 
> Why pkcs7 is because each certificate may have an associated chain
> of certificates leading to a trust-anchor CA certificate.  For instance,
> a vendor might have a CA called "foo-root" that signs an intermediate
> CA called "foo-intermediate" that signs the "foo-entity" certificates.
> So, a given foo-entity certificate (a single X.509 structure) is
> commonly presented along with its chain of CA certs (more X.509 
> structures), in this case, the "foo-intermediate" and "foo-root" CA
> certs.  The pkcs7 structure is commonly used for this purpose in the
> PKI world.  Yes, it could be just a TAR file having a flat list of
> certs, but then we'd have to define that structure, whereas its 
> already defined in pkcs7.
> 
> > I find in /etc/ssl/certs on my Debian system seem to be in PEM format.
> 
> PEM and DER are interchangeable formats.  PEM is essentially the base64
> encoding of the DER surrounded by the "===== BEGIN/END CERTIFICATE
> =====" header/footer.
> 

DER encoded certificate or pkcs7? I thought PEM is just a base64
encoded version of the DER encoded certificate, no pkcs7 involved.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
Fax:   [phone]         <http://www.jacobs-university.de/>