Re: [netconf] built-in trust anchors
Martin Björklund <mbj+ietf@4668.se> Wed, 13 January 2021 08:23 UTC
Return-Path: <mbj+ietf@4668.se>
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B38A3A10A7 for <netconf@ietfa.amsl.com>; Wed, 13 Jan 2021 00:23:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.123
X-Spam-Level:
X-Spam-Status: No, score=-0.123 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, PDS_NAKED_TO_NUMERO=1.997, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=4668.se header.b=cXfdWpzl; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=E7z5OHRI
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XpLDofX2mLuo for <netconf@ietfa.amsl.com>; Wed, 13 Jan 2021 00:23:29 -0800 (PST)
Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3843C3A10A6 for <netconf@ietf.org>; Wed, 13 Jan 2021 00:23:29 -0800 (PST)
Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 58DA35C0449; Wed, 13 Jan 2021 03:23:28 -0500 (EST)
Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Wed, 13 Jan 2021 03:23:28 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=4668.se; h=date :message-id:to:cc:subject:from:in-reply-to:references :mime-version:content-type:content-transfer-encoding; s=fm3; bh= LJoBc5MDUI08qU9NcgfvsjRhO55on5lsdQ/A0UnxwOc=; b=cXfdWpzlEU8ikIAu dJmWiqoFFF4S8WjH/E5vM7RTqKG+IklVpwrCxlW9nNyUt6cl0Jh/klVBL9kgZ/31 N8fnAjV1k3E4EB197guQLq4n16nEwHPkfW4X2BIuXCpQo7G9nEqeFHhVOzyNvNKp KKMhBgkJfzJdflY7p8EuZKo2qbs6rHy+7eouKm5wo/mIkWxu6Qto7kOlDQyc7hmq 97g6pEMZu5dVvq+dPJkieKZgBCgcYEQOCibR9LPe/ilkJIwka3MeIIjvsUHqpm8s s8v+Nbz/vW448sofg89fUWOp6RKPdrWPtcu3J0NRO5/grnwLZ0jxAyG/aWfvjSmQ cAIfWQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=LJoBc5MDUI08qU9NcgfvsjRhO55on5lsdQ/A0Unxw Oc=; b=E7z5OHRIg6aUfRY5AuuYl5JwjMAzZr1o1iUzOztGrjv4eyWa2Ilp3GhNG aEibuxQWPuHVh//3VBFyqN9GrpG8bn8RD5sD9vFtL/3p2Fc1sQTM925fnyytSF5D 4XWOBljWQqd/tYeDy20aC7hNLe+FVAf3x6FdYOzi7Mgsk6Xa9FwRYJYCIQDMBAci TuBEo4fK3E2Ig7/F7CVX1qprEcU+tQrdDEXI/sF6N3mSM5Cw2ig3DepibodvwIn1 3ENLuH/bCXCG5xUX6+Sq2iIbWBfkL53fijnR4cChktprw3g6xb7UB6EyXOYm3/lc bwg4kufeyDLHTr+SSJjRiEqLBfpZw==
X-ME-Sender: <xms:_63-X9fqBH__t7BSKTewYnj5sigj7vwbZ4I1Ha0GwgOm1Q2bwnAVzw> <xme:_63-X7NDP7gOlkP-T3iG08LYz5hIRSe0srsVW3e89tBA9iEp6ehgPv3Xsf3UdLP-0 NeC7PeaF5gorcx2Sxo>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedukedrtddugdduvddtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpeffkffvuffhjghfofggtgfgsehtje ertdertddvnecuhfhrohhmpeforghrthhinhcuuehjnphrkhhluhhnugcuoehmsghjodhi vghtfhesgeeiieekrdhsvgeqnecuggftrfgrthhtvghrnhepffehudffhfevleevvdejie ffudfftdehvdehteehtdetleelkeekffejtdfhtdefnecuffhomhgrihhnpehivghtfhdr ohhrghdpjhgrtghosghsqdhunhhivhgvrhhsihhthidruggvnecukfhppeduheekrdduje egrdegrddvudehnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhf rhhomhepmhgsjhdoihgvthhfseegieeikedrshgv
X-ME-Proxy: <xmx:_63-X2j9JuQGVnN7cg85dpQZNWiNWdYNsC1blEZO8TbYXpb5j5Dtpg> <xmx:_63-X2_BCD03m4UDlmJjIz-bgnNZTqFtI15oGmECyLNiPcnDqaA9bQ> <xmx:_63-X5vaG6uk140V0-6ZSezlvwA7UqiUcN20tRqPm6SkekfP-c-OzQ> <xmx:AK7-X31fvwD8pMkmCWU_QxNxdyiXu2N-Ybcc3kGX2CXZeLxTTCqcdg>
Received: from localhost (unknown [158.174.4.215]) by mail.messagingengine.com (Postfix) with ESMTPA id F14B024005A; Wed, 13 Jan 2021 03:23:26 -0500 (EST)
Date: Wed, 13 Jan 2021 09:23:25 +0100
Message-Id: <20210113.092325.468429939674786955.id@4668.se>
To: jason.sterne@nokia.com
Cc: j.schoenwaelder@jacobs-university.de, netconf@ietf.org
From: Martin Björklund <mbj+ietf@4668.se>
In-Reply-To: <DM6PR08MB5084ED69870DF456DA8F1A509BAA0@DM6PR08MB5084.namprd08.prod.outlook.com>
References: <DM6PR08MB5084E8CF8D3D4D0E77C841CD9BAA0@DM6PR08MB5084.namprd08.prod.outlook.com> <20210112195951.oi7dlnnqpda7wavm@anna.jacobs.jacobs-university.de> <DM6PR08MB5084ED69870DF456DA8F1A509BAA0@DM6PR08MB5084.namprd08.prod.outlook.com>
X-Mailer: Mew version 6.8 on Emacs 26.3
Mime-Version: 1.0
Content-Type: Text/Plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/Exnd-Fw4osPvW58ScPwFFqgjii0>
Subject: Re: [netconf] built-in trust anchors
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netconf/>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 13 Jan 2021 08:23:31 -0000
Hi, "Sterne, Jason (Nokia - CA/Ottawa)" <jason.sterne@nokia.com> wrote: > Yes - adding require-instance false would eliminate the issue about > built-in anchors in <running>. But there are useful advantages to > keeping require-instance true. I don't have a strong feeling though > one way or the other. The current text has this: A server MUST reject attempts to modify any aspect of built-in trust anchors, both the certificates themselves and the bags that contain them. That these certificates are "configured" in <running> is an illusion, as they are strictly a read-only subset of that which must already exist in <operational>. This is really weird special handling of some config in <running>, which goes against the idea that the client(s) "own" the contents of <running>. It is also not clear what happens if the set of built-in trust anchors are changed during a software upgrade. Will they be removed from <running> automatically? If so, <running> may become invalid with dangling refrences. If they are not removed, they will be stuck there, since a client can't remove them. I agree that strong references are preferred in most situations, but in this case I think a weak reference is the best solution. It has it's own set of problems that must be solved though, specifically what happens if the target doesn't exist. > But assuming we keep require-instance true then the question still > remains of how built-in items get into <running> (and are they > deletable, and do we only need keys in running, etc). I think these lists have some mandatory elements, which means that you can't just copy the keys. /martin > > Jason > > > -----Original Message----- > > From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> > > Sent: Tuesday, January 12, 2021 3:00 PM > > To: Sterne, Jason (Nokia - CA/Ottawa) <jason.sterne@nokia.com> > > Cc: Netconf <netconf@ietf.org> > > Subject: Re: [netconf] built-in trust anchors > > > > Jason, > > > > since the leafref typedefs are weak references that do not require > > that the certs/keys exist (there is no 'require-instance true'), it > > may be OK to not have the certs/keys in <running> in terms of validity > > of the <running> datastore. > > > > Oops, I had to reread RFC 7950 (section 9.9.3): if require-instance is > > not present, it defaults to true, so my review comment about weak > > references is incorrect, these are actually strong references and > > hence there is the need to copy what is referenced. Setting > > require-instance to false may resolve this (but we loose the ability > > to catch references to certs/keys that do not exist). > > > > /js > > > > On Tue, Jan 12, 2021 at 07:02:04PM +0000, Sterne, Jason (Nokia - > > CA/Ottawa) > > wrote: > > > Hi all, > > > > > > I noticed Jurgen's comment about built-in trust anchors in his YANG > > > doctor > > review of trust-anchors-13. I wanted to pull that out into a dedicated > > thread/discussion here. > > > > > > Jurgen: > > > > > > > > > - Section 3 talks about populating <running> with built-in trust > > > > > > anchors. > > > > > > > > > > > > In order for the built-in trust anchors to be referenced by > > > > > > configuration, the referenced certificates MUST first be copied into > > > > > > <running>. The certificates SHOULD be copied into <running> using > > > > > > the same "key" values, so that the server can bind them to the built- > > > > > > in entries. > > > > > > > > > > > > Is the idea that this copy operation is an explicit management > > > > > > operation or can implementations populate <running> with this > > > > > > data automatically? > > > > > > I suppose a server *could* populate this in running as part of a > > > built-in > > startup datastore in the absence of a startup datastore (i.e. as > > contents of a > > RFC8808 factory default). But I assume it is desirable to be able to > > delete the > > running copy of a built-in item. So the system would have to avoid > > populating > > these unless it is loading the factory default. > > > > > > But even if the system can populate these, we'd also want the > > > client/user > > to be able to explicitly populate them as well (i.e. in case they > > delete one > > from running, and want to add it back in to reference it). > > > > > > In either case (system population of running, or client population of > > running), do we really need to put the contents of the bag or the cert > > into > > running? Or is populating the list key enough since the operational > > copy > > shows what contents are in use for that list entry? > > > > > > Jason > > > > > _______________________________________________ > > > netconf mailing list > > > netconf@ietf.org > > > https://www.ietf.org/mailman/listinfo/netconf > > > > > > -- > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > > Fax: +49 421 200 3103 <https://www.jacobs-university.de/> > > _______________________________________________ > netconf mailing list > netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf
- [netconf] built-in trust anchors Sterne, Jason (Nokia - CA/Ottawa)
- Re: [netconf] built-in trust anchors Juergen Schoenwaelder
- Re: [netconf] built-in trust anchors Sterne, Jason (Nokia - CA/Ottawa)
- Re: [netconf] built-in trust anchors Qin Wu
- Re: [netconf] built-in trust anchors Martin Björklund
- Re: [netconf] built-in trust anchors Juergen Schoenwaelder
- Re: [netconf] built-in trust anchors Martin Björklund
- [netconf] 答复: built-in trust anchors maqiufang (A)
- [netconf] 答复: built-in trust anchors maqiufang (A)
- Re: [netconf] built-in trust anchors Juergen Schoenwaelder
- Re: [netconf] built-in trust anchors Kent Watsen
- Re: [netconf] built-in trust anchors Martin Björklund
- Re: [netconf] built-in trust anchors tom petch
- Re: [netconf] built-in trust anchors Kent Watsen
- Re: [netconf] built-in trust anchors Martin Björklund
- Re: [netconf] built-in trust anchors Kent Watsen
- Re: [netconf] built-in trust anchors Kent Watsen
- Re: [netconf] built-in trust anchors Martin Björklund
- Re: [netconf] built-in trust anchors Kent Watsen
- Re: [netconf] built-in trust anchors maqiufang (A)