When queried by e-mail address, only return an encryption-capable certificate
Under what circumstances does hagrid expect to be used when queried by e-mail address?
Consider the first-contact case, i.e., i'm trying to send alice@example.org
an e-mail and i would like to encrypt the message, but i have no certificate matching that e-mail address. In that case, when queried by e-mail address, it is pointless for hagrid to return a certificate that is not encryption-capable.
If a signature is being verified, then the verifier can use hagrid's key ID or fingerprint interfaces instead of the e-mail address interface.
If there are other circumstances where retrieval by e-mail address are warranted, can we enumerate them? If not, is there any reason to distribute a certificate that is not encryption-capable when queried by e-mail address?
Furthermore, if this is the only specific circumstance, then we have a stronger argument for restricting this specific interface to zero-or-one certificates, rather than the multiple certificates proposed in #101 (closed) (though the retrieval-by-keyid and retrieval-by-fingerprint aspects of #101 (closed) are still relevant). This is because there is no good way for a user who is sending mail to choose between two different encryption-capable certificates that both match the same e-mail address. That argument may not hold if there are other circumstances contemplated for the retrieval-by-e-mail-address interface, though.
Note: i'm not sure how serious i am about this issue; it is something of a thought experiment. If you have a non-encryption scenario in mind that seems obvious to you, feel free to document it and close this issue.
One counterexample scenario i can imagine is monkeysphere-authentication lookups by e-mail address, which want authentication-capable subkeys, not encryption-capable subkeys. Do we want to support that scenario?