[30770] in Kerberos
Re: FIPS certification
daemon@ATHENA.MIT.EDU (Ken Raeburn)
Sat Feb 28 13:08:38 2009
Message-Id: <70288C02-967E-4F6E-A512-BBC2BECC21F9@mit.edu>
From: Ken Raeburn <raeburn@MIT.EDU>
To: Kerberos mailing list <kerberos@MIT.EDU>
In-Reply-To: <20090228174348.GB6935@mit.edu>
Mime-Version: 1.0 (Apple Message framework v930.3)
Date: Sat, 28 Feb 2009 13:07:50 -0500
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: kerberos-bounces@MIT.EDU
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
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
