Re: What ASN.1 got right

Nico Williams <> Tue, 02 March 2021 18:55 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 758DA3A0CDC for <>; Tue, 2 Mar 2021 10:55:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -7.1
X-Spam-Status: No, score=-7.1 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_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id JaFT5u4CLgln for <>; Tue, 2 Mar 2021 10:55:26 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6471A3A0CDA for <>; Tue, 2 Mar 2021 10:55:26 -0800 (PST)
X-Sender-Id: dreamhost|x-authsender|
Received: from (localhost []) by (Postfix) with ESMTP id 085AE482812; Tue, 2 Mar 2021 18:55:24 +0000 (UTC)
Received: from (100-98-118-122.trex.outbound.svc.cluster.local []) (Authenticated sender: dreamhost) by (Postfix) with ESMTPA id 6ED2B4827D8; Tue, 2 Mar 2021 18:55:23 +0000 (UTC)
X-Sender-Id: dreamhost|x-authsender|
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384) by (trex/6.0.2); Tue, 02 Mar 2021 18:55:23 +0000
X-MC-Relay: Neutral
X-MailChannels-SenderId: dreamhost|x-authsender|
X-MailChannels-Auth-Id: dreamhost
X-Wiry-Bored: 06cd89651f4b1b2a_1614711323792_2684150585
X-MC-Loop-Signature: 1614711323791:1566504574
X-MC-Ingress-Time: 1614711323791
Received: from (localhost []) by (Postfix) with ESMTP id F40BE8702E; Tue, 2 Mar 2021 10:55:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed;; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to;; bh=WCS5UrNXD0M7eJ 5Diawhl1L4tjs=; b=kVhMPD6oeMMMFs6nuiX2kgpstD0IrBLm448sKJUw9GzwNT ZQ6UFP+lJzImLYKBSpdUUM+EJSAfnVExrKA8XwPFBc3ACNYvnvDv3KVok4DbHmdC qvJsLMT32293jciqbuaqSYMYCIu9NXn5nFThmgOg73OgbHYtzax5WSOkZymXo=
Received: from localhost (unknown []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: by (Postfix) with ESMTPSA id 56B968702C; Tue, 2 Mar 2021 10:55:20 -0800 (PST)
Date: Tue, 2 Mar 2021 12:55:17 -0600
X-DH-BACKEND: pdx1-sub0-mail-a13
From: Nico Williams <>
To: Michael Thomas <>
Cc: Phillip Hallam-Baker <>, IETF Discussion Mailing List <>
Subject: Re: What ASN.1 got right
Message-ID: <20210302185515.GW30153@localhost>
References: <20210302010731.GL30153@localhost> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.9.4 (2018-02-28)
Archived-At: <>
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 02 Mar 2021 18:55:28 -0000

On Tue, Mar 02, 2021 at 10:38:15AM -0800, Michael Thomas wrote:
> TLS is water under the bridge. We got the mess of disjoint trust anchors and
> who should be trustworthy or not, but somehow it mostly works. My beef is
> with the collateral damage of that choice. ASN.1 instantly makes figuring
> out what's going on much harder. Instead of more(1) I have to do some arcane
> openssl incantation to view the contents of a certificate. And instead of
> just directly using a public key to bind to an identity, I have to figure
> out how and what CA to issue a certificate, blah blah blah, instantly making
> a simple concept far, far harder. And don't even get me started on business
> models.

Yes, which is why I put some effort into automatic open type handling.
I can now get a pretty JSON view of a certificate, with all Extensions,
all Attributes, all RDNs, all GeneralName alternatives (well, ok, I've
not implemented X.400 naming, and I won't), all SANs, everything decoded

> Look at the complexity difference between DKIM vs. STIR which are doing
> approximately the same thing (or at least should be). I would say that part
> of STIR's failing is that they got sucked down the X.509 rathole requiring
> special root CA's so they could assert things about e.164 addresses instead
> of doing the far more obvious thing that DKIM did which was to assign
> responsibility for messages to the domains sending them. It's not directly
> X.509's fault they solved the wrong problem, but it absolutely didn't help
> because it set up the mindset where solving the wrong problem seemed like a
> tractable problem when in fact it is not.

It's possible, yes, but this is why it's important to understand the
technology one picks.  TCG, for example, picked PKIX then they created
non-string-valued attributes (%^&@!).  Tools are just that, and you can
always misuse the right tools, or pick the wrong tools to begin with.

That's why my post ended with an imploration to know what came before
before one goes around reinventing the darned thing.

Since this sub-thread is devolving into what went wrong with x.509,
maybe we should also look at what went right, and about the only things
I can think went right was:

 - that it got extended to support arbitrary naming forms,
 - EKUs,
 - and that PKIX usage is evolving towards short-lived certificates to
   avoid dealing with revocation.

Also, having end entities send their certificate chain.  RPs simply
can't construct validation chains from just EE certs, and it was always
pure fantasy that they could, just as public X.500 DAP / LDAP
directories full of private information made public was always a 1980s
naive fantasy.  Ah, the naive 80s, before the Morris worm, before spam,
back when the only people on the Internet were professors, grad
students, and the military.