Re: [netconf] ietf crypto types - permanently hidden

[Kent Watsen <[e-mail]>]

[WARNING: wide-screen needed]



> IMO, allowing <generate-key> to create the configuration directly is the only client-friendly answer.

Speaking of friendly solutions, the current solution struggles on another point too.  In particular, it is troubling that public-key-grouping and asymmetric-key-grouping nodes aren't "mandatory true".  The reason these fields are not "mandatory true" is captured in ietf-crypto-types:

       [These] nodes are not
       mandatory because they MAY be defined in <operational>.
       Implementations SHOULD assert that these values are
       either configured or that they exist in <operational>.";

How did we get here?   

1) We needed to support manufacturer-generated private key and IDevID certificate, which would be in <operational> with origin="system" and, in order to support leafrefs to the manufacturer-generated IDevID cert, we said that the client needs to create an "overlay" key in <running> (by "name" only).   [note that this was after exploring a solution using "require-instance false"]

2) We felt that, in order to use the `generate/install-hidden-key` actions, the "config true" parent node should be created first and then these actions would only populate descendent values in <operational>.

To recap, following is an abbreviated version of what's in the current keystore draft:

     +--rw keystore
        +--rw asymmetric-keys
           +--rw asymmetric-key* [name]
              +--rw name
              +--rw algorithm?                             <--- optional?
              +--rw public-key?                            <--- optional?
              +--rw private-key?           union           <--- optional?   (note union)
              +---x generate-hidden-key
              +---x install-hidden-key
              +---x generate-certificate-signing-request
              +--rw certificates
                 +--rw certificate* [name]


This seems messy.  Let's reconstruct the solution from basics, and build up from there...

First, assuming no hidden-keys or special actions, we would have this:

     +--rw keystore
        +--rw asymmetric-keys
           +--rw asymmetric-key* [name]
              +--rw name
              +--rw algorithm                             <--- not optional.
              +--rw public-key                            <--- not optional.
              +--rw private-key            binary         <--- not optional.   (note binary)
              +---x generate-certificate-signing-request
              +--rw certificates
                 +--rw certificate* [name]

Note that the private-key type is just "binary", because there isn't a need for a union with the "permanently-hidden" value.

Now, adding back support for manufacturer-generated private key and IDevID certificate (but WITHOUT the ability for clients to create their own TPM-protected keys), we could have this:

     +--rw keystore
        +--rw asymmetric-keys
           +--rw asymmetric-key* [name]
              +--rw name
              +--rw algorithm                             <--- not optional.
              +--rw public-key                            <--- not optional.
              +--rw private-key         ct:private-key    <--- not optional.   (note ct:private-key)
              +---x generate-certificate-signing-request
              +--rw certificates
                 +--rw certificate* [name]

There are two differences:
  - the private key type is changed (more on that below)
  - there's an implicit assumption that the manufacturer-generated private key and IDevID
    certificate will initially only exist in <operational> (w/ origin="system") and that
    the client MUST first COPY those values into <running> before they can be referenced
    by configuration.

Regarding the "ct:private-key" type, rather then using the "union" we have today (between a binary value and the string "permanently-hidden"), it would be better to accommodate the recently-discussed idea that the device MAY be able to encrypt the TPM-protected private key.  For instance:

   typedef private-key {
     type union {
       type binary;    // the real value of the private key
       type string {
         pattern '<encrypted by="*">[A-Za-z0-9+/]+[=]*' {
           description
             "Used for hidden-keys the device is able to encrypt.
              The base64-encoded encrypted private key, prefixed by
              the sting '<encrypted by=\"*\">', where the 'by' value
              is a device specific value that might represent, e.g.,
              the device's serial number, the TPM's serial number,
              and/or the specific key identifier within the TPM.";
         }
       }
       type enumeration {
         enum permanently-hidden {
           description
             "Used for hidden-keys the device is unable to encrypt.";
         }
       }

     }
   }
 

Now let's add back the ability for a client to request a "not-hidden" key to be created (note: we only need the 'generate' action, since <edit-config> is effectively the same as an 'install' action):

     +--rw keystore
        +--rw asymmetric-keys
           +--x generate-key      <-- LOOK HERE
           |  +--w input
           |     +--w name         // "name" MUST NOT conflict with any other name in use
           |     +--w algorithm
           +--rw asymmetric-key* [name]
              +--rw name
              +--rw algorithm 
              +--rw public-key
              +--rw private-key 
              +---x generate-certificate-signing-request
              +--rw certificates
                 +--rw certificate* [name]

Note that the action has been added to the parent "container", to avoid to need for the client to first have to create the "asymmetric-key" in <running>.  Now let's discuss what this action does.  Two options:

1) it generates values in <running>.  This is most friendly, but gives some folks heartburn ;)
2) it generates values in <operational>, thus necessitating that the client MUST first COPY
   those values into <running> before they can be referenced by configuration.  Note that
   this is exactly the same language used above, with respect to a manufacturer-generated
   private key and IDevID certificate.


If we stopped here, I think we'd have a go-to-market solution, but let's enable `generate-key` to be able to create a "hidden" key:

     +--rw keystore
        +--rw asymmetric-keys
           +--x generate-key
           |  +--w input
           |     +--w name
           |     +--w hidden?    boolean  {hidden-keys-supported}?     <--- LOOK HERE
           |     +--w algorithm
           +--rw asymmetric-key* [name]
              +--rw name
              +--rw algorithm 
              +--rw public-key 
              +--rw private-key
              +---x generate-certificate-signing-request
              +--rw certificates
                 +--rw certificate* [name]


Now the only thing left is the ability to install a hidden key, which could be supported as follows:

     +--rw keystore
        +--rw asymmetric-keys
           +--x generate-key
           |  +--w input
           |     +--w name
           |     +--w hidden?    boolean  {hidden-keys-supported}?
           |     +--w algorithm
           +--x install-hidden-key  {hidden-keys-supported}?     <-- NOTE "hidden" in name and
           |  +--w input                                             no "hidden" input param...
           |     +--w name
           |     +--w algorithm
           |     +--w public-key 
           |     +--w private-key
           +--rw asymmetric-key* [name]
              +--rw name
              +--rw algorithm 
              +--rw public-key 
              +--rw private-key 
              +---x generate-certificate-signing-request
              +--rw certificates
                 +--rw certificate* [name]

Presumably how this action works would be similar to how the `generate-key` action works.


This is what I think we should do.

Kent // contributor