ASN.1 enhancements: DER, open types, ...
Mon Dec 4 23:27:06 CET 2000
I've been playing with the Erlang/OTP ASN.1 compiler lately, and have
found some deficiencies (for my uses). So I'm thinking about hacking
it up a bit, and am wondering what the protocol for this is. Is there
some code master I should be in touch with? Is there a development
copy of the source somewhere that I should work from? Can I talk
someone else into doing this for me?
More specifically, my wish-list includes:
* DER encoding -- this shouldn't be too hard, although it is
difficult to be sure that one hasn't missed something (DER is hard
to test, as compared to plain BER). I've noticed a several
problems here; the compiler in its current form is definitely
unusable for crypto-signing purposes.
* Open types -- as far as I can tell, there isn't support for any
open types in the compiler (tell me if I'm doing something wrong).
There appears to be some code in place to deal with them, but it
seems to be incomplete.
Ideally, of course, I would like support for the full "Information
object specification". I could get by just fine with
TYPE-IDENTIFIER and INSTANCE OF, or with ANY [DEFINED BY].
Support for ANY might be a good idea anyway, even if it isn't part
of the standard any more. It provides a general escape mechanism
to let the caller take over the encoding/decoding, which is useful
in those cases where the compiler is, for whatever reason,
inadequate. It also should be simple enought to implement (at
least with BER, I'm not familiar with PER). I've often had to use
it for this reason with other compilers.
* BIT STRING -- the current implementation seems to be oriented
around the use of short bit strings for a list of options (which
is one important case). But it is common in the crypto standards
for BLOBs (e.g. encrypted data) to be specified as BIT STRINGs.
So not only is the inefficiency of converting to/from a list of
zeros and ones bad enough that it might be a problem, but the
inconvenience is non-trivial too. A compiler option to choose how
one wants non-enumerated bit strings represented as erlang terms
would be nice.
More information about the erlang-questions