FIPS certification

[Ken Raeburn]

On Feb 28, 2009, at 12:43, Theodore Tso wrote:
> It might be possible to dispatch on krb5_keyblock->magic to determine
> whether it the new fields are there, and in places where a passed in
> krb5_keyblock is allocated on the stack, the called function could
> allocate a new-style krb5_keyblock and import the key.  (How many such
> places are there?  I didn't think there would be that many.)  It
> wouldn't be that pretty, yes, but if it's considered important to
> preserve the ABI, it's probably doable...

Yeah, that's been considered.  It's a little risky in that sometimes  
the "magic" field just isn't initialized (especially in an application- 
provided keyblock), and adding a dependence on it (at least on it  
*not* having a certain 32-bit value that indicates the extended form)  
would be a minor ABI change.  I think the risk is probably low, and  
it'd probably be worth the extra ugliness to get the benefits.

We'd also still need to handle the krb5_keyblock structure embedded in  
krb5_creds; in that instance it wouldn't be extensible.

It'd be so nice to be able to do a new API for a v2.0 someday. :-)

Ken