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

[Nico Williams]

On Wed, Nov 15, 2017 at 08:53:16AM +0000, Erwann ABALEA wrote:
> > By using extensibility markers.  Which Protocol Buffers.. does not have.
> 
> Correct. Or by declaring the module as EXTENSIBILITY IMPLIED, or simply by
> using BER/DER (where extensibility is implied in the deciding phase even if
> the module doesn't declare it).

Mind you, just using BER/DER/CER is not sufficient, since a decoder is
free to produce an error when it sees unexpected SEQUENCE fields.  And
for CHOICEs and SETs the extensibility markers are even more important.

ISTR reading some of the history behind ASN.1's extensibility rules.
They were motivated by both, PER and the existence of BER decoders that
complained about unexpected fields.  Of course, there are other
extensibility mechanisms that do not require special support from the
notation / encoding rules, such as "typed holes" (sequences of
{type_id, inner_value}).

What's interesting about that history is that there's been nothing new
since.  Ignoring ASN.1 is a really bad idea whatever one's reason for
ignoring it.

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.

When you reinvent a wheel with this much history, you will almost
certainly miss important ideas if you don't look at that history.

And, with this much history, you might as well just _use_ ASN.1 and only
build new tools as needed.  New encoding rules make sense for interop
with existing other systems, but that's about it.

Nico
--