Re: [Netconf] Mandatory local configuration in Keystore groupings

[Balázs Kovács <[e-mail]>]

Hi,

One more question. I found this in ct:

  grouping asymmetric-key-pair-with-certs-grouping {
    description
      "A private/public key pair and associated certificates.";
    uses asymmetric-key-pair-grouping;
    container certificates {
      description
        "Certificates associated with this asymmetric key.
         More than one certificate supports, for instance,
         a TPM-protected asymmetric key that has both IDevID
         and LDevID certificates associated.";
      list certificate {
        must "../../algorithm
               and ../../public-key
                 and ../../private-key";
        key name;
        description
...

Is it ok to have the must statement in the certificate list? I think with (C) the idea was to have hidden keys represented in the configuration for which certificates can still be configured, but hidden keys will have no algorithm/public-key/private-key in configuration. What's your view?

Br,
Balazs

-----Original Message-----
From: Netconf <[e-mail]> On Behalf Of Balázs Kovács
Sent: Tuesday, October 9, 2018 8:50 AM
To: Martin Bjorklund <[e-mail]>; [e-mail]
Cc: [e-mail]
Subject: Re: [Netconf] Mandatory local configuration in Keystore groupings

Hi Kent,

First of all, thank you for the keystore update.

I was checking it at the moment and noticed something that may be a miss.

  typedef asymmetric-key-ref {
    type leafref {
      path "/ks:keystore/ks:asymmetric-keys/ks:asymmetric-key"
           + "/ks:name";
      require-instance false;
    }
    description
      "This typedef enables modules to easily define a reference
       to an asymmetric key stored in the keystore. The require
       instance attribute is false to enable the referencing of
       asymmetric keys that exist only in <operational>.";
    reference
      "RFC 8342: Network Management Datastore Architecture (NMDA)";
  }

I think we were discussing changing 'require-instance' to 'true' in relation to the change toward alternative (C) as discussed below. Should it be 'true' instead of 'false'?

Br,
Balazs

-----Original Message-----
From: Martin Bjorklund <[e-mail]>
Sent: Tuesday, September 18, 2018 10:12 PM
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

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

_______________________________________________
Netconf mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/netconf