Re: [netconf] ietf crypto types - permanently hidden

Kent Watsen <> Thu, 02 May 2019 01:56 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 05A1D1202C7 for <>; Wed, 1 May 2019 18:56:52 -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 RXz8CWBX_xQg for <>; Wed, 1 May 2019 18:56:49 -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 5A0C51202A7 for <>; Wed, 1 May 2019 18:56:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw;; t=1556762207; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=2GIFAcsqteeoAykExsexOF03FUodhHc+qNaYRy9quO4=; b=H1CAABLk4Fa0Hv4gT1FuxmUWmMkWv/0MOkE2ZEz1sGHds6C7lvCwmpH8gILJhaUr lQSQP07eh0iF3liX6nohA5Xy3EpuOF1rD1Yht1q5h3pZ5zMyh4qV4z2S0ZfSqyglKdV MU1Q0iQE1OU/1BKUi5+fS20cTm7GlWxmAS2nDsaA=
From: Kent Watsen <>
Message-ID: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_4605E82F-F4B1-44C9-9A81-692C7A3DFF8C"
Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\))
Date: Thu, 02 May 2019 01:56:47 +0000
In-Reply-To: <>
Cc: Juergen Schoenwaelder <>, "" <>
To: Martin Bjorklund <>
References: <> <> <> <>
X-Mailer: Apple Mail (2.3445.102.3)
X-SES-Outgoing: 2019.05.02-
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, 02 May 2019 01:57:00 -0000

> What I object to is a third use case, where the action would modify
> the config with the generated keys.

What is your proposal for how to address the best practice and, in some cases, 
government requirement, that a private key never exists outside of a device 
(controlled backups aside)?

From <>

    "It’s crucial that the generation of the key be done on the same system and the same
     local filesystem as the storage location.  Generating the key on a server and then
     transferring the key back to the local system and storing it just adds multiple points
     of vulnerability.  Why would you want to increase the chance of your private key
     being compromised?"

Additionally, SC-12(3) of NIST 800-53 says:   (note: the word "produce" is key here)

    "Produce, control, and distribute asymmetric cryptographic keys using [Selection: 
     NSA-approved key management technology and processes; approved DoD PKI
     Class 3 certificates; prepositioned keying material; approved DoD PKI Class 3 or
     Class 4 certificates and hardware security tokens that protect the user’s private
     key; certificates issued in accordance with organization-defined requirements]."

Many networking devices include an SSL-protected web-interface.

    1) Typically the interface is initially secured via a self-signed certificate, which
         causes the browser to display a nagging message when connecting,
         thus prompting remediation.

    2) Almost all products include an ability to upload the 2-tuple of a private key
         and a signed certificate.  This resolves the self-sign cert issue, but the
         best practice and government compliance concerns are not addressed.

    3) The better products have an ability to:
          a) let the device generate the private key
          b) let the device generate a certificate signing request using its private key
          c) upload to the device a certificate generated by an external CA signing the CSR.   
          [FWIW, Juniper's SRX device introduced this ability in 2011.]

The current model supports (2), as well as (3b) and (3c), we're just missing (3a), 
which is what the original `generate-asymmetric-key` action was for.

FWIW, from a product perspective, supporting (3a) is more important then supporting
`generate-hidden-key` or `install-hidden-key` (so long as manufacturer-generated
hidden keys are still supported, e.g., for IDevID certificates).   While client-generated
permanently-hidden keys is goodness, it's not widely implemented.