> ASN.1 implementation bugs have also caused security problems for SSL, > Kerberos, ISAKMP, and probably others. These bugs are also not due to > shared code history: they turn up again and again. > > Are there any other binary protocols that can be usefully compared with > ASN.1's security history?
There is indeed a lot of complexity in ASN.1. At the root, ASN.1 is a basic T-L-V encoding format, similar to what we see in multiple IETF protocols. However, for various reasons, ASN.1 includes a number of encoding choices that are as many occasions for programming errors: * In most TLV applications, the type field is a simple number varying from 0 to 254, with the number 255 reserved for extension. In ASN.1, the type field is structured as a combination of scope and number, and the number itself can be encoded on a variable number of bytes. * In most TLV applications, the length field is a simple number. In ASN.1, the length field is variable length. * In most TLV applications, structures are delineated by the length field. In ASN.1, structures can be delineated either by the length field or by an "end of structure" mark. * In most TLV applications, a string is encoded as just a string of bytes. In ASN.1, it can be encoded either that way, or as a sequence of chunks, which conceivably could themselves be encoded as chunks. * Most applications tolerate some variations in component ordering and deal with optional components, but ASN.1 pushes that to an art form. * I don't remember exactly how many alphabet sets ASN.1 does support, but it is way more than your average application. * Most applications encode integer values by reference to classic computer encodings, e.g. signed/unsigned char, short, long, long-long. ASN.1 introduces its own encoding, which is variable length. * One can argue that SNMP makes a creative use of the "Object Identifier" data type of ASN.1, but one also has to wonder why this data type is specified in the language in the first place. Then there are MACRO definitions, VALUE specifications, and an even more complex definition of extension capabilities. In short, ASN.1 is vastly more complex that the average TLV encoding. The higher rate of errors is thus not entirely surprising. -- Christian Huitema _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
