Re: What ASN.1 got right

Nico Williams <nico@cryptonector.com> Tue, 02 March 2021 02:17 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 F3EDB3A0C61 for <ietf@ietfa.amsl.com>; Mon, 1 Mar 2021 18:17:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.753
X-Spam-Level:
X-Spam-Status: No, score=-5.753 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_BL_SPAMCOP_NET=1.347, 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: 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 zY2CvbN2gpuO for <ietf@ietfa.amsl.com>; Mon, 1 Mar 2021 18:17:39 -0800 (PST)
Received: from dog.elm.relay.mailchannels.net (dog.elm.relay.mailchannels.net [23.83.212.48]) (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 826DC3A0C5C for <ietf@ietf.org>; Mon, 1 Mar 2021 18:17:39 -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 7DD3A121F46; Tue, 2 Mar 2021 02:17:38 +0000 (UTC)
Received: from pdx1-sub0-mail-a86.g.dreamhost.com (100-96-17-38.trex.outbound.svc.cluster.local [100.96.17.38]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 000E212203F; Tue, 2 Mar 2021 02:17:37 +0000 (UTC)
X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com
Received: from pdx1-sub0-mail-a86.g.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384) by 100.96.17.38 (trex/6.0.2); Tue, 02 Mar 2021 02:17:38 +0000
X-MC-Relay: Neutral
X-MailChannels-SenderId: dreamhost|x-authsender|nico@cryptonector.com
X-MailChannels-Auth-Id: dreamhost
X-Grain-Zesty: 1c55c9034ede8011_1614651458285_4207882404
X-MC-Loop-Signature: 1614651458285:1959398192
X-MC-Ingress-Time: 1614651458285
Received: from pdx1-sub0-mail-a86.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a86.g.dreamhost.com (Postfix) with ESMTP id B2C7487299; Mon, 1 Mar 2021 18:17:37 -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=xFuuJ3ZRzmtlvz V4oH4HNCs3KP4=; b=UJb6UCG0x26KJ3vq5MXPPiLEe+jHktmpbEmnnKKt39y8iH GEn1+uqnx8Wc1Ui0m5IkDk9Zr0i3j6K8fouZejWYY2yECOSzUiF94lME6c3PGOmP i77zZxRScZUwRdmCk78nEezitAgkgtrGqSDyhOqB3esbo4DANn4s93UCGm2lM=
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-a86.g.dreamhost.com (Postfix) with ESMTPSA id 2346C7EF9C; Mon, 1 Mar 2021 18:17:34 -0800 (PST)
Date: Mon, 1 Mar 2021 20:17:32 -0600
X-DH-BACKEND: pdx1-sub0-mail-a86
From: Nico Williams <nico@cryptonector.com>
To: Larry Masinter <LMM@acm.org>
Cc: ietf@ietf.org
Subject: Re: What ASN.1 got right
Message-ID: <20210302021731.GM30153@localhost>
References: <20210302010731.GL30153@localhost> <04f601d70f04$404c5870$c0e50950$@acm.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <04f601d70f04$404c5870$c0e50950$@acm.org>
User-Agent: Mutt/1.9.4 (2018-02-28)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/OKfm7h70KkkKPfXs66oJqM8GIW8>
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 02:17:41 -0000

On Mon, Mar 01, 2021 at 05:34:55PM -0800, Larry Masinter wrote:
> JSON-LD seems to fit modern needs from an extensibility / simplicity point
> of view.

I know nothing about JSON-LD.

> All the bit-packing goodness of various encodings are dreadful from an
> interoperability point of view.
> Rich formalisms and separation of syntax and "encoding rules" seem
> counter-productive.

The nicest thing about XML is XSLT/XPath, and the nicest thing about
JSON is jq.  Such languages are probably only feasible when you have
loose typing, which XML and JSON do.  And loose typing does arguably
mean dispensing with the formalisms that force static typing.

That said, and as much as I love jq, for all the protocols I work on I
would much rather have static typing and rich formalisms.  Especially in
security protocols, I'd rather have rich formalisms.

As always, one should use the right tool for the job.  (FWIW, I used to
maintain jq and might again, and I maintain an ASN.1 implementation.)

I don't see how separation of syntax and encoding can be counter-
productive: alternative syntaxes are always possible, and transcoding is
generally possible, and people often have to do these things for some
reason.

As to "bit-packing"...  have you noticed that every textual encoding
eventually evolves a binary adaptation?  XML has FastInfoSet.  JSON has
a multitude of binary encodings (at least three).  Parsing textual
encodings isn't easy, and much less parsing them efficiently.  Parsing
dynamically typed data requires more overhead than parsing statically
typed data.

Parsing JSON efficiently is really hard.  Parsing anything without a
schema shifts a lot of burden onto the developer, unless the developer
is using something like jq.  People have devoted a lot of effort to
using SIMD to parse JSON more quickly than can be done on a traditional
CPU, but IIUC there are no online JSON parsers that use SIMD -- no one
would bother doing this for XDR because there is no need.

XDR was always simpler to compile or hand-roll codecs for than TLV
encodings, and definitely than textual encodings.  I've never heard a
bad thing uttered about XDR.

It turns out that once you've parsed the syntax into an AST it's pretty
trivial to generate codecs (possibly bytecoded) regardless of the
encoding rules' nature.

XDR being so much simpler than TLV types because of the absence of tags
and wasteful lengths, was always easy to handle, but what made it easy
was not having any crutches and so having to have parsed the syntax
defining the types one needed to encode.  There's a lot of hand-rolled
XDR out there as well, including some I look after, because it's much
easier to hand-roll XDR than TLV encodings, and certainly than textual
ones.

NDR's pointer dedup feature made it much harder to implement, but
otherwise it's really similar to XDR.  OER and PER are not too
dissimilar to XDR, so they're probably comparable to XDR in
implementaiton complexity.

Nico
--