Review of Kerberos AEAP API

[Sam Hartman]

>>>>> "Love" == Love Hörnquist Åstrand <lha at kth.se> writes:

    Love> 2 dec 2008 kl. 09.46 skrev Love Hörnquist Åstrand:

    >> Hello here is my comments from the initial pass over the
    >> document.
    >> 
    >> Limiting to only on DATA buffer is overly restrictive.
    >> 
    >> On decryption, the HEADER/TRAILER data should be define to be
    >> read only as well as the ivec content, ie it should be possible
    >> to setup an recv'er ivec array and keep reusing it over and
    >> over again w/o re-init the data.
    >> 
    >> There should be an option to have a readonly DATA buffer, but I
    >> can live w/o that for now.

Love, Luke started out with this approach.  Unfortunately, as you are
probably aware, the length field in krb5_data is not size_t.  He found
that you always ended up having to use a temporary, and the API was
not useful because you almost always were filling in a krb5_data.

This is particularly problematic because it makes it easy to write
code on a 32-bit system that will not work on a 64-bit system.

So,  the API is more useful for MIT Kerberos if the return from krb5_c_crypto_length uses the same size as the length field in krb5_data.

When you add Heimdal to the mix, it gets kind of ugly.  It's my
understanding that Heimdal does use size_t in krb5_data.

We could say that for both APIs, the length coming out of
krb5_c_crypt_length will be correct size to be used in krb5_data.
I think that's reasonably clean.

--Sam