Re: [netconf] ietf crypto types - permanently hidden

Martin Bjorklund <mbj@tail-f.com> Fri, 03 May 2019 06:50 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 B119112006B for <netconf@ietfa.amsl.com>; Thu, 2 May 2019 23:50:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-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 FgSNZZQdhOWI for <netconf@ietfa.amsl.com>; Thu, 2 May 2019 23:49:59 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id B7601120044 for <netconf@ietf.org>; Thu, 2 May 2019 23:49:59 -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 D74A41AE0389; Fri, 3 May 2019 08:49:58 +0200 (CEST)
Date: Fri, 03 May 2019 08:49:58 +0200 (CEST)
Message-Id: <20190503.084958.1871984073774502678.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: <0100016a7957dd62-0c25451b-3a69-4a08-b4e6-d7ad22e5227d-000000@email.amazonses.com>
References: <0100016a6f64a438-50e97747-d12b-429b-8147-8bf6ed82bdac-000000@email.amazonses.com> <20190502.120944.41224357089248496.mbj@tail-f.com> <0100016a7957dd62-0c25451b-3a69-4a08-b4e6-d7ad22e5227d-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=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/4Jg4BNsdDlqtKVYeYHdty5tFkkI>
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: Fri, 03 May 2019 06:50:02 -0000

Kent Watsen <kent+ietf@watsen.net>; wrote:
> 
> >> In enum permanently-hidden:
> >>  OLD:
> >>       The private key is inaccessible due to being protected by the
> >>       system (e.g., a cryptographic hardware module).
> >>  NEW:
> >>       The private key is inaccessible due to being protected by the
> >>       system (e.g., a cryptographic hardware module).  Since hidden
> >>       keys are only ever reported in <operational>, the value
> >>       'permanently-hidden' never appears in <intended>.
> > 
> > Ok, but perhaps s/<intended>/conventional configuration datastores/?
> 
> Fixed in my local copy.
> 
> 
> >> Note that this statement was added because Juergen asked about how
> >> hidden keys could be removed/replaced.  We iterated towards not
> >> wanting to support the "replace" case
> > 
> > But why?  If an operator wants to replace, why should the list entry
> > first be deleted and then created and then the key can be generated?
> > This seems like a CLR to me.
> 
> https://mailarchive.ietf.org/arch/msg/netconf/ZwXll9BtAv61EvVXtFDLLzTkljE
> <https://mailarchive.ietf.org/arch/msg/netconf/ZwXll9BtAv61EvVXtFDLLzTkljE>
> 
> 
> 
> > Ok, I see.  I think the text needs some clarification; make it more
> > explicit.  It needs to say that if a "permanently-hidden" private key
> > exists in <operational> under a parent config true node and this
> > parent node is deleted, the private key is supposed to be (MUST be?)
> > deleted from the system as well.
> 
> Added, with a MUST.
> 
> 
> > A remove-hidden-key action can be problematic b/c if you forget to
> > call this action and then delete the config, presumably you have
> > lingering keys in the system that you can't remove.
> 
> I don't think this is true.  Even if an asymmetric key only exists in
> <operational> (i.e., the corresponding "config true" parent node is
> deleted), it seems that a 'remove-hidden-key' could still remove it.
> In fact, this is the most consistent thing, to have an 'action' act on
> values in <operational>.

You're right.  If we have "create" action it makes sense to have a
"delete" action.  But see the mail from Rob W.  Perhaps we shouldn't
have these actions at all?


/martin