[Cryptography] Is ASN.1 still the thing?

[Tony Arcieri]

On Mon, Nov 13, 2017 at 6:11 PM, Ron Garret <ron at flownet.com> wrote:

> I got fed up with the complexity of ASN.1 and DER and designed my own
> binary serialization format for my implementation of the Signal
> double-ratchet.  The only documentation is in the in-line comments of the
> original implementation, which was done in Common Lisp:
>
> https://github.com/rongarret/tweetnacl/blob/master/ratchet.lisp


I've also been working on a project which is, at least in part, borne out
of similar frustrations:

https://github.com/zcred/veriform

It's underspecified and incomplete, but generally follows a similar design
to Protocol Buffers. That is to say, it's TLV-ish (type and length are
combined into a single varint ala Protos), with numbered fields and an IDL
to describe schemas.

Why not just use Protos then? This is described at length in the README,
but tl;dr: I was trying to apply Ben Laurie's afforementioned ObjectHash
idea to Protos and ran into a particularly annoying problem: older clients
will be unable to calculate the ObjectHashes of unknown fields, i.e. the
content hash algorithm is coupled to the schema. I wanted to support a
format that allowed addition of new fields while still letting clients
calculate the same content hash. This requires a self-describing wire
format, which is unfortunately a property Protos do not have.

Additionally, I wanted to support an isomorphic text format for which the
same ObjectHashes would be calculated (even in the presence of binary
data), TJSON:

https://www.tjson.org

In TJSON I've also aimed to make a stricter format which eliminates many
common JSON ambiguities, including ones which are LANGSEC-relevant like
handling of duplicate keys.

Does this all sound a bit like reinventing csexps? Sure, but I strongly
doubt we'll see a csexp revival any time soon. I would like to carry
forward the best ideas of csexps, but with a succinct and easy-to-read JSON
syntax.

As for ASN.1, there are encodings that seem fairly reasonable like OER. But
the reality is BER/DER won, and if you're doing any IETF specification work
they're what you'll be strongly encouraged to use. Yes BER/DER are more
compact than OER or something like Protocol Buffers (although there's PER
if you really want to save space), but this comes at the cost of an awful
lot of complexity which has been the source of countless parser bugs.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20171114/69215095/attachment.html>