return multiple certificates from fingerprint-based certificate discovery
This feature request is lower priority (for me, at least) than #97 (closed), #98 (closed), and #99 (closed).
If i'm verifying an OpenPGP signature that has a Issuer Fingerprint
subpacket but i have no certificate with any signing-capable key that matches that fingerprint, I might want to ask hagrid for the matching certificate. Then i would look at other information in that certificate to decide whether this signature is acceptable in the current context or not.
I'd typically do this discovery via the VKS fingerprint interface, but currently that interface can only return at most one OpenPGP certificate.
If two certificates happen to share a signing-capable subkey, or one certificate's signing-capable subkey happens to be another certificate's primary key, then it's conceivable that there are multiple certificates i'd like to evaluate -- maybe i'm just looking for any certificate that satisfies some particular criterion, and if more than one is available, it's my job as the evaluator to decide which one i care about.
Who would construct such a shared-key, multi-certificate monstrosity? I don't have a great story here for its legitimate construction. Perhaps there is a subkey stored in an HSM that can't be updated, but the original primary key is problematic somehow? The right answer of course is that good people shouldn't do this. But they might, and it'd still be nice to be able to use hagrid with those certs.
This, when combined with the multi-certificate keyID lookup described in #98 (closed), is the "certificate discovery" interface described in the abuse-resistant keystores draft.
PS i note that malicious "adoption" of other people's signing keys (whether primary keys or subkeys) can be mitigated by ensuring that #97 (closed) is addressed. However, it's possible that an adversary somehow gets the chance to issue a single signature from the signing key. If they use that chance to create a cross-sig as part of their own certificate, and they manage to inject that certificate into hagrid before the legitimate certificate is uploaded, they could block the legitimate certificate from distribution on hagrid. Permitting multiple keys defends against this DoS attack as well (though it is still incumbent on the clients to evaluate both certs and pick the right one).
PPS in the ideal world, people would just ship the issuing certificate with every signature, unless there was a compelling reason to believe that the verifier already had the certificate (e.g. operating system updates can assume that the installed operating system knows the signing key). If we lived in such a world, we could drop this interface entirely, relying instead on the primary-key-only interface described in #99 (closed).