Re: What ASN.1 got right

Nico Williams <> Tue, 02 March 2021 04:56 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 66E8A3A1014 for <>; Mon, 1 Mar 2021 20:56:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Status: No, score=-2.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_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 uq_JJB347H8z for <>; Mon, 1 Mar 2021 20:56:08 -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 D2F633A1009 for <>; Mon, 1 Mar 2021 20:56:07 -0800 (PST)
X-Sender-Id: dreamhost|x-authsender|
Received: from (localhost []) by (Postfix) with ESMTP id 96B5C780997; Tue, 2 Mar 2021 04:56:06 +0000 (UTC)
Received: from (100-96-17-38.trex.outbound.svc.cluster.local []) (Authenticated sender: dreamhost) by (Postfix) with ESMTPA id 162CA780C67; Tue, 2 Mar 2021 04:56:06 +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 04:56:06 +0000
X-MC-Relay: Neutral
X-MailChannels-SenderId: dreamhost|x-authsender|
X-MailChannels-Auth-Id: dreamhost
X-Slimy-Abiding: 2d7e668837e1d184_1614660966391_4042751990
X-MC-Loop-Signature: 1614660966391:4013906512
X-MC-Ingress-Time: 1614660966391
Received: from (localhost []) by (Postfix) with ESMTP id BB4D78729B; Mon, 1 Mar 2021 20:56:05 -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:content-transfer-encoding; s=; bh=UgEGiU64obmvrmPaO0MowwjFz3A=; b=wWhVqs/qXJX N8Ub1P/qA8pXYeizvcmrKhpeNvLQWsWk6LGalwEjRYBewjbbLG0fjzlaErgpTYlo rukmtKX/YYM3L5Dm2GU++QEjnZACo5APLu6GjyZNU4c85l/KPH0BGNSsOEn3+nki k+jAZPlo/C4PKc+0snc5zCIEOTUOktAE=
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 AF9B585342; Mon, 1 Mar 2021 20:56:03 -0800 (PST)
Date: Mon, 1 Mar 2021 22:56:01 -0600
X-DH-BACKEND: pdx1-sub0-mail-a86
From: Nico Williams <>
To: Keith Moore <>
Subject: Re: What ASN.1 got right
Message-ID: <20210302045559.GO30153@localhost>
References: <20210302010731.GL30153@localhost> <04f601d70f04$404c5870$c0e50950$> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.9.4 (2018-02-28)
Content-Transfer-Encoding: quoted-printable
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 04:56:09 -0000

On Mon, Mar 01, 2021 at 11:09:31PM -0500, Keith Moore wrote:
> (wondering what brought up this subject... did someone decide that this is
> the week to rant about every past poor protocol design choice that we have
> to deal with?)

I had to deal with ugly things the TCG did, like creating non-string
directory attributes.  So I implemented automatic open type handling for
an ASN.1 compiler.  And now I can get beautiful JSON dumps of arbitrary
ASN.1 things.  And it wasn't very hard, and I wanted to thank Paul
Hoffman and Jim Schaad for RFC 5912.  And it made me think ASN.1 isn't
the awful think people make it out to be (but BER/DER/CER are).

> On 3/1/21 8:34 PM, Larry Masinter wrote:
> > Rich formalisms and separation of syntax and "encoding rules" seem
> > counter-productive.
> <soapbox>
> There's something I used to call "ASN.1 disease", but it applies equally to
> XDR, some uses of XML, and a lot of other systems used to define data
> structures used in communications.

Yes, well, and JSON too.  I got into jq precisely because I needed to
deal with overwrought structures in JSON.

And look, that TCG stuff I mentioned above?  Similar disease.  Yes, that
one involves ASN.1.

> The basic problem is that if you give people the ability to generate and
> require arbitrarily complex type-checked data structures, protocol designers
> will use that ability to create overly complex structures.   [...]

They have that ability regardless.

> And because it's difficult to extend such protocols when needed, there's
> pressure to get things "right" the first time, which is often interpreted as
> "let's make sure specify every feature that could possibly be needed".

Typically we try to bake in extensibility only.

> A related problem is setting up a tight binding between say an ASN.1
> structure and a C struct which imposes even more rigidity and subtle bugs.

Examples?  I don't think that's the case with any of the ASN.1-using
protocols I've ever had to implement any part of or which I'm familiar
with (e.g., PKIX, Kerberos, LDAP).  None of them are laid out with C in
mind, though all have C implementations, and all vary a fair bit in the
internal struct layouts.

I would think if you want nice alignment with C you'd want XDR, only
maybe an 8-octet alignment version nowadays.

> (Encodings are separate issues but I have yet to see an encoding of ASN.1
> that is really efficient to either encode or decode. Not saying it cannot be
> done, but there's sort of an expectation that marshaling has to be done one
> datum at a time, in the sequence that they appear on the wire, and that
> slows things down by itself. )

I've not implemented OER, but I suspect that OER is efficient in
run-time, and certainly in space needed.

> Nico WIlliams wrote:
> > I've never heard a bad thing uttered about XDR.
> Besides being too rigid in the same way that ASN.1 is (for many
> applications), XDR is also grossly inefficient (in time more than space,
> though there's some space inefficiency) in both encoding and decoding,
> requiring extra memory copies and mallocs/frees to convert between
> on-the-wire and internal representations, and this slows things down
> tremendously.

Nah, that's just rpcgen -- one particular implementation.  Many JSON
implementations do that too.  You _can_ implement more flatbuffers-like
strategies for XDR.