OTP ASN.1 encoders for 1.10

[Ken Raeburn]

On Oct 30, 2011, at 23:47, ghudson at MIT.EDU wrote:
> For the 1.11 release, I hope the OTP plugin can be part of the krb5
> source tree, with a pluggable interface for vendor-specific modules,
> which will render k5-int-pkinit.h moot (or a purely internal
> artifact).  I also hope we can improve the ASN.1 extensibility
> situation for 1.11, but I need to do more research before I can lay
> out concrete options for that.

Tom and I kicked around a few ideas for registering the rough equivalent of an ASN.1 module, so you could define a krb5 module and a krb5-otp module that would import certain types from krb5, without having to manage a zillion symbol names in the export list, deal with namespace issues, etc.  I don't know if I've still got any notes around from those discussions, but maybe he does.  If a handful of routines were provided for registering a module (with a table mapping type name string to descriptor structure) and looking up descriptors, some support code could glue them together at run time...  Because you'd presumably want to be able to import types like KerberosTime and KerberosString and PrincipalName, and not make them opaque in other modules' C types, you'd probably have to let the module access the headers for the imported "module" (e.g., krb5), and just add support for exporting and importing definitions using symbolic names as strings.

I wish I'd had time to work out the decoder side of things; it would have simplified things quite a bit.  Currently decoders would still need to be exported one by one and explicitly called, I think.

Then again, perhaps we were wrong about requiring a solution that used our existing data structures, and should've used an existing product and translated the data structures to maintain the old interface.  In retrospect, the performance and even ugliness factors may not be that big a deal.  (I'd sort of steer away from adopting the Heimdal implementation, in the interest of having more-independent Kerberos implementations to cross-check each other, but as there are still other implementations, maybe it's not that big a concern.)  I wonder what the state of Paul Hoffmann and Jim Schaad's a2c is these days....

Ken