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

[Nico Williams]

On Fri, Nov 24, 2017 at 03:36:58PM -0500, Phillip Hallam-Baker wrote:
> On Tue, Nov 21, 2017 at 4:05 PM, Nico Williams <nico at cryptonector.com> wrote:
> > Sure.  But again, would you rather respond to this by:
> >
> > a) building a new spec and tools for it,
> >
> > or
> >
> > b) building tools for the existing spec
> 
> A

Please don't.  Don't use BER/DER/CER -- those are lousy, as is Protocol
Buffers, because they are all TLV encodings.

Use PER/OER/XDR or anything like them, but don't build something brand
new.  It'll be a burden on the rest of us.

> Missing important considerations is a risk but I find JSON with very
> minor extensions has met all my needs and the Mesh is pretty
> extensive.

JSON is _horrible_, mostly because of the need to escape characters in
strings, and the lack of a binary type.  Some binary JSON encodings are
OK.

> > If you listen to PHB and friends who say "ASN.1 is bad" when what they
> > mean "BER/DER/CER are bad", then you will probably choose (a).
> 
> Actually, the ASN.1 schema format is worst of all. I just could not be
> bothered with it and so I created my own, lust like I did with XML. If
> needed, I would generate ASN.1 from my schema along with the
> serializer.

Sure, you absolutely can generate ASN.1 or whatever from equivalent
languages, and there's a lot to say for doing that, especially if you
use XML or SQL, as then you can write a lot of tooling in functional/
declarative languages.  I do this sort of thing (in the latest case I
generate JSON schema descriptions from SQL schemata).

And, of course, you can easily produce a one-to-one mapping of a subset
of XML to/from ASN.1, so you really need not think of ASN.1 if you hate
the notation.

> > As others, and I, have been saying, XDR is a perfectly good choice in
> 
> Main objection I would make is 32 bit lengths are rather short for modern needs.

Easy to work around: chunk up any data types whose values can get that
big.  It's probably worth it too.  And if you have indeterminate-length
payloads, you'll have to chunk them up anyways, a la HTTP chunked
transfer encoding.

Nico
--