Deprecating krb5_octet_data and krb5_typed_data
ghudson at MIT.EDU
Mon Dec 19 13:21:43 EST 2011
krb5_octet_data was added when PKINIT was merged and is only used by
PKINIT. It differs from krb5_data in that it uses an unsigned char
pointer. It continues to be only used by PKINIT (and associated
encoders). I find it awkward because (1) you can't use any of the
krb5_data helpers with it, and (2) we use krb5_data with unsigned
characters all the time (e.g. in the crypto library), so having a
separate krb5_octet_data presents a schizophrenia over how much we
dislike casting between char * and unsigned char *.
I would like to switch to using krb5_data everywhere we currently use
krb5_octet_data. krb5_octet_data and krb5_free_octet_data would
remain with deprecation comments.
(I know that using void * in krb5_data would be an improvement if we
had a time machine, but breaking the libkrb5 API is not currently on
krb5_typed_data was also added with PKINIT and is only used by PKINIT.
It was initially not part of krb5.hin, but was moved there for obscure
(but valid) reasons. Although typed-data is specified in RFC 4120,
more recent standards such as RFC 6113 effectively deprecate it in
favor of pa-data. Having the krb5_typed_data type around is awkward
for the same reason as krb5_octet_data; it has the same internal
structure as krb5_pa_data but you can't use the same helper functions
I would like to use the krb5_pa_data structure everywhere we use the
krb5_typed_data structure. We would still have ASN.1 encoding and
decoding functions for typed-data, but they would use krb5_pa_data as
the C type. krb5_typed_data would remain in krb5.hin with a
I don't expect either of these to be controversial, but I'm checking
before taking unilateral action since both changes would touch a lot
of lines of code.
More information about the krbdev