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: Balázs Kovács <balazs.kovacs@ericsson.com>
To: Balázs Kovács <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, 09 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>; 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>; Balázs Lengyel <balazs.lengyel@ericsson.com>; 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>; Balázs Lengyel > <balazs.lengyel@ericsson.com>; 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
- [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