[netconf] 答复: built-in trust anchors

"maqiufang (A)" <maqiufang1@huawei.com> Wed, 13 January 2021 13:15 UTC

Return-Path: <maqiufang1@huawei.com>
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 256793A0D6D; Wed, 13 Jan 2021 05:15:00 -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, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, 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 ThGh0ID4R0rT; Wed, 13 Jan 2021 05:14:57 -0800 (PST)
Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C5133A0C2E; Wed, 13 Jan 2021 05:14:57 -0800 (PST)
Received: from fraeml742-chm.china.huawei.com (unknown [172.18.147.200]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4DG7Bf5K5rz67ZxP; Wed, 13 Jan 2021 21:11:54 +0800 (CST)
Received: from dggeme719-chm.china.huawei.com (10.1.199.115) by fraeml742-chm.china.huawei.com (10.206.15.223) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.1.2106.2; Wed, 13 Jan 2021 14:14:52 +0100
Received: from dggeme770-chm.china.huawei.com (10.3.19.116) by dggeme719-chm.china.huawei.com (10.1.199.115) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2106.2; Wed, 13 Jan 2021 21:14:50 +0800
Received: from dggeme770-chm.china.huawei.com ([10.8.68.58]) by dggeme770-chm.china.huawei.com ([10.8.68.58]) with mapi id 15.01.2106.002; Wed, 13 Jan 2021 21:14:51 +0800
From: "maqiufang (A)" <maqiufang1@huawei.com>
To: Qin Wu <bill.wu@huawei.com>, "Sterne, Jason (Nokia - CA/Ottawa)" <jason.sterne@nokia.com>, Netconf <netconf@ietf.org>
CC: "draft-ma-netconf-with-system@ietf.org" <draft-ma-netconf-with-system@ietf.org>
Thread-Topic: built-in trust anchors
Thread-Index: AdbpFFL2IioTw935RTC9hP47Cn7q7QAAD8+QACZAphA=
Date: Wed, 13 Jan 2021 13:14:50 +0000
Message-ID: <beee731475d94261b495c7e1bc3357fa@huawei.com>
References: <DM6PR08MB5084E8CF8D3D4D0E77C841CD9BAA0@DM6PR08MB5084.namprd08.prod.outlook.com> <B8F9A780D330094D99AF023C5877DABAADCD04AA@dggeml531-mbs.china.huawei.com>
In-Reply-To: <B8F9A780D330094D99AF023C5877DABAADCD04AA@dggeml531-mbs.china.huawei.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.136.100.25]
Content-Type: multipart/alternative; boundary="_000_beee731475d94261b495c7e1bc3357fahuaweicom_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/U7HDJ9W3QmnZ3XUUqGrjBf7q30g>
Subject: [netconf] =?gb2312?b?tPC4tDogYnVpbHQtaW4gdHJ1c3QgYW5jaG9ycw==?=
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 13:15:00 -0000

Hi , Qin,

Thanks for bringing up this topic.
You are right, the mechanism defined in our draft aims at solving this issue.
We proposed a "system" datastore,  and  there are two system configuration data handling basic modes. One is automatically  loading system into running,
The other is the client explicitly populates running with system configuration.
It allows the client to identify how system configuration are processed by the server, and also define a new mechanism for client control of server processing of system configuration data.

Any suggestions and comments would be greatly appreciated.

Qiufang Ma


发件人: Qin Wu
发送时间: 2021年1月13日 9:15
收件人: Sterne, Jason (Nokia - CA/Ottawa) <jason.sterne@nokia.com>om>; Netconf <netconf@ietf.org>
抄送: draft-ma-netconf-with-system@ietf.org
主题: RE: built-in trust anchors

发件人: netconf [mailto:netconf-bounces@ietf.org] 代表 Sterne, Jason (Nokia - CA/Ottawa)
发送时间: 2021年1月13日 3:02
收件人: Netconf <netconf@ietf.org<mailto:netconf@ietf.org>>
主题: [netconf] built-in trust anchors

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.

[Qin]:Interesting discussion, either loading the factory default from factory datastore or define a new system datastore, I think both can enable the server to populate the data automatically, one of individual draft in NETCONF (draft-ma-netconf-with-system) seems to target to address this issue, i.e., avoid duplicated data items to be created in the running, I have copied this email to the author of draft-ma-netconf-with-system for their feedback.

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

[Qin]: See details in draft-ma-netconf-with-system. It helps define consistent behavior for system data handling, just like what RFC6243 did.

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