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

Nico Williams nico at cryptonector.com
Tue Nov 21 16:05:05 EST 2017


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

?

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.

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

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

Nico
-- 


More information about the cryptography mailing list