Re: [netmod] SSH keys - draft-ietf-netmod-system-mgmt

nisse@lysator.liu.se (Niels Möller ) Wed, 30 April 2014 06:49 UTC

Return-Path: <nisse@lysator.liu.se>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16FBB1A6EE8 for <netmod@ietfa.amsl.com>; Tue, 29 Apr 2014 23:49:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.122
X-Spam-Level:
X-Spam-Status: No, score=-1.122 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.651, SPF_NEUTRAL=0.779] autolearn=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 JglrAgS8UJ4d for <netmod@ietfa.amsl.com>; Tue, 29 Apr 2014 23:49:14 -0700 (PDT)
Received: from bacon.lysator.liu.se (bacon.lysator.liu.se [IPv6:2001:6b0:17:f0a0::ce]) by ietfa.amsl.com (Postfix) with ESMTP id A9CC31A6EEE for <netmod@ietf.org>; Tue, 29 Apr 2014 23:49:10 -0700 (PDT)
Received: from bacon.lysator.liu.se (localhost [127.0.0.1]) by bacon.lysator.liu.se (8.14.5+Sun/8.14.5) with ESMTP id s3U6n732024476; Wed, 30 Apr 2014 08:49:07 +0200 (MEST)
Received: (from nisse@localhost) by bacon.lysator.liu.se (8.14.5+Sun/8.14.5/Submit) id s3U6n6ZQ024475; Wed, 30 Apr 2014 08:49:06 +0200 (MEST)
X-Authentication-Warning: bacon.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f
From: nisse@lysator.liu.se
To: Martin Bjorklund <mbj@tail-f.com>
References: <20140429.220505.221212226.mbj@tail-f.com>
Date: Wed, 30 Apr 2014 08:49:06 +0200
In-Reply-To: <20140429.220505.221212226.mbj@tail-f.com> (Martin Bjorklund's message of "Tue, 29 Apr 2014 22:05:05 +0200 (CEST)")
Message-ID: <nnlhunqplp.fsf@bacon.lysator.liu.se>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (usg-unix-v)
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/Jf4ahKtzaaLhgO1LIhbGMM0WPxY
X-Mailman-Approved-At: Tue, 29 Apr 2014 23:54:03 -0700
Cc: ietf-ssh@NetBSD.org, netmod@ietf.org
Subject: Re: [netmod] SSH keys - draft-ietf-netmod-system-mgmt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 30 Apr 2014 06:49:16 -0000

Martin Bjorklund <mbj@tail-f.com> writes:

> 1)  Clarify that the leaf "key-data" contains:
>
>          string    certificate or public key format identifier
>          byte[n]   key/certificate data
>
>     This allows for simple copy-and-paste from normal open ssh and
>     rfc4716 files.
>
>     However, if we also keep the leaf algorithm, we need to specify
>     what happens if the leaf algorithm has a value that is different
>     from the value embedded in the key blob.

Right, eliminating this redundancy makes things simpler.

> 2)  Like 1, but remove the "leaf algorithm".

I'm not sure I understand the context, but this sounds like the best
option to me. If one wants a human-readable algorithm identifier, one
could include that in the name field (but ideally, any tools handling
this data should be able to extract the algorithm id from the key blob).

> 3)  Keep "leaf algorithm" and specify that the leaf "key-data" contains:
>
>          byte[n]   key/certificate data
>
>     This is NOT copy-and-paste friendly and probably pretty
>     confusing to operators.

I would recommend *not* picking apart the ssh key (unless you really
want to convert it to some other reasonable representation, say, an
spki-style s-expression).

> Some other issues, probably less important.
>
> o  If we do 1 or 2 above, is the name "key-data" really correct;
>    shouldn't it be changed to just "key", in order to use the same
>    terminology as RFC 4253:

Makes sense.

> o  Should list "ssh-key" be called "ssh-public-key"?
>
>    The description says it is public keys only, so shouldn't this be
>    reflected in the name of the list?

I think it would make more sense to have a name that reflects the
*purpose* of the list of keys, rather than just the data type. E.g., if
it's authorization keys for logging in to the users account, it could be
"authorized-ssh-keys" or something like that.

Regards,
/Niels

-- 
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.