[mcs]

ASN.1 parsing in implementations of several different standards have had this class of issue for well over a decade. ip phone and software stack vulnerabilities in, for example in asterisk, specifically for ASN.1 handling have probably been used by our intelligence community for a long time. The safe implementations are probably ran in virtual machine languages.

[cyphar]

I think we should all agree to move from ASN.1 as quickly as possible. Many implementations don't include some of the wacky features (like recursive serialisation of structures), because nobody needs them and they cause bugs. But there is so much more weirdness in ASN.1 that it would honestly be much nicer if we used JSON (as an example of the other extreme). Maybe there's a nice binary, typed format which doesn't resemble the 80s we should be using.

[zeveb]

This is why the SPKI guys, seventeen years ago, made one of their design goals not using ASN.1: https://tools.ietf.org/html/rfc2692 states 'No library code should be required for the packing or parsing of SPKI certificates. In particular, ASN.1 is not to be used.'

They came up with a simple, beautiful representation for certificates. They also came up with a simple, logic, understandable way to think about what certificates can and cannot do.

The world ignored them. RFCs 2692 & 2693 stand as a remarkable example of what could have been.

[lmm]

Thrift/Protobuf/etc. are reasonably nice IME.

[cyphar]

The cool thing about protobuf is that it allows automated parser generation (that isn't some horrific hack built on bison). The downside is that if there's a bug in someone else's code, it becomes a bug in your code. :D

[spc476]

CBOR (RFC-7049) comes to mind.