Re: What ASN.1 got right

Michael Thomas <mike@mtcc.com> Tue, 02 March 2021 01:18 UTC

Return-Path: <mike@fresheez.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 E19993A0918 for <ietf@ietfa.amsl.com>; Mon, 1 Mar 2021 17:18:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.75
X-Spam-Level:
X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mtcc.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 gXoBB4xk_MMY for <ietf@ietfa.amsl.com>; Mon, 1 Mar 2021 17:18:16 -0800 (PST)
Received: from mail-pf1-x432.google.com (mail-pf1-x432.google.com [IPv6:2607:f8b0:4864:20::432]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2EF5A3A0912 for <ietf@ietf.org>; Mon, 1 Mar 2021 17:18:15 -0800 (PST)
Received: by mail-pf1-x432.google.com with SMTP id 192so5730483pfv.0 for <ietf@ietf.org>; Mon, 01 Mar 2021 17:18:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mtcc.com; s=fluffulence; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=H1UOMIDYLkZ7CJ/vUwDR8rLebuVb7Ysb/85vOWwGRLg=; b=I3s0pkC9JSwidQfaKT++DO4cLETgsrxBVke12DJ7eiD2irVwPqe17B3lZi2DYkQoLi rttMnI+5IsKiom5FLfcLT46jFLQbmW2NldW36jQABoY3FRynMgkZfJIJ7/woVsJ/BERe kuw4CHIV9PlA1H+EyC1sORAoiTv+NEL1gKZ9rL41s9uwnqXz+1zJxCo3zc8o87VGRZOB Ur+khL0bT1wFnXEnFSPQL7acCNWngIOo8I2IH00Ukozqn3V05RnavyfJlCd1TBTSOjJt VrCww+nXlWIx4smn6Mjbm8IV0tDAd0JzDFFwmRyvtgi4onZ4JKFmJugdIyCxHxTtebLt H0Mw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=H1UOMIDYLkZ7CJ/vUwDR8rLebuVb7Ysb/85vOWwGRLg=; b=b1Vsc3dXdhrQgyuRzhCQNWaQKyxCtA68qczY13lUubYJZg84c8/p8Sf+P6YQ2cY36Z obhtJVk3e7oOqmLmmoZDFsrMBNutxOMOP3+o4HfsJO8OpqIFzoU1hmQ7NmV5HT5j64wV TsyuEj5S2Jkelk7AeriT/3QFDKlrKUolapSaGbuXCz+Zzz2kLmp0LucgwyDzeE10pB9g 72Y6lOWLtdZmrR02q17mybvug1xJoRagQe/OCi5SVdvA+KJhhnXN/arc205YUrsvEJKU eKkxziF0ThOWlr0h1nV8TA2E31Wv5/QGyYiK6V3Mf7Q3NNajKGK5ANI1iMXFY4G3Yi6f AehA==
X-Gm-Message-State: AOAM533lml9VVBjLKrCec2hMCb/9R28ftHV2vpizBhuGbESO8wCEc3ay DaKfXrmXpIwMUCBwajfN44TFP7vonFy6zw==
X-Google-Smtp-Source: ABdhPJxZwy8fBONSU9oUHv8MeTVtRgiZ04vfilYhpXPxq8fJ4NDyOQ+J+ZYwX3DDAIFqMLjM61Aubw==
X-Received: by 2002:a63:2948:: with SMTP id p69mr16141398pgp.15.1614647893005; Mon, 01 Mar 2021 17:18:13 -0800 (PST)
Received: from mike-mac.lan ([206.107.197.192]) by smtp.gmail.com with ESMTPSA id w8sm17620040pgk.46.2021.03.01.17.18.12 for <ietf@ietf.org> (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 01 Mar 2021 17:18:12 -0800 (PST)
Subject: Re: What ASN.1 got right
To: ietf@ietf.org
References: <20210302010731.GL30153@localhost>
From: Michael Thomas <mike@mtcc.com>
Message-ID: <0632b948-9ed1-f2bd-96da-9922ebb2aa60@mtcc.com>
Date: Mon, 1 Mar 2021 17:18:10 -0800
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.8.0
MIME-Version: 1.0
In-Reply-To: <20210302010731.GL30153@localhost>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/W_yRbB5kXq6wQquo4XBYeSoJtig>
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 01:18:18 -0000

The combination of ASN.1 and X.509 has done irreparable harm to identity 
on the internet. X.509 provides exactly one benefit: the ability to 
verify offline that almost nobody cares about anymore. They have 
needlessly obfuscated the contents in the case of ASN.1, and the 
name/key binding in the case of X.509. Every security newbie immediately 
assumes that if you want to use an asymmetric key that you need X.509 
and hence ASN.1. That is not the case and that tail has wagged way too 
many dogs.

The best you can say is that X.509 bootstrapped TLS, but it would have 
been a way better world had it been bootstrapped by DNS.

Mike, yuck.

On 3/1/21 5:07 PM, Nico Williams wrote:
> As an ASN.1 implementor, I can tell you things I, like many of you, hate
> about 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
> that 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
> kind (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
> only be monetized in exchange for limiting their adoption, so figure out
> what your goals are, then align pricing and licensing with those.
>
> And since open types appear to be unavoidable, but also always a pain if
> you 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 enough.
>
> Nico
>
> [*] A big thank you to RFC 5912's authors, though sadly one of them has
>      passed.
>