Re: [netconf] ietf crypto types - permanently hidden

Martin Bjorklund <mbj@tail-f.com> Tue, 30 April 2019 12:49 UTC

Return-Path: <mbj@tail-f.com>
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD6B212001B for <netconf@ietfa.amsl.com>; Tue, 30 Apr 2019 05:49:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id riW4Rth_wjix for <netconf@ietfa.amsl.com>; Tue, 30 Apr 2019 05:49:33 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 7996F120006 for <netconf@ietf.org>; Tue, 30 Apr 2019 05:49:33 -0700 (PDT)
Received: from localhost (h-4-215.A165.priv.bahnhof.se [158.174.4.215]) by mail.tail-f.com (Postfix) with ESMTPSA id AD2B21AE0589; Tue, 30 Apr 2019 14:49:30 +0200 (CEST)
Date: Tue, 30 Apr 2019 14:49:30 +0200 (CEST)
Message-Id: <20190430.144930.844252169549242587.mbj@tail-f.com>
To: kent+ietf@watsen.net
Cc: balazs.kovacs@ericsson.com, netconf@ietf.org
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <0100016a6e2130be-ee556dd0-e993-459f-be28-65fe1f74ece8-000000@email.amazonses.com>
References: <0100016a69e36565-37279712-e5de-4c48-9a8a-7397d54c11b3-000000@email.amazonses.com> <VI1PR07MB47353B20AF138B5B8B702285833A0@VI1PR07MB4735.eurprd07.prod.outlook.com> <0100016a6e2130be-ee556dd0-e993-459f-be28-65fe1f74ece8-000000@email.amazonses.com>
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: <https://mailarchive.ietf.org/arch/msg/netconf/dyP4crs_CiQFwHKWCqec6txALxc>
Subject: Re: [netconf] ietf crypto types - permanently hidden
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netconf/>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 30 Apr 2019 12:49:36 -0000

Kent Watsen <kent+ietf@watsen.net>; 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
'permanently-hidden'.

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

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?


/martin



> 
> 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
> > <balazs.kovacs@ericsson.com>; 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