Crypto Modularity proj proposal

[ghudson@MIT.EDU]

> A new project proposal is posted on
> http://k5wiki.kerberos.org/wiki/Projects/Crypto_modularity to
> address Crypto Modularity of MIT Kerberos code.

I have shifted this from "early project" to "under review" status and
set a review end date of July 31.

I removed the part about overloading krb5_keyblock.  The remainder of
what's in there is relatively uncontroversial, I think, and
implementation can proceed in parallel with formal review.

We had some discussion about the 1.8 crypto project work yesterday and
decided to split it up into three ordered projects:

  1. Modularity (under review)
  2. Caching of key-derived data for performance
  3. Support for cryptographic modules (external keys)

I will be working on a project proposal for #2.  Following Nico's
idea, my plan is to introduce a new opaque type krb5_key, add crypto
APIs to use it, and use the krb5_key type in the (non-exposed)
gss-krb5 and krb5 security context structures.  Keyblocks in exposed
krb5 structures will be left alone, as it is not necessary to
associate cached information with those keyblocks for performance.

The other reasonable alternative I see is a lookaside table for
keyblocks, and I think it's more likely to result in long-term
maintenance issues than Nico's idea.  (For more background, refer to
http://mailman.mit.edu/pipermail/krbdev/2009-June/007780.html)

For #3, I anticipate we will reuse the krb5_key type and associated
crypto APIs added in #2; however, there will be additional
complications depending on what types of keys we support as external
references.