5 ms·
I implemented X.509 several times in the late 90's. Generalized ASN.1 is a mess: I don't believe there were any decent open source toolsets then, and the code e
by timdierks 12y ago
I implemented X.509 several times in the late 90's. Generalized ASN.1 is a mess: I don't believe there were any decent open source toolsets then, and the code emitted by the ASN.1 compilers I could test was lame and required you to adopt their conventions completely through your code.
Furthermore, ASN.1 has the usual lameness you get when people build generic description languages: for example, it's quite common to encode a particular ASN.1 structure, and then put the resulting structure into an OCTET STRING for inclusion in a parent structure (take a look at Extension in RFC 5280's ASN.1, for example). This is presumably because ASN.1 didn't (doesn't?) support an ANY type to allow inclusion of arbitrary structures that the decoder didn't know how to parse, so there's no extensibility without such tricks.
In the end, I punted and just used BER/DER directly without ever using ASN.1. This made a lot of things much simpler and produced much smaller and more efficient code (e.g. my cert parser for our SSL library for the Palm III ran with no additional allocation space, and compiled to a few K of code).