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