Store should support returning multiple keys with the same fingerprint/keyid
It is entirely possible that the same subkey can be bound to multiple primary keys. In the case of encryption subkeys, Mallory can take Bob's encryption subkey and add it to his own key. This could confused Alice. But, even in the case of signature subkeys, which require a backsig, Mallory can create multiple keys with the same subkey to potentially confuse Alice's OpenPGP implementation.
Also, it is possible to create 64-bit keyid collisions.
Given this, the Store should by able to handle multiple keys with the same fingerprint/keyid. To do this, I think Pool::lookup, Pool::lookup_by_keyid, and Pool::lookup_by_subkeyid should all be changed to return a Vector of Keys.
Returning a vector instead of trying to figure out the right key is consistent with our goal of avoiding policy decisions in the low-level APIs. Also, users of these APIs will have more contextual information and will be able to make better decisions.