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

Mahesh Jethanandani <> Wed, 23 May 2018 12:50 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 41BD112DA6A for <>; Wed, 23 May 2018 05:50:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 2siW3C5FG68U for <>; Wed, 23 May 2018 05:50:41 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c0d::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A6EFF1200C5 for <>; Wed, 23 May 2018 05:50:41 -0700 (PDT)
Received: by with SMTP id h2-v6so27837863qtp.7 for <>; Wed, 23 May 2018 05:50:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=references:mime-version:in-reply-to:content-transfer-encoding :message-id:cc:from:subject:date:to; bh=1Nz1pZUNc3jWhhersgEfroIaeotyyaN7p/DGlVcnOiI=; b=hNYzBX4jUn6tQFkUCD0gYX4kn4veouc6srdjHrPOY1E9dsm7IIRuGRIs6l5p/k960S im7QX+8NIf3lFJm+2mDd1ZQal0umKYln8BB+0VwpLZQsQl7Sp9UW70xUEyV+XRnKHJtt 5R2r3Sug5rwSLve91NRbngkYfRvZHxPXmSNJ2/vTGO9ogsBgubGFjWUEfCQoBh/BgQAb nHo4U1PhnngDfyEC7DGIK/BOJyfpw7gtgdixD0yJ14ayCtubStsoC/q1OXHBQDy0hm3J aqO1HYqSLsKsezgy9Mu7bjwJqa2+fUV0l8ZZXGDw+YJftB9DZvioTm2dTzEQNl4IaAyI 5Lpw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:references:mime-version:in-reply-to :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=1Nz1pZUNc3jWhhersgEfroIaeotyyaN7p/DGlVcnOiI=; b=cL9uOogPdDMGFObfcqZjjNrDdWE6RLX/9t3IHYuqh+z8knxzf/txgYZrNlUJzrGPJs OXwFDXMGkF3pu/GGwVPtRCVr0H8GeVl+SVit57akdzuL2GOlfzXOx8/GDF5k3EcOoEPX R7Q+ASv3ao+GtTm10c7PdQVrkmZPOwBR8fUg7EkmQZc4oceGQu0kuD96wdKWpYq2b33H rqb3jKYa5ls2k5xJdA926VzTa83v++0WRBZ74ukwInbzb/8BZCbAmRqGcHb6/GiVFtmX sa+Dfpzar6LN7wxZ4rfICLR8l9nziigGq60tDtLfNmtUw82cl3i18vNyfjrJ3rxW5c44 6tig==
X-Gm-Message-State: ALKqPwf8GCmOqbhcoHyhVGRqsnJwC4i1Qg5e4118yAqxkW67q8xewCi4 Wj1kDRoNz/YzNp0WLnxNtAg=
X-Google-Smtp-Source: AB8JxZpwS+Sjazxyytvb2Mn07HN91+YSB2B5NWIp2Of1MBTJco8mtfr6t4dK/ceDPDGyVavaLHl5vQ==
X-Received: by 2002:a0c:a8e4:: with SMTP id h36-v6mr2262630qvc.99.1527079840626; Wed, 23 May 2018 05:50:40 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id h3-v6sm13919755qkf.86.2018. (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 23 May 2018 05:50:40 -0700 (PDT)
References: <> <> <> <> <> <> <>
Mime-Version: 1.0 (1.0)
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="Apple-Mail-2D87DAFB-CCF9-4602-B859-3FBEAAA2D391"
Content-Transfer-Encoding: 7bit
Message-Id: <>
X-Mailer: iPad Mail (13G36)
From: Mahesh Jethanandani <>
Date: Wed, 23 May 2018 08:50:38 -0400
To: "" <>
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:50:44 -0000

Based on the discussion till date, there seems to be support for bringing back -03 version of the ietf-keystore draft, while splitting the crypto-types and trust-anchors into their own modules/drafts.

With that, this closes the poll for adoption of the two new drafts. Kent, can you post the two new drafts as draft-ietf-netconf-crypto-types and draft-ietf-netconf-trust-anchors without changing any of the contents in the draft.

At the same time, please revert the draft-ietf-netconf-keystore draft to its -03 version, and (re)factor as needed, the SSH/TLS Client/Server drafts to use the new modules.


Mahesh Jethanandani

> On May 23, 2018, at 8:12 AM, Eric Voit (evoit) <> wrote:
> 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.
> Eric
> Eric
> Kent // contributor
> _______________________________________________
> Netconf mailing list