The problem with ASN.1 is that it is big and complicated, and you only need a fraction of it for cryptography, and it isn't really used for anything outside of pki anymore.

It wouldn't be as bad if asn.1 had cought on more as a general purpose serialization format and there were ubiquitous decent libraries for dealing with it. But that didn't happen. Probably partly because there are so many different representations of asn.1.

A bespoke serialization specifically for certificates might actually have aged better, if it was well designed.

▲

jll29 3 days ago | parent | next [-]

Assuming there are some libraries for it, would this make a pretty good case for LLM-generated ports of these existing libraries into other languages or onto other OSs/platforms? One implementation could be treated as "the spect".

▲

pocksuppet 3 days ago | parent | prev [-]

ASN.1 is protobufs designed by committee. It is a general-purpose serialization format, but there's no good reason to choose it instead of protobufs.

	▲	thayne 3 days ago \| parent [-]
		> It is a general-purpose serialization format Yes. My point is that in practice it hasn't really been used for much outside of cryptography. > there's no good reason to choose it instead of protobufs Well, the reason it is used in a lot of the places it is, is because protobufs didn't exist when those protocols or file formats were created. There are also some things that ASN.1 does better at a technical level. Of important significance to cryptography is that the DER representation is "canonical", meaning that there is only one way to serialize a set of data to bytes. That's important because it means that you can just hash the contents of the serialization for signatures, rather than having to have some kind of separate canonicalization step (which is a common source of mistakes).