Re: [netconf] built-in trust anchors

[Kent Watsen <[e-mail]>]

Hi Martin,

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

Thank you for the example.  It's infinitely easier to understand what folks intend when examples are provided.

Yes, your model enables just the “name” node to appear, but I’m confused/concerned by its implications...

In particular, what would be in <operational> in a device as shipped from Manufacturing?  It can’t be “built-in” because the certificate data must be accessible.  But, assuming it’s “inline”, then we’d expect “inline” in <running> too, right?  If not, then we're devising yet other special case rules that are no better than those described in the truststore draft.  Worse, how to reference specific certs (not the bag), as is needed in some cases (not a TLS-client), becomes even more complicated.

Related, please see my response just now to Tom.




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

Do you mean that built-in values should be in <factory-default>, not <operational>?

It is an interesting idea, and one I hadn’t considered before, but:

1) there would still be a need for special-case rules ensuring that descendent nodes of “built-in” (read-only) keys/certs are never changed. E.g., consider a built-in (TPM-protected) key having an associated IDevID cert, nothing about it can vary.

2) how do vendor-updates for the built-in public CA certs get picked up?  Do we suggest that operators re-merge that part of <factory-default> into their <running> after each OS update?  (And what if the update occurs via ZTP and somehow that new cert is needed then?)

3) looking to my response to Tom, the proposal supports #3 - is this what we want?   I personally think that deleting built-in public CA certs is a questionably bad idea (too many things can break).  #2 is “okay” (at least nothing breaks), but some may question if it’s ever needed (i.e., rather than merge a new cert into the existing bag, it may be better to put it in its own bag and have the TLS-client point that bag instead).  #1 is the most conservative, perhaps to a fault, but in the world of security, sometimes that is what’s needed.

4) it seems that it may be possible to use alternate cert-data for a “built-in” cert.  E.g., consider a built-in public CA cert called “Verisign Root CA 2009-2”, it would be possible to configure a cert having that name/key but with a different base64 value, potentially opening up an attack vector.  My intention for #3 was “all or nothing”, that is, certs can be present or deleted in their entirety, nothing in-between. 

5) The entire contents of the built-in public CA certs bag would have to be copied into <running>, cluttering it up unnecessarily with a bunch of base64 strings representing the contents of, e.g., /etc/ssl/certs/.  Maybe this is okay, but it would likely be unwelcomed by many.


My seems that the currently documented approach (tweaked per my email to Tom) is still the simplest, agreed?   Yes, there are special case rules, but they’re simple (“treat built-in values as read-only”).

K.