Re: [netconf] built-in trust anchors

Kent Watsen <> Thu, 14 January 2021 18:28 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BAF5F3A12FB for <>; Thu, 14 Jan 2021 10:28:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.916
X-Spam-Status: No, score=-1.916 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id KFmYLWcLtoh0 for <>; Thu, 14 Jan 2021 10:28:00 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id DB8163A12FA for <>; Thu, 14 Jan 2021 10:27:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=224i4yxa5dv7c2xz3womw6peuasteono;; t=1610648878; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=UMK25W1aYwNpVn9RQgbaquV+IMlDWAk3ZpI2oNuMsmc=; b=Hanv7lmXVzAUYNqMJemPmTpw9dyPJp+M3U6F9VrGC/SOhB9rPypuptA0Kw7No11K 7OXdn2ekdLDPfE1E59N3/oG0HysyzRmCiPgdSbWDO+k4AnjFTjTxnAKQK8qKDl1mc8s nEF+1jlStqDpALyKs8YwOFYhHeK7g0nBMQ/h6o/w=
From: Kent Watsen <>
Message-ID: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_66876209-A5A5-402E-B08B-031777C4715A"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.\))
Date: Thu, 14 Jan 2021 18:27:58 +0000
In-Reply-To: <>
Cc: "" <>
To: tom petch <>
References: <> <> <> <> <> <> <>
X-Mailer: Apple Mail (2.3608.
X-SES-Outgoing: 2021.01.14-
Archived-At: <>
Subject: Re: [netconf] built-in trust anchors
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 14 Jan 2021 18:28:02 -0000

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

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 in the tls-client-server draft, and note that it refs 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 <> 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?