Date: Wed, 27 Sep 1995 15:22:08 -0700 From: Bill Stewart <stewarts@ix.netcom.com>
Bill,
I'd always heard X.509 public key certificates were a hierarchical, evil, anti-WebOfTrust ISOism. But Netscape is now doing them, and talking S/MIME, so I sat down to read the specs, and they're really not all that bad.
I was all set to scream, when I read this first sentence. Then I read on.
(Technically, I've only read PKCS#6 and RFC 1422, and not the real ISOisms...) Yeah, they've got lots of clunky ASN.1 Ambiguous Encoding Rules and X.500 Silly Name Format, but those can be lived with, and the X.500 may be possible to simply ignore in most cases.
At this point, I realized that we agree in evaluation but not in weighting. Twice now, I have had to deal with X.509 certificates in real code and it is excruciatingly painful -- especially for someone, like me, with some background in performance engineering and much background in software engineering. ASN.1 is not merely ambiguous, it is actively wrong as part of a design methodology. It encourages people to define structures in the BNF style -- and they do (witness X.509). When you translate this into C or PASCAL structures by an automatic translator, you end up with structures whose definitions are nested so deeply that even with short field names you would have variable names which occupy a substantial part of a line of text. However, ASN.1's BNF-ness encourages people to use longNamesWithEmbeddedCapitals -- so you end up with variable names which turn routine C function calls into multi-line, unreadable blocks. You also end up with too much code. I recently had to deal with X.509 certs for an authentication application (a firewall proxy). The proxy was about 30KB of code prior to the ASN.1. The ASN.1 code, just to do packing and parsing, was over 100KB (.o file sizes, in both cases). You also end up with too many bytes being transferred. I worked out an example of ASN.1 abuse -- defining a triple-DES key structure for encrypting and transmittal -- as a raw C structure (following long established practice and performance engineering (an array of unsigned char, with offsets for each key and the IV)) and as ASN.1 (following modern ASN.1 practice). The raw C structure was 32 bytes long. The ASN.1 structure was 86 bytes. Worse was the code dedicated to structure definition and packing/unpacking. In the raw C case, it took 48 ASCII characters to define the structure and its offsets (including comments) and nothing to pack/unpack. With ASN.1, it took 55085 characters of definition, pack and unpack code. This is a factor of 1148 in source code expansion. -------------------------------- I could go on at length, and have in other fora. Not only is ASN.1 clearly the work of Satan, the Distinguished Name definition is more than a victim of ASN.1 generality, it is a clear reason for the unpopularity of systems which use it. Do you remember when X.400 names started showing up in e-mail (e.g., with Lotus Notes). How many of those names do you see now? It didn't work. The concept is flawed -- but it lives on in X.509. [It reminds me of a flaky grad student's idea of a way to do things -- elevated to standard before people had the chance to try it and discover how completely bogus it was.] It is possible to implement something which reads and writes ASN.1 -- but it is ugly, it inflates your code and it hurts your runtime. I would like to see as many hold-outs against ASN.1 and Distinguished Names as possible. PGP is one such. TIS/MOSS has learned its lesson (from PEM days) and is making all of the ASN.1 and DN stuff (X.509) optional. With luck, the X.509 parts will die away (although MOSS was retarded so strongly in the PEM days that it may never recover -- may never acquire the market share to make it a force). I would strongly encourage others to join the battle. This might not be easy. It is clear that there is an ASN.1 juggernaut. It is taking over all sorts of standards. I believe I know why. It makes the job of the standards writer easier. However, I also believe it needs to be fought...not merely to save future S/W development efforts from the waste and abuse which ASN.1 creates, but also to take a stand against the process by which non-implementors get together on standards committees and come out with standards which preclude good software architectures -- and who, in a kind of old-boy-network, endorse other standards (e.g., the ISO set) as part of their own. Such a design process is destructive. - Carl +--------------------------------------------------------------------------+ |Carl M. Ellison cme@tis.com http://www.clark.net/pub/cme | |Trusted Information Systems, Inc. http://www.tis.com/ | |3060 Washington Road PGP 2.6.2: 61E2DE7FCB9D7984E9C8048BA63221A2| |Glenwood MD 21738 Tel:(301)854-6889 FAX:(301)854-5363 | +--------------------------------------------------------------------------+