replacing MIT's ASN.1 code

[JC Ferguson]

My big concern would be quality.  As you state below,
the MIT ASN.1 implementation has been kicked around
for years, is solid, interops with MSFT and others.

The challenge is how to replace AND maintain the
same level of quality that exists in the current
implementation.  In general, this is always a tough
one to pull off and would likely take a few releases
of the library to solidify.

2 cents

/jc


 

> -----Original Message-----
> From: krbdev-bounces at mit.edu [mailto:krbdev-bounces at mit.edu] 
> On Behalf Of Ken Raeburn
> Sent: Monday, October 15, 2007 17:11
> To: Kerberos developers list
> Subject: replacing MIT's ASN.1 code
> 
> Some people may have heard, there's a new free ASN.1 compiler 
> in development by Paul Hoffman and Jim Schaad 
> (http://code.google.com/p/ a2c/ is the project page, and has 
> a link to the discussion list info), intended to support the 
> modern ASN.1 specifications and make it easier for IETF 
> specifications to be updated to use the newer ASN. 
> 1 specs.  This compiler generates data structures and code 
> (currently only in C) describing the ASN.1 structures, and 
> runtime code for encoding and decoding DER or BER.
> 
> The ASN.1 code in the MIT Kerberos distribution, on the other 
> hand, has been maintained by hand for something like 13 
> years, since MIT stopped using ISODE.  Each addition of a new 
> data structure -- for PKINIT, or the encoding of key data to 
> store in an LDAP database -- means tweaking things by hand, 
> using subtle and poorly documented macros that hide variable 
> declarations, function calls using these hidden variables, 
> etc., and getting all the attendant opportunities to screw it up.
> 
> So, I'm really interested in seeing if we can switch, and I'd 
> like to hear what other people think.
> 
> There are some complicating factors:
> 
> * This ASN.1 compiler is pretty new, as is its runtime 
> library.  It hasn't yet had years of experience with multiple 
> projects banging on it and shaking out encoding bugs, buffer 
> overruns, memory leaks, etc.  The API may still be subject to 
> change, but it's probably pretty close to becoming stable.
> 
> * It generates its own data structures, based on the ASN.1 
> description.  Unfortunately, the MIT Kerberos code exposes 
> some data structures in <krb5.h> that represent the decoded 
> protocol messages, and they're different.  So some conversion 
> of data structures (in both directions) is going to be 
> needed, and that'll probably have to be maintained by hand.  
> There are other protocol data structures we use internally, 
> with different names, so we'd either have to convert all our 
> code, or write more code to convert these additional data 
> structures.  I'm contemplating whether the conversions can be 
> made table-driven like the ASN.1 code itself.
> 
> * The ASN.1 compiler is written in C#, so on UNIX it requires 
> that Mono be installed.  I've had some trouble on PowerPC Mac 
> systems, but on Intel it seems to work okay.  And we can just 
> check in the generated C sources, so C#/Mono would only be a 
> requirement for developers tweaking the ASN.1, not for 
> building the Kerberos distribution.  There's also a web 
> server that feeds supplied files to the ASN.1 compiler and 
> gives you the results, so developers don't have to run it 
> locally, either.
> 
> * The ASN.1 compiler has some minor issues I'm trying to get 
> dealt with, like assuming sizeof(int)==4.  (We've probably 
> got similar assumptions in the MIT code, but if so, that 
> should be fixed too, and a general-purpose ASN.1 library 
> intended to be used on embedded platforms as well as 
> general-purpose computers shouldn't assume it.)
> 
> So it's not a trivial task, but I think for long-term 
> maintainability of the MIT code, it's probably worth 
> exploring.  Please take a look, and let me know what you 
> think.  Useful?  Waste of time?  Want to do the work? :)  (I 
> do have a bunch of other stuff on my plate, scheduled for the 
> 1.7 release when this wasn't even on the radar, so I'm not 
> going to be able to do this any time soon unless it suddenly 
> jumps up onto the priority queue.)
> 
> Ken
> _______________________________________________
> krbdev mailing list             krbdev at mit.edu
> https://mailman.mit.edu/mailman/listinfo/krbdev
>