Re: What ASN.1 got right

Phillip Hallam-Baker <phill@hallambaker.com> Tue, 02 March 2021 05:28 UTC

Return-Path: <hallam@gmail.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 E25B53A112D for <ietf@ietfa.amsl.com>; Mon, 1 Mar 2021 21:28:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.398
X-Spam-Level:
X-Spam-Status: No, score=-1.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
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 y-bi6-e5gZIz for <ietf@ietfa.amsl.com>; Mon, 1 Mar 2021 21:28:15 -0800 (PST)
Received: from mail-yb1-f179.google.com (mail-yb1-f179.google.com [209.85.219.179]) (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 9C2553A1137 for <ietf@ietf.org>; Mon, 1 Mar 2021 21:28:14 -0800 (PST)
Received: by mail-yb1-f179.google.com with SMTP id c131so19476342ybf.7 for <ietf@ietf.org>; Mon, 01 Mar 2021 21:28:14 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=cjTlwwskfY9pMijY0GTlSW3pTileqT2MhQsUgQ/ieo0=; b=fptmLUEbz3j8+42UV3HYjPWTlhu9F8y74gfcITDq147ilAbqqjOM/rYdEtmmcllVzg 66EOhN2uUIo20Ksq3p2hZ4tnUh1lZyaB3xE3329cdGKEUaLG3bVEtHxMUt2W/vE0vpjx aEKEtwOBJNYywcbukKIUDn9Tbi49vDOF5SfniTeiR62QPlhAROfXuCy7jy4dm/ixLnE5 FOIKJURWpEtkABHtd2/bGMMM5/OssW761RchozT44dBMGdW+8NSBGczk7iQF5uuEeaKZ 1geezfQfpXHkof+gpCav2JTvWQkjwtt+sdG/iIAD8b5JJU1cSeRuXXYOWvpCTLQteYl9 IRjA==
X-Gm-Message-State: AOAM531uXA/LNSNatO6j9xixcZPvfBxVsf5QWf/yAv3K7Rw3Dh185LHV OoXVtw/1SJzsWCatNgSspIqfplvjdNXFZkh8AsIt1BvosBM=
X-Google-Smtp-Source: ABdhPJynznU9jWvQW89GCuTkDQN6HDaj00CucENZbuYVXSyG+y2Sx9He4KSuiOCCCsflnbT4oNKCKey6TaJr2PXs75g=
X-Received: by 2002:a25:2307:: with SMTP id j7mr30062596ybj.518.1614662893840; Mon, 01 Mar 2021 21:28:13 -0800 (PST)
MIME-Version: 1.0
References: <20210302010731.GL30153@localhost> <0632b948-9ed1-f2bd-96da-9922ebb2aa60@mtcc.com>
In-Reply-To: <0632b948-9ed1-f2bd-96da-9922ebb2aa60@mtcc.com>
From: Phillip Hallam-Baker <phill@hallambaker.com>
Date: Tue, 2 Mar 2021 00:28:03 -0500
Message-ID: <CAMm+Lwjgv1jj6txiDRik_3by_FL0RKRqD=-8ds0bPvDKDw98-g@mail.gmail.com>
Subject: Re: What ASN.1 got right
To: Michael Thomas <mike@mtcc.com>
Cc: IETF Discussion Mailing List <ietf@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000382ed505bc870053"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/XigiTuQHYc9j8LYApKJwtwD2EQs>
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 05:28:17 -0000

Thing about the WebPKI is that everyone seems to hate it just as much today
as when we originally proposed it 25 years ago. All the things people keep
saying were better were on the table then as well. We could have a
discussion about why DNSSEC is no better but that won't get us anywhere.

None of the systems on the table in 1995 is going to work and if you want
to understand why go get a machine that SHIPPED with Windows 95, boot it
and see what we had to work with.

PKIX and the WebPKI were built for 30MHz machines with 32 bit processors
and 4MB of memory.


If you want a decent PKI for user authentication you need to be willing to
do Internet2 for PKI and do some blue sky research.

There aren't many folk doing that at the moment as BitPonzi has sucked all
the air out of the room.

Its not ASN.1 that is the problem. Its actually Public Key crypto isn't
enough, you need threshold. But we are getting rid of the ASN.1 as well for
two reasons. First, nobody is going to use our stuff if we force them to do
ASN.1. Second, nobody is paying me to do my stuff right now but once I have
it working in JSON/JSON-B, I can probably find some ASN.1 aficionados to
give me a consulting gig to write an ASN.1 version.


On Mon, Mar 1, 2021 at 8:18 PM Michael Thomas <mike@mtcc.com> wrote:

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