Re: [saag] ASN.1 vs. DER Encoding

Michael Richardson <mcr+ietf@sandelman.ca> Tue, 26 March 2019 19:38 UTC

Return-Path: <mcr@sandelman.ca>
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 B5150120A22 for <saag@ietfa.amsl.com>; Tue, 26 Mar 2019 12:38:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 tAtJ7Qg8U_b9 for <saag@ietfa.amsl.com>; Tue, 26 Mar 2019 12:38:56 -0700 (PDT)
Received: from relay.sandelman.ca (relay.cooperix.net [176.58.120.209]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A757012089A for <saag@ietf.org>; Tue, 26 Mar 2019 12:38:56 -0700 (PDT)
Received: from dooku.sandelman.ca (dhcp-94a3.meeting.ietf.org [31.133.148.163]) by relay.sandelman.ca (Postfix) with ESMTPS id BCC3D1F45B; Tue, 26 Mar 2019 19:38:54 +0000 (UTC)
Received: by dooku.sandelman.ca (Postfix, from userid 179) id 090A32DA0; Tue, 26 Mar 2019 20:38:58 +0100 (CET)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: "Dr. Pala" <madwolf@openca.org>
cc: "saag@ietf.org" <saag@ietf.org>
In-reply-to: <21dec229-5b5c-8d52-6817-edac2e39ceec@openca.org>
References: <21dec229-5b5c-8d52-6817-edac2e39ceec@openca.org>
Comments: In-reply-to "Dr. Pala" <madwolf@openca.org> message dated "Tue, 26 Mar 2019 17:24:38 +0100."
X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha256"; protocol="application/pgp-signature"
Date: Tue, 26 Mar 2019 20:38:58 +0100
Message-ID: <20198.1553629138@dooku.sandelman.ca>
Archived-At: <https://mailarchive.ietf.org/arch/msg/saag/Othzdy2889fSeCFrq964Fo2-58Q>
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 19:38:59 -0000

Dr. Pala <madwolf@openca.org> 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.

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

ASN.1 is the goo the causes DER encoding to be present on the wire.
While it is true that ASN.1 could be used with different encoding rules,
nobody really cares about that.   Almost nobody uses encoders/decoders that
generate code from ASN.1 today, it's all hand-coded...

This is why we hate DER, and we like CDDL/CBOR.

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

They are, from a practical point of view, the same.
That wasn't true back in 1986, but many of the people who would make the
mistake were not even alive then.

--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-