[Cryptography] [FORGED] Re: Is ASN.1 still the thing?

[Nico Williams]

On Tue, Nov 14, 2017 at 05:53:57AM -0600, alex at alten.org wrote:
> Quoting Peter Gutmann <pgut001 at cs.auckland.ac.nz>:
> >If you really want something simple, lightweight, and straightforward, what
> >about XDR?  That's pretty well defined, and dates from a time when primary
> >design goals were that stuff be efficient and easily implementable, rather
> >than as complex as you can make it, or as hip as possible, or with angle
> >brackets (some stuff encompasses all three of those).
> 
> God, I hated ASN.1. I spent the better part of six years dealing with ASN.1
> in SNMP (at first in raw binary/hex), then an uncounted number of years
> dealing with it in X.509 and PKCS. DER, BER, ugh!!

Why should it have been a problem at all?  If you have a decent compiler
and run-time, like, e.g., Heimdal does, then ASN.1 and BER/DER can be an
afterthought.

> I actually built a couple of custom authentication protocols using XDR ~20
> years ago when I was doing heavy amounts of C, C++ and Intel assembly.  I
> really liked XDR.  Nice and simple. Perfect for small authentication
> payloads (about 300 bytes back then).

Then by all means use XDR.

Just for the record (and, I know, I'm repeating myself here), XDR
(syntax and encoding) is basically a subset of ASN.1 (syntax) and PER
(packed encoding rules) with 4-octet alignment and no packing of
booleans.

If you can do XDR, you're not far from doing ASN.1/PER.

If you think XDR is simple, then why would you not also think the same
of ASN.1/PER?  The only obvious answer is "lack of tooling".  Even XDR
doesn't come with that much tooling either -- there's the rather lame
rpcgen(1) program, libxdr, and not much else.  XDR is just simple enough
that one can code it from memory -- a very nice advantage, to be sure.

(The very simple krb5_ret_*() and krb5_store_*() functions in Heimdal
can be trivially used to implement XDR protocols without having a
compiler.  This is not by design.  It's just an accident -- a very happy
accident -- born of XDR's utter obviousness and simplicity.  So there's
a lot to say for XDR!  But when you have good compilers then this
simplicity advantage disolves away.)

If nothing else, the ASN.1 specifications series, x.68x (ASN.1) and
x.69x (encoding rules) are extremely well-written and readable, with
decades of experience fine-tuning.  That too is an advantate, especially
now that those are free (and now have been for years).

It is DER (and CER, and to a lesser degree, BER) that sucks, not ASN.1.

IF you ever must invent your own encoding (please don't), just remember
that TLV ("self-describing") is garbage.  TLV encodings have unnecessary
redundancy, lead to serious bugs in hand-coded implementations, and are
all-around just a lazy way to avoid compiling a description of the data.

The only nice thing about TLV is that when you don't know the type of
some data, you can still get a feel for its shape, and so you can have
tools like asn1dump that don't need to know what type of data you want
to dump.  But it's still better to [and usually inexcusable not to] know
the type of the data anyways.

Nico
--