Re: What ASN.1 got right

Phillip Hallam-Baker <phill@hallambaker.com> Wed, 03 March 2021 02:18 UTC

Return-Path: <hallam@gmail.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 1D9F73A16B1 for <ietf@ietfa.amsl.com>; Tue, 2 Mar 2021 18:18:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.399
X-Spam-Level:
X-Spam-Status: No, score=-0.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, BIGNUM_EMAILS=1, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 qVwjY0oLssfb for <ietf@ietfa.amsl.com>; Tue, 2 Mar 2021 18:18:15 -0800 (PST)
Received: from mail-yb1-f179.google.com (mail-yb1-f179.google.com [209.85.219.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A247B3A1766 for <ietf@ietf.org>; Tue, 2 Mar 2021 18:18:07 -0800 (PST)
Received: by mail-yb1-f179.google.com with SMTP id u3so22882664ybk.6 for <ietf@ietf.org>; Tue, 02 Mar 2021 18:18:07 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=M+1ncX6Hw2zuJBZOh0qTXRPTxXxlVtFWAQQdCAHQVeo=; b=sk7nYCIJOtZ4cLzpMJrtvIjI5UUbM9+hrjYdphfU6JGNbTMf8rYcAqFlsGFSpArUju A3Eh27HuFAr7YeOUPs2a/EFGkdrqhu7H5U1t0K5lO/p21DQBkiNjKbCZ0AGjWXu31591 UFNRuFcUzh2ccBRF9F2vl3BvtJ6ncWa0ou0pE4VuYVx46GxFK6i6lWNKYFcuPWR6Bw6q cS9AbCJ07VnuHr7twoFsByCFWkE0eMN5UCrH/WsVI3Gt+DESTx9pnjHCl/DXWIx3oa3g zsPuamidjAZTTl/zbM40+d2m0cnwEmS1Pqhq2I02v9dcoHEJ/LmLo6PEDJ/vNR68MD87 gatA==
X-Gm-Message-State: AOAM530ipUsZMgRbMxyMGk5TkbjsoPXJi1TtLZ73kQlVLEiMVG1ZAQ5W OUq1E+U8yxmM6n3Y+fXM8rDt+Ej19B/Y6kwREm+JSBqTHMIL0w==
X-Google-Smtp-Source: ABdhPJx/zz2VAINSC0bou/f7caSmZb6G3PPLQJfP+J7Jy+/TcNUEcRf+7u8Umhh9EXw9vKXBf13WhTkD0DPC8idrYdI=
X-Received: by 2002:a25:2f43:: with SMTP id v64mr34472764ybv.302.1614737886686; Tue, 02 Mar 2021 18:18:06 -0800 (PST)
MIME-Version: 1.0
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> <20210302234928.GX30153@localhost> <CAKr6gn13eKWvS0meCs9MM-kCRsCD35CtH6_bsP5WeNbEnR7ing@mail.gmail.com> <fb9c261e-9ac0-aa4b-8817-d89b1142f1fc@huitema.net>
In-Reply-To: <fb9c261e-9ac0-aa4b-8817-d89b1142f1fc@huitema.net>
From: Phillip Hallam-Baker <phill@hallambaker.com>
Date: Tue, 2 Mar 2021 21:17:55 -0500
Message-ID: <CAMm+LwhNJRLshBnTT-D+StAuk6tB1tECLvY0_mcKrxU8DHATuQ@mail.gmail.com>
Subject: Re: What ASN.1 got right
To: Christian Huitema <huitema@huitema.net>
Cc: IETF Discussion Mailing List <ietf@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000002431a005bc987671"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/1DZqXEQF-sKkHD3r8ZafA9jwbWY>
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 02:18:17 -0000

On Tue, Mar 2, 2021 at 7:20 PM Christian Huitema <huitema@huitema.net>
wrote:

> On 3/2/2021 4:00 PM, George Michaelson wrote:
>
> > X.500 is complicated because names are complicated.
>
> Well, no. George, I worked on X.500 at the same time you did, and my
> conclusions are different. X.500 names main source of gratuitous
> complexity what that they embedded an arbitrary hierarchy. If I remember
> correctly, the name hierarchy in X.500 embedded things like country
> name, telecom company name, city, street, company (aka, organization),
> department (a.k.a., organization unit), maybe several levels of those,
> and then common name.
>

X.500 was designed to support X.400 email which was designed to replace
mail. So of course you would write out the postal address to send an email.
Email is mail right? Skendomorphism rulz.

DNS also suffers from gratuitous hierarchy but it is only one layer of
bogosity most of the time. There was never any logic to .com/.net/.edu it
was a naive taxonomy which has only worked for extracting rents. It worked
because it was only four redundant characters.

Names are simple, it is when people try to encode unnecessary assumptions
into them that it all collapses.

On Tue, Mar 2, 2021 at 6:23 PM Michael Thomas <mike@mtcc.com> wrote:

>
> On 3/2/21 2:27 PM, Phillip Hallam-Baker 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 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 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.
>
> 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.
>

Or you could use XKMS which is a W3C spec that does exactly that.

The peculiar thing about SSH certs is that they only exist for servers, not
for users. At least as far as I could see.