Re: [netconf] crypto-types and keystore comments

Kent Watsen <> Thu, 14 November 2019 13:40 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6C6CF1200EC for <>; Thu, 14 Nov 2019 05:40:44 -0800 (PST)
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 DqBMdBrj1R1p for <>; Thu, 14 Nov 2019 05:40:42 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6CA9F1200E5 for <>; Thu, 14 Nov 2019 05:40:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw;; t=1573738840; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=TNupkwAGfPNj1lR46+MsPOpffk8eF0wyR51P/4wwO8o=; b=FINAlzKVrn+xJD+XBqbeauJD7c56AEx8v7a1EaiPpya/SSzzxz0QLvhvuiBEiB1z 6Dfzr/ekj27cCP0UXio02/NvVDpl3tJnOD7payRVlQXRO5Qu94NAI1v5Hh+omWrDych pPACIuIv5XJWQlFnDT8kqq3gVTM+XkuAFURS3seg=
From: Kent Watsen <>
Message-ID: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_2B78E6D6-B382-4C1A-9729-91711F7EA2B1"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Thu, 14 Nov 2019 13:40:40 +0000
In-Reply-To: <>
Cc: "" <>
To: Martin Bjorklund <>
References: <> <> <> <>
X-Mailer: Apple Mail (2.3445.104.11)
X-SES-Outgoing: 2019.11.14-
Archived-At: <>
Subject: Re: [netconf] crypto-types and keystore comments
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: Thu, 14 Nov 2019 13:40:44 -0000

Hi Martin,

>> The issue presents itself when configuring the "server-identity" in
>> ietf-ssh-server, whether a local definition or a reference to a key in
>> the keystore.  A "must" expression could be used to constrain the
>> supported key-formats allowed.  Our modules could hardcode this for
>> all implementations
> Ok.  This is worth exploring imo.

I added FIXME comments into all of ietf-[ssh/tls]-[client/server].

>>> You're using a normal config false list for this (which is fine), but
>>> I don't think you can use a single global list like this.
>> I don't understand this statement.
> My point is really just that a single global list like this is not
> sufficient.   It doesn't matter if "feature" has problems; a single
> global config false list is not sufficient for what you're trying to
> do.

True.  But how can we define a way to get a list per instance?  Should there be a "config false" list wherever the "algorithm" node appears (i.e., put the list into the crypto-type groupings having the algorithm node?)

>> Not true or, rather, the intention is to support native encoding
>> formats, including DER vs PEM, and CMS vs multi-part PEM.
> But that would be different key-format identities, right?  

I think so, yes.

> The issue
> here is about what the specfic format is for ssh-public-key-format.
> The format I suggest is also already used in RFC 7317, as was pointed
> out before by someone else.

That is the binary encoding for the on-the-wire public key.  Yes, for the binary encoding, this is a great option.  But I thought a goal was to try to use native tool formats when possible.  Not that we want to hardcode to OpenSSH, but `man ssh-keygen`:

     -m key_format
             Specify a key format for the -i (import) or -e (export)
              conversion options.  The supported key formats are:
              ``RFC4716'' (RFC 4716/SSH2 public or private key),
              ``PKCS8'' (PEM PKCS8 public key) or ``PEM'' (PEM
              public key).  The default conversion format is
              ``RFC4716''.  Setting a format of ``PEM'' when
              generating or updating a supported private key
              type will cause the key to be stored in the legacy
              PEM private key format.

>>>> That said, if you refer to the link I provided at top, it is my belief
>>>> that the "key-format" node may be extended to support alternate
>>>> encodings (e.g., DER vs PEM and, potentially, CMS vs multi-part PEM).
>>>> To this end, perhaps we could support both the 4716 and 4253 formats.
>>> Do we really want to go there?  This is already quite complex, and
>>> having a multitude of optional formats for the same thing may make
>>> things even more complex, to understand and get right.
>> Binary formats (e.g., DER) are fundamental, but some raised usability
>> concerns
> Do you have a pointer to this?

There was an email from Juergen a few months back.

>> , hence the exploration.  As for complexity, how do we know
>> until we try?
> I think we _are_ trying now...

Fair, but there's yet to be a concrete proposal for how to support, e.g., multi-part PEM encoding and, in particular, how it is distinguished from the PEM encoding of the equivalent CMS.  Presumably it's just another identity, but there maybe more to it...

Kent // contributor