Re: [Netconf] Mandatory local configuration in Keystore groupings

[Martin Bjorklund <[e-mail]>]

Hi,

Ok, so we have these two alternatives illustrated below.  There are
some details that probably are wrong, but it doesn't really matter at
this stage.  With (A), there is one more action to control the
lifespan of keys (delete-hidden-key).

In the case that the key is given as config, A and C works in the same
way.

In the case that the key is permanent, A and C also works in the same
way.

A and C differ in how hidden keys are handled.


In order to create a hidden key + certificate, the steps are:

A:  1. call generate-hidden-key with a given name
    2. create an asymmetric-key with the same name in the config
    3. call generate-certificate-signing-request
    4. <get hold of a cert>
    5. create the certificate in the config

(step 1 and 2 can be done in reverse order)

C   1. create an asymmetric-key in the config
    2. call generate-hidden-key on this key
    3. call generate-certificate-signing-request
    4. <get hold of a cert>
    5. create the certificate in the config

In order to delete a hidden key completely:

A:  1. call delete-hidden-key on the asymmetric-key to be deleted
    2. delete the asymmetric-key from the config

C:  1. delete the asymmetric-key from the config



In summary, they are very similar.

One possible twist that probably works best for C could be to use
leafrefs with require instance true, and say that in order to use a
permanent key (created during manufacturing), you first need to create
config for the key (more or less empty config).  The benefit is that
we get proper leafref validation (no dangling pointers to handle in
all other models).  FWIW, this is the approach taken in
ietf-interfaces.

If we don't do this twist, I think that we can use either of A and C.



/martin




Kent Watsen <[e-mail]> wrote:
> 
> > 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
> 
> 
>