ASN.1 compiler enhancements: DER, open types, ...
Mon Dec 4 23:36:34 CET 2000
[Oops. I had some mailer problems, and this message got mangled the
first time I sent it. So here it is again. Sorry for the repeat.]
I've been playing with the Erlang/OTP ASN.1 compiler lately, and have
found some deficiencies, at least as regards my intended usage. So
I'm thinking about hacking it up, and am wondering what the protocol
for this is. Is there some source-code master that I should be in
touch with? Is there a more recent (development) copy of the source
than what is in the latest open source OTP release? Has someone else
already done this? Does anyone else want the results I produce? Can
I talk someone else into doing this for me?
(Wishful thinking, that last one :-))
More specifically, my requirements are:
* DER encoding -- this shouldn't be too hard to implement, although
it is difficult to be sure that one hasn't forgotten something
(DER is hard to test, as compared to plain BER). I've noticed
several problems here; the compiler in its current form is
definitely unusable for digital-signing purposes.
* Open types -- as far as I can tell, there isn't any functioning
support for open types in the compiler (tell me if I'm doing
something wrong). There appears to be some code to deal with
them, but it seems to be incomplete.
Ideally, of course, I would like support for the full "Information
Object Specification" (X.681). I could get by with just
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, when, for
whatever reason, it is necessary (most often because the compiler
doesn't handle something correctly, but there are some other
special cases as well). I've often used it for this with other
ASN.1 compilers. It also should be simple to implement (at least
with BER, I'm not familiar with PER).
* BIT STRINGs -- 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 a fairly common practice in the
crypto standards to specify some fairly hefty BLOBs as BIT
STRINGs. 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 of doing this conversion isn't trivial either.
A compiler option to choose the erlang representation of
non-enumerated bit strings would be nice.
For example, using the "ber_bin" option, the decode could just use
a sub-binary of the input as the bit string representation (well,
usually anyway), which is probably what one would want to pass to
a crypto driver anyway.
Of course, if ANY was supported, then one could just specify the
BLOBs as ANY, and then do the encoding/decoding oneself, using
whatever erlang term format was convenient (an example of the
point above). But it still would be nicer if the compiler did the
* Character strings -- this is a real can of worms. I don't think
it is possible to solve all the problems here (given what a mess
the standard is), but there are a few simple and very useful
functions that would help handle the worst cases (e.g. convert
BMPString to some more manageable representation, perhaps UTF-8.
And BTW, UTF8String ought to be built-in).
So I'm digging in and getting ready to hack (I haven't yet done more
than take a quick glance at the sources). Anyone who has an interest
should let me know.
More information about the erlang-questions