Each key determines the public key algorithm to be used to encrypt to
it. To send to an RSA key, we use RSA, and to send to an ElGamal key,
we use ElGamal, etc. There is also in PGP 5.0 a self-signature packet
which allows the key to describe which conventional algorithm(s) it
prefers to receive.
The issue of choosing a key comes about when multiple keys share a userid,
and we are looking up a key on that basis. Then we have the question
of which key (or keys) to use to encrypt to that user. If the user has
multiple keys which have the same userid, it is not obvious which ones
to use.
One idea we have discussed at PGP is to combine all the keys belonging to
a user into one "key cluster". This would be a generalization of the
current structure where we have a signature key with an encryption subkey
attached to it. With the key cluster there could be an extra packet which
indicated the user's preferences as to which keys to use.
This idea works well for email, but perhaps not so well for a capability
based model like SPKI. In SPKI, keys have certain attributes or privileges
based on the signatures on them. They don't necessarily have userids, and
may not be associated with a particular user.
There seems less value to clustering keys together in a SPKI-like model.
It adds complexity and would make interpreting the attributes of each
key more difficult. If we think we will be moving towards a capability
system like SPKI, it would be better to avoid doing more with clustering.
A possibly simpler way to do handle key preferences would be to allow
a key to claim that it has higher priority than a specified list of
other keys. So if you had keys A, B, and C matching the desired userid,
and A claimed it was higher priority than B, while C claimed to be higher
priority than A or B, we would use C.
Hal