Re: [netconf] built-in trust anchors

[Martin Björklund <[e-mail]>]

Kent Watsen <[e-mail]> wrote:
> Hi Martin,
> 
> 
> > On Jan 14, 2021, at 2:46 AM, Martin Björklund <[e-mail]>
> > wrote:
> > 
> > Kent Watsen <[e-mail]> wrote:
> >> [Top-posting as this is a response to the entire thread, sans
> >> draft-ma-netconf-with-system, which I haven’t looked at yet].
> 
> Update: I did look at this draft and found the motivation unclear.
> 
> 
> >> Having "instance-required false” was an idea from before, but it
> >> didn’t make sense to disable validation for the 99% use-case to enable
> >> a 1% use-case.  There will only ever be a few built-in keys/certs
> >> (typically at most just one of each, to enable bootstrapping), whereas
> >> potentially many keys/certs will be configured over time (for normal
> >> ops).
> > 
> > Ok.
> > 
> >> Hiding all the descendent nodes except “name” for built-in keys/certs
> >> doesn’t work because the pubkey/cert is needed in order to encrypt
> >> data that only a device can decrypt
> > 
> > I don't understand this.  The descendent nodes would not be present in
> > 'running', but they would be present in <operational> (b/c they are
> > present in the firmware).
> 
> I think that there is a misunderstanding somewhere.  It might be
> helpful for me to clarify that, at a high-level: 1) the drafts only
> present a *configuration* model, and that 2) it’s possible that some
> “config” only shows up in <operational>, when the values are
> “built-in”.
> 
> For the “config” that only shows in <operational>, it’s necessary to
> promote them to <running> in order for leafrefs to resolve.  I agree
> that only the “name” is needed, but we lack a mechanism to just
> configure a name as otherwise 1) validation would fail because
> "mandatory true” descendants would fail validation and 2) there’s no
> way to tell “apply config” process to not-delete the missing values.

It can be done by doing something similar to "hidden", here's a sketch
of the idea:

  list certificate-bag {
    key name;
    leaf name { ... }
    choice type {
      case inline {
        list certificate { ... }
      }
      case built-in {
        leaf built-in { type empty; }
      }
    }
  }


> >> , as needed to support RMA
> >> scenarios (see
> >> https://tools.ietf.org/html/draft-ietf-netconf-keystore-20#section-4.3
> >> <https://tools.ietf.org/html/draft-ietf-netconf-keystore-20#section-4.3>
> >> starting with the 4th paragraph).
> >> 
> >> The built-in keys/certs are envisioned to be forever; they never
> >> expire nor are affected by firmware updates.
> > 
> > :)
> > 
> >> For the example of a
> >> list of public CAs (trust anchors such as Verisign, RSA, etc.), these
> >> SHOULD be in <startup> and admins SHOULD be allowed (NACM permitting)
> >> to add/remove entries.
> >> 
> >> I agree that the “illusion” text Martin quoted is "weird special
> >> handling”, but this was the best that could be envisioned after
> >> several tries.  You might recall there were two or three other
> >> variations (inc. the "instance-required false” mentioned above) that
> >> we tried before landing on this approach.
> > 
> > Since this problem comes up every now and then, it would be good with
> > a design pattern that can work in other cases as well.  
> 
> I agree the patterns are good, but disagree that *this* come up once
> in awhile or, for that matter, ever before…and likely never again (at
> least not within my understanding).
> 
> 
> > It seems that
> > the "hidden" design already used in crypto-types can be used in this
> > case, as Jürgen suggested.
> 
> Please note that the value is hidden in <operational> originally.
> This is because, e.g., it is impossible to extract a private key value
> from a TPM.  Regardless, the net-net is that the value is “hidden” in
> both <operational> *and* <running> (when the asymmetric key has been
> copied into <running>).  To be clear, hidden private keys nodes still
> appear in <running> (they are *not* missing) and have the same value
> as appears in <operational>.

Yes.

> >  I don't remember this propsal from the
> > previous discussion; was it discussed?
> 
> We’ve been discussing these drafts for a long time, and you know that
> I’ve been careful to communicate pretty much everything along the way…

Absolutely, this is much appreciated!

> Looking at the keystore draft's Change Log, I see that the
> “require-instance false” idea was added in -05 (June 2018) and removed
> in -07 (April 2019).
> 
> As for “hidden”, the current approach arrived in crypto-types-08.
> Previously, the node was a ‘union’ with "permanently-hidden” being an
> enumerated value.  This idea was moved into crypto-types-01 from
> keystore-06.  It was called "hardware-protected” in keystore 03-05,
> and “INACCESSIBLE” in keystore 01-02.
> 
> We also explored letting the private-key value be "mandatory false”
> somewhere along the line.  Without digging for dates, I’m sure the
> reason we backed out of it is because, again, it didn’t make sense to
> do it for a 1% use case.

I much prefer Jürgen's proposal than haveing special rules for some
nodes in <running>.  Especially if it falls into this "1%" bucket.


/martin