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

[Juergen Schoenwaelder <[e-mail]>]

On Fri, Jul 28, 2017 at 05:00:06PM +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).
> 
> Fine, but this is SSH architecture thing, not something specific to
> the draft - right?

???
 
> > 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).
> 
> Okay, then do you like having a /keystore/keys/key/ssh-host-key node?

I guess what I am looking for is a more radical split between X.509
stuff and SSH key stuff, the most radical split would be a module for
X.509 keys and certs and another module for SSH host keys. Or
alternatively, if there is really a strong reason to have all these
different keys in one list, then define the list such that
augmentations add X.509 stuff and SSH key stuff. I am not a fan of
lists where the usage of leafs for different purposes is not clear.

> > 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.
> 
> So then perhaps factoring out the x.509 and ssh stuff out into augmenting
> modules? 

I am not sure how much is left, other than a list with a key name leaf
and whether it is worth to have this common structure (and whether any
uniqueness constraints resulting from that are a benefit or not).

> 
> >> >> >> - 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.
> 
> Two modules, something like ietf-ssh-keystore and ietf-x509-keystore?
> Of course, there would overlap between them (e.g., both modules would
> have the /keys/key hierarchy, the ietf-ssh-client/server modules might
> need to import both keystores, since SSH can use X.509 certs too (per
> RFC6187).  I don't know, this doesn't seem right.  For instance, what
> is a server to do if it generates a private key that has not yet been
> associated with an X.509 cert or SSH host key, is the private key to
> appear in both keystores?

Is this how systems work? My command line tools either create X.509
keys or SSH keys.

> >> >> >> - 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.
> 
> Both PKCS7 and X.509 or ASN.1-encoded structures, and all ASN.1 structures
> can be encoded using PEM, DER, or even BER.   Your debian system's "certs"
> directory undoubtedly only contains root certs, hence there is no cert-chain
> to staple to them, and hence a single X.509 structure (either PEM or a DER)
> is perfect.  As soon as you step into needing more than one cert, then
> either PKCS7 or PKCS12 (both of which could be PEM or DER encoded), or a
> very special multi-part PEM (one that contains more than one of the "====="
> BEGIN/END blocks) could be used.  BTW, all this was discussed a while back
> related to https://github.com/netconf-wg/keystore/issues/1.  What's written
> in the GitHub issue tracker should be ignored, search instead the list-archive
> on issue #1... 
> 

What matters is that the I-D is clear and captures the important
reasons etc. You can't expect implementors to read github issues
or mailing list archives. Sorry for my ignorance.

/js

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