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

[Phillip Hallam-Baker <[e-mail]>]

On Mon, Apr 22, 2019 at 5:15 PM Nico Williams <[e-mail]> wrote:

> On Mon, Apr 22, 2019 at 04:47:24PM -0400, Phillip Hallam-Baker wrote:
>
> It turns out there's a great deal of demand for both, a) "textual", and
> b) binary encodings.  And for (b), TLV kinda sucks, but it's what we've
> done for 30 years in many cases.  We also have "bits on the wire"
> encodings.
>

Hence the reason I decided to smoosh in binary encodings into JSON to
create a superset so that one decoder can read either the JSON or the
binary version.



> That's why we have all the ASN.1 encoding rules, XDR, NDR, XML,
> FastInfoSet, JSON, a whole bunch of "binary JSON" formats (including
> ones not brought to the IETF, such as PostgreSQL's JSONB, which is
> actually quite neat), and now all the *buffers rules (protocolbuffers,
> flatbuffers), and who knows what else I might be missing.  Oh, and
> things like MIME, which in fact are encoding rules.  And SSHv2, and TLS,
> and...  And S-expressions, and Perl5 data dumper, and...
>
> Easy, safe prediction: we'll have more encoding rules soon.
>

True. But here is the thing, I have a series of schema driven parsers that
use essentially the same schema language to create parse r for ASN.1, XML,
JSON, DNS Records, TLS, RFC822, RFC821 etc. I can throw out YANG, SML
Schema, Relax etc. if needs be as well.

The basic principle is to allow the basic encoding to be specified (e.g.
integer) plus hints if needed in addition (e.g. 16bit, 32bit, signed,
Little, Big endian, etc.)

Yes.  The decisions made in both DER and CER make both of them difficult
> to use in actuality.  The ITU-T could have made better choices for a
> canonical flavor of BER :(
>

Had they chosen to require lists, sets, etc. to use the indefinite length
encoding instead, the problems would have gone away. But nobody got round
to implementing until after they made that choice.



> > 5) The botched DER encoding is even worse because the nested lengths is
> the
> > use of nested variable length length specifiers. This means that the only
> > efficient strategy for encoding ASN.1 is to fill the buffer in the
> REVERSE
> > order starting with the last item.
>
> It's worse: you have to realloc as you go, or build a rope, or do one
> pass to compute length and one to encode.  DER is truly awful.
>

I use the rope trick.

One thing we've learned is that we *don't* want directories or white
> pages of any kind, not outside the corporate environment.
>

I disagree. There is a role for a personal directory mapping local names to
devices and users. It just looks nothing like the nonsense of X.500 and
LDAP.

If I say 'close garage door', it is implicit that it is the one connected
to the house I am currently in. And I want my Apple, Google, Microsoft,
DEC, etc. devices to all make use of the same local names in the same way
which mean that they have to be MY local names from MY directory, not
whatever sludge the AI heuristics driving Siri, Alexa, Hal, etc. try to
infer.

Basically, if we want to sell consumers hundreds of IoT devices then we
have to either admit that all that stuff we sold to enterprise customers
was unnecessary and they never needed it or decide it is needed and find
some way to provide the same sorts of functionalities but without the make
work that enterprise software sales require.