Re: [netconf] latest update to crypto-types and keystore drafts

Qin Wu <> Sat, 29 June 2019 07:21 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1C8F21209AC for <>; Sat, 29 Jun 2019 00:21:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id LMaGmBKHkeyp for <>; Sat, 29 Jun 2019 00:21:42 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E19751209AA for <>; Sat, 29 Jun 2019 00:21:41 -0700 (PDT)
Received: from (unknown []) by Forcepoint Email with ESMTP id 88C6C2DB78565B11207F for <>; Sat, 29 Jun 2019 08:21:39 +0100 (IST)
Received: from ( by ( with Microsoft SMTP Server (TLS) id 14.3.408.0; Sat, 29 Jun 2019 08:21:38 +0100
Received: from ([]) by ([]) with mapi id 14.03.0415.000; Sat, 29 Jun 2019 15:19:50 +0800
From: Qin Wu <>
To: Kent Watsen <>, Martin Bjorklund <>
CC: "" <>
Thread-Topic: [netconf] latest update to crypto-types and keystore drafts
Thread-Index: AdUuSuzipKZ4tapKQ5qFcPhBDiZorQ==
Date: Sat, 29 Jun 2019 07:19:49 +0000
Message-ID: <>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_B8F9A780D330094D99AF023C5877DABAA49BA5A2nkgeml513mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <>
Subject: Re: [netconf] latest update to crypto-types and keystore drafts
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: Sat, 29 Jun 2019 07:21:44 -0000

No I disagree.  If an admin can create it, it could be part of the
factory default config, for convenience.  A user with the right access
can delete it from the config, just as if it had been created by an

Based on your later comments, it seems that we're more in agreement than not.  Let me rephrase, if the manufacturer generated keys (with 'hidden-key' or 'hidden-private-key') are stored in the factory default datastore, per draft-ietf-netmod-factory-default, they would be read-only and hence immutable.  Now, upon that configuration being copied into <running>, the configuration would become editable and said keys could be removed.

[Qin]: Not very familiar with this security part, two questions I am curious to know:

1.      If the manufacturer generated keys (with 'hidden-key' or 'hidden-private-key') are stored in the factory default datastore, how do we protect manufacturer generated keys from leaking, encryption, signature?

2.      Public key and private key pair is usually generated together, if you put private key in factory default datastore, where do we put public key? Rely on TPM hardware to generate public key and put them into operational datastore?