Re: [netconf] ietf crypto types - permanently hidden

Martin Bjorklund <> Tue, 30 April 2019 12:49 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BD6B212001B for <>; Tue, 30 Apr 2019 05:49:35 -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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id riW4Rth_wjix for <>; Tue, 30 Apr 2019 05:49:33 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 7996F120006 for <>; Tue, 30 Apr 2019 05:49:33 -0700 (PDT)
Received: from localhost ( []) by (Postfix) with ESMTPSA id AD2B21AE0589; Tue, 30 Apr 2019 14:49:30 +0200 (CEST)
Date: Tue, 30 Apr 2019 14:49:30 +0200
Message-Id: <>
From: Martin Bjorklund <>
In-Reply-To: <>
References: <> <> <>
X-Mailer: Mew version 6.7 on Emacs 25.2 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset="utf-8"
Content-Transfer-Encoding: base64
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, 30 Apr 2019 12:49:36 -0000

Kent Watsen <> wrote:
> Correct, as I didn’t think there was consensus yet.  Perhaps there is
> rough-consensus, and it may be that the only way to gauge that is to
> try and see how much push back there is.
> Okay, so how about this, based on this thread, there appears to be
> support to add a flag to control if a key should be “permanently
> hidden” or not, in which case configuration is created.

I (still) object to this.  Actions shouldn't create config.  We
already have generic protcol operations to do this.  We go from a
document-oriented configuration model towards a command-oriented
model.  Not good.  In RESTCONF, the generic methods support things
like ETags, which I suspect you don't want to replicate in this
action?   Will the action support all error-options of edit-config,
like rollback-on-error?

Some comments on the new text:

In action generate-hidden-key, it should be stated that the public-key
will be populated, and that the private-key will exist but report

In action install-hidden-key, shouldn't both public-key and
private-key be mandatory?  Also state that the private-key will report

In leaf private-key, the type binary part of the union doesn't have a
description, and the description for the leaf itself says:

       A binary that contains the value of the private key.

which is not quite correct.

I think we should state that the enum 'permanently-hidden' is only
reported in operational state.

The new descriptions say:

            [...] present only in
            <operational> and bound to the lifetime of the parent
            'config true' node.

Aren't all nodes bound to the lifetime of their parent?
The action is invoked in a node that exists in <operational> and it
creates a key.  What does the statement tell me?


> This change will be in the next update, in about a week’s time, if no
> objections are raised.
> Kent // contributor
> > On Apr 30, 2019, at 7:30 AM, Balázs Kovács
> > <> wrote:
> > 
> > Hi Kent,
> >  
> > I don’t see the your proposal below addressed in latest update
> > (keystore-09). Was it missed?
> >  
> > 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.
> >  
> > Br,
> > Balazs