Re: [netconf] ietf-keystore, truststore, crypto-types

Kent Watsen <kent@watsen.net> Tue, 30 July 2019 01:31 UTC

Return-Path: <0100016c4080d8cf-c12d13c2-d356-4c44-b70e-13633e160c93-000000@amazonses.watsen.net>
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 0B09212002E for <netconf@ietfa.amsl.com>; Mon, 29 Jul 2019 18:31:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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=amazonses.com
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 SQYs89vDBuJI for <netconf@ietfa.amsl.com>; Mon, 29 Jul 2019 18:31:23 -0700 (PDT)
Received: from a8-32.smtp-out.amazonses.com (a8-32.smtp-out.amazonses.com [54.240.8.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1097C120019 for <netconf@ietf.org>; Mon, 29 Jul 2019 18:31:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1564450281; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=L7iDjanlfAzA7LtX2Voildje+ZA9E0f4MRDJydsm00M=; b=EhCoYvePh1KDICKLQvPCBq2Q30DcehmFWF777mAqkBaOH1VAqLodXCEe45gvXXs5 PI1qUyDpAsGlhJTudOGnF3xU1mQB48LUZ4ddTzojReZUSXpuXicmNbEe7wuDsmpZnkF xoLglcBhpFqFI5dhrWR59twCm1pY2q8hCv4v76Vg=
From: Kent Watsen <kent@watsen.net>
Message-ID: <0100016c4080d8cf-c12d13c2-d356-4c44-b70e-13633e160c93-000000@email.amazonses.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_E362A6AB-B6F1-43F0-AEE4-49A8672624F4"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Tue, 30 Jul 2019 01:31:21 +0000
In-Reply-To: <VI1PR07MB47355EFE36C004F0BB831B8A83DD0@VI1PR07MB4735.eurprd07.prod.outlook.com>
Cc: "netconf@ietf.org" <netconf@ietf.org>
To: Balázs Kovács <balazs.kovacs@ericsson.com>
References: <VI1PR07MB47355EFE36C004F0BB831B8A83DD0@VI1PR07MB4735.eurprd07.prod.outlook.com>
X-Mailer: Apple Mail (2.3445.104.11)
X-SES-Outgoing: 2019.07.30-54.240.8.32
Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/pvBD1dOzQc925hw7NMP96rxrFxo>
Subject: Re: [netconf] ietf-keystore, truststore, crypto-types
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 Jul 2019 01:31:25 -0000

Hi Balazs,

 
> Typo
>  
> <CODE BEGINS> file "ietf-truststire@2019-06-07.yang <mailto:ietf-truststire@2019-06-07.yang>"

I'd previously found/fixed this in my local copy, but thanks for reporting it.


 
> Is mandatory true missing from ‘cert’ leaf in ietf-crypto-types?
>  
> <snip/>

Possibly, but I don't think so.  For instance, consider asymmetric-key-pair-with-cert-grouping that uses both asymmetric-key-pair-grouping and end-entity-cert-grouping.   One has to create the asymmetric-key prior to being able to execute the generate-certificate-signing-request action to create the end-entity certificate. 

That said, this probably is going to raise the question for why then asymmetric-key-pair-grouping nodes are mandatory true, or more generally, if groupings should ever define mandatory true nodes, rather than leave it to the using-schema to refine-in the mandatory true statements if desired.



> Question: why have the key generation actions been converted to RPCs? If this is because of their earlier containers having now mandatory leaves, then have you considered just moving them one level up, adding ‘name’ as parameter, and keeping them as actions? I’d prefer actions.

Because the requests are no longer bound to an "object".  The RPCs are defined have no effect on either configuration or opstate, they simply return a value that the client will, presumably (especially if encrypted), return back to the device via a standard config update request (e.g, <edit-config>).

FWIW, see "discussion #2" starting on page 12 here https://datatracker.ietf.org/meeting/105/materials/slides-105-netconf-client-server-suite-of-drafts-00 <https://datatracker.ietf.org/meeting/105/materials/slides-105-netconf-client-server-suite-of-drafts-00>.

Why do you prefer actions?


Kent