[Kdc-info] prelim draft of kdc information model

[Sam Hartman]

>>>>> "Ken" == Ken Raeburn <raeburn at MIT.EDU> writes:

    Ken> Sam Hartman <hartmans at MIT.EDU> writes:
    Jeffrey> Yes, you probably do.  This saves the user or
    Jeffrey> administrator from having to explicitly specify a list of
    Jeffrey> enctypes each time the password is changed.  This is
    Jeffrey> particularly important with regard to service principals,
    Jeffrey> where the set of enctypes for which there are keys in the
    Jeffrey> KDC must match that supported by the server software.
    >>  I'd actually argue that it is particularly unimportant for
    >> server software, where in an ideal world the application
    >> server's library will rekey to only those keys it supports
    >> guaranteeing this match.

    Ken> I don't see any point in perpetuating the overloading we do
    Ken> in the MIT database where the set of service key enctypes
    Ken> also describes the encryption types supported by the
    Ken> application server software.  

I think there are too many enctype related options, not too few.  If
you want to separate enctypes a service supports from keys that a
service has, I think that you should justify the additional complexity/options.

I agree that there is no need for both the supported enctypes and
keyed enctypes to be the same.  However I don't see any harm in doing
things this way and it is one less thing to configure or get out of
sync.