Re: What ASN.1 got right

Keith Moore <> Tue, 02 March 2021 04:09 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9D98D3A13CE for <>; Mon, 1 Mar 2021 20:09:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.919
X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Id2UfMQDeizx for <>; Mon, 1 Mar 2021 20:09:36 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 02AF83A1389 for <>; Mon, 1 Mar 2021 20:09:34 -0800 (PST)
Received: from compute3.internal (compute3.nyi.internal []) by mailout.nyi.internal (Postfix) with ESMTP id 7C1FC5C00ED for <>; Mon, 1 Mar 2021 23:09:33 -0500 (EST)
Received: from mailfrontend1 ([]) by compute3.internal (MEProxy); Mon, 01 Mar 2021 23:09:33 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=DLk87XvFu6FBdpZih8b+wGWSxXOYYQ0/u5W1lgSGg 2g=; b=k6LQZkahr79RXKuHHypAN+TMB0iCiVATM2fiX31gwETvqO2GTFLLBkkiB drOPsqU3mWKU1Dl5WqMF7TYPrSaUJhZRfXPbvP75GXmLWj4DKvbYIx3o/Cn+rHbP JI8VrUzWXUERCArEGFc8PYgh3M2+heHfrtbDccppb06fZRZhKGq82z+3Yrc54RaR nYTG+2Yos6kYU5XeRnO9a3+EwEPgetwF+/pEmCDDf7gwdmPBqoWrrHLHettm4yWM p98Z3eOC4KrM54idryUBS+dJb/irywSq1dG2X9PbWz0WacZ5SBGPmAUgbNqkmur2 rkscQRTkodp+qzdEjdiMYjirQpVcA==
X-ME-Sender: <xms:fLo9YPOQni_m5SWFQ3Z4ZYUf9ZAqKE-cVjQAUNdpMg14iyUkuxQRTQ> <xme:fLo9YJ8luF5IMzE0MpuRACnXK0aWBlctRsggd0MjUqYqXbp0LyUumXKOedOG8q3W7 5rAIqHTrOpnHQ>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrleelgdeijecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepuffvfhfhkffffgggjggtgfesthekre dttdefjeenucfhrhhomhepmfgvihhthhcuofhoohhrvgcuoehmohhorhgvsehnvghtfiho rhhkqdhhvghrvghtihgtshdrtghomheqnecuggftrfgrthhtvghrnhephefhuedtheefgf efgffhkeehgfeugfeiudeugeejkeefleelueeiffetfeeuudeunecukfhppedutdekrddv vddurddukedtrdduheenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrih hlfhhrohhmpehmohhorhgvsehnvghtfihorhhkqdhhvghrvghtihgtshdrtghomh
X-ME-Proxy: <xmx:fLo9YOQ2KU6wPqr7FZ2AayqO9vPthurLA5lgDFjg_wjB2VzIzTnwnA> <xmx:fLo9YDuj8OWBjbb8lLvJnGeo1nCvI0JPwH3aH_m5Fj3uFFOx02jjhg> <xmx:fLo9YHdGxPrJF2Zsrhs_LVIX7x1pi5_2rIeCzmcfQGCXbAERspS1iA> <xmx:fbo9YK9m3hc7ACa2bh9Sa6DET0XgQAhyUvlGsfssyhYUreAqd2Jc7g>
Received: from [] ( []) by (Postfix) with ESMTPA id AEC4224005A for <>; Mon, 1 Mar 2021 23:09:32 -0500 (EST)
Subject: Re: What ASN.1 got right
References: <20210302010731.GL30153@localhost> <04f601d70f04$404c5870$c0e50950$>
From: Keith Moore <>
Message-ID: <>
Date: Mon, 1 Mar 2021 23:09:31 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0
MIME-Version: 1.0
In-Reply-To: <04f601d70f04$404c5870$c0e50950$>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
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:09:38 -0000

(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?)

On 3/1/21 8:34 PM, Larry Masinter wrote:

> Rich formalisms and separation of syntax and "encoding rules" seem
> counter-productive.

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.

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.   
This in turn makes protocols and implementations much more brittle and 
less interoperable than they should be.   Every non-optional field must 
be specified and checked whether it is needed or not, it's more 
difficult to extend such protocols when needed, and implementation bugs 
that break things at a level which is hard to work around are far too 

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".

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.

There are some situations in which you need rigid type checking and a 
minimum of permitted variation, and probably X.509v3+DER is a good 
example of such a situation.   But this should not be the default.

And sure, you can use SEQUENCE or OPTIONAL or whatever to define ASN.1 
structures that aren't so rigid, but these tend to be used sparingly 
because people get enamored with their ability to define grandiose 
structures that solve all of the world's problems.

(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. )

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 

(You're welcome.)