Re: [netconf] ietf crypto types - permanently hidden

Kent Watsen <> Tue, 07 May 2019 21:13 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9C8581202B1 for <>; Tue, 7 May 2019 14:13:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 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.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 zhf9lqIu4wRA for <>; Tue, 7 May 2019 14:13:46 -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 0EF64120170 for <>; Tue, 7 May 2019 14:13:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw;; t=1557263624; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=LHfsrPdwBSD27WwdKt2mW2BUm5BlFsPI3oDQjsnsY0E=; b=J+G/cjO/ojIlafaEkJ3y+KMdR/zvpuVW7YxUeyo5Q/8lqRsvDJLszDowxLjOCXrg mPgbjMD3vSL2lHRcOFaYnvd5bZOKTnuWjSM7SowkkFWvkXSMrX2sdTLxzl7i0eJjN3t qogyoB65ZHZDq+w4I+++rm4ZOMoy1z5s0P0ZzRGo=
From: Kent Watsen <>
Message-ID: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_0A1DEEFB-F337-447D-8C43-0AF892693851"
Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\))
Date: Tue, 07 May 2019 21:13:44 +0000
In-Reply-To: <>
Cc: "Rob Wilton (rwilton)" <>, "" <>
To: Martin Bjorklund <>
References: <> <> <> <>
X-Mailer: Apple Mail (2.3445.102.3)
X-SES-Outgoing: 2019.05.07-
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: Tue, 07 May 2019 21:13:54 -0000

>> The problem that I have with <generate-key> generating configuration
>> directly in <running> is that <running> on the device is now different
>> from what the management system thinks should be in <running> on the
>> device.
>> I.e. it breaks the architectural simplicity that it is only the client
>> that controls what goes into in <running>

I'm confused.  At least it seems that, regardless if the client uses <edit-config> or <generate-key>, the client is performing the operation and can be fully aware of what it is <running>.  For other clients, presumable they receive a yang-push notification alerting them to the update to <running>.

Before I thought the objection regarded non-compliance to the document model, but that's not true in that, once the configuration is set (via an action), it becomes part of the document, even if nacm:default-deny-all.

Now I'm unclear what the objection is.  Martin has twice identified some issues, and both times I replied that it is acceptable to constrain the actions so as to avoid those issues.

>> If the clients would like to see the keys in the configuration then
>> they can monitor <operational> (or <intended>), and then add the keys,
>> either in raw form, or encrypted in some way.  But I still think that
>> it is architecturally cleaner if it is always the client that updates
>> the <running> configuration and never the device.
> I agree.  I think it would be worthwile to explore the
> "non-action-based" solution that Rob proposed.  Is there anything in
> that solution that doesn't work?

I discussed this option in my "wide-screen needed" email from last Friday.
There are 3 cases to consider:

1) the manufacturer creates the (most likely "hidden") key pair and associated certificate.
      - these nodes MUST originate in <operational> (origin="system")
      - clients MUST replicate their (potentially encrypted or "permanently-hidden"
        enumerated) content into <running> in order reference the key and/or cert.

2) the client wishes to generate a key (hidden or not) without ever touching the
    private key.
      - presumably this occurs via a "generate-key" action (open to ideas)
      - this key ultimately MUST be in <running> in order to be referenced by config.
      - ideally it shows up in <running> as consequence of invoking the action.
      - less ideal, as in (1), a <get-data>/<edit-data> sequence could be used
        to bring the key into <running>.

3) the client wished to installed a hidden key.
      - note that we don't discuss installing a non-hidden key here, because
        that is exactly what a standard <edit-config> operation does.
      - presumably this occurs via a "install-key" action (open to ideas)
      - this is a weird case because the client is initially okay with touching the
        private key, but thereafter wants it to be protected by the system.
      - again, as with (2), ideally the key shows up in running as consequence
        of the action, but a round-trip could also get it there.

Kent // contributor