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

Kent Watsen <> Tue, 25 June 2019 16:20 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4D1AB1207A6 for <>; Tue, 25 Jun 2019 09:20:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Status: No, score=-1.897 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] 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 IbWbIZpVMVzy for <>; Tue, 25 Jun 2019 09:20:22 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 655F31207A5 for <>; Tue, 25 Jun 2019 09:20:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw;; t=1561479617; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=u5/Uws38099AqkaQ8W0VpGMOwmQ5xHSvDIbQIXsWpgA=; b=MUo5YfDXTvK7aIvEQQMG3oZfLE6Tf3iy0Bo0Duxyqhv8r7pZGfBaw3uZmsV9ytqi I00AgV1K8UByHbDdJPypdg0X9KTlHmO9BBaT868scHTB7t8HNO3tIu1yDA9m9SyLDG4 EylkBXxyBolCoTHSuCjUhARlNaDGLRYO39uM+4to=
From: Kent Watsen <>
Message-ID: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_AF60F449-15F1-42F5-8F5A-BDC45CC62200"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Tue, 25 Jun 2019 16:20:17 +0000
In-Reply-To: <>
Cc:, "" <>
To: Martin Bjorklund <>
References: <> <> <> <>
X-Mailer: Apple Mail (2.3445.104.11)
X-SES-Outgoing: 2019.06.25-
Archived-At: <>
Subject: Re: [netconf] I-D Action: draft-ietf-netconf-crypto-types-09.txt
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 25 Jun 2019 16:20:24 -0000

> So, to start with, for each of the types in the crypto module, could
> you specify the link to the corresponding IANA registry?

Yes, please send out the links so we have more clue...

To take a step back, my perception for how we got here is thus:

1) the keystore draft wishes to store keys (perhaps created at the time of manufacturing) that can subsequently be referenced by downstream models, such as in the SSH and TLS client/server drafts.

2) to support this goal, the crypto-types draft defined some types for keys (first as identities, now as enumerations).

3) crypto savvy folks wanted to embrace and extend the definitions in crypto-types to be more complete (i.e., more then just keys)

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.

5) the IPsec folks now have a similar problem, to which the answer might be to do the same as the SSH and TLS drafts (i.e., define mappings from IPSec-specific types to crypto-types types)

6) the general underlying issue is likely exasperated by the crypto-types draft defining more types than needed for just keys (i.e., the more it tries to support, the more mapping tables are needed), albeit this in itself seems like a good thing.

7) it's unclear to me where the root cause of the problem lies.  It seems that the crypto folks may have instigated this long ago, by creating overlapping definitions for identical algorithms, which then manifested in the form of multiple IANA registries.

8) our efforts to normalize this may be futile, and yet we want to support keystore.

Please correct any misstatements, as I'm speculating on some of the above.

Thinking out of the box, if we were to fold on crypto-types defining algorithms, perhaps keystore could store instances of something like an abstract base class that is subclassed by downstream modules (ssh, tls, ipsec).  The problem with this approach is that the keys become purpose-specific and so, e.g., if a device has a manufacturer-generated key, that key could only be used for the single purpose (e.g., TLS) and not for any other purpose (e.g., SSH, IPSec, etc.).  Sure, the vendor could create key multiple purpose-specific "keys" for the same underlying key store in hardware, but it would ultimately fail to support any purpose, potentially defined later in time.

Kent // contributor