Re: [Netconf] Mandatory local configuration in Keystore groupings

[Martin Bjorklund <[e-mail]>]

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

Yes; in (C), "generate-hidden-key" and "load-hidden-key" doesn't take
"name" as input.


/martin


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