RE: What ASN.1 got right

Larry Masinter <> Tue, 02 March 2021 01:35 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5F7023A0A29 for <>; Mon, 1 Mar 2021 17:35:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.499
X-Spam-Status: No, score=-1.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Uar7aqfB0-cS for <>; Mon, 1 Mar 2021 17:34:58 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::42d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D68B93A0A27 for <>; Mon, 1 Mar 2021 17:34:58 -0800 (PST)
Received: by with SMTP id t29so12746619pfg.11 for <>; Mon, 01 Mar 2021 17:34:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=sender:from:to:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=/K88uLmPGdpyIlk9txUyDhq/0mdLJUIjuoxiGVM0IkA=; b=LAfQfljybHEQZ0UWPpT68j0oa6JR7PYei+RjiK6/ELxTq2H2UDLOOlygLW1V68+4JT Rfl4y2hQV5ydmPWk5am5Bzv/ESumS8cA8h14H64padp6kUK0KRfox8ukOJXNbFciv8qD pdzdqzNBGLfwtKED051rFO6YUfRNfJSVFKxL6ht3hnKIXvDhcpzN/6cvyT3A/fwWRGSw FbfAMAVcJAd7ozR+vhOsaKUA/cLn+JSei03WUnwXDavMOKafN9F64zKet0ssiSwXYElh axuit1sl4DhjqNYCRVmmabc9x/vXu8WyVKtxWksRBxn0CcehPvnjBsbQrlH4t8noH/Ge 8CWw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:sender:from:to:references:in-reply-to:subject :date:message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=/K88uLmPGdpyIlk9txUyDhq/0mdLJUIjuoxiGVM0IkA=; b=HveAQW/ECmBo2H8HWfYOI38/2M2FYn6eWj2TLLiYgpBK/NCeXbDq7T/3W/21HpXaH9 6Lg+eJUindw4aZItQP8pLqMFXTU47W3nh5FaNYgmVsCzGV69dhXWA/b0UUI4ign+Y3Pn 1WwYbTYUBj0tKE+D+VBpg79f+7MGGpZgmNsmo54YAds9Hrs6+JSgGa77NRRCeAanO8RN m6/7CleL3vsplJfSLxNmhqeBMFFcddLLBV346tOEC+D4gZ9nceEq4tUUXxY3Wu4WfaCa F4pwak4hCvYgGsGZKtNuLNmm/mT+vw/IOw5+u9Oikz+LZxNA2bA7bocjQXePWu8eBF+z OQpg==
X-Gm-Message-State: AOAM533urXW5yympqQFn4X9Hogp57hA0pmR9PYLWQj1+m2BJPwPoHmPv 2zkssXYZ7cNLPqPpaIE61VJwEWsVGH8=
X-Google-Smtp-Source: ABdhPJyUFNaG6gefOAJzk8RXO3+eg71g75+Gl6wJqeuiS4tLqoCmveN4Jt+wv5aotVEAQ+6T4sjJAA==
X-Received: by 2002:aa7:84cb:0:b029:1ed:9b6f:1b6f with SMTP id x11-20020aa784cb0000b02901ed9b6f1b6fmr1184307pfn.57.1614648896566; Mon, 01 Mar 2021 17:34:56 -0800 (PST)
Received: from TVPC ( []) by with ESMTPSA id z8sm688347pjr.57.2021. (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 01 Mar 2021 17:34:56 -0800 (PST)
Sender: Larry Masinter <>
From: Larry Masinter <>
X-Google-Original-From: "Larry Masinter" <>
To: "'Nico Williams'" <>, <>
References: <20210302010731.GL30153@localhost>
In-Reply-To: <20210302010731.GL30153@localhost>
Subject: RE: What ASN.1 got right
Date: Mon, 1 Mar 2021 17:34:55 -0800
Message-ID: <04f601d70f04$404c5870$c0e50950$>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQEj3ShpOKesyRLLBV7vp+AP5sD21avWR7OQ
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 01:35:01 -0000

JSON-LD seems to fit modern needs from an extensibility / simplicity point
of view.
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

> -----Original Message-----
> From: ietf <> On Behalf Of Nico Williams
> Sent: Monday, March 1, 2021 5:08 PM
> To:
> Subject: What ASN.1 got right
> As an ASN.1 implementor, I can tell you things I, like many of you, hate
> ASN.1:
>  - ugly syntax (made uglier by having tags as optional lexical elements)
>  - ugly OIDs (should have been URNs or URN-like)
>  - BER/DER/CER and all TLV encodings in the world (protocol buffers, I'm
>    looking at you too) are awful
>  - the fact that the specs were, for a long time, non-free, which led to
>    a dearth of open source tooling that still persists somewhat (though
>    not as bad as it used to be)
>  - the fact that for years people hand-rolled their codecs due to the
>    previous item, and so created many bugs
>  - X.400/X.500, which are not part of ASN.1, of course, but closely
>    related -- especially X.500 style naming!
> Having recently implemented automatic open type decoding handling X.681/
> X.682/X.683 (see RFCs 6025 for some insight, and 5912 for real examples
> I'm making use of), I can tell you that ASN.1 got some things
> right:
>  - rich formalisms ("constraints")
>  - separation of syntax and encoding rules
> The fact that there are many encoding rules for ASN.1, of almost every
> (binary TLV, binaray non-TLV, and textual, including XML- and JSON-based
> rules) proves the last point.  I can't help but see how XDR, NDR, and
> flatbuffers, among many other encodings out there, could easily be used
> with ASN.1.  (E.g., what XDR and NDR call "pointers" are just optional
fields in
> ASN.1.)
> The fact that one can implement automatic open type decoding using ASN.1
> formalisms and those already published in, e.g., RFC 5912[*] proves the
> utility of those formalisms.  I now get to see certificates and many other
> things in all their "glorious" detail as JSON, including all extensions
and what
> not, and that's made possible by these formalisms.
> I beg the next person to re-invent this darned wheel to please educate
> themselves as to what came before.  Among many lessons you should learn,
> learn that some things can't be monetized well enough, or at all, or can
> be monetized in exchange for limiting their adoption, so figure out what
> goals are, then align pricing and licensing with those.
> And since open types appear to be unavoidable, but also always a pain if
> don't have the metaschema to express the metadata needed to automate
> their handling, don't forget to cover that.
> XML, of course, with namespaces and references, has a reasonable approach
> to open types as well.  It's not just ASN.1 that gets that right well
> Nico
> [*] A big thank you to RFC 5912's authors, though sadly one of them has
>     passed.