Re: [netconf] ietf crypto types - permanently hidden

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

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 64FA51200EF for <>; Fri, 3 May 2019 09:09:58 -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 0Shwz14B4ETb for <>; Fri, 3 May 2019 09:09:56 -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 7C3621200E3 for <>; Fri, 3 May 2019 09:09:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw;; t=1556899795; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=QLstcES3h5szAlbsubAjXfM0olHCZJpgY0/Kxl7T0cY=; b=NX6oLkXnByb3q/J0I9F01R+vhN6gCLyhG4lo1ZPeaq3CelaHQNjPjRLbdyzLSAEl pLQ6UWJJ6l4mKvBXVQtqn3KYuZezZSAAz82NYDDvqxCPQrn84MAC4oF4CpeFuWvZvq3 uBws2tTe1uj66YALEVweeaBfNbNxZIvGAZZmQGRQ=
From: Kent Watsen <>
Message-ID: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_769C2580-D271-47E6-B921-9A4C6B4054A6"
Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\))
Date: Fri, 03 May 2019 16:09:55 +0000
In-Reply-To: <>
Cc: "" <>
To: Martin Bjorklund <>
References: <> <> <> <>
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:09:58 -0000

> I don't think the last column is less important.  That's the TPM case, right?

Yes, the last column is the TPM case, which are very important to support, but there's a subtly between:

a) there exists a TPM that the manufacturer uses to generate a protected private key, e.g., in order to pre-provision the device with an IDevID certificate.  (this is a hyper-critical use case to support)


b) there exists a TPM that average clients can use to generate a protected private key.  The motivation behind this is unclear to me, but perhaps because 1) the owner wants to use an LDevID certificate instead of the IDevID certificate, 2) the owner requires that the private key is TPM-protected, and 3) the device is unable to generate a second CSR using the same private key used for the IDevID certificate.  (given that I believe #3 SHOULD be supported, this use case seems less important, bordering on not important).

> For the "no solution" case, it means that the client doesn't want to
> write the private key, but it wants to read it.  Why should it read it
> if it never writes it?  The whole point would be to be able to
> re-generate the config on another device - but this would mean that
> the client would use <edit-config> to pass the key, and it would be in
> the upper left cell in table above.

We have to envision different classes of clients: regular-access and special-access.  Regular access clients should be able to ask the system the generate a private key to which they have no read-access.  Special access clients have read (and write) access, but presumably are only ever used to perform backup/restore operations.

> An option could perhaps be to let the "generate-key" with option
> "not-hidden" create the private key in <operational> (still with
> nacm:default-deny-all).  To re-create the key on another device, the
> client would use install-key.

Yes, this is the goal, to enable not-hidden keys to be migrated to another device (but only by a special-access client).

Kent // contributor