Re: [Netconf] Mandatory local configuration in Keystore groupings
Martin Bjorklund <mbj@tail-f.com> Mon, 17 September 2018 14:38 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 406C4128CF3 for <netconf@ietfa.amsl.com>; Mon, 17 Sep 2018 07:38:25 -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 VP0AyNr8MWax for <netconf@ietfa.amsl.com>; Mon, 17 Sep 2018 07:38:23 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id BEB75127332 for <netconf@ietf.org>; Mon, 17 Sep 2018 07:38:22 -0700 (PDT)
Received: from localhost (unknown [173.38.220.61]) by mail.tail-f.com (Postfix) with ESMTPSA id D12611AE0311; Mon, 17 Sep 2018 16:38:19 +0200 (CEST)
Date: Mon, 17 Sep 2018 16:38:19 +0200
Message-Id: <20180917.163819.1278530557866964677.mbj@tail-f.com>
To: kwatsen@juniper.net
Cc: balazs.kovacs@ericsson.com, balazs.lengyel@ericsson.com, netconf@ietf.org
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <1F126D9A-775C-4590-A645-6529C3066C14@juniper.net>
References: <185C7E6D-7EF1-4FFE-9A9B-74BA7E16D946@juniper.net> <20180911.095334.2041631968993039535.mbj@tail-f.com> <1F126D9A-775C-4590-A645-6529C3066C14@juniper.net>
X-Mailer: Mew version 6.7 on Emacs 24.5 / 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/yaXTC5GBsyfMdoymHZnbV-rRLyM>
Subject: Re: [Netconf] Mandatory local configuration in Keystore groupings
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Configuration WG mailing 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: Mon, 17 Sep 2018 14:38:25 -0000
Kent Watsen <kwatsen@juniper.net> wrote: > > > >> There are two solutions being discussed here. > >> > >> The first regards how to enable a certificate to be configured for a key > >> in <operational> (e.g., an LDevID cert for a preexisting key). Both > >> solution (A) and (C) give us this - a la RFC 8342 Section C.3.2. > >> > >> The second is how to delete a "hidden key" created by a client (note here > >> that I'm distinguishing this case from hidden keys not created by a client, > >> i.e., in <operational>, which cannot be deleted). Here's where the ideas > >> diverge: > >> > >> - with (A), we keep the "generate" action outside the list entry (thus > >> results are in <operational>, and add a new "delete-asymmetric-key" > >> action is needed. > >> > >> - with (C), the action is moved inside the list entry, thus the list > >> entry node itself in <intended>, and hence can be removed from > >> <intended> via a normal config operation (no special action needed). > >> > >> I don't see an issue configuring certificates in either case. As I wrote > >> above, both solution (A) and (C) give us this. (C) still has to handle > >> the case where the key is in <operational> same as (A). With (C), it's > >> the 1% case, whereas with (A) it’s the 100% case. > > > > How can a key be in operational but not in config in (C)? I.e., what > > is the 1% case? > > Maybe too subtle, but in my first paragraph above said "e.g., an LDevID > cert for a preexisting key". I'm referring to how, during manufacturing, > a private key and an associated IDevID certificate are created and loaded > onto the device. This key and cert are immutable, but another cert could > be loaded for the same key. This is the scenario captured in the example > in: https://tools.ietf.org/html/draft-ietf-netconf-keystore-05#section-3.2. > (search for "tpm-protected-key"). This is the 1% case. Ok. > >> They seem close. For the purpose of creating a key, (C) is more > >> complicated. For the purpose of deleting a key, (C) seems easier. > > > > For the purpose of creating a certificate (A) is more complicated. > > How is that so? Actually, it seems that (A) and (C) are identical > in this respect, from a protocol perspective. The only difference > is in the backend, where it uses the RFC 8342 Section C.3.2 overlay > behavior. With (A), once you have generated the key, you first have to create the config for it, then invoke the action. With (C) (99% of) the keys already exist in the config, so you can just invoke the action. To summarize, A and C both get the job done. Which one is better is probably subjective. I think (C) is might be easier to understand. > > Depending on the answer above, (C) has the advantage that references > > (leafrefs) to a key can be require instance true. With (A) they have > > to be require instance false, since some keys only exists in > > operational, which means that whenever there is a reference to a key, > > that model and code must be able to handle the case that the key > > doesn't exist. > > Even with (C), some keys can be in <operational> - the 1% case, right? > > Yes, if *all* keys had a presence in <intended>, then learefs to keys > could be "require-instance true". Right. /martin
- [Netconf] Mandatory local configuration in Keysto… Balazs Lengyel
- Re: [Netconf] Mandatory local configuration in Ke… Kent Watsen
- Re: [Netconf] Mandatory local configuration in Ke… Martin Bjorklund
- Re: [Netconf] Mandatory local configuration in Ke… Kent Watsen
- Re: [Netconf] Mandatory local configuration in Ke… Martin Bjorklund
- Re: [Netconf] Mandatory local configuration in Ke… Kent Watsen
- Re: [Netconf] Mandatory local configuration in Ke… Martin Bjorklund
- Re: [Netconf] Mandatory local configuration in Ke… Kent Watsen
- Re: [Netconf] Mandatory local configuration in Ke… Martin Bjorklund
- Re: [Netconf] Mandatory local configuration in Ke… Balázs Kovács
- Re: [Netconf] Mandatory local configuration in Ke… Kent Watsen
- Re: [Netconf] Mandatory local configuration in Ke… Martin Bjorklund
- Re: [Netconf] Mandatory local configuration in Ke… Balázs Kovács
- Re: [Netconf] Mandatory local configuration in Ke… Balázs Kovács
- Re: [Netconf] Mandatory local configuration in Ke… Kent Watsen
- Re: [Netconf] Mandatory local configuration in Ke… Martin Bjorklund
- Re: [Netconf] Mandatory local configuration in Ke… Balázs Kovács
- Re: [Netconf] Mandatory local configuration in Ke… Balázs Kovács
- Re: [Netconf] Mandatory local configuration in Ke… Kent Watsen
- Re: [Netconf] Mandatory local configuration in Ke… Martin Bjorklund
- Re: [Netconf] Mandatory local configuration in Ke… Balázs Kovács
- Re: [Netconf] Mandatory local configuration in Ke… Kent Watsen
- Re: [Netconf] Mandatory local configuration in Ke… Martin Bjorklund
- Re: [Netconf] Mandatory local configuration in Ke… Kent Watsen
- Re: [Netconf] Mandatory local configuration in Ke… Martin Bjorklund
- Re: [Netconf] Mandatory local configuration in Ke… Balázs Kovács
- Re: [Netconf] Mandatory local configuration in Ke… Kent Watsen
- Re: [Netconf] Mandatory local configuration in Ke… Martin Bjorklund
- Re: [Netconf] Mandatory local configuration in Ke… Balázs Kovács
- Re: [Netconf] Mandatory local configuration in Ke… Balázs Kovács
- Re: [Netconf] Mandatory local configuration in Ke… Kent Watsen
- Re: [Netconf] Mandatory local configuration in Ke… Balázs Kovács
- Re: [Netconf] Mandatory local configuration in Ke… Kent Watsen