A warning, ASN.1 is disliked by many people in software security. It often features in security vulnerabilities involving TLS and LDAP/Active Directory. They would recommend against adopting ASN.1 for new projects.<p>I get the impression this partially due to a) most implementations being adhoc, of varying completeness, and written in C or C++ (e.g. OpenSSL); and b) sheer complexity of ASN.1 and other standards from that family/era.<p>Sources: following software security researchers/practioners on Twitter, a few podcasts, here, etc.
How does ASN.1 compare to something like binary protobuf?<p>I have no data to back this up, but I was under the impression ASN.1 is one of those specifications that is so large and complicated it’s essentially impossible to implement correctly; and that ASN.1 parsers are a pretty infamous source of security bugs (although I mean, most parsers seem to be).
If you're interested of learning more about ASN.1, two great books on the subject are:<p>- ASN.1 Communication between Heterogeneous Systems[0]<p>- ASN.1 Complete[1]<p>Both of which are available online for free. Last time I checked, they may not cover the latest fads like JER etc. but will provide you with a solid understanding of ASN.1 nonetheless.<p>[0] <a href="https://www.oss.com/asn1/resources/books-whitepapers-pubs/larmouth-asn1-book.pdf" rel="nofollow">https://www.oss.com/asn1/resources/books-whitepapers-pubs/la...</a>
[1] <a href="https://www.oss.com/asn1/resources/books-whitepapers-pubs/dubuisson-asn1-book.PDF" rel="nofollow">https://www.oss.com/asn1/resources/books-whitepapers-pubs/du...</a>
The bittorrent protocol uses a very simple binary data representation system: bencoding.<p>It can be described in a single paragraph: <a href="https://www.bittorrent.org/beps/bep_0003.html#bencoding" rel="nofollow">https://www.bittorrent.org/beps/bep_0003.html#bencoding</a><p>Although it supports only dictionaries, lists, ints and strings, it may be enough for your use case and is easily extendable.<p>Edit: also ASN.1 does not solve futute-extending out-of-the-box. In JSON/bencoding/XML, it's trivial to add another key/element to a dictionary/array/element and allow applications to use it if they can and ignore it otherwise. Okay, TLV looks like it could handle that, but there's nothing about it in the description language itself.
ASN.1 was great. Another old specification language still in use today is EXPRESS, one of the foundations of the huge ISO 10303 (STEP) standard series, as defined in ISO 10303-11. It even has algebraic data types. The development of STEP started in 1984 and has been one of the largest efforts ever undertaken by ISO.
Does ASN handle versioning of the messages?<p>If I add a field to the message I expect the new binaries to read the messages serialized by the old binaries and vice versa.<p>Obviously the old binaries are not expected to understand the added field but they should not break when handed the upgraded message.
If you ran into ASN.1 run away (if you can). It's so insane hopeless overenginered with so many intersecting standard, different representations and nobes that it can easily become a nightmare. Most parsers also only support an opinionated subset for a specific purpose simply rejecting everything outside of the supported sunset even if they by specification should support it. This night sound fine, until you actually run into it in production and two supposedly compatible systems more are incompatible with no easy fix around.
Its greatest weakness is 10 different string encodings. I've always wondered what sort of bugs you could expose with a cert using videotex for the CN fields.
this is cool. i’ve only ever used asn1 as content for metadata in x509 certs and it makes a tiny bit more sense now why this is better than a basic string encoding
I've been using asn.1 for 20 years now, and i find it absolutely fabulous. I still learn something new from time to time, when something doesn't parse or encode correctly :)
It's very clear the writer has not used ASN.1 or BER/DER encoding. There's no discussion of which standard for bit fields to use, constructed encoding, the practical requirement of an ASN.1 compiler or any security concerns.<p>Heck, why not just use CORBA?
Oh hey! There's quite a chunk of code in the Linux kernel to support this protocol. I hope that people here find some use for this "useful" old technology, otherwise it's just taking up space.
ASN.1: I can only imagine that one day someone said "Strings are bad for security" and some bold lad overheard and said "Hold my Beer!".
Nice to see someone actually put the TL;DR at the top for a change..<p>Never understood the logic of people putting them at the end of an article.. If I wasn't gonna read the whole thing, what makes you think I'm gonna scroll to the bottom?