Re: [netconf] built-in trust anchors
Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> Tue, 12 January 2021 19:59 UTC
Return-Path: <j.schoenwaelder@jacobs-university.de>
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 B353A3A1124 for <netconf@ietfa.amsl.com>; Tue, 12 Jan 2021 11:59:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 1OmI-F2m77oD for <netconf@ietfa.amsl.com>; Tue, 12 Jan 2021 11:59:55 -0800 (PST)
Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53B1E3A1123 for <netconf@ietf.org>; Tue, 12 Jan 2021 11:59:54 -0800 (PST)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 23E28670; Tue, 12 Jan 2021 20:59:53 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas5.jacobs-university.de ([10.70.0.198]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id PunA56Q4rdUm; Tue, 12 Jan 2021 20:59:52 +0100 (CET)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "DFN-Verein Global Issuing CA" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Tue, 12 Jan 2021 20:59:52 +0100 (CET)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9F78320156; Tue, 12 Jan 2021 20:59:52 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10028) with ESMTP id gp47Erx2ZABy; Tue, 12 Jan 2021 20:59:52 +0100 (CET)
Received: from localhost (anna.jacobs.jacobs-university.de [10.50.218.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by hermes.jacobs-university.de (Postfix) with ESMTPS id F0C5620154; Tue, 12 Jan 2021 20:59:51 +0100 (CET)
Date: Tue, 12 Jan 2021 20:59:51 +0100
From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
To: "Sterne, Jason (Nokia - CA/Ottawa)" <jason.sterne@nokia.com>
Cc: Netconf <netconf@ietf.org>
Message-ID: <20210112195951.oi7dlnnqpda7wavm@anna.jacobs.jacobs-university.de>
Reply-To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
Mail-Followup-To: "Sterne, Jason (Nokia - CA/Ottawa)" <jason.sterne@nokia.com>, Netconf <netconf@ietf.org>
References: <DM6PR08MB5084E8CF8D3D4D0E77C841CD9BAA0@DM6PR08MB5084.namprd08.prod.outlook.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <DM6PR08MB5084E8CF8D3D4D0E77C841CD9BAA0@DM6PR08MB5084.namprd08.prod.outlook.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/iHI3S3UeaAPBdmL94FvBQtRp3KU>
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: Tue, 12 Jan 2021 19:59:58 -0000
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] 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)