Plug-in interfaces & internal APIs

[Greg Hudson]

On 05/18/2015 05:07 PM, Ken Hornstein wrote:
> However ... it does in my mind at least raise the larger issue is that it
> would be nice for plugins to have the ability to access the ASN.1 encoding/
> decoding routines for various Kerberos messages (I am thinking of SAM2
> in particular).  I am not sure if there is some way to pass up the expanded
> structure for the upper-level library to encode/decode (I know that the
> way SAM2 works this is particular problematic).  Just thinking out loud
> here; it's not an easy problem.

We could expose structures and encoder functions which are currently
internal, at the cost of significantly increasing our API surface.  But
most of the time plugin modules want to encode structures we don't
already have internal encoders for, which make use of RFC 4120 or other
existing Kerberos types.

Exposing a generally extensible ASN.1 framework is on our wishlist, but
it's not an easy problem (I'll skip the essay on why this is).

> Looking at other internal interfaces .... I see that I currently use
> krb5int_c_combine_keys() and krb5int_c_mandatory_cksumtype().  The
> former, okay, I know you're not crazy about exposing that one.  But
> how about the latter?

I don't think there's really anything stopping us from exposing a
krb5_c_mandatory_checksum() function.  The internal function was added
in 2003 by Ken Raeburn with a "Not sure it's ready for exposure just
yet" comment.  My guess is that he had concerns about the answers for
DES enctypes, which I think were resolved in 2010 by SA-2010-007.

However, since 1.8 it's been possible to pass a checksum type of 0 to
krb5_c_make_checksum() to use the mandatory checksum type.  That covers
most of the reasons one would want to use krb5_c_mandatory_checksum(),
removing a lot of the impetus for doing the (relatively minimal) work of
exposing it.  We can still do it if there's a need.