KDC TGT enctype selection question

[Ken Hornstein]

>The general convention is that a principal's long term keys are ordered
>from strongest to weakest, thus picking the first key that is approved
>by local policy (permitted_enctypes) is generally what you want.  This
>is just a convention.
>
>I suspect that for root TGS principals (krbtgt/REALM at REALM where the two
>REALMs are the same) the convention MIT wants is that the first key _is_
>the key to use always, and woe unto you then if that key's enctype is
>not in the permitted_enctypes.

I understand the convention, but it doesn't really answer my question:
this is a very explicit coding choice and I can't really see WHY it
exists.  For one it could make it difficult to upgrade enctypes when
you had geographically-distributed KDCs that were managed by different
organizations.  Also, it doesn't really match the expected behavior
in terms of other Kerberos enctype negotations and I am trying to
understand why.  I am perfectly willing to believe there is something
I don't understand!

>I'm not sure how B ends up accepting the TGTs that it vends though, in
>this case, given that it shouldn't be accepting the second key to
>decrypt the TGT's enc-part.

It ends it calling krb5_dbe_def_search_enctype() which has this
code:

        /* Filter out non-permitted enctypes. */
        if (!krb5_is_permitted_enctype(context, kd->key_data_type[0])) {
            saw_non_permitted = TRUE;
            continue;
        }

So on KDC B the sha384 key is skipped and the sha1 key is returned.

--Ken