digital signatures

[Peter Gutmann]

Neil Dunbar <nd@hplb.hpl.hp.com>

>I think DER *did* help -- just not enough. God knows that its full of
>ambiguities and bogosity at every level (my favourite is the encoding of
>BitStrings). I seem to remember that SSLeay had this "wrong" for a while,
>ie it did things in a logical manner. You'll know better than I when
>OpenSSL fixed it. Nevertheless, can you imagine trying to write systems
>which use *BER*? Actually, early LDAP drafts suggested BER encoding. Did
>anyone use BER over DER? Did they hell, and thank God for that.

The encoding isn't the problem, you just use an ASN.1 engine and encoding
issues pretty much go away.  Just as noone would, I hope, try to write an EDI
or XDR or XML or whatever parser from scratch, I hope noone's going to try
building their own ASN.1 engine using toothpicks and rubber bands.

The real problem with ASN.1 is the gargoyles which have been erected atop the
cathedral.  ASN.1 makes it easy to write the equivalent of unstructured BASIC
spaghetti code (although again this wouldn't be fixed with XML or EDI or
whatever).  The result of this is that we're seeing a flood of ASN.1-based
standards and protocols which look like the designers threw all the features
they could think of at a wall and kept the ones which stuck, with no
(discernable) logic or reason applied.  The two most horrible examples I know
of are X.400 (commented on in my X.509 style guide,
http://www.cs.auckland.ac.nz/~pgut001/pubs/x509guide.txt in the section "ASN.1
Design Guidelines", where I use the X.400 ORAddress as a convenient all-in-one
example of everything you can do wrong with ASN.1) and PFX (commented on in
http://www.cs.auckland.ac.nz/~pgut001/pubs/pfx.html).  More recent examples of
jumbled PDU's thrown together without rhyme or reason include CMP (some of the
highlights include apparently random tagging and data elements, provision for
specifying elements which are specifically disallowed by certificate standards
so that the message conveyed by sending this type of PDU is "I wanted to waste
your time by sending you this", and non-Y2K compliance in a protocol which
probably won't become a (shudder) official standard for another year or two).
Having said that, there are some examples of good ASN.1 use as well.  PKCS #7
has a certain elegant simplicity to it, and PKCS #15 is a good example of the
expressive power of the notation.

ASN.1's failing then isn't the encoding, but that fact that it makes it trivial
to design crap.  The result is seemingly endless interoperability problems, and
processing software which, chameleon-like, has to switch across a dozen
personalities to handle whatever the sender throws at it.  What's needed isn't
a different encoding, but better education of the people working with the
tools.  At the moment we're (mostly) in the hand-coded uncommented
self-modifying assembly language level of ASN.1 use.  Advances like structured
programming are still a long way off in the future.

Peter.