[RFC] kdb: store mkey list in context and permit NULL mkey for kdb_dbe_decrypt_key_data

[Sam Hartman]

>>>>> "Greg" == Greg Hudson <ghudson at MIT.EDU> writes:

    Greg> For purposes of discussion, I want to call out the performance
    Greg> impact.  Currently, the caller of krb5_dbe_decrypt_key_data is
    Greg> required to identify the correct master key using the entry's
    Greg> tl-data.  Unfortunately, that tl-data is not available to
    Greg> krb5_dbe_decrypt_key_data given its current API, so it will
    Greg> try all master keys in order.  During a master key transition,
    Greg> that will result in some extra decrypt operations on a running
    Greg> KDC.

    Greg> We can re-optimize this case by adding an optional argument to
    Greg> krb5_dbe_decrypt_key_data for the full DB entry, and passing
    Greg> that argument at all performance-sensitive call sites where we
    Greg> pass a null mkey.  As I told Sam earlier, I am happy
    Greg> considering that re-optimization to be future work, and think
    Greg> we might be able to fit it into the margin for 1.9.

O, if you don't mind it being an optional argument, it's relatively
easy, and I can try to fit into my margin.  The code for
decrypt_key_data becomes cleaner (removes the loop and the non-cleanup
goto) if you make it mandatory.
Reworking the call sites in kadmind for that was a bit more than I
wanted to do.

note that for principals where the principal is encrypted in the current
master key there is no performance impact with this code.