kadm5_randkey_principal_3

[Ben Cox]

I have a server application that wants to periodically randomize its
service key.  This key MUST be a des-cbc-crc key, and it MUST be the
only current key for the service principal (for reasons that I don't
want to discuss right now; suffice it to say that my application won't
interoperate with its clients if the KDC is going around handing out
service tickets with other key types for my service).  (I know that
single-DES isn't necessarily the tightest cipher in the implementation,
but it's really not up for discussion.)

I'm trying to do this by using kadm5_init_with_skey to the changepw
service, using my current key, and then kadm5_randkey_principal_3,
passing a key-salt tuple containing only one entry: des-cbc-crc:normal. 
(And then calling kadm5_get_principal to get my new kvno, since
kadm5_randkey_principal_3 doesn't give me back that useful nugget of
information...)

The problem is that kadm5_randkey_principal_3 returns TWO keys: a
des3-cbc-raw key and a des-cbc-crc key.  Since it contains a des-cbc-crc
key in the list, I can paw through it and get that key, but this result
doesn't meet my second requirement: that the des-cbc-crc key be the ONLY
current key for the service principal.

(I'm seeing this behavior running MIT k5 1.2.4, and observed the
following in the 1.2.5 source tree.)

I've traced through the code, and it appears that if the calling
principal matches the principal whose key is being changed, the
server-side wrapper calls randkey_principal_wrapper, which ignores the
ks_tuple argument and calls kadm5_randkey_principal instead of
kadm5_randkey_principal_3.  (And, maddeningly enough,
kadm5_randkey_principal calls kadm5_randkey_principal_3 with a fixed set
of ks_tuples.)

Bummer.

Is there a good reason for this?  Is it fixed in 1.2.6?  (Seems to me
that one Q&D fix would be trivial: have a randkey_principal_3_wrapper
that calls kadm5_randkey_principal_3 at the end instead of
kadm5_randkey_principal.  But I can't go around handing out kadmind
patches to sites that want to use my server.)

Is there a workaround that doesn't require my keeping credentials around
for some other principal that has the changepw privilege?  (If the
calling principal is someone else, calling the kadmin service, with the
changepw privilege, it works fine, but I don't want to store a key for
that principal.

Thanks in advance for any suggestions,

-- Ben