[17450] in Kerberos_V5_Development
Deprecating krb5_octet_data and krb5_typed_data
daemon@ATHENA.MIT.EDU (ghudson@mit.edu)
Mon Dec 19 13:21:47 2011
Date: Mon, 19 Dec 2011 13:21:43 -0500 (EST)
From: ghudson@mit.edu
Message-Id: <201112191821.pBJILhIj022903@outgoing.mit.edu>
To: krbdev@mit.edu
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krbdev-bounces@mit.edu
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
the table.)
---
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
with it.
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
deprecation comment.
---
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.
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
