Can't blame him. ASN.1 is one of the most complicated binary formats, with so many encoding rules that there's no free decoder that can process them all.

Shameless plug, but you may be interested in my library (which is MIT/Apache-2.0) that offers decoding from BER/DER/CER all from a single model in code, there's no UPER/APER support at the moment, but it's coming in the next few months. :)

https://github.com/XAMPPRocky/rasn

You mean DER, not ASN.1. ASN.1 is just notation for describing data. There are many encoding rules for ASN.1, including ones based on XML and JSON.

Except for interoperability with existing systems, is there any reason why anyone would use this ASN.1 protocol/format?

What's it good for?

In my opinion, avoid ASN.1 if you can.

There's a reason why all the cool companies invented their own serialization formats: Google's Protobuf, Facebook's Thrift, etc.. even when ASN.1 had been an international standard for years: It's too complicated.

The big part of the reason is combination of NIH with bad reputation mostly related to X503 and such rather than anything else - hard to advocate for it when the main library you can point to is OpenSSL, and most commonly known encoding is DER (which has certain implementation complexity, effectively being sorted BER, which has certain important value in cryptography).

Both Protobuf and Thrift evolved from RPC systems that possibly started out too simple for ASN.1, combined with above issue where good tools were probably commercial and expensive (FWIW, my experience also suggests that Thrift is shitty rpc system, compared even to Sun/ONC RPC, but maybe things changed)

No. It mostly exists so that people who haven't tried to use it can tell other people that they should have used ASN.1.

ASN.1 is incredibly good for one use case: As a cautionary tale against design by committee.

BER/DER/PEM encodings are mostly quite simple, have very few subtle details.

Yeah, those are the easy one. I worked in Telecom, and dealing with unaligned PER is a PITA.

Hi, here is issue related to this where i explain a bit what would be required https://github.com/wader/fq/issues/20 and how protobuf support currently works.

note that the tool linked is for binary files. ASN.1 is text, isn't it?

I assume they meant the binary encodings of asn.1 like BER/DER.

And tangentially PEM, which is Base64-encoded DER.

That’s what I thought until recently, but it turns out that PEM refers to just base64 wrapped with ——BEGIN—— and ——END—— lines, and the encapsulated data does not have to be DER.

https://datatracker.ietf.org/doc/html/rfc7468