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

[Kent Watsen <[e-mail]>]

>> >> >> - 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 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? 



>> >> >> - 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?


>> >> 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).

Okay, so maybe we're only in the position of saying that such a
thing is highly desirable, but we'd be dependent on security 
experts to get it right, and SecDir involvement could help
kickoff that effort...


>> >> >> - 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... 

K.