On the surface, he is right, of course: ASN.1 is an overly complex domain-specific language which consists of two major categories of languages: a schema language, specified in X.680, X.681, X.682, and X.683; and a number of encodings. There is, however, one encoding in there that I happen to like for its mix of efficiency and simplicity: it’s called DER, for Distinguished Encoding Rules, and is a subset of BER, the Basic Encoding Rules, both of which are defined in X.690 (along with the Canonical Encoding Rules).

DER is a nice encoding in that it consistently encodes values as type-length-value types which the values themselves can be sets or sequences of type-length-value tuples. Values are encoded in (close to) their smallest possible representation in whole octets. This makes DER reasonably easy to decode.

Hence, I replied with

I.e. the problem is in the schema language, which defines innumerable string types which can all be represented in the same way (as an std::vector). I as much here:

Before I go much father, I should note that the way I debate things often leaves me arguing for the minority position: I challenge the preposition ruthlessly, relentlessly and fearlessly until it either crumbles or survives. ASN.1 implementations are crappy more often than not, DER decoders are no exception. However, these are implementation issues that are not sure to ASN.1’s design. Disregarding X.681, X.682, and X.683, XER, BER, CER, and PER, a safe subset of ASN.1, using X.680 and a subset of X.690, exists.

So, I stopped on the side of the road:

and started coding.

Two weeks later, I decided that this might be interesting for this website, so as of now:

• All commits on the master branch will be shown here, with their commit message (updated: due to the way this site is implemented, you’ll have to click the “commits” link above to get to the commits)

• I will occasionally post here to explain a few design decisions

• You can ask questions for particular commits in the comments of the corresponding post.