Re: What ASN.1 got right

Nico Williams <nico@cryptonector.com> Tue, 02 March 2021 23:49 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 7A1C13A1485 for <ietf@ietfa.amsl.com>; Tue, 2 Mar 2021 15:49:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.119
X-Spam-Level:
X-Spam-Status: No, score=-2.119 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_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 kLpSIOm9om1I for <ietf@ietfa.amsl.com>; Tue, 2 Mar 2021 15:49:35 -0800 (PST)
Received: from earwig.apple.relay.mailchannels.net (earwig.apple.relay.mailchannels.net [23.83.208.54]) (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 41EAB3A1484 for <ietf@ietf.org>; Tue, 2 Mar 2021 15:49:35 -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 199C5342933; Tue, 2 Mar 2021 23:49:34 +0000 (UTC)
Received: from pdx1-sub0-mail-a14.g.dreamhost.com (100-96-11-30.trex.outbound.svc.cluster.local [100.96.11.30]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 9CBF5342881; Tue, 2 Mar 2021 23:49:33 +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.11.30 (trex/6.0.2); Tue, 02 Mar 2021 23:49:34 +0000
X-MC-Relay: Good
X-MailChannels-SenderId: dreamhost|x-authsender|nico@cryptonector.com
X-MailChannels-Auth-Id: dreamhost
X-Share-Attack: 16d31f942d5ead5a_1614728973911_607915660
X-MC-Loop-Signature: 1614728973911:2104654035
X-MC-Ingress-Time: 1614728973910
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 590297E6D9; Tue, 2 Mar 2021 15:49:33 -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=WbeVaGgcvI4pL0 uXkXdQmvHNA5g=; b=wGSUhhJkAheL3ltlJ4zGwI2GLxxQl8MS2HmbLdYky3GIhU LrYMzy29taWZuGmQU93NKOnbtY4CSqI/TXCIpF0r85rQdd6bAeBOyGoamCK3LJQo OELCHDWGHDnt4DGdfyNb+IRQJf7cM2bRo2sqbrdaETXc6SZRCznEmjNg8jgDY=
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 6ACBC7E3D1; Tue, 2 Mar 2021 15:49:31 -0800 (PST)
Date: Tue, 2 Mar 2021 17:49:29 -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: <20210302234928.GX30153@localhost>
References: <0632b948-9ed1-f2bd-96da-9922ebb2aa60@mtcc.com> <006750D4-B70D-44F8-A01A-BD3AB136D9D3@webweaving.org> <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>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1631e20d-9d8a-b8c2-9d5e-6c7f4defa72d@mtcc.com>
User-Agent: Mutt/1.9.4 (2018-02-28)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/YMY5jQM1tQbUq31_X5JsYiUuIps>
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: Tue, 02 Mar 2021 23:49:37 -0000

On Tue, Mar 02, 2021 at 03:23:24PM -0800, Michael Thomas wrote:
> So I just looked up ssh certificates which I think somebody mentioned. This
> is a prime example of throwing needless complexity at a problem. If you just
> added the user's public keys to, say, an LDAP repo, you get the scaling they

In the 80s the naive assumption was made that we'd have "white pages" --
directories -- where we could do such lookups.  I think that's what you
have in mind since you refer to an "LDAP repo".

That did not work, and cannot work because it has privacy issues, at
least when you do lookups _by name_.

Now, maybe you have something different in mind.

The authenticating party presents a directory name, a public key, and a
signature, and the RP looks up the key in the directory to get a name?

That might not have privacy issues, but it still requires online infra
that someone has to pay for, and that RPs need to contact (so they need
to do async I/O, naturally).  More things to break.

And, of course, LDAP is insanely complex and brings X.500 naming right
back into the picture completely unnecessarily (along with ASN.1,
naturally).

> claim to be solving for, and avoid all of the needless complexity of issuing
> certs and installing them on the client. The client ssh doesn't need to do
> anything different as bonus. With LDAP you get the added bonus that it can

The client is also a relying party though, since it has to authenticate
the server.

> dish out attributes for things like roles and permissions, which would be a
> giant headache if it had to be done with reissued certs every time your role
> or permission changed.

Certificates are infinitely easier.  Now, you mention "the needless
complexity of issuing certs and installing them on the [authenticating
party]".  But that's not so complex.  You can run an online CA that
issues short-lived client certificates based on a longer-lived
credential, and that and "installing" the certificates (and private
keys) are purely internal details that users shouldn't need to know.
That works for corporate networks, but it should work for a home network
too.  For a Mesh-like scheme you're really going to need long-lived
(forever) device public keys and revoke them only in the sense of
removing the public keys from Alice's other devices, and there is a
directory in Mesh case, but it's purely local (just Alice's devices,
which should be few enough that the whole thing scales fine).

> I'm trying to think of major things that use public key authentication.
> There's TLS with certs, DKIM using raw public keys, and SSH mainly using raw
> public keys. Am I missing anything else that is widely deployed? DNSsec and
> BGP are still pretty skimpy from what I can tell.

Kerberos, with PKINIT.  Mosh?  But note that SSH, TLS, and Kerberos (or,
rather, GSS-API) covers... a lot of protocols -- practically all
Internet protocols.

Nico
--