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

[Phillip Hallam-Baker]

On Tue, Nov 21, 2017 at 4:05 PM, Nico Williams <nico at cryptonector.com> wrote:
> On Wed, Nov 22, 2017 at 04:20:45AM +1000, James A. Donald wrote:
>> On 11/16/2017 3:10 AM, Nico Williams wrote:
>> >Everything we've discussed in this thread, from TLV vs. XDR-like vs.
>> >textual vs. markup encodings, canonical vs. not, online vs. not,
>> >extensibility, notation, mapping to/from other schemes (e.g., XML
>> >Schema) -- it's all there in ASN.1's history, and, indeed, in the
>> >x.68x and x.69x specification series.  We have decades of experience
>> >with ASN.1 in the ITU-T and IETF, and in the communities that
>> >implement protocols that use it.
>>
>> I could not find a tool that would produce canonical byte aligned PER
>> decoding and encoding on both Windows and Linux that did not involve a
>> frightening and confusing license.
>>
>> Let alone manage the sockets and protocol negotiation when forming a
>> connection.
>
> 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


> If you do (a), chances are you'll do something like what Google did with
> Protocol Buffers: i.e., miss important considerations.  And worse:
> you'll burden the rest of us with building yet more tools.

The most important issue for me is not having to bother with the whole
ASN.1 hate thing. Too many people have been burned by ASN.1 already.
They just don't want to hear about it.

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.

Since I already generate ASN.1, JSON, TLS and XML
serializers/deserializers from my tool set, I could almost certainly
add Protocol Buffers in a couple of days if I needed. I very much
doubt I have left any important requirement out since I have already
supported all the most commonly used formats.


> If you do (b) you have less work to do.
>
> 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.


>> I have no plans to reinvent the wheel.  I am looking for a wheel someone
>> else has built.  ASN/1 PER was the first thing I looked at. There seem to be
>> an absurdly large number of wheels available, but ASN.1 PER is not one of
>> them.
>
> There are few wheels like PER out there at all.  The closest is XDR.
>
> You will not make a serious mistake in picking XDR, though the tools
> that exist for it are not very good.
>
> 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.