Review of Kerberos AEAP API

[Jeffrey Altman]

Sam Hartman wrote:

> 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

Sam:

It is indeed unfortunate that krb5_data does not use size_t and
is not 64-bit ready.  However, like with the 64-bit time_t vs
32-bit krb5_timestamp, at some point the MIT Kerberos API is going
to have to be fixed.

I believe it is appropriate to design the API for what we would
want it to be when things are fixed instead of tying it to what the
existing internal implementation is.

Does that mean that the API will have to check for an report
ETOOBIG conditions?   Sure.  Until the internal krb5_data structure
is capable of cleanly supporting 64-bit values in mixed 64-bit/32-bit
environments.  (e.g., Windows)

This is just my opinion.  Take it with a grain of salt.

Jeffrey Altman
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3355 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mailman.mit.edu/pipermail/krbdev/attachments/20081204/54097e58/attachment.bin