Re: [Netconf] Semi-configurable design in server model draft

[Kent Watsen <[e-mail]>]

Replying to myself here, the answer came during a revised-datastore authors call earlier today.  The solution is for the configuration to use the same list key value as used by the system.  For example, assume the system created:

  <keystore xmlns="urn:ietf:params:xml:ns:yang:ietf-keystore">
    <keys>
      <key origin='system'>     <-- revised-datastore metadata
        <name>DevID Key</name>
        ...
        <certificates>
          <certificate>
            <name>IDevID certificate<name>
            <value>base64-encoded X.509 cert</value>
          </certificate>
        </certificates>
      </key>
    </keys>
  </keystore>


At this point, there is no "configuration", just a system-generated key that shows in the operational state.  Now a client can configure an LDevID certificate for it as follows:

     <rpc message-id="101"
          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <edit-config>
         <target>
           <running/>
         </target>
         <config>
           <keystore xmlns="urn:ietf:params:xml:ns:yang:ietf-keystore">
             <keys>
               <key>
                 <name>DevID Key</name>   <-- note: same key value
                 <certificates>
                   <certificate>
                     <name>LDevID certificate<name>
                     <value>base64-encoded X.509 cert</value>
                   </certificate>
                 </certificates>
               </key>
             </keys>
           </keystore>
         </config>
       </edit-config>
     </rpc>


After this, another <get-data> request on the operational state datastore returns the following result.  Note: I'm going a little bit out on a limb here with regards to the recursive application of the 'origin' annotation, at least it hasn't been discussed before, but it seems obvious that this is what we'd want.

  <keystore xmlns="urn:ietf:params:xml:ns:yang:ietf-keystore">
    <keys>
      <key origin='static'>     <-- used to be 'system'
        <name>DevID Key</name>
        ...
        <certificates>
          <certificate origin='system'>    <-- now this is 'system'
            <name>IDevID certificate<name>
            <value>base64-encoded X.509 cert</value>
          </certificate>
          <certificate>
            <name>LDevID certificate<name>
            <value>base64-encoded X.509 cert</value>
          </certificate>
        </certificates>
      </key>
    </keys>
  </keystore>


Does this make sense to everyone?  Can we move forward with this approach?  I'll assume it is if no one responds otherwise in a few days.

Thanks,
Kent


-----ORIGINAL MESSAGE-----

Picking up where we left off, we discussed making 'private-key' configurable, as shown below, protected by nacm:default-deny-all.  This, in lieu of having an action statement called 'generate-private-key', which is the crux of the issue described in the subject line.

    +--rw keystore
       +--rw keys
          +--rw key* [name]
             +--rw name                            string
             +--rw private-key?                    binary
             +--ro algorithm?                      identityref
             +--ro key-length?                     uint32
             +--ro public-key                      binary
             +--rw certificates
                +--rw certificate* [name]
                   +--rw name     string
                   +--rw value?   binary

This resolves one issue, but then raises another, which is how to fully support system-generated keys, such as a key created by a TPM, that need to have certificates configured for them, such as IDevID or an LDevID certificates from IEEE 802.1AR.

Again, while we now know to use the operational state datastore to represent system-generated values, the problem becomes how to *configure* certificates for these system-generated keys, specifically the IDevID and LDevID certificates.  

But, as seen in the tree-diagram above, this is not a leafref problem, which might be solved using a solution like the one proposed for the I2RS topo model, where a require-instance false leafref in the running datastore *can* point to a node in the operational state datastore.  No, here the 'certificate' nodes are descendants of the 'key' node, so the leafref solution doesn't apply.

I don't have any good ideas for how to address this issue. Does anyone have any thoughts on how we should handle it?

[ref: https://github.com/netconf-wg/keystore/issues/2]

Thanks,
Kent