[17432] in Kerberos_V5_Development
Re: Future ASN.1 support
daemon@ATHENA.MIT.EDU (Nathaniel McCallum)
Fri Dec 9 16:05:53 2011
Message-ID: <1323457433.25965.35.camel@localhost>
From: Nathaniel McCallum <npmccallum@redhat.com>
To: ghudson@mit.edu
Date: Fri, 09 Dec 2011 14:03:53 -0500
In-Reply-To: <201112081744.pB8Hi9DU005220@outgoing.mit.edu>
Mime-Version: 1.0
Cc: krbdev@mit.edu
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krbdev-bounces@mit.edu
On Thu, 2011-12-08 at 12:44 -0500, ghudson@MIT.EDU wrote:
> We have several problems with the current state of ASN.1 encoding and
> decoding in MIT krb5:
>
> * Plugin modules and applications cannot make use of the libkrb5 code
> to encode and decode types built on top of Kerberos types. In the
> past we have incorporated support into the core code when a module
> needs to do ASN.1 encoding, which kind of defeats the point of having
> a pluggable interface.
>
> * Translating from an ASN.1 module to the data-driven encoder
> structures is painstaking and error-prone.
>
> * Decoders are still open-coded using macros. Translating from an
> ASN.1 module to decoding functions is also painstaking and
> error-prone.
>
> * Our table-driven encoding logic and decoding macros do not hew very
> closely to the ASN.1 data model; instead, they are designed around the
> idioms of RFC 4120 (and to some extent to the krb5 type hierarchy).
> As we incorporate types from different ASN.1 subcultures, we wind up
> with hacky workarounds. For instance, some PKINIT types are still
> open-coded, partly because they use some implicit tags.
>
> * Writing good tests for ASN.1 encoders and decoders is tedious. The
> risk of interoperability issues is extremely high if we don't generate
> test cases using a separate (and good) ASN.1 implementation.
>
> I want to address this problem for 1.11. Here are the broad options
> I'm considering:
>
> 1. asn1c + type conversion: we could use asn1c to generate structures
> and encoders for ASN.1 types, and then wrap the encoders and decoders
> with converters for our types. (Using asn1c's types directly would be
> a huge migration issue and would also be pretty cumbersome.)
>
> 2. Heimdal asn1_gen + hacking: we could incorporate the Heimdal
> libasn1 and modify it to generate code for our types and handle our
> edge cases.
>
> 3. New ASN.1 compiler + modified existing code: in this plan we alter
> our ASN.1 infrastructure to (1) be less tailored to RFC 4120 idioms,
> (2) support data-driven decoding as well as encoding, and (3) throw
> out the CPP macros for generating data structures. Then we write a
> new ASN.1 compiler in Python which generates the data structures based
> on an ASN.1 module and some additional input describing our data
> structures.
>
> For all of these options, we also need to expose some of the ASN.1
> machinery so that plugins can compile their own ASN.1 modules which
> import existing types.
>
> Currently I'm exploring the third option, but I'm interested in
> opinions on which option is best or whether I should be looking at
> other options.
Having thought about this a bit more, I'd like to offer the following:
1. asn1c + using asn1c's types directly represents in my mind roughly
equivalent work as writing your own compiler. I think the end result is
better since it offloads completely a task from krb5 and completely
eliminates the need to write conversion shims for new data types. The
only downside that I can see is that it will break API/ABI. Why not just
bite the bullet and call it 2.0?
2. After evaluating all our options for AuthHub, asn1c is clearly the
best option. We can't wait around for 1.11/2.0, so we're going to go
with it. If MIT chooses not to go the asn1c route, so be it. However, I
also cannot say what priority migrating AuthHub to the new krb5 ASN.1
system will have. This may delay merging OTP support into krb5, even
indefinitely. Probably not a deal-breaker, but worth considering.
3. asn1c is clearly the closest thing to a general purpose tool. Basing
krb5 on asn1c while updating it to handle krb5's edge cases would be a
clear benefit to its other users. I've not been able to find any other
tool that is not project specific.
4. I think that the time estimated to create a Python ASN.1 compiler
that is RFC compliant and handles all the required edge cases has been
grossly underestimated. While Python is clearly much faster to develop
in than C (I myself think in Python), I doubt the result will be
anything nearly as useful as asn1c already is aside from the fact that
it can handle krb5 types. This may be nothing more than my spidey sense
that goes off anytime someone says "the best way to optimize for my
problem is to write my own compiler," but I still think it holds true.
Anyway, that's my PoV, take it or leave it.
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
