There has been some discussion of the pros and cons of using ASN.1 in X.509
certificates, with Steve Crocker and Donald Eastlake of CyberCash being among
the most vocal critics. Others have weighed in on the pem-dev list with
opposing views, and I thought it might be useful to summarize on these views on
the e-payment list, for the benefit of those who don't monitor both lists.
The negative comments (Steve Crocker) related to the complexity, difficulty in
debugging, and difficulty in reaching closure on the precise specifications.
Carl Ellison of Trusted Informaton systems commented that the ASN syntax
encourages people to write small, deeply nested definitions as one would with
BNF, But that produces overhead in message size and requires CPU cycles for
packing and unpacking. and general purpose ASN.1 compilers often generate
inefficient code, resulting in large object programs. Theodore Ts'o of MIT
related a horror story of using the ISODE ASN.1 compiler, which required 3
megabytes of source code. Replacing that with hand-coded ASN.1 routines reduced
the source to 120K. The OSF DCE was released with the wrong flag set to the
Mavros compiler, resulting in BER ratther than DERs being generated, causing
lots of incompatibilities.
On the positive, side, Amanda Walker of InterCon System Corp. said:
"I've done plenty of ASN.1 stuff without a compiler. It's small and fast.
I actually *like* ASN.1 at this point, because of its lack of ambiguity.
I really like self-describing compound data representations.
The biggest problem with ASN.1 is that people expect to be able to use it
without thinking about it, in my experience. It's just tagged data, after
all. A general-purpose ASN.1 compiler has to generate general-purpose code,
which is quite a bit of overkill for most applications."
John Lowry of BBN reported that their ASN.1 to C++ compiler source is 162K and
is portable to Solaris 1 and 2, MSDOS, and Win3.1. The ASN.1 library is 116K.
It includes support fo ANY DEFINED BY, EXTENSIONS, SIGNED, and has automatic
syntax checking. Charles Gardiner of BBN reported that they used the BBN
compiler on a project with lots of ASN.1 and programmers who had never dealt
with ASN.1 before. They were up and running in no time, and at integration time
the pieces fit together very smoothly. Carl Ellison reported that despite his
dislike of ASN.1, he thought the BBN compiler was well done.
In summary, it does not appear that there is is anything that is inherently
wrong with ASN.1 per se. The fact that it is an international standard that is
widely used in many different application fields is a significant aid to
interoperability, and the strong typing and extensibility of ASN.1 defined
attributes should help considerably when adding new features to ASN.1-based
systems. These benefits should more than outweigh any concern for a modest
increase in message overhead, which is part of the price paid for the
generality and flexibility of self-describing objects.
However, ASN.1 may have an initial learning curve that should be taken into
account when planning a project. And the size of the code and object libraries
associated with a general purpose compiler must also be taken into
consideration.
If I were starting a new project that involved abstract data types and was
likely to see considerable evolution over its life, and especially if
interoperation with other systems was likely to be required, I would
undoubtedly use ASN.1. Certainly for the first or prototype version, I would
use the BBN compiler to generate C++ for the ASN.1 to ease the debugging and
integration. Then, perhaps in the second version, I would analyse the resulting
code to see which sections, if any, generated egregiously large C++ code, took
a disproportionate amount of run time, and/or messages with obviously
inefficient structures, and then redesign or hand-code those sections to
optimize them.
Bob
--------------------------------
"Robert R. Jueneman" <Jueneman(_at_)gte(_dot_)com>
Staff Scientist, Wireless and Secure Systems Laboratory
GTE Laboratories, 40 Sylvan Road, Waltham, MA 02254
Waltham office: Voice: 1-617-466-2820, FAX: 1-617-466-2603
Telecommuting: Voice: 1-508-264-0485, FAX: 1-508-264-4165