ASN.1 compiler enhancements: DER, open types, ...

[Lon Willett]

[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.]

Hi,

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).

    Comments anyone?

  * 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
    work.

  * 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.

Cheers,

Lon Willett
<Lon.Willett@REDACTED>