Re: [Netconf] Adoption poll for crypto-types and trust-anchors

"Eric Voit (evoit)" <> Wed, 23 May 2018 12:12 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D8076126DED for <>; Wed, 23 May 2018 05:12:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id GQfNRsS3379x for <>; Wed, 23 May 2018 05:12:47 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 88DCE126DCA for <>; Wed, 23 May 2018 05:12:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=16478; q=dns/txt; s=iport; t=1527077567; x=1528287167; h=from:to:cc:subject:date:message-id:references: mime-version; bh=cHzG1w5L3QMtMPw9QukeE5RmqBeTosBqHSRR4alg+es=; b=Zovc1Pe9u/gw2rtivyoV34dSsburpu9+ckJH3aP4+HQQt8Z4pQDOY43T YTTTEDTANJI+KTgE7tgVfc4CWLIeAc7MTrrTovV5cUPJa4fcSEQbVRuWf paXA6tfVfVRIsx65w4vHxEwXLwT5Wwn0hfHMttSTJrpfBadoycyVaf5PD s=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.49,432,1520899200"; d="scan'208,217";a="396548520"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 23 May 2018 12:12:46 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id w4NCCk53031556 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 23 May 2018 12:12:46 GMT
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1320.4; Wed, 23 May 2018 08:12:45 -0400
Received: from ([]) by ([]) with mapi id 15.00.1320.000; Wed, 23 May 2018 08:12:45 -0400
From: "Eric Voit (evoit)" <>
To: Kent Watsen <>
CC: "" <>
Thread-Topic: [Netconf] Adoption poll for crypto-types and trust-anchors
Date: Wed, 23 May 2018 12:12:45 +0000
Message-ID: <>
References: <> <> <> <> <> <>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_2474b9e72e734988bf5b6bb5ebd67109XCHRTP013ciscocom_"
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [Netconf] Adoption poll for crypto-types and trust-anchors
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Network Configuration WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 23 May 2018 12:12:50 -0000

From: Eric Voit, May 11, 2018 6:13 PM

From: Kent Watsen, May 10, 2018 6:31 PM
Kent writes, in response to Balazs:
You're right about that, if added later, it may not be widely implemented.  Back to the technical discussion, some important points have been raised.  Perhaps it is better after all to keep ietf-keystore, the -03 version, before the private key was converted to being a grouping.  Right now, the adoption poll is showing weak support, and this seems to be the core issue.  Hearing from others on this point would be very helpful!

<Eric> I do like providing grouping which allow key-pairs to be defined and used in various models.

<Kent> It's possible to both have groupings (for those that want them) and to use those groupings in a keystore data model.  The only question then would be if the ietf-[ssh/tls]-[client/server] modules use one, or the other, or both?  [I think the idea of bringing back the keystore module would be then to just use it in our modules]

<Eric2> I don’t have a very strong opinion on this.  I see this more of a preference question of how much modularity do we want.  My assumption is that in the security space, solid modular identities & group definitions might play a role similar to that of RFC 6021 for common YANG types.

<Eric> One question on this, leaf public-key in draft-kwatsen-netconf-crypto-types-00 has a must constraint for a private key, which is fine for the purpose of this grouping.  But do you see a case where other YANG modules might want to pick up using the schema definition of public key and the various key algorithm identities defined?  Maybe for someone who just wants to store decryption keys?  If yes, perhaps an extra grouping definition?

<Kent> Potentially.  If I understand you correctly, the public-key-only grouping wouldn't be used in any current modules (e.g., in the keystore module), but merely be available for anyone who might want just a public-key in the future?

<Eric2>  Yes.  As your module is being designed for such reuse already, it would seem a natural extension at low cost.

<Eric3>  Based on the set of discussions, I support adoption.  This is worthwhile topic for the WG.


Kent // contributor