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

[Lon Willett]

Hi,

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.