3 ms·
IDK if you would say that ASN.1 (DER) is 'bit packed', but I still kind of like it. I had some young feller tell me some time back why ASN.1 was the anti-chris
by ci5er 8y ago
IDK if you would say that ASN.1 (DER) is 'bit packed', but I still kind of like it.
I had some young feller tell me some time back why ASN.1 was the anti-christ, but I can't remember (for the life of me why). Do you happen to know/remember why ASN.1 is 'bad'?
I can write 8-bit assembler to it - I can write 32- or 64- bit compiled C to it, and it's pretty easy to create an FPGA pre-processor (and router) for it, and it certainly is more constrained than random JSON strings. What's wrong with ASN.1? Too old?
- wmf 8y agoASN.1 has multiple ways to serialize the same message which opens it up to bugs in rarely-used code paths. And every ASN.1 implementation was rife with security holes. But mostly ASN.1 comes from the same "bad neighborhood" as CORBA, X.400, X.509, OSI protocols, etc.
- ci5er 8y agoFair enough - there were bugs in specs (like the X.509 letting you attach arbitrarily large image or blobs), but mostly I found that the compilers were buggy. Whenever (way back in the day) we (our/my company) did SET (secure 3P "secure" credit card protocol) with competitors (MS/HP/RSA/IBM/Netscape/etc.), because we compiled an interpreter from the spec, we were able to put in code-path switches depending on the counter party and adapt. Since they had a buggy compiler from a 3rd party - they could not. Was that an issue with ASN.1? Or crappy tooling that people used?