[netconf] crypto-types and keystore comments

Martin Bjorklund <mbj@tail-f.com> Wed, 13 November 2019 12:57 UTC

Return-Path: <mbj@tail-f.com>
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id E8F4C1208C1 for <netconf@ietfa.amsl.com>; Wed, 13 Nov 2019 04:57:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id rUeqm5WjJ39f for <netconf@ietfa.amsl.com>; Wed, 13 Nov 2019 04:57:22 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com []) by ietfa.amsl.com (Postfix) with ESMTP id 19C2E1208A9 for <netconf@ietf.org>; Wed, 13 Nov 2019 04:57:22 -0800 (PST)
Received: from localhost (unknown []) by mail.tail-f.com (Postfix) with ESMTPSA id EF1EF1AE018B for <netconf@ietf.org>; Wed, 13 Nov 2019 13:57:19 +0100 (CET)
Date: Wed, 13 Nov 2019 13:56:49 +0100 (CET)
Message-Id: <20191113.135649.2218807015240802033.mbj@tail-f.com>
To: netconf@ietf.org
From: Martin Bjorklund <mbj@tail-f.com>
X-Mailer: Mew version 6.8 on Emacs 25.2
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/ryFSEGxlEZjsUY36Dki7HllSpKA>
Subject: [netconf] crypto-types and keystore comments
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: Wed, 13 Nov 2019 12:57:24 -0000


I have some comments on draft-ietf-netconf-crypto-types-12 and

o  Is the key-format there to support multiple formats for the same
   kind of key (e.g., ssh key), or is it there to be able to have
   different kinds of keys in the same list?  (Or both?)

   I.e., is the intentation that a client can freely pick any
   private-key-format (that is supported by the server), regardless of
   how the key is used?

o  One idea that was floating around was to have separate keystore
   lists for different things (see the ML archives, e.g. some mails in
   the thread "crypto-types fallback strategy").  I.e. instead of the

   +--rw keystore
      +--rw asymmetric-keys
      |  +--rw asymmetric-key* [name]

   we would have something like:

   +--rw keystores
      +--rw ssh-keystore
      |  ...
      +--rw tls-keystore  // x509-keystore?

   If we don't have to support multiple formats for the same kind
   of key, I don't think we need the key-format in this case.

   With the current design it is not obvious to me how I can find all
   ssh keys, for example.

   This said, *if* we use a single generic list, I think the list in
   the current model works fine.  It is a bit complicated, but some
   complexity is inevitable with a generic model like this.

o   iana- modules

  The iana modules have a list of supported algorithms, e.g.:

       list supported-asymmetric-algorithm

  I mentioned this before - I don't think a global list like this is
  sufficient.  For example, perhaps my TLS code supports "secp521r1",
  but my SSH code does not.

And some random small things I noticed:

o  ssh-public-key-format

  The crypto model has:

    identity ssh-public-key-formatp {
      base "public-key-format";
        "The public key format described by RFC 4716.";

  I think that this should be:

      "The binary public key data for an SSH key, as
       specified by RFC 4253, Section 6.6, i.e.:

         string    certificate or public key format
         byte[n]   key/certificate data.";
      "RFC 4253: The Secure Shell (SSH) Transport Layer

  Note that the public key format in 4716 is textual:

    ---- BEGIN SSH2 PUBLIC KEY ----
    Header-tag ':' ' ' Header-value
    ---- END SSH2 PUBLIC KEY ----

  Where BODY is:

   The body of a public key file is the base64 encoded ([RFC2045])
   public key data as specified by [RFC4253], Section 6.6:

         string    certificate or public key format identifier
         byte[n]   key/certificate data

  So with your current definition we would take this textual format
  (that has the key base64-encoded), and base64 encode the whole
  thing (includign the already base64-encoded key).

o  subject-public-key-info-format

  The crypto model has:

    identity subject-public-key-info-format {
      base "public-key-format";
        "A SubjectPublicKeyInfo (from RFC 5280).";

  Should this be "DER encoded"?

  (this and other defintions have references to RFCs in the
  description; they should be moved to proper "reference" statements)

o  iana-hash-algs

  This module has a bunch of shake-*:

      enum shake-224 {
        value 7;
          "The SHA3 algorithm with 224-bits output.";

  I think this should be "sha3-224" etc.

  (there are just two shake hash functions defined; shake 128 & 256,
  and they have variable output)

  (and BTW, FIPS PUB 202 doesn't define sha3-128)