ASN.1 is a ludicrously complicated format for what it does.
Its designers added all sorts of ways to save a few bits here and there by creating optional special cases to be handled in the encoders and decoders.
This makes complicated code with lots of edge cases for bugs to hide in, Cisco SNMP implementations were notoriously savaged by this. Ironically, it also requires lots of branches which slow down modern processors more than just reading the bits.
Fortunately most uses of ASN.1 have died. SNMP and SSL are still using it. It's not 1984 anymore, let it die.
Actually, all of the SNMP implementations were savaged by ASN.1/BER implementation bugs: the format is so poorly understood that virtually all of them derived from the same code.
There is a trick to ASN.1/DER encoding that gets it down into the hundreds- of- lines- of- code range (you get the whole document in memory and serialize/unserialize it backwards). I once wrote a program that converted arbitrary ASN.1/DER/BER buffers into a shell script that regenerated the same. It's not as complicated as it looks, but it's idiosyncratic and you have to think about it a specific way.
That said: I agree, it should be scorched off the planet with fire.
How do you go backwards? You don't know the length of the last element/position of the last tag unless you work forward from the front, as far as I can see.
BER is complicated, but no more complicated than rfc-822 style headers, which are also poorly parsed by ad-hoc parsers, and were a wide source of vulnerabilities.
But it did successfully mitigate, if not kill, the threat of having Sun's XDR (eXternal Data Representation) become the defacto way of describing complex data structures. The arguments that ASN used in the RPC standards wars were "no need to bundle both a description and the data", "new stuff could be added without changing clients", and "all systems (little endian and big endian) have similar data conversion costs."
It was a really annoying war (I suspect there isn't any other kind although some people apparently really enjoy the standards 'game').
My favorite quote from Bob Lyon at the time, "Try to solve the problem, not the future."
I vaguely remember that parts of the GSM protocol were also described using ASN.1 (BER). I'm not sure how relevant this is for newer cellular network protocols, though. But if so, that makes it unlikely it will go away soon.
Since it was standardized by ITU, it's still used in newer telecom protocols, and it's pervasively used throughout higher level cryptography-related protocols/standards, CAdES is one of the more recent ones and gaining acceptance in the EU. Seems like we have to live with it for a while...
It is being used in much more than just telecom and cryptography. Even the UPU use it for tracking packages that get shipped. Take a look at Space Link Extension (for space communications) that uses ASN.1 also.
The 1984 version of ASN.1 should die, but the 2008 version is widely being used in many industries. Digital Certificates still use it. Air-to-ground communication uses it. Financial services are using it. LTE (the next generation of mobile telephony) uses it. Electric Utilities are using it in monitoring power lines. Toll Roads are using it for those electronic payments so that you don't have to stop at toll booths. Incident Management - Fire, Ambulance, Police, Trafic Control, etc - use ASN.1. I could go on naming other areas as well. The 2008 Edition of ASN.1 is definitely NOT dying!!
The recent ANSI/NIST ITL-2011 biometric standard is XML Schema based, but includes a TYPE-98 security record that is nothing but ASN.1. ASN.1 was chosen to meet performance requirements, as XML-based cryptographic messaging was found to be too slow.
The just published DoD EBTS 3.0 standard uses ITL-2011 and is also defined using XSD. But it too looks to an ASN.1 binary representation of its XML markup messages to get the data compression and performance needed for high volume transaction systems and hand held mobile biometric collection devices.
Its designers added all sorts of ways to save a few bits here and there by creating optional special cases to be handled in the encoders and decoders.
This makes complicated code with lots of edge cases for bugs to hide in, Cisco SNMP implementations were notoriously savaged by this. Ironically, it also requires lots of branches which slow down modern processors more than just reading the bits.
Fortunately most uses of ASN.1 have died. SNMP and SSL are still using it. It's not 1984 anymore, let it die.