Re: [netconf] crypto-types and keystore comments

Martin Bjorklund <mbj@tail-f.com> Thu, 14 November 2019 13:02 UTC

Return-Path: <mbj@tail-f.com>
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 0384F12012E for <netconf@ietfa.amsl.com>; Thu, 14 Nov 2019 05:02:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y1GwZy_RuKoO for <netconf@ietfa.amsl.com>; Thu, 14 Nov 2019 05:02:07 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 4A77412001A for <netconf@ietf.org>; Thu, 14 Nov 2019 05:02:07 -0800 (PST)
Received: from localhost (unknown [173.38.220.41]) by mail.tail-f.com (Postfix) with ESMTPSA id DEC011AE0312; Thu, 14 Nov 2019 14:02:05 +0100 (CET)
Date: Thu, 14 Nov 2019 14:01:35 +0100 (CET)
Message-Id: <20191114.140135.2027227966816173737.mbj@tail-f.com>
To: kent+ietf@watsen.net
Cc: netconf@ietf.org
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <0100016e69e99e3c-893fbfb4-3dc8-4725-b7ef-87bbf491dc2c-000000@email.amazonses.com>
References: <0100016e66c9b02d-382d9d6e-6d88-47ec-a117-5f38a3699fb1-000000@email.amazonses.com> <20191114.100558.1371995383202419404.mbj@tail-f.com> <0100016e69e99e3c-893fbfb4-3dc8-4725-b7ef-87bbf491dc2c-000000@email.amazonses.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/KHzntu9MHtm8J1m2rtBu8F2v2ig>
Subject: Re: [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: Thu, 14 Nov 2019 13:02:09 -0000

Kent Watsen <kent+ietf@watsen.net> wrote:
> Hi Martin,
> 
> 
> > Suppose I want to configure a ssh host-key as the server-identity for
> > my NETCONF server.  Is the intention that a client can pick either
> > "ssh-public-key-format" or "subject-public-key-info-format", and the
> > server must support both?
> 
> It's assumed that the client would set the public key using
> "ssh-public-key-format" (per RFC 4716, as that is the only
> standards-based public key format that `openssh` is able to export).
> While it's possible to convert the public key to a
> SubjectPublicKeyInfo structure, doing so is unlikely.  In either case,
> the same data is conveyed.
> 
> 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.

> or, if wanting to provide flexibility, we could
> let implementations augment-in their own 'must' expression.
> 
> 
> 
> >> Yes, well, this is a known problem (e.g.,
> >> https://github.com/netmod-wg/yang-next/issues/82
> >> <https://github.com/netmod-wg/yang-next/issues/82>).
> > 
> > That is quite different.
> 
> How so?  Features are effectively opstate lists too and, in both
> cases, YANG fails to support granular discrimination.
> 
> > 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.

> >> I will say that the definition above was given because it is the only
> >> *standards* based key that `openssh` can output (i.e., `ssh-keygen -e
> >> [-m RFC4716] -f <private-key-file>`).
> > 
> > With my proposal you can take the output of this openssh command and
> > copy & paste the base64-encoded data from this output to a YANG node
> > using ssh-public-key-format.
> > 
> > With your proposal you have to copy the entire output, base64 encode
> > it *again*, and then copy & paste that result to the YANG 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?  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 a
> text-based format is base64 encoded is not an issue and, IMO, a
> feature as it escaping concerns when the content is placed in an XML
> or JSON document.
> 
> 
> 
> >> 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?

> , hence the exploration.  As for complexity, how do we know
> until we try?

I think we _are_ trying now...


/martin



> >>> o  subject-public-key-info-format
> >>> 
> >>> The crypto model has:
> >>> 
> >>>   identity subject-public-key-info-format {
> >>>     base "public-key-format";
> >>>     description
> >>>       "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)
> >> 
> >> Yes.  I put together these definitions in as a test/protocol to gauge
> >> viability with the plan to enhance the definitions if the WG committed
> >> to the approach.  I just added some "FIXME" comments to my local copy.
> > 
> > Ok.
> 
> It helps immensely when folks can provide spec-text, either on list or
> as a pull request.
> 
> 
> 
> Kent // contributor
> 
>