Re: [netconf] ietf crypto types - permanently hidden

Kent Watsen <> Thu, 30 May 2019 14:14 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 786B8120074 for <>; Thu, 30 May 2019 07:14:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.312
X-Spam-Status: No, score=-2.312 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, RCVD_IN_MSPIKE_H2=-0.415, SPF_HELO_NONE=0.001, SPF_NONE=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 iDhqRjSacriu for <>; Thu, 30 May 2019 07:14:24 -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 DFAF0120111 for <>; Thu, 30 May 2019 07:14:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw;; t=1559225662; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=CUPio/ZLJqc0/AGPUaja+v8zeA1R86LUqUKDnFZHf3g=; b=DLJIdt4ZtVBdqQXVoefvK7gqKCGxZl4ozUNYFZJxJ57NQYjAUSpRCxcQXxKfedNv TZ5S8PtqhyvmMsUQUCfp1kYiWrerbPYmllcXdY16ljR4rL8z7CdzsmAC4nSyoPEnzl+ eFY7i0TQYhcS+OoLYjz1Z59+xAs5YxJ7bHBPAnRA=
From: Kent Watsen <>
Message-ID: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_1952B2D4-F890-4F71-ADBC-941261A80663"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Thu, 30 May 2019 14:14:22 +0000
In-Reply-To: <>
Cc: "" <>
To: Balázs Kovács <>
References: <> <> <> <> <> <> <> <> <>
X-Mailer: Apple Mail (2.3445.104.11)
X-SES-Outgoing: 2019.05.30-
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: Thu, 30 May 2019 14:14:26 -0000

Hi Balazs,

> In case of crypt-hash, I can accept the extension of the crypt(3) schemes with a $0$ that sort of represents a hash() action, since it matches the original crypt(3) syntax.
> In this case, I find it awkward to tell what to do with the data (verbs) as prefixes of the data.

Agreed, but we seem to be at an impasse and I thought this approach could get us over the line.

> I personally preferred actions better for this purpose.

It is my preference to use actions as well, but there's pushback there.  Maybe we could claim that the pushback is "in the rough" and press ahead regardless, but I'd rather avoid that if possible. 

> I assume that this representation also does not change the matter of “actions” affecting configuration (see ‘output’ values).

You mean, exploring this solution leaves the "is it possible for actions to affect configuration" as unresolved?  - correct, that discussion would remain open.

> Also validation of required input and output seems more complicated to me.

How so?

> The generate action returning the name of the key or optionally creating configuration sounded so far the closest match to me.


>  I’m also thinking do we need the ‘generate-and-not-hide’ and the ‘install-and-hide’ use cases?

Actually, I view  ‘generate-and-not-hide’ as a very common case.  That is, ask the system to generate the key (because clients are lazy and security best practice), and let standard NACM rules protect the key.   I think that systems supporting user-generated "hidden" keys will be somewhat rare, to the extent that there should feature statements enabling servers to indicate if they support the ability or not.


I'm growing weary of this discussion.  Perhaps we should do even less for the first release of the crypto-types module.  That is, instead of:

   leaf private-key {
     type union {
       type binary;
       type string {
         + '|<encrypted by="*">[A-Za-z0-9+/]+[=]{1,3}'
         + '|<value-to-be-generated(-and-hidden)?>'
         + '|<value-to-be-hidden>[A-Za-z0-9+/]+[=]{1,3}';

we have:

   leaf private-key {
     type union {
       type binary;
       type string {
         + '|<encrypted by="*">[A-Za-z0-9+/]+[=]{1,3}'

This removes the "verbs" (as you call them) and thus leaves open possibility for either "verbs" or action statements to be added in some future revision.   This subset still supports the critical use-case of a manufacturer-generated private key for a secure device identifier (i.e., IDevID).    Unfortunately, it does not support the security best practice use-case of having the device generate the private key.  The IESG (Security Directorate) may or may not be okay with this (obviously the shepherd would have to bring it to their attention), but perhaps it's worth testing their resolve and see what happens?

Kent // contributor