At Sat, 23 Aug 2003 21:31:19 -0700, Randy Presuhn wrote:
In fairness,
1) SNMP's (ab)use of ASN.1 pretty much precludes the use of ASN.1 compiler
technology. All the implementations I know of used hand-coded
encoders and
decoders. The vulnerabilities aren't a result of ASN.1, but rather
of trusting
humans to do a compiler's job.
2) Dean was specifically writing about PER, which can be *much* more
compact
than BER would ever hope to be. PER can potentially result in a more
compact
encoding than applying compression to a single packet. Look at the
spec to see
why.
I've used ASN.1 compiler technology for a project that included an
H.323-related frob, and ended up wishing I hadn't. Can you say more
than 2MB just for the ASN.1 PER encoder/decoder on a box with an 8MB
flash chip? (For comparision, the embedded Linux kernel on this same
box was quite a bit less than 1MB.) I knew you could. No doubt we
could have gotten a smaller implementation if we'd been willing to
throw serious money at it, but H.323 wasn't even the main point of the
box, it was just an extra feature that Marketing hung on the side
because it made a cute demo. YMMV, but based on that experience I'd
have a hard time believing that ASN.1 PER is worth the trouble.