Subject: Re: [Netconf] Mandatory local configuration in Keystore groupings

From: Martin Bjorklund <[email-masked]>
Date: Mon, 03 Sep 2018 12:18:23 +0200 (CEST)

Kent Watsen <[email-masked]> wrote:
> > Balazs> The certificates in keystore are useless without a corresponding
> > private key, so certificates of a key cannot be in the configuration 
> > tree once the corresponding key is removed. By the way, how would a 
> > private key be removed from <operational> if it does not exist in 
> > configuration? If you do it with an action too, how would the 
> > corresponding certificates be removed from the configuration?
> 
> Good points.

Yes.  The lifecycle of keys are not handled fully in the current
draft.  But I think that if this is done properly, separating the
config of keys and certificates would not change the lifecycle of how
keys.  So let's first discuss how we want to handle creation and
removal of the hidden keys (configured keys are not a problem).

With the current draft, a hidden key is created in <operation> with an
action and may not be present in <running> and <intended>.  There is
no way to delete such a key.  We would have to create a new action to
remove it.

An alternative design could be to move the action
"generate-asymmetric-key" into the "asymmetric-key" list (and maybe
rename it to "generate-hidden-key").  A client would then first have
to configure an entry in the "asymmetric-key" list, and then it can
generate the hidden key.  If the asymmetric-key list entry is removed
from <intended>, then presumably the corresponding hidden key is
removed as well.

With this design, a separate "certificate" list could have normal
leafref (require-instance true) into the "asymmetric-key" list.
However, with this new design my original issue with how certificates
are handled goes away, so having them contained in the
"asymmetric-key" list works fine.

> >> Martin makes a case for 'B', but he also said that my 'b' was 
> >> "Better" but has scaling issues in the general case.  Perhaps 
> >> we don't worry about the general case here?
> >
> > Balazs> Was it so? I saw an A and B model, A containing 
> > must "(algorithm and public-key and private-key)
> >              or not (algorithm or public-key or private-key)";
> > and B containing the keys and the certificates in separate container,
> > and a note "I think model B is cleaner".
> 
> Right, but if you scroll up higher, I had previously had an (a) and (b)
> [note lowercase] to which he said (b) was "better".  Maybe it's moot,
> since his (A) was effectively my (b).

Here's the new alternative:

(C)

  container keystore {
    container asymmetric-keys {
      list asymmetric-key {
        key name;

        leaf name { ... }
        leaf algorithm { mandatory true; ... }

        leaf public-key { ... }
        leaf private-key { ... }

        // ensure that both or none are given
        must "(public-key and private-key)
              or not (public-key or private-key)";

        action generate-hidden-key { // no input params }

        container certificates {
          list certificate { ... }
        }
    }
  }

A possible extension to this would be to add anoter action next to
"generate-hidden-key":

   action install-hidden-key {
      leaf public-key { ... }
      leaf private-key { ... }
   }

One case to consider is that there may exist an entry in <intended>
that has been configured but no hidden key has yet been generated.
Such an entry would then not exist in <operational>, and the action
"generate-certificate-signing-request" would fail.

/martin

> My point is that the containment approach 1) does resolve the he primary
> goal (configuring a cert for a key in <operational> and 2) I'm not concerned
> about the general scaling problem.  By "perhaps we don't worry about the
> general case here?", I mean to say that I prefer keeping the containment
> approach.
> 
> 
> > If I got it well, model A would keep the containment and produce
> > the key name after invoking the action (affecting the configuration 
> > tree!?) at least covering the key removal use case properly.
> 
> Invoking the generate/load-asymmetric key actions, as thus far dscribed,
> would NOT affect the config tree (i.e., <intended>), only <operational>.
> 
> 
> > Balazs> If the key generation and load only affects the <operational>
> > only, I would rather vote for model A having the containment relationship
> > between key and certificate(s). 
> 
> This is my preferred approach as well.
> 
> 
> > Plus, I would also think about the mandatory statements in the
> > configuration tree whether all 4 leaves (name, private-key,
> > public-key, alg) or just name and private key needs to be configured.
> 
> I'm think all four are needed.  Only public-key is possibly not needed,
> but it's trivial to ask a client to pass it, so why not?
> 
> 
> > ...but why use an action at all then?  Everything can be done via 
> > standard configuration, right?
> >
> > Balazs> That is actually a good question. Until the enum had the 
> > literal 'hardware-protected' only the configuration use case of 
> > the private-key was a bit unclear. Now I assume configuring the 
> > private-key as 'hidden' could do the same as generate-private-key,
> > but in that case the operator has no means to configure the public
> > key (the removal of the mandatory condition for the public key
> > could solve this). Regarding 'alg', I guess if hidden private key
> > is asked, then algorithm is an input, but if binary private-key
> > is configured, then it is rather implicit. Would the action be
> > needed then?
> 
> There are a few things off in what you write, but the most important
> thing is that there is no way to *configure* (via <intended>) a hidden
> key.  Trying to do so, by passing the "hidden" enum, means that the
> real private key raw data would NOT be set!
> 
> 
> > Balazs> The action in this case seem to make sense only if the 
> > purpose of the actions is really to only affect <operational>. 
> 
> Yes, that is the intent.
> 
> 
> > But based on the above, I doubt yet how affecting configuration 
> > can be avoided (even with alt A -> to maintain consistent composition
> > of key and cert) I think this question goes back to some YANG 
> > principles and is beyond my YANG competence.
> 
> I'm not following, can you say a different way?
> 
> 
> Kent // contributor
> 
> 
> 
>

---

From: Balázs Kovács <[email-masked]>
Date: Mon, 3 Sep 2018 12:08:11 +0000

Hi Kent,

See below.
Br,
Balazs

> -----Original Message-----
> From: Kent Watsen <[email-masked]>
> Sent: Thursday, August 30, 2018 11:15 PM
> To: Balázs Kovács <[email-masked]>; Martin Bjorklund
> <[email-masked]>; Balázs Lengyel <[email-masked]>
> Cc: [email-masked]
> Subject: Re: [Netconf] Mandatory local configuration in Keystore groupings
> 
> 
> 
> 
> > Balazs> I preferred the original short name and for me it was clear
> > that this action produces a 'hidden' key. I actually like the idea of
> > changing the 'hardware-protected' enum literal to 'hidden'.
> 
> okay
> 
> 
> > Balazs> I myself just started to realize that you intend to maintain
> > an operational tree that is out-of-sync with the configuration tree.
> 
> unsure what you mean here.
>

I meant the state in operational datastore is not reflected in some way in the configuration datastore. This was a confusion from my side.

> 
> > For example, a public key can be determined from the private key. It
> > is ok to require an instance of public key (with must) for a private
> > key, but why is it mandatory to configure it?
> 
> In most asymmetrical crypto system implementation, the only fact that
> is ensured is that you cannot find the private key from the public key.
> The other way around, finding the public key from the private key is
> trivial, but not guaranteed, in most cases.
> 
> 
> > I did expect the public key filled in either by generate-asymmetric-key
> > action, or by configuring private key.
> 
> You want the public key to be automatically computed from the private
> key, right?   It might be possible, but it's always possible that the
> client can pass both, so the thinking is just do that - makes sense?
> 

Yes it makes, see below (also related to the 'hidden' enum discussion below).

> > Also the private-key, the public-key, and the algorithm leaves need to
> > be in sync (all valid in respect to the other)
> 
> True.  I think you're making a case for letting the server derive the
> public key, as the client might pass a mismatched set.  Deriving the
> pubkey vs verifying a passed pubkey: both ops require crypto clue,
> but only one is guaranteed to always work.
> 
> >>> In our opinion with Balazs L., we think it would be disadvantageous to
> >>> change the model by ruining the containment relationship between
> >>> certificate and corresponding asymmetric key.
> >>
> >> Can you say some more about this?  Is it mostly that the containment
> >> is really intuitive?  That the relationship is linked both ways,
> >> whereas a leadref only goes one way?
> >

Ok, I follow.

> general case here?", I mean to say that I prefer keeping the containment

With the containment approach, does it still mean that the operator must read the key names in <operational> and create a key and certificate in the configuration datastore, where key name must match a right key stored in <operational>? How can a key be removed?

> This is my preferred approach as well.

Ok.

> but it's trivial to ask a client to pass it, so why not?

Well, ok, let's keep it as it is in the new must statement you proposed.

> real private key raw data would NOT be set!

If it is 'hidden', then is there a need to set the real private key raw data? It can just be drawn as it was when invoking generate-asymmetric-key.  Or what is the difference between generate-asymmetric-key vs. setting 'hidden' enum (regardless of the user not being able to provide public key in 'hidden' case--which is currently a must)?

> I'm not following, can you say a different way?

What is the procedure to remove a key that was created via generate-asymmetric-key?

---

From: Balázs Kovács <[email-masked]>
Date: Tue, 4 Sep 2018 08:34:35 +0000

Hi Martin,

I prefer your alternative (C) with some comments.

I'd keep the name of the action as 'generate-asymmetric-key'. I think the word 'asymmetric' gives a hint on its intended use case, so it is important (though it is already in an asymmetric-key list). The word 'hidden' is not that important for me since the action in itself hints that the key in this case is not provided by the operator, thus its binary value won't appear either. If operator needs to provide it, it has to go via the 'private-key' leaf. Or the action could be just called 'generate-key'.

A question still: it is unclear to me what the difference is between calling the action vs just configuring the 'private-key' to enum 'hidden'.

Br,
Balazs

> From: Martin Bjorklund <[email-masked]>
> Sent: Monday, September 3, 2018 12:18 PM
> To: [email-masked]
> Cc: Balázs Kovács <[email-masked]>; Balázs Lengyel
> <[email-masked]>; [email-masked]
> > > Balazs> The certificates in keystore are useless without a
> > > Balazs> corresponding
> Yes.  The lifecycle of keys are not handled fully in the current draft.  But I
> think that if this is done properly, separating the config of keys and
> certificates would not change the lifecycle of how keys.  So let's first discuss
> how we want to handle creation and removal of the hidden keys (configured
> keys are not a problem).
> 
> With the current draft, a hidden key is created in <operation> with an action
> and may not be present in <running> and <intended>.  There is no way to
> delete such a key.  We would have to create a new action to remove it.
> 
> An alternative design could be to move the action "generate-asymmetric-
> key" into the "asymmetric-key" list (and maybe rename it to "generate-
> hidden-key").  A client would then first have to configure an entry in the
> "asymmetric-key" list, and then it can generate the hidden key.  If the
> asymmetric-key list entry is removed from <intended>, then presumably the
> corresponding hidden key is removed as well.
> 
> With this design, a separate "certificate" list could have normal leafref
> (require-instance true) into the "asymmetric-key" list.
> However, with this new design my original issue with how certificates are
> handled goes away, so having them contained in the "asymmetric-key" list
> works fine.
> 
> > >> "Better" but has scaling issues in the general case.  Perhaps we
> > >> don't worry about the general case here?
> > >
> > >              or not (algorithm or public-key or private-key)"; and B
> > > containing the keys and the certificates in separate container, and
> > > a note "I think model B is cleaner".
> >
> > Right, but if you scroll up higher, I had previously had an (a) and
> > (b) [note lowercase] to which he said (b) was "better".  Maybe it's
> > moot, since his (A) was effectively my (b).
> 
> One case to consider is that there may exist an entry in <intended> that has
> been configured but no hidden key has yet been generated.
> > My point is that the containment approach 1) does resolve the he
> > primary goal (configuring a cert for a key in <operational> and 2) I'm
> > not concerned about the general scaling problem.  By "perhaps we don't
> > worry about the general case here?", I mean to say that I prefer
> > keeping the containment approach.
> >
> >
> > > If I got it well, model A would keep the containment and produce the
> > > key name after invoking the action (affecting the configuration
> > Invoking the generate/load-asymmetric key actions, as thus far
> > dscribed, would NOT affect the config tree (i.e., <intended>), only
> <operational>.
> >
> >
> > > Balazs> If the key generation and load only affects the
> > > Balazs> <operational>
> > > only, I would rather vote for model A having the containment
> > > relationship between key and certificate(s).
> >
> > I'm think all four are needed.  Only public-key is possibly not
> > needed, but it's trivial to ask a client to pass it, so why not?
> >
> >
> > > literal 'hardware-protected' only the configuration use case of the
> > > private-key was a bit unclear. Now I assume configuring the
> > > key (the removal of the mandatory condition for the public key could
> > > solve this). Regarding 'alg', I guess if hidden private key is
> > > asked, then algorithm is an input, but if binary private-key is
> > > configured, then it is rather implicit. Would the action be needed
> > > then?
> >
> > > But based on the above, I doubt yet how affecting configuration can
> > > be avoided (even with alt A -> to maintain consistent composition of
> > > key and cert) I think this question goes back to some YANG

---

From: Kent Watsen <[email-masked]>
Date: Tue, 11 Sep 2018 00:58:16 +0000

There are two solutions being discussed here.  

The first regards how to enable a certificate to be configured for a key
in <operational> (e.g., an LDevID cert for a preexisting key).  Both
solution (A) and (C) give us this - a la RFC 8342 Section C.3.2.

The second is how to delete a "hidden key" created by a client (note here
that I'm distinguishing this case from hidden keys not created by a client,
i.e., in <operational>, which cannot be deleted).  Here's where the ideas
diverge:

  - with (A), we keep the "generate" action outside the list entry (thus
    results are in <operational>, and add a new "delete-asymmetric-key"
    action is needed.

  - with (C), the action is moved inside the list entry, thus the list
    entry node itself in <intended>, and hence can be removed from
    <intended> via a normal config operation (no special action needed).

I don't see an issue configuring certificates in either case.  As I wrote
above, both solution (A) and (C) give us this. (C) still has to handle
the case where the key is in <operational> same as (A).  With (C), it's
the 1% case, whereas with (A) it’s the 100% case.

They seem close.  For the purpose of creating a key, (C) is more
complicated.  For the purpose of deleting a key, (C) seems easier.

If the action is brought inside the list entry, then renaming it to
"generate-hidden-key" makes sense.

Kent // contributor

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

Hi Martin,

Br,
Balazs

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 11 Sep 2018 09:53:34 +0200 (CEST)

Hi,        

> the 1% case, whereas with (A) it’s the 100% case.

How can a key be in operational but not in config in (C)?  I.e., what
is the 1% case?

> complicated.  For the purpose of deleting a key, (C) seems easier.

For the purpose of creating a certificate (A) is more complicated.

Depending on the answer above, (C) has the advantage that references
(leafrefs) to a key can be require instance true.  With (A) they have
to be require instance false, since some keys only exists in
operational, which means that whenever there is a reference to a key,
that model and code must be able to handle the case that the key
doesn't exist.

/martin

---

From: Balázs Kovács <[email-masked]>
Date: Tue, 11 Sep 2018 07:58:36 +0000

Hi Kent and Martin,

I agree with the comments of Martin. If you look at the whole use case of key and certificate provisioning, (C) is simpler for both creation and removal. The issue of leafrefs adds even more on the side of (C).

Br,
Balazs

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

Hi,        

Kent Watsen <[email-masked]> wrote:
> The first regards how to enable a certificate to be configured for a 
> key in <operational> (e.g., an LDevID cert for a preexisting key).  
> Both solution (A) and (C) give us this - a la RFC 8342 Section C.3.2.
> 
> The second is how to delete a "hidden key" created by a client (note 
> here that I'm distinguishing this case from hidden keys not created by 
> a client, i.e., in <operational>, which cannot be deleted).  Here's 
> where the ideas
> diverge:
> 
> I don't see an issue configuring certificates in either case.  As I 
> wrote above, both solution (A) and (C) give us this. (C) still has to 
> handle the case where the key is in <operational> same as (A).  With 
> (C), it's the 1% case, whereas with (A) it’s the 100% case.

How can a key be in operational but not in config in (C)?  I.e., what is the 1% case?

Depending on the answer above, (C) has the advantage that references
(leafrefs) to a key can be require instance true.  With (A) they have to be require instance false, since some keys only exists in operational, which means that whenever there is a reference to a key, that model and code must be able to handle the case that the key doesn't exist.

/martin

> > > > private key, so certificates of a key cannot be in the 
> > > > configuration tree once the corresponding key is removed. By the 
> > > > way, how would a private key be removed from <operational> if it 
> > > > does not exist in configuration? If you do it with an action 
> > > > too, how would the corresponding certificates be removed from the configuration?
> > >
> > > Good points.
> > 
> > config of keys and certificates would not change the lifecycle of 
> > how keys.  So let's first discuss how we want to handle creation and 
> > With the current draft, a hidden key is created in <operation> with 
> > an action and may not be present in <running> and <intended>.  There 
> > is no way to delete such a key.  We would have to create a new action to remove it.
> > 
> > "generate-asymmetric- key" into the "asymmetric-key" list (and maybe 
> > rename it to "generate- hidden-key").  A client would then first 
> > have to configure an entry in the "asymmetric-key" list, and then it 
> > can generate the hidden key.  If the asymmetric-key list entry is 
> > removed from <intended>, then presumably the corresponding hidden key is removed as well.
> > 
> > However, with this new design my original issue with how 
> > certificates are handled goes away, so having them contained in the 
> > > > and B containing the keys and the certificates in separate 
> > > > container, and a note "I think model B is cleaner".
> > >
> > > (b) [note lowercase] to which he said (b) was "better".  Maybe 
> > > it's moot, since his (A) was effectively my (b).
> >

---

From: Kent Watsen <[email-masked]>
Date: Tue, 11 Sep 2018 19:40:57 +0000

> How can a key be in operational but not in config in (C)?  I.e., what

Maybe too subtle, but in my first paragraph above said "e.g., an LDevID
cert for a preexisting key".  I'm referring to how, during manufacturing,
a private key and an associated IDevID certificate are created and loaded
onto the device.  This key and cert are immutable, but another cert could
be loaded for the same key.  This is the scenario captured in the example
in: https://tools.ietf.org/html/draft-ietf-netconf-keystore-05#section-3.2.
(search for "tpm-protected-key").  This is the 1% case.

> For the purpose of creating a certificate (A) is more complicated.

How is that so?  Actually, it seems that (A) and (C) are identical
in this respect, from a protocol perspective.  The only difference
is in the backend, where it uses the RFC 8342 Section C.3.2 overlay
behavior.

> that model and code must be able to handle the case that the key

Even with (C), some keys can be in <operational> - the 1% case, right?

Yes, if *all* keys had a presence in <intended>, then learefs to keys
could be "require-instance true".

Kent // contributor

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 17 Sep 2018 16:38:19 +0200 (CEST)

Ok.

> is in the backend, where it uses the RFC 8342 Section C.3.2 overlay

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.

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.

> could be "require-instance true".

Right.

/martin

---

From: Kent Watsen <[email-masked]>
Date: Mon, 17 Sep 2018 21:42:01 +0000

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

> 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

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 18 Sep 2018 09:02:27 +0200 (CEST)

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

---

From: Balázs Kovács <[email-masked]>
Date: Tue, 18 Sep 2018 09:39:40 +0000

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 <[email-masked]> 
Sent: Tuesday, September 18, 2018 9:02 AM
To: [email-masked]
Cc: Balázs Kovács <[email-masked]>; Balázs Lengyel <[email-masked]>; [email-masked]
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.

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.

/martin

---

From: Kent Watsen <[email-masked]>
Date: Tue, 18 Sep 2018 18:52:58 +0000

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,

Br,
Balazs

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

Hi,

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 18 Sep 2018 22:12:10 +0200 (CEST)

Kent Watsen <[email-masked]> 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
> 
> 
> 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.
> 
> 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
>