Re: [Netconf] Mandatory local configuration in Keystore groupings

[Kent Watsen <[e-mail]>]

I like Martin's "twist" - I don't view it as an extreme hardship (the 1% case), and I prefer (C) for supporting "require-instance true" as well as having one less action.  So, let's go with (C).

Martin, you mentioned some details might be wrong, are they wrong in (C)?  - I'd like to have it right when posting the next update...

Balazs, the desire to reference an IDevID could be from any SSH/TLS-based app, it would be hard to know in advance where.  No matter, with (C)+twist, we can have "require-instance true" always.

Kent // contributor


-----Original Message-----

Hi,

I'd just emphasize that in creation step of hidden key, the name must be coordinated between step A/1&2 by external application logic. Same holds for deletion of hidden key for A/1&2. "Same name" is important.

Enabling the possibility for 'require instance true' would be also good remark on the side of (C).

Regarding manufactured keys, I would not expect manufactured keys to be used in other common models, such as in TLS/SSH use cases. If they have some specific use case, maybe those models could either have 'require instance false' or it could be said to create an empty key for them as Martin described.

Br,
Balazs

-----Original Message-----
From: Martin Bjorklund <[e-mail]> 
Sent: Tuesday, September 18, 2018 9:02 AM
To: [e-mail]
Cc: Balázs Kovács <[e-mail]>; Balázs Lengyel <[e-mail]>; [e-mail]
Subject: Re: [Netconf] Mandatory local configuration in Keystore groupings

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
> 
> 
>