[saag] ASN.1 vs. DER Encoding

"Dr. Pala" <madwolf@openca.org> Tue, 26 March 2019 16:24 UTC

Return-Path: <madwolf@openca.org>
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 EC5F512059D for <saag@ietfa.amsl.com>; Tue, 26 Mar 2019 09:24:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.485
X-Spam-Level:
X-Spam-Status: No, score=-0.485 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_IMAGE_ONLY_28=1.404, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_HK_NAME_DR=0.01, 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 ae1dqgAJAHLo for <saag@ietfa.amsl.com>; Tue, 26 Mar 2019 09:24:41 -0700 (PDT)
Received: from mail.katezarealty.com (mail.katezarealty.com [104.168.158.213]) by ietfa.amsl.com (Postfix) with ESMTP id C3CBC12056E for <saag@ietf.org>; Tue, 26 Mar 2019 09:24:41 -0700 (PDT)
Received: from localhost (unknown [127.0.0.1]) by mail.katezarealty.com (Postfix) with ESMTP id A0043374128E for <saag@ietf.org>; Tue, 26 Mar 2019 16:24:41 +0000 (UTC)
X-Virus-Scanned: amavisd-new at katezarealty.com
Received: from mail.katezarealty.com ([127.0.0.1]) by localhost (mail.katezarealty.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id L7WTAsClUVCP for <saag@ietf.org>; Tue, 26 Mar 2019 12:24:41 -0400 (EDT)
Received: from dhcp-8b3d.meeting.ietf.org (dhcp-8b3d.meeting.ietf.org [31.133.139.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.katezarealty.com (Postfix) with ESMTPSA id 739033740F7B for <saag@ietf.org>; Tue, 26 Mar 2019 12:24:40 -0400 (EDT)
To: "saag@ietf.org" <saag@ietf.org>
From: "Dr. Pala" <madwolf@openca.org>
Message-ID: <21dec229-5b5c-8d52-6817-edac2e39ceec@openca.org>
Date: Tue, 26 Mar 2019 17:24:38 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.5.3
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="------------BC8B274E4ED5EDA0828D6394"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/saag/Epuh2Fe6UgXkaxubzppaLFdZ7Kc>
Subject: [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:24:43 -0000

Hi SAAG,

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 ?

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.

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.

Therefore, my recommendation is to keep this distinction in mind when 
talking about encoding and parsing of, for example, certificates. I hope 
this helps.

Just my 2 cents...

Cheers,
Max

-- 
Best Regards,
Massimiliano Pala, Ph.D.
OpenCA Labs Director
OpenCA Logo