Re: What ASN.1 got right

Nico Williams <nico@cryptonector.com> Wed, 03 March 2021 00:23 UTC

Return-Path: <nico@cryptonector.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FB5F3A14FE for <ietf@ietfa.amsl.com>; Tue, 2 Mar 2021 16:23:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.101
X-Spam-Level:
X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.com
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 g7gMpK4ybUHr for <ietf@ietfa.amsl.com>; Tue, 2 Mar 2021 16:23:39 -0800 (PST)
Received: from hedgehog.birch.relay.mailchannels.net (hedgehog.birch.relay.mailchannels.net [23.83.209.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1074B3A14FD for <ietf@ietf.org>; Tue, 2 Mar 2021 16:23:38 -0800 (PST)
X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com
Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 0B15C541D70; Wed, 3 Mar 2021 00:23:38 +0000 (UTC)
Received: from pdx1-sub0-mail-a14.g.dreamhost.com (100-96-16-25.trex.outbound.svc.cluster.local [100.96.16.25]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 8C97D541D1F; Wed, 3 Mar 2021 00:23:37 +0000 (UTC)
X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com
Received: from pdx1-sub0-mail-a14.g.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384) by 100.96.16.25 (trex/6.0.2); Wed, 03 Mar 2021 00:23:37 +0000
X-MC-Relay: Neutral
X-MailChannels-SenderId: dreamhost|x-authsender|nico@cryptonector.com
X-MailChannels-Auth-Id: dreamhost
X-Blushing-Broad: 22ff7e9d65082e78_1614731017827_3625600286
X-MC-Loop-Signature: 1614731017827:3642515171
X-MC-Ingress-Time: 1614731017827
Received: from pdx1-sub0-mail-a14.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a14.g.dreamhost.com (Postfix) with ESMTP id 510227E3D5; Tue, 2 Mar 2021 16:23:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=R9ZiLBMGWaZGMA 6ojrmtG/aldHI=; b=izGeZeAEWr2mPbowJm3oQX6eBF9weFQxsq7lgzii8tJDbB 1zfs7Cf+27ALbF3W2ZUrPym+DTtVPheXHMvSUjFaseFJJoBFx0R6qJMBC1YAsyIp adLDdTLJwJEJuoC7kBGJgGQxMq3NZruuZpDm9JMyoawozuNIccsKeU5lcavlg=
Received: from localhost (unknown [24.28.108.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by pdx1-sub0-mail-a14.g.dreamhost.com (Postfix) with ESMTPSA id 072517E3D7; Tue, 2 Mar 2021 16:23:33 -0800 (PST)
Date: Tue, 02 Mar 2021 18:23:31 -0600
X-DH-BACKEND: pdx1-sub0-mail-a14
From: Nico Williams <nico@cryptonector.com>
To: Michael Thomas <mike@mtcc.com>
Cc: Phillip Hallam-Baker <phill@hallambaker.com>, IETF Discussion Mailing List <ietf@ietf.org>
Subject: Re: What ASN.1 got right
Message-ID: <20210303002330.GZ30153@localhost>
References: <a584ff73-34ae-1c9e-e746-ce98749461d7@mtcc.com> <20210302183901.GV30153@localhost> <CAMm+Lwj8QwuqaA3f625Ui8arc0TxY3uLXbG-PKToWGdtq8az6w@mail.gmail.com> <613072c6-5518-91e3-41b9-3b7590ee2346@mtcc.com> <CAMm+LwiEqL3bMg09e5NBNZwkPJ90DmQgLTy=SQNEN0q=vp=wrQ@mail.gmail.com> <ed6830b3-e650-d3fa-b253-9f53e01f9615@mtcc.com> <CAMm+LwifpPg-Sg9cXLpWvjmExt8KfuYq6oRZd4D1L0ZBR3nRFg@mail.gmail.com> <1631e20d-9d8a-b8c2-9d5e-6c7f4defa72d@mtcc.com> <20210302234928.GX30153@localhost> <cb4960e2-05a1-9d28-f17b-9f610ac378c9@mtcc.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <cb4960e2-05a1-9d28-f17b-9f610ac378c9@mtcc.com>
User-Agent: Mutt/1.9.4 (2018-02-28)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/yG54t0HDGUY1gw1kIX78X0yeUeY>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 03 Mar 2021 00:23:41 -0000

On Tue, Mar 02, 2021 at 04:17:28PM -0800, Michael Thomas wrote:
> > Now, maybe you have something different in mind.
> 
> I'm talking about the server side sshd just fetching the associated ssh keys
> with the user trying to log in, maybe with some authz sprinkled in for finer
> granularity. It could be LDAP, it could whatever you want. I don't know how
> configurable sshd is, so that might limit your choices.

I wouldn't want to do this.  It's much more complex than the client
sending a certificate.

And getting their public key(s) (they will almost certainly have more
than one, and many ephemeral) into the directory is the equivalent of
getting a certificate issued.  So you're not saving anything, and you're
adding complexity, and if you're using LDAP you're not even getting rid
of x.500 or ASN.1.

> I'm just using LDAP as an example of a well known corpro directory. It could
> be anything. It just needs to be something online that can store the name
> public key(s) binding so that the sshd can see if they should allow that
> user/key to log in.

It can't be anything.  It has to be standard-enough.

> > The client is also a relying party though, since it has to authenticate
> > the server.
>
> If you care about that, I suppose. I think most people do the leap of faith
> and known_hosts ignores the problem.

I very much care about that.  Certainly in a corporate network.

> I don't see how doing nothing at all on the client can be "infinitely
> easier" than doing a lot of something else. [...]

It's not nothing.  New keys?  Update the directory.  Same complexity as
getting keys certified, only worse because the online CA only needs to
be online when you want new keys / certs, but the directory has to be
online any time you want to use those keys.

> Is anybody using PKINIT?

Yes.

Nico
--