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

[Kent Watsen <[e-mail]>]

Hi Tom,


> Changing the subject because my tack is slightly different.
> 
> I cannot reconcile this I-D with my (mis?)understanding of cryptography.
> 
> Stepping back, I see two types of keys, symmetric where one key is used
> for encryption and decryption, and asymmetric, where there are two keys,
> public and private, mathematically related but impossible to derive one
> from the other, one used to encrypt, the other to decrypt.
>
> I see this I-D as solely concerned with asymmetric keys.

Correct, though there was a time when we considered having a "password"
leaf, which would've been a form of a symmetric key.


> Public and private key pairs must be generated together, after which the
> private key must stay secret else you have no security.  Public keys by
> contrast are public for all to know.  The challenge is authenticating
> that the public key really is the public key of who you think it is.
> Most public keys arrive by certificates which then allow you to follow a
> chain thereof to a hopefully trustworthy trust anchor.  SSH, and some
> other protocols, are different in distributing naked public keys and
> relying on some other means of authenticating them (e.g. Trust on First
> Use).

Correct, though it's worth noting that SSH can also distribute X.509 certs
per RFC 6187.


> So when you say  "AFAICT, the system should be able to generate its
> host-key from the private-key itself." that is at odds with my 
> understanding and would lead to an absence of security.

My mistake, I was using the old name "private-key" before we changed
it to just "key", and what I really meant to say was that the system
should be able to convert /keystore/keys/key/private-key into a
representation suitable for software consumption (e.g., an openssh
host-key file).


> When the I-D says, "that might be used to hold onto private keys
> and certificates "I struggle to see the point.  Indeed, the 
> module contains public keys as well as
> "leaf public-key {
>          config false;
>          mandatory true;"
> so you are really storing public/private key pairs (which may be
> generated on the box).

That particular sentence, in the Abstract and Introduction, has been
rewritten based on Juergen's comments.  The abstract now says:

   This document defines a YANG module for a system-level mechanism,
   called a "keystore", containing security-sensitive data including
   private keys, pinned certificates, and pinned SSH host-keys.

The Introduction now says:

   This document defines a YANG [RFC7950] module for a system-level
   mechanism, herein called a "keystore".  The keystore provides a
   centralized location for security sensitive data, as described below.

   This module has the following characteristics:

   o  A configurable list of keys, each a public/private key pair.  If a
      key is used to sign a certificate signing request (CSR), which is
      then signed by a certificate authority (CA), then the resulting
      certificate may be configured as being associated with the key.
      Keys are expected to be configured using standard configuration
      mechanisms, however, to support hardware that generates keys, the
      key may also be created via an action called 'generate-private-
      key" action.  Keys may also be preinstalled (e.g., a key
      associated to an IDevID [Std-802.1AR-2009] certificate).

   o  An unordered list of pinned certificate sets...<snip/>
   o  An unordered list of pinned SSH host key sets...<snip/>
   o  An action to request the server to generate a new key...<snip/>
   o  An action to request the server to generate a CSR...<snip/>
   o  A notification...<snip/>

Does this help?  What "point" are you not seeing?


> The I-D also says "Certificates associated with this private key."
> which defeats me.  A certificate or chain thereof gives me a public key,
> never a private one, and the means to authenticate the public key.

Again, this goes back the old name "private-key" before we changed
it to just "key".  I agree that it's wrong at face-value.  Above you
can see how this text was changed.  Now what it says makes more sense.


> A public key may or may not have a certificate or chain thereof.  

true.


> A TLS client would likely have both but will rarely have a private
> key.

True, assuming client certificate based authentication is "rare".


> A server of any protocol (except SSH and such like) will have a
> public/private key pair and a certificate (and likely a chain thereof)
> to send to any enquiring client along with the public key.  An SSH
> server would have a public/private key pair but likely no certificates.

All true


> So, I cannot reconcile my understanding with the I-D.

I think it was mostly due to the whole "private-key" to "key" rename
not having percolated through all the text yet.  Yes?


> Tom Petch

Kent