> I wonder how long until we collectively decide to banish things like ASN.1 to the past Indeed, in the security community there is a trend to get rid of ASN.1

> I wonder how long until we collectively decide to banish things like ASN.1 to the past Indeed, in the security community there is a trend to get rid of ASN.1. E.g. TLS uses a custom ad-hoc format: https://datatracker.ietf.org/doc/html/rfc5246#section-4 https://datatracker.ietf.org/doc/html/rfc5246#section-4 And this is used by e.g. certificate transparency: https://datatracker.ietf.org/doc/html/rfc6962#section-1.2 https://datatracker.ietf.org/doc/html/rfc6962#section-1.2 Maybe it's just a question of tooling, but personally I haven't found a binary format that is as nicely debugable as ASN.1. In many other instances I have to stare at hexdumps while for ASN.1, the lapo.it viewer exists. E.g. I still haven't been able to parse the extra_data of a certificate transparency log entry. In the case of ASN.1, you can dump it to lapo.it. How can you debug data in the ad hoc TLS format? There is literally no information in the binary format, you must know the schema. That being said, it's indeed more difficult to write parsers for ASN.1 formatted data without using ASN.1 libraries. The ad hoc TLS format definitely has an advantage here. But IMO ASN.1 has way too much of a bad name.