Ted,
Take a look at ftp://ests.bbn.com/pub/outgoing/asn_src/...
You will find a full-function, production quality
ASN.1 to C++ compiler.
Well, in the Kerberos V5 distribution, for a while we were using ISODE.
The ISODE subset that only included the ASN.1 compiler and its
associated support libraries was 3 megabytes of source. (That's right,
3 ***million*** characters.....) The entire krb5 distribution,
including the rlogin, telnet, pop applications, as well as the Kerberos
V5 and V4 libraries, the Kerberos KDC, and other Kerberos client and
administrative tools, was 5 megabytes.
Sorry to hear about ISODE. It was one motivation for us for generate
a compiler of our own. Our ASN.1 library (C++) weighs in at only 116K.
The compiler source is 162K. Portable to Solaris1 and 2 and early
returns indicate no problem with MSDOS and Win3.1.
Supports BER, DER, etc. No flags, you call the member function you
want at runtime. Support for ANY DEFINED BY, EXTENSIONS, SIGNED,
automatic syntax checking (did you forget a non-OPTIONAL element or
pass in a T.61 string instead of a PrintableString ?), etc.
Hence ISODE added an additional 60% of code which had to be audited for
security holes/bugs. We've since replaced the use of ISODE with
hand-coded ASN.1 routines, which is only 120k of souce --- a reduction
in size by over an order of magnitude. People may be amused to know
that the glue code that we had been using to interface the krb5 library
to the ISODE generated ASN.1 parsers took more space than the hand-coded
ASN.1 routines did themselves; so much for the benefits of using an
ASN.1 compiler. However, even the hand-coded ASN.1 routines were
definitely much harder to write and are larger than the equivalent
routines would have taken to to parse some custom binary or text based
format.
It is true that C++ (gcc 2.6.3) adds size overhead.
Again drawing on the Kerberos V5 experience, we also had a large number
of incompatibility headaches with different implementations, in
particular with the OSF DCE (which was released to the world with the
wrong flag passed to the Mavros ASN.1 compiler, so it produced BER
instead of DER. This made the verification of crypto checksums in
Kerberos protocol requests generated by DCE implementations
particularily interesting....) This and several other interoperability
headaches can be directly attributable to the mistake we made of using
ASN.1 in the Kerberos protocol.
We have tested ours against as many different encodings as possible.
Knowing what I know now, I don't think I would never design something
new using ASN.1, unless there was a gun pointed at my head. For a
worked counterexample of how to specify interchangable, interoperable
certificates, take a look at how PGP specifies its key and certificates.
It's still a binary format, but it's much easier to understand the
specification, and it's far easier to write and debug programs that use
its certificate formats.
- Ted
Don't let one ugly experience dissuade you. I have also used ISODE.
(I also used cc68 and lnk68 in the early years but it didn't convince
me to abandon C either.)
Try it, you'll like it !
Thinking of "Green Eggs and Ham",
John Lowry