Re: [Netconf] Mandatory local configuration in Keystore groupings

Balázs Kovács <balazs.kovacs@ericsson.com> Tue, 09 October 2018 10:25 UTC

Return-Path: <balazs.kovacs@ericsson.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 E2429131256 for <netconf@ietfa.amsl.com>; Tue, 9 Oct 2018 03:25:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.756
X-Spam-Level:
X-Spam-Status: No, score=-4.756 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.456, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=Tez2bwwv; dkim=pass (1024-bit key) header.d=ericsson.com header.b=CRJqym+d
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 PigZaXpZoiXB for <netconf@ietfa.amsl.com>; Tue, 9 Oct 2018 03:25:53 -0700 (PDT)
Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9BE4131254 for <netconf@ietf.org>; Tue, 9 Oct 2018 03:25:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1539080750; x=1541672750; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=Ox3MLZNjEwdMcowLkBoyHmDA5CFjyHtIYpgidE7lsMk=; b=Tez2bwwvFIuod8HRlTnXppeem6Od8swO21IAEiaiAD7iyNP7hL/obMuFpfbSfdPs b1G8zGvu1RjqBonlP0SF0z/mcNIUsBykreGQvLK7MZ+1+3/ncLQ+lGUQS13m8U0/ KOmXOBBMlYRYMlLoJ35cfZH+koPbUKetgWbLj0EaoOs=;
X-AuditID: c1b4fb30-776849e0000047d2-05-5bbc822e0e3f
Received: from ESESBMB505.ericsson.se (Unknown_Domain [153.88.183.118]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id E3.E5.18386.E228CBB5; Tue, 9 Oct 2018 12:25:50 +0200 (CEST)
Received: from ESESBMR504.ericsson.se (153.88.183.139) by ESESBMB505.ericsson.se (153.88.183.188) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Tue, 9 Oct 2018 12:25:50 +0200
Received: from ESESSMB505.ericsson.se (153.88.183.166) by ESESBMR504.ericsson.se (153.88.183.139) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Tue, 9 Oct 2018 12:25:49 +0200
Received: from EUR03-DB5-obe.outbound.protection.outlook.com (153.88.183.157) by ESESSMB505.ericsson.se (153.88.183.166) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Tue, 9 Oct 2018 12:25:49 +0200
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=VH//Df1FpKYcTI7WmcE4hnz/ptsceFbYf94URoS0QGc=; b=CRJqym+da/+xsUYOnGTAhM1bnWC+1M3oJuW3LhQb12Y51g3rI61NJVR+45VdwVhjQw6P5EhKORYDA2oCE4asWrjDtjrSFikEM8FMulohx8nYV5oie/InUEAjHakttF8ffBsxh5KRCKA2xB7UWDLqcejTb6C6KIInV2Yeqih/OTM=
Received: from VI1PR0701MB2016.eurprd07.prod.outlook.com (10.167.209.150) by VI1PR0701MB2654.eurprd07.prod.outlook.com (10.173.78.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1228.13; Tue, 9 Oct 2018 10:25:48 +0000
Received: from VI1PR0701MB2016.eurprd07.prod.outlook.com ([fe80::b0f7:7595:9501:6d8d]) by VI1PR0701MB2016.eurprd07.prod.outlook.com ([fe80::b0f7:7595:9501:6d8d%4]) with mapi id 15.20.1228.020; Tue, 9 Oct 2018 10:25:47 +0000
From: =?iso-8859-1?Q?Bal=E1zs_Kov=E1cs?= <balazs.kovacs@ericsson.com>
To: =?iso-8859-1?Q?Bal=E1zs_Kov=E1cs?= <balazs.kovacs@ericsson.com>, "Martin Bjorklund" <mbj@tail-f.com>, "kwatsen@juniper.net" <kwatsen@juniper.net>
CC: "netconf@ietf.org" <netconf@ietf.org>
Thread-Topic: [Netconf] Mandatory local configuration in Keystore groupings
Thread-Index: AQHUE4npYduSZhsf/U2Th8xceQbCUaSAzHaAgEmH34CAAG1ZgIAA+nAAgAPuH4CAA+yKAIABAxSAgAB6cACAAHFXIIAAWSCAgADMp9CAAnp9gIAFkemAgAFwH/CACoYJAIAAdAkAgADFpICACRlvgIAAdmGAgACclYCAACUMUIAAoXkAgAAWIACAIB/ScIAAPI5w
Date: Tue, 9 Oct 2018 10:25:47 +0000
Message-ID: <VI1PR0701MB2016753ED14EC8BFEE82F45C83E70@VI1PR0701MB2016.eurprd07.prod.outlook.com>
References: <20180918.090227.98113334613843662.mbj@tail-f.com> <VI1PR0701MB2016707AE81A6F77719461D4831D0@VI1PR0701MB2016.eurprd07.prod.outlook.com> <A9FACF6E-2207-4FD3-966A-3482DC96B35D@juniper.net> <20180918.221210.1111111634668608576.mbj@tail-f.com> <VI1PR0701MB2016CB295B311EFCF2F7632C83E70@VI1PR0701MB2016.eurprd07.prod.outlook.com>
In-Reply-To: <VI1PR0701MB2016CB295B311EFCF2F7632C83E70@VI1PR0701MB2016.eurprd07.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=balazs.kovacs@ericsson.com;
x-originating-ip: [176.63.30.245]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; VI1PR0701MB2654; 6:riEnvMZtF7sgyFxS8OkWKQe55QaxWTL5qoHOWAFt8ZseQ7WBDw8XitARoHVBRWxo0PC2jJTxKEPbvqliAHjeyzeeF97FV5HMTph3zgqgwtCWhgFHUEROLuSxTOaznMzO7nucP21j34/lWSOT90sJCslqDIaZfbCjHy15jiFYNlQVMvlW9FykkwgTi2uMBO3YhyYj4j2f3R2/91qpGjqkCs0dLlPRB2qkmkVuWYPLiUyb9I8HL/bgYXUm5bVDCp3aSSwJsKzbRnoNQXhkyHFpOzIUg8/Ycu8WrzwURSW1CG5eZvH3hR+Xx2lL7R8aofmF2tkZQbXw++xm8eG+rRDu22VwW6fBjH4tJc85AsoqpE73w6NMSvF3iK4iBRUMaDqh4srp7d/Ius6PhUWiYCr1P/qtjqMGAi5APcYHU0T9cvWMp0F6qG383qd+k9hrW0xu0RSI0srPvKBURYNhh/E4XQ==; 5:YCKV+qqOlcEfkd763IkYq5lGLSMB6VvqnDNIGdOM99d64B1c1M6PTdf4aNtQdX6214SL8yLFCWD0awB/xIQLH+KGiEUbLPXuO0ohG8dFBsoFR/Jv9MxwnD9EcbJXhuDU4mxUiJ5n397TRMens6thSwAlLw2uo2X3Ys3gjSJPsbQ=; 7:q1v77EqMu8jA+daoUr2Fq88b2vWBln6xE8WbVxnActhM7xUQViOHNyNeIzQUDN8yRxdvr1BILtlQ1FshuI2vcyYePAAHWMKTt/miSRA+s4ARp+8vt35XX73YDlB/HfVWrRdfx2wPgoqTRUuZ0Q7HJsorXdwjs2smhcFZn/ekX0N6sw+u5E91stTXjr7BheWP98tG+dJNwIjxPhhlq268ZC7d/ay+CR3JA+Us2mr4gMfKXVnkYo1lidjAaXAIv3Ls
x-ms-exchange-antispam-srfa-diagnostics: SOS;SOR;
x-forefront-antispam-report: SFV:SKI; SCL:-1; SFV:NSPM; SFS:(10009020)(366004)(136003)(346002)(39860400002)(376002)(396003)(199004)(189003)(13464003)(51444003)(106356001)(7736002)(9686003)(6436002)(1941001)(345774005)(53936002)(99286004)(2906002)(14444005)(256004)(71200400001)(97736004)(71190400001)(81156014)(86362001)(8676002)(229853002)(93156006)(68736007)(305945005)(3846002)(6116002)(2900100001)(55016002)(6306002)(26005)(186003)(66574009)(8936002)(25786009)(2501003)(110136005)(33656002)(486006)(478600001)(81166006)(14454004)(66066001)(966005)(74316002)(5250100002)(93886005)(4326008)(446003)(316002)(11346002)(6246003)(76176011)(5660300001)(102836004)(476003)(6506007)(7696005)(53546011)(105586002)(2940100002); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0701MB2654; H:VI1PR0701MB2016.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
x-ms-office365-filtering-correlation-id: 2e69cb3c-be25-4d75-17b4-08d62dd19427
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(2017052603328)(7153060)(7193020); SRVR:VI1PR0701MB2654;
x-ms-traffictypediagnostic: VI1PR0701MB2654:
x-microsoft-antispam-prvs: <VI1PR0701MB2654A134DF8C2DE34BDE09C783E70@VI1PR0701MB2654.eurprd07.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(138986009662008)(37575265505322)(248295561703944);
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(93006095)(93001095)(10201501046)(3002001)(3231355)(944501410)(52105095)(149066)(150057)(6041310)(20161123562045)(20161123564045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(201708071742011)(7699051); SRVR:VI1PR0701MB2654; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0701MB2654;
x-forefront-prvs: 08200063E9
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: CS8rr7akpZNdfAZONgLyNXqyXPM9X076C8TXoccxPzosBW9ETgx4Z+7Dw5T0sUQidawRd1lkN1mnFDuRXI1koU0kiYTvxGRf4BdAxl5mDn/5Bof/Os3ye9SghNDNsbEWd/GaruQtgh9O7xDgyuzj+vE9epH6apz9ssEx2BSgchMcbC3BQJKqLlMwKrXhDlSmXhsQiZqrRCBFVSshkianuoy2Fo7hzEuyqrllZbtZVpVyWHPuJI7FW1cUO0Qai+qq58vHXO0p59YVapaTV5Nsd16UKv0KG9peTqxJbYFThMLlTjmqUqhquepSaoCLgFeUfIFqh8SjrOLXCDjFuIq6boI5vdpGVmf5RY2Up1NO0G0=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 2e69cb3c-be25-4d75-17b4-08d62dd19427
X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Oct 2018 10:25:47.5918 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0701MB2654
X-OriginatorOrg: ericsson.com
X-Brightmail-Tracker: H4sIAAAAAAAAA02SbUhTYRiGec85247W5Lj8eND84agfZS21oCEVKkiSZEIUpmauPKiom+yo NUlZIgqbgprTJn7myg9UyC008ZtU9Iei4FdaWU6bySITUYuytteif9fz3vfN/Tzw0qSohOdB J8nTWaVcliLmO1L6yM7M05LcnmjfpckA6UCVQKrVrgmkuo5FXiAZajDsEaFzuTOC0BffG6gI MsrxQjybkpTJKs9cinNM3NX1UWnlcQ9aSy1IjYxBGuRAA3MOyq0tfA1ypEXMMILlr+aDYRvB 6LBJ8G/YqjOReGggoKc5V2DLU0wxCeNNPlioIKA3v/Agsorg6VY5ZXPxmRBY1e/ZBRemAkHB xII9TjInoO3nJmnjI8wV6O5dRDZ2YcKgUNtPYZ5GsF/hheuOgXlgyP4uZOKgZi6Pwm3zBEyt N/I0iKYdGBm8XFPZPIhxg53xVgJ3ucMbcy2Bz2bA0DNJYnaF9ZVfPOy/DV0bSwL87g0f2lYp zF4wXatFti5gBgSwMPGMhwU/GG3uJ7Ewy4f2mc6DxFUw1g7ysTCGoN5sIWzbAXMKSnQq7FGA tSWPLEb+lf8tiFkC87oyPmYfeF6/QVbaj3aGMb2ZqkNUC3LlWO5uaoK/v4RVJt3jOIVcImfT O9CfjzJo+uHbhdY/BQ0hhkbiw8Lz2T3RIp4sk1OlDiGgSbGL0LWzO1okjJepslil4o4yI4Xl hpAnTYndhdJwY5SISZCls8ksm8Yq/6oE7eChRjGvy99ZV86KwyY1zU8ap96ra4o+X84qnR1p KpNkfVNcLF27frNp/1V/eHpAopVviXxbEFjlVlz9KNi3Oif5Vmys4b4+Ytk7esatfeGGdkRV lJOhv/ZYI3+Yvd09VtJa7+k8uhnjfqjDaUc9ku/EWT5Ky467dJhmd0P6ju4bg3VfxBSXKPM7 SSo52W+VB4RNJAMAAA==
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/wnJ6KeNddai5-ZgijBU4vIxdW9U>
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: Tue, 09 Oct 2018 10:25:56 -0000

Hi,

One more question. I found this in ct:

  grouping asymmetric-key-pair-with-certs-grouping {
    description
      "A private/public key pair and associated certificates.";
    uses asymmetric-key-pair-grouping;
    container certificates {
      description
        "Certificates associated with this asymmetric key.
         More than one certificate supports, for instance,
         a TPM-protected asymmetric key that has both IDevID
         and LDevID certificates associated.";
      list certificate {
        must "../../algorithm
               and ../../public-key
                 and ../../private-key";
        key name;
        description
...

Is it ok to have the must statement in the certificate list? I think with (C) the idea was to have hidden keys represented in the configuration for which certificates can still be configured, but hidden keys will have no algorithm/public-key/private-key in configuration. What's your view?

Br,
Balazs

-----Original Message-----
From: Netconf <netconf-bounces@ietf.org> On Behalf Of Balázs Kovács
Sent: Tuesday, October 9, 2018 8:50 AM
To: Martin Bjorklund <mbj@tail-f.com>om>; kwatsen@juniper.net
Cc: netconf@ietf.org
Subject: Re: [Netconf] Mandatory local configuration in Keystore groupings

Hi Kent,

First of all, thank you for the keystore update.

I was checking it at the moment and noticed something that may be a miss.

  typedef asymmetric-key-ref {
    type leafref {
      path "/ks:keystore/ks:asymmetric-keys/ks:asymmetric-key"
           + "/ks:name";
      require-instance false;
    }
    description
      "This typedef enables modules to easily define a reference
       to an asymmetric key stored in the keystore. The require
       instance attribute is false to enable the referencing of
       asymmetric keys that exist only in <operational>.";
    reference
      "RFC 8342: Network Management Datastore Architecture (NMDA)";
  }

I think we were discussing changing 'require-instance' to 'true' in relation to the change toward alternative (C) as discussed below. Should it be 'true' instead of 'false'?

Br,
Balazs

-----Original Message-----
From: Martin Bjorklund <mbj@tail-f.com>
Sent: Tuesday, September 18, 2018 10:12 PM
To: kwatsen@juniper.net
Cc: Balázs Kovács <balazs.kovacs@ericsson.com>om>; Balázs Lengyel <balazs.lengyel@ericsson.com>om>; netconf@ietf.org
Subject: Re: [Netconf] Mandatory local configuration in Keystore groupings

Kent Watsen <kwatsen@juniper.net> wrote:
> 
> I like Martin's "twist" - I don't view it as an extreme hardship (the 
> 1% case), and I prefer (C) for supporting "require-instance true" as 
> well as having one less action.  So, let's go with (C).
> 
> Martin, you mentioned some details might be wrong, are they wrong in 
> (C)?  - I'd like to have it right when posting the next update...

Yes; in (C), "generate-hidden-key" and "load-hidden-key" doesn't take "name" as input.


/martin


> Balazs, the desire to reference an IDevID could be from any 
> SSH/TLS-based app, it would be hard to know in advance where.  No 
> matter, with (C)+twist, we can have "require-instance true" always.
> 
> Kent // contributor
> 
> 
> -----Original Message-----
> 
> Hi,
> 
> I'd just emphasize that in creation step of hidden key, the name must 
> be coordinated between step A/1&2 by external application logic. Same 
> holds for deletion of hidden key for A/1&2. "Same name" is important.
> 
> Enabling the possibility for 'require instance true' would be also 
> good remark on the side of (C).
> 
> Regarding manufactured keys, I would not expect manufactured keys to 
> be used in other common models, such as in TLS/SSH use cases. If they 
> have some specific use case, maybe those models could either have 
> 'require instance false' or it could be said to create an empty key 
> for them as Martin described.
> 
> Br,
> Balazs
> 
> -----Original Message-----
> From: Martin Bjorklund <mbj@tail-f.com>
> Sent: Tuesday, September 18, 2018 9:02 AM
> To: kwatsen@juniper.net
> Cc: Balázs Kovács <balazs.kovacs@ericsson.com>om>; Balázs Lengyel 
> <balazs.lengyel@ericsson.com>om>; netconf@ietf.org
> Subject: Re: [Netconf] Mandatory local configuration in Keystore 
> groupings
> 
> Hi,
> 
> Ok, so we have these two alternatives illustrated below.  There are 
> some details that probably are wrong, but it doesn't really matter at 
> this stage.  With (A), there is one more action to control the 
> lifespan of keys (delete-hidden-key).
> 
> In the case that the key is given as config, A and C works in the same 
> way.
> 
> In the case that the key is permanent, A and C also works in the same 
> way.
> 
> A and C differ in how hidden keys are handled.
> 
> 
> In order to create a hidden key + certificate, the steps are:
> 
> A:  1. call generate-hidden-key with a given name
>     2. create an asymmetric-key with the same name in the config
>     3. call generate-certificate-signing-request
>     4. <get hold of a cert>
>     5. create the certificate in the config
> 
> (step 1 and 2 can be done in reverse order)
> 
> C   1. create an asymmetric-key in the config
>     2. call generate-hidden-key on this key
>     3. call generate-certificate-signing-request
>     4. <get hold of a cert>
>     5. create the certificate in the config
> 
> In order to delete a hidden key completely:
> 
> A:  1. call delete-hidden-key on the asymmetric-key to be deleted
>     2. delete the asymmetric-key from the config
> 
> C:  1. delete the asymmetric-key from the config
> 
> 
> 
> In summary, they are very similar.
> 
> One possible twist that probably works best for C could be to use 
> leafrefs with require instance true, and say that in order to use a 
> permanent key (created during manufacturing), you first need to create 
> config for the key (more or less empty config).  The benefit is that 
> we get proper leafref validation (no dangling pointers to handle in 
> all other models).  FWIW, this is the approach taken in 
> ietf-interfaces.
> 
> If we don't do this twist, I think that we can use either of A and C.
> 
> 
> 
> /martin
> 
> 
> 
> 
> Kent Watsen <kwatsen@juniper.net> wrote:
> > 
> > > 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.
> > 
> > I don't follow.  What I see is that, with (A), a hidden key can be 
> > created with a single action invocation while, with (C), first a 
> > configuration operation is needed to create the "asymmetric-key"
> > (without the three leafs) followed by an action invocation (to 
> > populate the three leafs).
> > 
> > 
> > > 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.
> > 
> > Okay, let's see how it looks.  Bubbling all the ideas to the top, I 
> > created the below tree-diagrams.  Note, in both cases, the three 
> > "mandatory true" leafs are replaced with an all-or-nothing "must"
> > expression:
> > 
> > 
> > (A) Uses RFC 8342 Section C.3.2 style config overlays for all hidden 
> > keys;
> >     and an action statement is used to delete all hidden keys.
> > 
> >      +--rw keystore
> >         +--rw asymmetric-keys
> >            +--rw asymmetric-key* [name]
> >            |  +--rw name                            string
> >            |  +--rw algorithm?                      ct:key-algorithm-ref
> >            |  +--rw public-key?                     binary
> >            |  +--rw private-key?                    union
> >            |  +---m "(algorithm and public-key and private-key)
> >            |  |       or not (algorithm or public-key or private-key)";
> >            |  +--rw certificates
> >            |  |  +--rw certificate* [name]
> >            |  |     +--rw name                      string
> >            |  |     +--rw cert                      ct:end-entity-cert-cms
> >            |  |     +---n certificate-expiration
> >            |  |        +-- expiration-date?         yang:date-and-time
> >            |  +---x generate-certificate-signing-request
> >            |  |  +---w input // KEY MAY BE IN <OPERATONAL>
> >            |  |  |  +---w subject                   binary
> >            |  |  |  +---w attributes?               binary
> >            |  |  +--ro output
> >            |  |     +--ro certificate-signing-request    binary
> >            |  +---x delete-hidden-key
> >            |        // no params
> >            +---x generate-hidden-key
> >            |  +---w input                           // RESULT IN <OPERATONAL>
> >            |     +---w name                         string
> >            |     +---w algorithm                    ct:key-algorithm-ref
> >            +---x load-hidden-key
> >               +---w input                           // RESULT IN <OPERATONAL>
> >                  +---w name                         string
> >                  +---w algorithm                    ct:key-algorithm-ref
> >                  +---w public-key                   binary
> >                  +---w private-key                  union
> > 
> > 
> > (C) Uses RFC 8342 Section C.3.2 style config overlays only for 
> > hidden keys
> >     created in <operational> (i.e., during manufacturing).  But if there
> >     is
> >     even just one key created during Manufacturing, and it doesn't appear
> >     in <intended>, then leafrefs still need to be "require-instance
> >     false",
> >     right? Also, it seems that such keys could never be deleted, unlike 
> >     other hidden keys, but that is probably okay (correct behavior).
> > 
> >      +--rw keystore
> >         +--rw asymmetric-keys
> >            +--rw asymmetric-key* [name]
> >               +--rw name                            string
> >               +--rw algorithm?                      ct:key-algorithm-ref
> >               +--rw public-key?                     binary
> >               +--rw private-key?                    union
> >               +---m "(algorithm and public-key and private-key)
> >               |       or not (algorithm or public-key or private-key)";
> >               +--rw certificates
> >               |  +--rw certificate* [name]
> >               |     +--rw name                      string
> >               |     +--rw cert                      ct:end-entity-cert-cms 
> >               |     +---n certificate-expiration
> >               |        +-- expiration-date?         yang:date-and-time
> >               +---x generate-hidden-key
> >               |  +---w input                        // RESULT IN <OPERATONAL>
> >               |     +---w name                      string
> >               |     +---w algorithm                 ct:key-algorithm-ref
> >               +---x load-hidden-key
> >               |  +---w input                        // RESULT IN <OPERATONAL>
> >               |     +---w name                      string
> >               |     +---w algorithm                 ct:key-algorithm-ref
> >               |     +---w public-key                binary
> >               |     +---w private-key               union
> >               +---x generate-certificate-signing-request
> >                  +---w input // KEY MAY BE IN <OPERATONAL>
> >                  |  +---w subject                   binary
> >                  |  +---w attributes?               binary
> >                  +--ro output
> >                     +--ro certificate-signing-request    binary
> > 
> > 
> > 
> > 
> > Kent // contributor
> > 
> > 
> > 
> 
> 

_______________________________________________
Netconf mailing list
Netconf@ietf.org
https://www.ietf.org/mailman/listinfo/netconf