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

[Phillip Hallam-Baker]

On Fri, Nov 24, 2017 at 4:11 PM, Nico Williams <nico at cryptonector.com> wrote:
> 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.

Nothing could be a tenth the burden that Asinine One has been.


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

JSON-B adds the missing binary type and an unescaped string type. Job done.


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

There is actually something I hate more than ASN.1 and it is SQL.

Why on earth would I want code injection heaven near my systems?


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

I could produce ASN.1 simply by changing one switch on the synthesizer
but I won't because ASN.1 is less popular than Ebola in some parts and
I am not going to spend my time and effort on restoring its
reputation.



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

Or just use a modern encoding like JSON-B.