Re: [saag] ASN.1 vs. DER Encoding
Nico Williams <nico@cryptonector.com> Tue, 26 March 2019 16:50 UTC
Return-Path: <nico@cryptonector.com>
X-Original-To: saag@ietfa.amsl.com
Delivered-To: saag@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16A4B120611 for <saag@ietfa.amsl.com>; Tue, 26 Mar 2019 09:50:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 ErgY33Tq-Wrb for <saag@ietfa.amsl.com>; Tue, 26 Mar 2019 09:50:06 -0700 (PDT)
Received: from bisque.maple.relay.mailchannels.net (bisque.maple.relay.mailchannels.net [23.83.214.18]) (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 9D2801202CB for <saag@ietf.org>; Tue, 26 Mar 2019 09:50:05 -0700 (PDT)
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 C4E012C2339; Tue, 26 Mar 2019 16:50:04 +0000 (UTC)
Received: from pdx1-sub0-mail-a57.g.dreamhost.com (100-96-9-134.trex.outbound.svc.cluster.local [100.96.9.134]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 2D29F2C21B2; Tue, 26 Mar 2019 16:50:04 +0000 (UTC)
X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com
Received: from pdx1-sub0-mail-a57.g.dreamhost.com ([TEMPUNAVAIL]. [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.17.2); Tue, 26 Mar 2019 16:50:04 +0000
X-MC-Relay: Neutral
X-MailChannels-SenderId: dreamhost|x-authsender|nico@cryptonector.com
X-MailChannels-Auth-Id: dreamhost
X-Fumbling-Glossy: 21dde86e1b2fe96c_1553619004570_2198946759
X-MC-Loop-Signature: 1553619004570:125989299
X-MC-Ingress-Time: 1553619004569
Received: from pdx1-sub0-mail-a57.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a57.g.dreamhost.com (Postfix) with ESMTP id 1C4F48017D; Tue, 26 Mar 2019 09:50:01 -0700 (PDT)
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=QDbX0pqxmWAEx3 jOjr58t3Kc6iQ=; b=Ra2R4HtQV6U6goy0gPFze9sK1nolpSOJkO5B8WSCUR98zI CwineTLKTyUWk1kynehaNVhq1rmYZNqSVykXbSvr59dCF7dkxNI9c/orWeVODMz3 jisqTBWJI+c0skx7y2wBF4iVR9kdBGVI7rh98NM99cDdpPaoQDt2nkQiJ2rCs=
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-a57.g.dreamhost.com (Postfix) with ESMTPSA id D34D780178; Tue, 26 Mar 2019 09:49:57 -0700 (PDT)
Date: Tue, 26 Mar 2019 11:49:51 -0500
X-DH-BACKEND: pdx1-sub0-mail-a57
From: Nico Williams <nico@cryptonector.com>
To: "Dr. Pala" <madwolf@openca.org>
Cc: "saag@ietf.org" <saag@ietf.org>
Message-ID: <20190326164951.GX4211@localhost>
References: <21dec229-5b5c-8d52-6817-edac2e39ceec@openca.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <21dec229-5b5c-8d52-6817-edac2e39ceec@openca.org>
User-Agent: Mutt/1.9.4 (2018-02-28)
X-VR-OUT-STATUS: OK
X-VR-OUT-SCORE: 0
X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedutddrkedtgdeklecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucggtfgfnhhsuhgsshgtrhhisggvpdfftffgtefojffquffvnecuuegrihhlohhuthemuceftddtnecunecujfgurhepfffhvffukfhfgggtuggjfgesthdtredttdervdenucfhrhhomheppfhitghoucghihhllhhirghmshcuoehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmqeenucffohhmrghinhepghhithhhuhgsrdgtohhmnecukfhppedvgedrvdekrddutdekrddukeefnecurfgrrhgrmhepmhhouggvpehsmhhtphdphhgvlhhopehlohgtrghlhhhoshhtpdhinhgvthepvdegrddvkedruddtkedrudekfedprhgvthhurhhnqdhprghthheppfhitghoucghihhllhhirghmshcuoehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmqedpmhgrihhlfhhrohhmpehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmpdhnrhgtphhtthhopehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmnecuvehluhhsthgvrhfuihiivgeptd
Archived-At: <https://mailarchive.ietf.org/arch/msg/saag/Y1de0Dn_Khoc110V87y2YSiaZOk>
Subject: Re: [saag] ASN.1 vs. DER Encoding
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Advisory Group <saag.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/saag>, <mailto:saag-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/saag/>
List-Post: <mailto:saag@ietf.org>
List-Help: <mailto:saag-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/saag>, <mailto:saag-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 26 Mar 2019 16:50:09 -0000
On Tue, Mar 26, 2019 at 05:24:38PM +0100, Dr. Pala wrote: > I just wanted to provide some feedback based on the contents of some > presentations I have seen in the security area. In particular, I noticed > that some authors seem to confuse the definition of information objects > (ASN.1) and their encoding (e.g., DER). I noticed that, sometimes, when > ASN.1 was mentioned, what was really the topic of discussion was actually > related to DER encoding. And then they (rightly!) hate BER/DER/CER, so they propose inventing something new, often badly. In this field, there is nothing new. I'm sure even flatbuffers isn't new. I say "rightly" because TLV encodings are just terrible. We really do need non-TLV encodings (see below). To save everyone else the bother of reading the rest of this: I agree with you and we should have a non-TLV encoding for ASN.1 that makes IETFers happy, and CBOR is a good a basis for that. > Since I have seen this happening multiple times, I am starting to wonder if > I am the one who is wrong. In particular, my question is: do people in the > security area support the statement that ASN.1 is equivalent to DER encoding > ? I sure do not. However, it is true that BER/DER are pretty much the only encoding rules used in IETF documents, and that is mostly a result of lack of tooling. Mind you, XDR is basically a PER- or OER-like encoding with 4-byte alignment, for a subset of ASN.1. Seen this way we could could easily produce an ASN.1-compatible ER that nonetheless has no direct, normative link to ASN.1, and which has its own syntax, just to please those who can't bother to find or built the tools they need if they are based on a 40 year old technology. > I ask this because ASN.1 is "used for the definition of data types, values, > and constraints on data types." independently from the how the data is > actually encoded (BER, PER, XER, DER, etc.) - it just happens that in X.509 > PKIs, we use DER as the preferred encoding (and PEM for 7-bit transport > mode). Therefore when we talk about certificate parsing, for example, we do > parse DER/PEM, not ASN.1. For example, for the proposal around CBOR-encoded > certificates (not endorsing the idea, just using this as an example), > defining the CBOR Encoding Rules (CER ?) would provide a path to provide > CBOR encoding for all ASN.1 definitions we use in PKIX. <sarcasm> Yes, but everybody knows you can't parse ASN.1 with a LALR(1) parser[*]! </sarcasm> * That's something I heard as a truism eons ago, but here's a bison-based ASN.1 compiler: https://github.com/heimdal/heimdal/tree/master/lib/asn1 I would be quite happy with a CBORER. CER is already taken, as a flavor of BER that is canonical, but in different ways than DER is. BER/DER/CER and all TLV encoding rules are just awful, and we should really have an alternative to them for Internet protocols. I suspect proponents of new certificate encodings aren't interested only in new encodings, but new schemas as well. ASN.1 is too complicated and all that. > Maybe this distinction is not important for people that already have a good > understanding of the information model, however there might be newcomers > (new IETF-ers or just new to the security area) that might think the two are > the same when they are not, in my opinion. We are doomed to reinvent our wheels. Often badly. It's always easier to create new legacy than to deal with old legacy, even though new legacy very soon becomes old legacy, and so new legacy is invariably worse than old legacy, just not right away. Few understand this. > Therefore, my recommendation is to keep this distinction in mind when > talking about encoding and parsing of, for example, certificates. I hope > this helps. It probably won't. You're inviting a flame war, and I'm probably helping you. Nico --
- Re: [saag] ASN.1 vs. DER Encoding Nico Williams
- Re: [saag] ASN.1 vs. DER Encoding Peter Gutmann
- [saag] ASN.1 vs. DER Encoding Dr. Pala
- Re: [saag] ASN.1 vs. DER Encoding Yoav Nir
- Re: [saag] ASN.1 vs. DER Encoding Nico Williams
- Re: [saag] ASN.1 vs. DER Encoding Carsten Bormann
- Re: [saag] ASN.1 vs. DER Encoding Carsten Bormann
- Re: [saag] ASN.1 vs. DER Encoding Volker Birk
- Re: [saag] ASN.1 vs. DER Encoding Volker Birk
- Re: [saag] ASN.1 vs. DER Encoding Nico Williams
- Re: [saag] ASN.1 vs. DER Encoding Nico Williams
- Re: [saag] ASN.1 vs. DER Encoding Nico Williams
- Re: [saag] ASN.1 vs. DER Encoding Michael Richardson
- Re: [saag] ASN.1 vs. DER Encoding Viktor Dukhovni
- Re: [saag] ASN.1 vs. DER Encoding Carl Wallace
- Re: [saag] ASN.1 vs. DER Encoding Benjamin Kaduk
- Re: [saag] ASN.1 vs. DER Encoding Nico Williams
- Re: [saag] ASN.1 vs. DER Encoding Benjamin Kaduk
- Re: [saag] ASN.1 vs. DER Encoding Nico Williams
- Re: [saag] ASN.1 vs. DER Encoding Nico Williams
- Re: [saag] ASN.1 vs. DER Encoding Nico Williams
- Re: [saag] ASN.1 vs. DER Encoding Dr. Pala
- Re: [saag] ASN.1 vs. DER Encoding Nico Williams
- Re: [saag] ASN.1 vs. DER Encoding Peter Gutmann
- Re: [saag] ASN.1 vs. DER Encoding Peter Gutmann
- Re: [saag] ASN.1 vs. DER Encoding Nico Williams
- Re: [saag] ASN.1 vs. DER Encoding Sean Leonard
- Re: [saag] ASN.1 vs. DER Encoding Nico Williams
- Re: [saag] ASN.1 vs. DER Encoding Nico Williams
- Re: [saag] ASN.1 vs. DER Encoding Michael Richardson
- Re: [saag] ASN.1 vs. DER Encoding Benjamin Kaduk
- Re: [saag] ASN.1 vs. DER Encoding Nico Williams
- Re: [saag] ASN.1 vs. DER Encoding Christian Huitema
- Re: [saag] ASN.1 vs. DER Encoding Viktor Dukhovni
- Re: [saag] ASN.1 vs. DER Encoding Carsten Bormann
- Re: [saag] ASN.1 vs. DER Encoding Stephen Farrell
- Re: [saag] ASN.1 vs. DER Encoding Salz, Rich
- Re: [saag] ASN.1 vs. DER Encoding Nico Williams
- Re: [saag] ASN.1 vs. DER Encoding Salz, Rich
- Re: [saag] ASN.1 vs. DER Encoding Benjamin Kaduk
- Re: [saag] ASN.1 vs. DER Encoding Nico Williams
- Re: [saag] ASN.1 vs. DER Encoding Phillip Hallam-Baker
- Re: [saag] ASN.1 vs. DER Encoding Nico Williams
- Re: [saag] ASN.1 vs. DER Encoding Phillip Hallam-Baker
- Re: [saag] ASN.1 vs. DER Encoding Russ Housley
- Re: [saag] ASN.1 vs. DER Encoding Nico Williams
- Re: [saag] ASN.1 vs. DER Encoding Watson Ladd
- Re: [saag] ASN.1 vs. DER Encoding Phillip Hallam-Baker
- Re: [saag] ASN.1 vs. DER Encoding Michael Richardson
- Re: [saag] ASN.1 vs. DER Encoding Nico Williams
- Re: [saag] ASN.1 vs. DER Encoding Viktor Dukhovni
- Re: [saag] ASN.1 vs. DER Encoding Adrian Hope-Bailie