<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Nov 13, 2017 at 6:11 PM, Ron Garret <span dir="ltr"><<a href="mailto:ron@flownet.com" target="_blank">ron@flownet.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">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:<br>
<br>
<a href="https://github.com/rongarret/tweetnacl/blob/master/ratchet.lisp" rel="noreferrer" target="_blank">https://github.com/rongarret/<wbr>tweetnacl/blob/master/ratchet.<wbr>lisp</a></blockquote><div><br></div><div>I've also been working on a project which is, at least in part, borne out of similar frustrations:<br></div><div><br></div><div><a href="https://github.com/zcred/veriform">https://github.com/zcred/veriform</a></div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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:</div><div><br></div><div><a href="https://www.tjson.org">https://www.tjson.org</a></div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div> </div></div>
</div></div>