Re: [netconf] ietf crypto types - permanently hidden

Kent Watsen <> Fri, 03 May 2019 16:23 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 32D3F1200EF for <>; Fri, 3 May 2019 09:23:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] 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 0Tmhiist6OcS for <>; Fri, 3 May 2019 09:23:41 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6E9BF1200E3 for <>; Fri, 3 May 2019 09:23:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw;; t=1556900620; h=From:Content-Type:Mime-Version:Subject:Date:References:To:In-Reply-To:Message-Id:Feedback-ID; bh=IFzfvZ2Yhw4IWFHjDYiwoKUwjphWZ90LqAWVB5oNZIk=; b=Q1pCar3SoXCdVKSHJ7Lpg67ZdBKZCQarodqJZWwz24e2P6nwyWahmv/BSeMKwuJ6 QaB0AlctHyWsmMnQKvfdIWrzPEtLs1LjJ0ySpBNEe1Ja64zlLY2Tf5N5Tz/QQVXLNF2 NbmXx0FwAOgtVRndbPw0SEGfnw/JwEGClO9UNxak=
From: Kent Watsen <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_FB52849F-CC35-44AF-A795-66254099705F"
Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\))
Date: Fri, 03 May 2019 16:23:40 +0000
References: <> <> <> <> <>
To: "" <>
In-Reply-To: <>
Message-ID: <>
X-Mailer: Apple Mail (2.3445.102.3)
X-SES-Outgoing: 2019.05.03-
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 16:23:43 -0000

I had an idea last night that might inch us closer to a solution.  

Essentially, the generate/install-key operations always populate <operational>, even for keys that are not-hidden, but then a follow-up operation (something like <copy-config>) replicates the not-hidden key in <operational> to <running>.    Two options:

1) A regular-access admin executes the actions to generate the key, get a CSR, configure a resulting signed certificate, etc. and then, as a second step later in time, a special-access admin replicates the key to <running> (perhaps using standard <get-confg> and <edit-config>), so that it can be included in a standard backup and restored to *any* device (since this key is "not-hidden", it isn't encrypted with a device-specific key and hence can be migrated).

2) A regular-access admin executes the actions to generate the key, get a CSR, configure a resulting signed certificate, etc. and then, as a second step (ideally immediately after), the regular-access admin executes a command like <copy-config>, but rather than copying the entire datastore, it just copies a subtree.   

Neither option seems great.  #1 is unappealing being it necessitates coordination between clients.  #2 is unappealing because defining a generic operation for this special case seems too much.   

IMO, allowing <generate-key> to create the configuration directly is the only client-friendly answer.

Kent // contributor