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

[Nico Williams <[e-mail]>]

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