Re: [netconf] ietf crypto types - permanently hidden

Balázs Kovács <> Fri, 03 May 2019 06:10 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 64EE312006D for <>; Thu, 2 May 2019 23:10:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 X76EXo4xpRua for <>; Thu, 2 May 2019 23:10:05 -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 5B389120059 for <>; Thu, 2 May 2019 23:10:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ZvU54oRMGYmsb1ZGM6GyDoQLsRq4+fNFRcEXG6eZ4Os=; b=WJnzJptgt5Clu5KHn/qSCL4nQaKJOim5lds44wFfBS6L2lQISB152RH4C3Bih/VS5+EnM5QKwExcoEd4pq3jYGY7qGCUE1EctsU6QeJ2aQoGZzOZgVo0gE0B+MOFAftd54EM/1mcI69i1Cu9mPqkNcTU7NrW9z6VlljI/Mglq1U=
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1878.11; Fri, 3 May 2019 06:09:57 +0000
Received: from ([fe80::dc72:dfff:beb3:3b47]) by ([fe80::dc72:dfff:beb3:3b47%7]) with mapi id 15.20.1856.008; Fri, 3 May 2019 06:09:57 +0000
From: Balázs Kovács <>
To: Kent Watsen <>, Martin Bjorklund <>
CC: "" <>
Thread-Topic: [netconf] ietf crypto types - permanently hidden
Date: Fri, 03 May 2019 06:09:57 +0000
Message-ID: <>
References: <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
authentication-results: spf=none (sender IP is );
x-originating-ip: [2a02:ab88:2cb8:5600:149b:bf3c:db30:aae6]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 47bde480-27fe-47c5-254e-08d6cf8df80c
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(2017052603328)(7193020); SRVR:VI1PR07MB5568;
x-ms-traffictypediagnostic: VI1PR07MB5568:
x-ms-exchange-purlcount: 1
x-microsoft-antispam-prvs: <>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0026334A56
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(366004)(136003)(376002)(346002)(39860400002)(199004)(189003)(71200400001)(486006)(8936002)(4326008)(53936002)(6436002)(54896002)(6306002)(81156014)(81166006)(74316002)(71190400001)(8676002)(316002)(478600001)(9686003)(476003)(25786009)(5660300002)(7736002)(46003)(2906002)(606006)(236005)(11346002)(9326002)(86362001)(446003)(76176011)(110136005)(7696005)(55016002)(66476007)(66946007)(33656002)(6246003)(66574012)(53546011)(6506007)(14454004)(68736007)(45776006)(102836004)(14444005)(186003)(52536014)(6116002)(256004)(966005)(229853002)(73956011)(790700001)(99286004)(66556008)(64756008)(66446008)(76116006); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR07MB5568;; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None ( does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: XEyxCOJ7kpBY4tkUS3rF5tNqtpHdkqcxTvrMzMqZpi5ABUvfd5/Ux6RosJaq5+kvIc0kdSUlpXK1FZlAv9jhhUG0BOGMGaZJqz9/Xpb8SsGJEtq5rs+d9r6IB797OjKM5JAwRbVOM0q6OhUp2xcrd7qjlDomZalT7MWQ+FExYiEDUw0a/9MUSVldxuGTFFjMsqIMmyJkrTmk/A+L5UGJw8BzmViriJAJRxo3x2lbDCObEvohNCJxR4TKkagDFdzuuk/nOGHQyETGl5B8Ffb0/JxFq/Qzi1LI7aEeTpqbpuFRForMNhF8p8c2oR5tbq/p+dbupFlLt9TYJ/whCbZQGEBSZTKev8Ja1RMVtKLZUZQOnL8O0F3DBQnu5rjZ8xduo1HtJRjyAzBCLU9jASVovxBCOUGrmdx/1/nFzSbOH9w=
Content-Type: multipart/alternative; boundary="_000_VI1PR07MB473550063330EE25D65642E083350VI1PR07MB4735eurp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 47bde480-27fe-47c5-254e-08d6cf8df80c
X-MS-Exchange-CrossTenant-originalarrivaltime: 03 May 2019 06:09:57.7468 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB5568
Archived-At: <>
Subject: Re: [netconf] ietf crypto types - permanently hidden
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: Fri, 03 May 2019 06:10:09 -0000


But why?  If an operator wants to replace, why should the list entry
first be deleted and then created and then the key can be generated?
This seems like a CLR to me.

I might back off from this one. I guess mismatched key pairs can occur with regular configuration case too, so it all depends on the operator to provide the right pair, and it should be the operator's decision to do a graceful key switch by creating a new key instance or do an instant renewal on the same instance. If the peer device does not have to be reconfigured, the renewal on same instance could be a better choice.


From: Kent Watsen <>
Sent: Thursday, May 2, 2019 6:19 PM
To: Martin Bjorklund <>
Cc: Balázs Kovács <>;
Subject: Re: [netconf] ietf crypto types - permanently hidden

In enum permanently-hidden:
      The private key is inaccessible due to being protected by the
      system (e.g., a cryptographic hardware module).
      The private key is inaccessible due to being protected by the
      system (e.g., a cryptographic hardware module).  Since hidden
      keys are only ever reported in <operational>, the value
      'permanently-hidden' never appears in <intended>.

Ok, but perhaps s/<intended>/conventional configuration datastores/?

Fixed in my local copy.

Note that this statement was added because Juergen asked about how
hidden keys could be removed/replaced.  We iterated towards not
wanting to support the "replace" case

But why?  If an operator wants to replace, why should the list entry
first be deleted and then created and then the key can be generated?
This seems like a CLR to me.

Ok, I see.  I think the text needs some clarification; make it more
explicit.  It needs to say that if a "permanently-hidden" private key
exists in <operational> under a parent config true node and this
parent node is deleted, the private key is supposed to be (MUST be?)
deleted from the system as well.

Added, with a MUST.

A remove-hidden-key action can be problematic b/c if you forget to
call this action and then delete the config, presumably you have
lingering keys in the system that you can't remove.

I don't think this is true.  Even if an asymmetric key only exists in <operational> (i.e., the corresponding "config true" parent node is deleted), it seems that a 'remove-hidden-key' could still remove it.  In fact, this is the most consistent thing, to have an 'action' act on values in <operational>.

Kent // contributor