Re: [Netconf] Mandatory local configuration in Keystore groupings

[Kent Watsen <[e-mail]>]

> With (A), once you have generated the key, you first have to create
> the config for it, then invoke the action.   With (C) (99% of) the 
> keys already exist in the config, so you can just invoke the action.

I don't follow.  What I see is that, with (A), a hidden key can be 
created with a single action invocation while, with (C), first a 
configuration operation is needed to create the "asymmetric-key" 
(without the three leafs) followed by an action invocation (to 
populate the three leafs).


> To summarize, A and C both get the job done.  Which one is better is
> probably subjective.  I think (C) is might be easier to understand.

Okay, let's see how it looks.  Bubbling all the ideas to the top, I 
created the below tree-diagrams.  Note, in both cases, the three 
"mandatory true" leafs are replaced with an all-or-nothing "must" 
expression:


(A) Uses RFC 8342 Section C.3.2 style config overlays for all hidden keys;
    and an action statement is used to delete all hidden keys.

     +--rw keystore
        +--rw asymmetric-keys
           +--rw asymmetric-key* [name]
           |  +--rw name                            string
           |  +--rw algorithm?                      ct:key-algorithm-ref
           |  +--rw public-key?                     binary
           |  +--rw private-key?                    union
           |  +---m "(algorithm and public-key and private-key)
           |  |       or not (algorithm or public-key or private-key)";
           |  +--rw certificates
           |  |  +--rw certificate* [name]
           |  |     +--rw name                      string
           |  |     +--rw cert                      ct:end-entity-cert-cms
           |  |     +---n certificate-expiration
           |  |        +-- expiration-date?         yang:date-and-time
           |  +---x generate-certificate-signing-request
           |  |  +---w input                        // KEY MAY BE IN <OPERATONAL>
           |  |  |  +---w subject                   binary
           |  |  |  +---w attributes?               binary
           |  |  +--ro output
           |  |     +--ro certificate-signing-request    binary
           |  +---x delete-hidden-key
           |        // no params
           +---x generate-hidden-key
           |  +---w input                           // RESULT IN <OPERATONAL>
           |     +---w name                         string
           |     +---w algorithm                    ct:key-algorithm-ref
           +---x load-hidden-key
              +---w input                           // RESULT IN <OPERATONAL>
                 +---w name                         string
                 +---w algorithm                    ct:key-algorithm-ref
                 +---w public-key                   binary
                 +---w private-key                  union


(C) Uses RFC 8342 Section C.3.2 style config overlays only for hidden keys
    created in <operational> (i.e., during manufacturing).  But if there is
    even just one key created during Manufacturing, and it doesn't appear
    in <intended>, then leafrefs still need to be "require-instance false",
    right? Also, it seems that such keys could never be deleted, unlike 
    other hidden keys, but that is probably okay (correct behavior).

     +--rw keystore
        +--rw asymmetric-keys
           +--rw asymmetric-key* [name]
              +--rw name                            string
              +--rw algorithm?                      ct:key-algorithm-ref
              +--rw public-key?                     binary
              +--rw private-key?                    union
              +---m "(algorithm and public-key and private-key)
              |       or not (algorithm or public-key or private-key)";
              +--rw certificates
              |  +--rw certificate* [name]
              |     +--rw name                      string
              |     +--rw cert                      ct:end-entity-cert-cms 
              |     +---n certificate-expiration
              |        +-- expiration-date?         yang:date-and-time
              +---x generate-hidden-key
              |  +---w input                        // RESULT IN <OPERATONAL>
              |     +---w name                      string
              |     +---w algorithm                 ct:key-algorithm-ref
              +---x load-hidden-key
              |  +---w input                        // RESULT IN <OPERATONAL>
              |     +---w name                      string
              |     +---w algorithm                 ct:key-algorithm-ref
              |     +---w public-key                binary
              |     +---w private-key               union
              +---x generate-certificate-signing-request
                 +---w input                        // KEY MAY BE IN <OPERATONAL>
                 |  +---w subject                   binary
                 |  +---w attributes?               binary
                 +--ro output
                    +--ro certificate-signing-request    binary




Kent // contributor