Re: [netconf] built-in trust anchors

[Kent Watsen <[e-mail]>]

Hi Tom,


> 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).
> 
> <tp>
> depends where you are.  For me, the great advance in Internet security was when Microsoft built in the certificates I needed to access sites securely, in the shrink-wrapped software.  I do not know how many there are but it is now rare for me to need to add one.
> 
> By contrast other certificates are ephemeral, used for a session and then discarded.
> 
> I can guess the model you have in mind but suspect that it is not the common one when looking at security across the Internet as a whole.

Please see https://tools.ietf.org/html/draft-ietf-netconf-trust-anchors-13#section-3 <https://tools.ietf.org/html/draft-ietf-netconf-trust-anchors-13#section-3>.

I think the question we need to ask ourselves is:

    Are “Built-In” Public CA Certs:
      1) read-only
      2) hybrid       (sys-defined entries are read-only, new values MAY be added)
      3) read/write (sys-defined entries are read-write, new values MAY be added)

The link above reflects #1.

In this case, just the “bag” itself is forever, whereas the certs within are free to come and go as the OS-provider desires.  This is fine as, in configuration, a TLS-client only refs the bag (see 3.1.2.1 in the tls-client-server draft, and note that it refs 2.1.3.1 in the truststore draft, which uses a "ts:certificate-bag-ref”).

As currently defined, #3 is supported by an administrator copying the “built-in” bag to custom bag “e.g., “My Public CA Certs”) and hack on them from there.  (note: I misspoke in my previous msg when I said the certs could be in <startup>, which is still possible, albeit less desirable IMO)

If that seems too coarse and #2 seems like a sweet-spot, then I think we could just change the text in https://tools.ietf.org/html/draft-ietf-netconf-trust-anchors-13#section-3 <https://tools.ietf.org/html/draft-ietf-netconf-trust-anchors-13#section-3> to allow it.  Specifically, the sentence:

      "No certificates may be added or changed; that is, the certificates in
       <running> MUST be a subset (which includes the whole of the set)
       of the built-in certificates define in <operational>.”

…could be tweaked to allow additions of new certificates while still 1) disallowing modification of any existing certificate and 2) only requiring the (subset of) certificates that are directly-referenced to be copied in <running> (note that it MAY be that no certs are copied, i.e., an empty bag).


PS: I have for a long time had difficulty reading your responses.  Can you investigate configuring your SMTP-client to support threading (i.g., indenting blocks) and/or trim messages down so that only relevant parts are visible?

K.