Re: [netconf] ietf crypto types - permanently hidden

Kent Watsen <> Mon, 29 April 2019 16:17 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 64F45120168 for <>; Mon, 29 Apr 2019 09:17:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Status: No, score=-1.898 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, URIBL_BLOCKED=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 DuEL1aHAogIh for <>; Mon, 29 Apr 2019 09:17:52 -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 A50E612032A for <>; Mon, 29 Apr 2019 09:17:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw;; t=1556554671; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=a0C1nJ42ohP9FEL3z4FKnHYYnEKlLZcjvlak9Dv9ZkY=; b=hBp8QPnnCaQ3XHCuIVqWx6XU1v/6jcE1CUs0+PAz4Fo5CA0/5qf6/F7eAcEQwd+C iKG+nJLTLBBIwY5nI9fSOepE9p4UNs7/tYAUKY3CygLAL49aEa8dSAueqi7C5NMuiwc kC8RUB4wSehgRL1AtMlAUFlKztRNIoj+97fgCwAg=
From: Kent Watsen <>
Message-ID: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_337CEA86-1976-4F0E-BADD-0964C68E94A8"
Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\))
Date: Mon, 29 Apr 2019 16:17:51 +0000
In-Reply-To: <>
Cc: Juergen Schoenwaelder <>, "" <>
To: Balázs Kovács <>
References: <> <> <01dd01d4eb9c$b9a04160$> <> <> <> <> <> <> <>
X-Mailer: Apple Mail (2.3445.102.3)
X-SES-Outgoing: 2019.04.29-
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: Mon, 29 Apr 2019 16:17:54 -0000

Okay, I've added the following text into the generate/install-hidden-key descriptions:

         The resulting asymmetric key values are
         considered operational state and hence present only in

         The resulting asymmetric key values are
         considered operational state and hence present only in
         <operational> and bound to the lifetime of the
         parent 'config true' node.  Subsequent invokaions of
         this or the '<other>-hidden-key' action are denied.";

    where <other> is the name of the other action (generate vs. install).


> On Apr 29, 2019, at 8:24 AM, Balázs Kovács <> wrote:
> Hi,
> Kent, I'm fine with your proposals.
> Regarding subsequent calls to the actions, I agree the safe choice would be to deny them; otherwise, one could run into invalid key pairs (where a certificate was already configured) and authentication failures with network peers (especially in SSH-key-based-authentication case). 
> Br,
> Balazs
>> -----Original Message-----
>> From: Kent Watsen <>
>> Sent: Wednesday, April 24, 2019 10:30 PM
>> To: Juergen Schoenwaelder <>
>> Cc: Balázs Kovács <>;
>> Subject: Re: [netconf] ietf crypto types - permanently hidden
>> Hi Juergen,
>>> Perhaps this should say 'implementation specific' instead 'application
>>> specific'.
>> Changed in my local copy.
>>>> My recommendation is to modify the "generate/install-hidden-key"
>> (renamed to just "generate/install-key") actions to have a flag indicating if
>> the key should be "permanently hidden" (perhaps by using a TPM) or not, in
>> which case configuration is created, same as if the client had used <edit-
>> config>, but without needing to touch the key.
>>> I agree that having a flag to control the behavior is useful and I
>>> think there should be explicit text how the action fails in case the
>>> requested action cannot be performed.
>>> I am not sure I understand install-hidden-key. The description says:
>>>          "Requests the device to load the specified values into
>>>           a hidden key.  The resulting asymmetric key values are
>>>           considered operational state and hence present only in
>>>           <operational>.";
>>> So what is the persistence model of this? Does a key installed with
>>> install-hidden-key survive reboots? If so, can I delete somehow such a
>>> hidden key? (Is the answer that this key is tied to the lifetime of
>>> the list element indirectly using this grouping?) Does invoking
>>> install-hidden-key twice cause the first installed key to be
>>> overwritten? Can the install-hidden-key action fail in any way?
>>> This leads to related questions for generate-hidden-key: Does invoking
>>> this action twice cause an existing key to be overwritten? Can I
>>> explicitely delete a generated hidden key? Does deleting the list item
>>> that directly or indirectly uses this grouping delete a hidden key?
>> [Disclaimer: the below reflect my understanding of how the current model
>> works, and does not necessarily reflect if we were to flip things around by
>> letting the actions generate configuration.]
>> The expectation is that the "permanently hidden" keys would persist,
>> presumably with origin=system.
>> In the YANG, the "permanently-hidden" enum only appears in the
>> "asymmetric-key-pair-grouping" grouping.   Consuming data models are
>> expected to "use" this grouping under a "config true" node.  This grouping's
>> description statement is noteworthy:
>> grouping asymmetric-key-pair-grouping {
>>    description
>>      "A private/public key pair.
>>       The 'algorithm', 'public-key', and 'private-key'  nodes are
>>       not mandatory because they MAY be defined in <operational>.
>>       Implementations SHOULD assert that these values are either
>>       configured or that they exist in <operational>.";
>>    ...
>> }
>> Thusly it is expected that the client will create the parent node (e.g., via
>> <edit-config>) and then invoke either the generate or install hidden key
>> action.  Presumably, the lifetime of the permanently hidden key would be
>> tied to the lifetime of its parent.
>> Regarding what happens when the actions are invoked a second time, it's
>> not specified.  One choice, perhaps the safe choice, would be to deny
>> subsequent attempts, forcing the client to create a new parent node instead.
>> If the parent node is in a list, such as in the keystore, then the second key
>> could be created, with certificates bound to it, before mapping reference to
>> the old-key to the new-key.  However, if the key is not in a list, such as when
>> using a "local-definition", then in in-place migration, along with service
>> disruption, would be required.
>> Of course, one has to ask how often/likely is it that a client wants to
>> regenerate the private key.  Presumably it would only be due to the concern
>> that the key had been compromised (which shouldn't happen if
>> "permanently hidden") or, perhaps, due to a proactive key-rotation policy,
>> thinking (misguided, I believe, proven false now) that the private key's
>> entropy expires over time.  Regardless, the point is that it seems to be an
>> action that would seldomly occur and, when/if it does, the effort to create
>> another parent node (in keystore or a local-definition) might not be a big
>> deal.
>> PS: words such as "expectation" and "presumably" are used above to
>> indicate a likely need for the text to be more explicit.
>> Kent // contributor