[krbdev.mit.edu #7918] LDAP key data decoder ignores salt type if salt value is empty

[Greg Hudson via RT]

In 1.11, we made the ASN.1 decoder table-driven.  For the LDAP KrbKeySet 
decoder, there was no easy way to make the decoder set the key_data_ver 
and key_data_kvno fields of krb5_key_data, so we handled it in 
asn1_decode_sequence_of_keys (a function in the LDAP KDB module) after 
the fact.  At the moment we set key_data_ver to 2 if key_data_length[1] 
is non-zero, and to 1 otherwise.  This is not correct; a salt type may 
be present without a salt value.  If a non-zero salt type is present 
with no salt value, we will erroneously treat the key as having the 
default salt.

Experimentally, we seem to currently store salt values along with all of 
the non-default salt types, even though the salt value is ignored by 
krb5_dbe_compute_salt for all salt types except SALTTYPE_SPECIAL.  So at 
least for entries we currently generate, the only visible impact of this 
bug is just to ignore the v4 salt type (because it comes with an empty 
salt).  Entries generated by earlier versions might have other non-
default salt types ignored; I haven't done that analysis yet.