Quoteing asn1 / rd.francetelecom.com, on Tue, Mar 18, 2003 at 06:11:03PM +0900:
> "MikkelFJ" <mikkelfj-anti-spam / bigfoot.com> wrote in message news:<3e6c9416$0$142$edfadb0f / dtext01.news.tele.dk>...
> > Problem is that ASN.1 isn't widely supported outside specific application
> > protocols such as encryption and multimedia.

That's because its hideous to work with. It has all the problems and
ambiguities of other formats, such as XML, or the IETF text-based
formats, except that when something goes wrong, you're staring into a
hex dump trying to figure out what went wrong where. And it can't make
its mind up about how to represent strings, so you get to pick from a
half-dozen encodings. It's also got a theoretical abstraction between
the ASN.1, and the many ways of encoding it, some of which doesn't make
sense in the abstraction (try explaining ASN.1 implicit vs. explicit
tagging without describing BER...).  Then explain the DTD format for
XML, then try to explain the latest ASN.1 syntaxes...

To which, everybody says "don't write hand encoders, use a tool". Yeah,
sure, they're hopelessly complex, and have huge run-time code and data
overheads.

Anyhow, sorry for the rant, but I've spent a year implmenting encoding
of various crypto standards, and I can't say I've learned to like
ASN.1/BER any more with my experience.

XML is at least readable, by comparison. Though I have to say, given the
success rate implementors have getting DER correct (low), the chance
that anybody is going to cannonicalize XML to verify a signature I
estimate as laughable. I still can't believe they repeated the worst
mistake of the crypto community with ASN.1, belief in "distinguished"
encodings.

Anyhow, sorry for the rant!

Good luck to anybody who has to work with ASN.1,
Sam

> ASN.1 is used in a lot of other application domains.
> For a (non-exhaustive) list, see
> http://asn1.elibel.tm.fr/uses/
> 
> A list of (free and non-free) ASN.1 tools is also available at:
> http://asn1.elibel.tm.fr/links/#tools
> 
> O. Dubuisson
>