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

[Kent Watsen <[e-mail]>]

Hi Juergen,


> Using
>
>  <private-key>base64encoded===</private-key>
>
> sounds like an interesting option since this should allow tools
> to validate the instance documents (and this is what I am really
> looking for).

Great, and this thread forked already, so let's continue it there.


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


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


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


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


K.