ASN.1 and Kerberos version 5
-----BEGIN PGP SIGNED MESSAGE----- Perry E. Metzger writes:
I've heard people associated with the decision to use ASN.1 in Kerberos V say it was a mistake. Frankly, I think ASN.1 is a blight which should be exterminated from the planet.
I'll say it. I was the person who pushed for the use of ASN.1 in Kerberos version 5. I had this disease at the time that made me think that ASN.1 was a good idea. I got better, unfortunately we have been living with the results of my braino for quite some time now... poor Ted. However, the problem with ASN.1 isn't its waste of space (which actually isn't that bad for a mechanism for encoding arbitrary objects). The problem is that it is the product of a standards making process that didn't (and doesn't) value interoperability. Adherence to the ISO specifications does not guarantee interoperation. Instead regional "workshops" negotiate aspects of implementations to obtain interoperation. What does this mean for ASN.1? It means that the definition of ASN.1 is a bit abstract (as its name implies). Problems result when two organizations (say MIT and OSF!) attempt to implement from the specification in ASN.1 but use different ASN.1 compilers and things then don't work. Arguments then ensue about whose compiler (or manually written parsing code) is "correct" in terms of doing the right thing with ASN.1. This is particularly so when using DER (for Distinquished Encoding Rules) which is itself an after-thought added to ASN.1 later in the process. It is required in order to verify digital signatures (which have to be computed on the "encoded" form of an object because there is no good way to calculate a signature on an "abstract" object). If the Kerberos specification said: "pub this byte here and that one there" none of these arguments and problems would happen. -Jeff -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMEiaf8UtR20Nv5BtAQFzNAP/Q/LuIMbxAPAp64Kn2PSPd600TYlRAUJh QbsuL/iRhGXWrxSjsFzkcr6e3sIpSFggxglFU38TJT/DG2AD8MOid3Uj4pRJVbyo z7Au0Vp1NiotmRBHq2udItzJ7LLPM0j38FHQenqPs9mkX2Cq5kVgGUBO94HabEuE S9XPCgV8E1Q= =kTyw -----END PGP SIGNATURE-----
I don't think that the concept of ASN.1 is as bad as Jeff makes out. If it worked then ASN.1 would be very very usefull. But is just plain don't. ASN.1 is worse than useless, it means that a very good idea is rendered unusable because of a baddly botched implementation. The ambiguities of the ASN.1 spec are at least as bad as Jeff makes out. I have attempted to implement an ASN.1 compiler but I have little cofidence in its correctness because the structure of ASN.1 is so unweildy. It is not just ANY that causes problems, IMPLICIT is a complete cock up. ASN.1 is poor because it is unecessarily complex, has little intelectual coherence and has been extended in a manner which conflicts with the original design principle. Is it any coincidence that ASN.1 backwards is the name of a well known organisation? Also the only person who has defended ASN.1 to my face happened to work for that organisation once. So the motto is: ASN.1 - Just say NO! Phill
participants (2)
-
hallam@w3.org -
jis@mit.edu