Re: [Ksummit-discuss] Last minute nominations: mcgrof and toshi

[David Howells <dhowells@redhat.com>]

James Bottomley <James.Bottomley@HansenPartnership.com> wrote:

>    4. Our current key type model is slightly confusing, because we have
>       about 18 different ones from specific key types: assymetric, secure,

"secure"?  Do you mean "trusted"?

>       encrypted confused with use case key types like: cifs.spnego,
>       dns_resolver and grouping types like keyring.  We should probably
>       document them all somewhere and encourage subsystems which don't use
>       them (like dm crypt) to start.  We might also consider discouraging
>       key type proliferation?

With hindsight, one thing I should've done right from the start is to search
*only* on key description and not key type plus key description.  It might be
too impractical to change that now - though it could be made possible to pass
NULL as the type to keyring_search().  There are problems with doing this:

 (1) The keyring associative array is indexed by key type and key description
     for fastest access (the entire array can also be iterated over to find
     things by other criteria).  Changing this affects the performance of
     anything that wants to look up specifically by type+description, though
     in actuality it might not be a problem.

 (2) Currently we don't permit two keys with the same type+description to be
     in a keyring (adding one displaces the other).  If we look up only by
     desc, we really need to tighten the restriction to require that keys must
     differ on description, irrespective of type.  Note that this restriction
     is a function of the assoc array.

Take AF_RXRPC and kafs as an example: they don't really want an rxrpc-type
key, what they really want is a key that represents an old AFS KA service
token, a kerberos 4/5 ticket or a gss token.  The advantage of having an
rxrpc-type key is that I get to parse the token at key instantiation time
rather than each time I request it or want to use it.

With something like a kerberos ticket, it would likely be possible to extract
the relevant fields without knowledge of what it's going to be used for.

Another advantage of using the kerberos ticket key directly, is that it might
make it possible to share with the in-keyring cache available to libkrb5.

David