Re: [netconf] I-D Action: draft-ietf-netconf-crypto-types-09.txt

Kent Watsen <kent+ietf@watsen.net> Thu, 27 June 2019 00:05 UTC

Return-Path: <0100016b9640a87c-b6e29e8c-0db0-4f15-bb58-887fc48c81d0-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 4DE5C120164 for <netconf@ietfa.amsl.com>; Wed, 26 Jun 2019 17:05:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 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, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=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 oRNUUsfk0ugO for <netconf@ietfa.amsl.com>; Wed, 26 Jun 2019 17:05:49 -0700 (PDT)
Received: from a8-31.smtp-out.amazonses.com (a8-31.smtp-out.amazonses.com [54.240.8.31]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A70D412007A for <netconf@ietf.org>; Wed, 26 Jun 2019 17:05:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1561593948; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=atm5ZOD6hzYJSq73Gq3HWzSr1SYOvekMH/4IPExt9T8=; b=KYL1kYmZV8aHD401B7XCB+gfq59JN+vzYtC6b5Aq1qbSY+ViQvPGlO9EiEa1Qrov jXE4o+UAiq9WI+vCtcVeJzLMhuXX3aLVNmuPG1o7JE3JUeGfeK5w2u4HkqRnJTMZbKS TLc7svPpfEJUmBY0GUYRmiF1aUNn5eJ/hXftpEv0=
From: Kent Watsen <kent+ietf@watsen.net>
Message-ID: <0100016b9640a87c-b6e29e8c-0db0-4f15-bb58-887fc48c81d0-000000@email.amazonses.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_6EBD5D1E-72A1-4EFC-967E-5AFDD1EB6AA2"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Thu, 27 Jun 2019 00:05:48 +0000
In-Reply-To: <20190625.224243.332607515244909664.mbj@tail-f.com>
Cc: frank.xialiang@huawei.com, "netconf@ietf.org" <netconf@ietf.org>
To: Martin Bjorklund <mbj@tail-f.com>
References: <C02846B1344F344EB4FAA6FA7AF481F13E7B118B@dggemm511-mbx.china.huawei.com> <20190625.084508.905200182299290020.mbj@tail-f.com> <0100016b8f701d10-02dff612-5c5f-4ed3-938d-8b9f25679996-000000@email.amazonses.com> <20190625.224243.332607515244909664.mbj@tail-f.com>
X-Mailer: Apple Mail (2.3445.104.11)
X-SES-Outgoing: 2019.06.27-54.240.8.31
Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/JJay4zcHKsWLKgMZs8qR6orldPA>
Subject: Re: [netconf] I-D Action: draft-ietf-netconf-crypto-types-09.txt
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: Thu, 27 Jun 2019 00:05:51 -0000

Hi Martin,

>> 4) to enable the SSH and TLS models to use types defined in their
>> protocol specs, mapping tables were added to those drafts to map the
>> protocol-specific types to the generic crypto-types type.
> 
> So perhaps this is not the best solution?  The big set of types (in
> crypto-types) will change over time, and the subsets used in various
> applications will also change over time.  The best solution for such
> sets in the IETF seems to be IANA registries, with corresponding
> IANA-maintained YANG modules.

I'm hoping someone, perhaps my co-authors, can suggest a path forward.



>> 8) our efforts to normalize this may be futile, and yet we want to
>> support keystore.
> 
> Perhaps we can take a step back and define just the types we need
> right now for keystore, in order to finish these drafts.  Then we (or
> some other WG) can immediately start to work on an update to
> crypto-types that would define more types for other purposes as well.

Maybe, depending on how that turns out, it may be trivial to extend the approach to cover everything.


Kent // contributor