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

[James Bottomley <James.Bottomley@HansenPartnership.com>]

On Wed, 2016-07-27 at 17:07 +0100, David Howells wrote:
> 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"?

Yes, sorry I meant the trusted key types that currently use the TPM.

> >       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:

OK, can we do this now? because with this change we can look for the
key we actually want to use without knowing its mechanism, which is
kind of the point of keys, particularly asymmetric vs trusted keys
where they're an identical type of key, just one is implemented in
software and the other in the TPM hardware.

>  (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.

Right, that's why I find it confusing.  It confuses use case with
actual type.

>   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.

OK, I'm no expert on kerberos.  I draw the line at understanding X509
and RSA keys ... purely in order to preserve my sanity, you understand.

James