Hi OpenPGP folks (and Cc'ed notmuch developers/users)-- Some recent discussion about verifying OpenPGP signatures for the notmuch mail user agent got me thinking about different ways one might interpret a negative result from a signature made over a message. Most OpenPGP signatures i've seen use the (unhashed) issuer subpacket to refer to the low 64 bits of the fingerprint of the issuer's key (the issuer's "key ID"): https://tools.ietf.org/html/rfc4880#section-5.2.3.5 Given that we can't assume that key IDs are unique with any high degree of confidence, this creates some ambiguity between these states: A) "you don't have the key that made this signature" B) "this signature is bad" a user-friendly MUA that thinks it is in state A might do something sensible like offer to do a keyserver lookup (if it is online), while simply reporting "signature error" if it thinks it is in state B. But a devious attacker could potentially create a colliding Key ID (i believe collisions of the low 64 bits of SHA1 are within reach today, i'd love to be corrected if this is not the case) and cause the user-friendly MUA to assume it is in state B when it is actually in state A. The attacker doesn't even need access to the message or signature in question to do this. They'd only need to have been able to supply a key to the user at some time in the past. (e.g. push a new subkey to the keyservers which a user pulls during a keyring refresh) One way around this ambiguity would be to include the issuer's entire fingerprint instead of just the low 64 bits, which would make the certainty of state A vs. state B much clearer. Would there be any objection to a new subpacket type for OpenPGPv4 that would include the remaining 96 bits of the issuer's fingerprint? (the "high 96" proposal) Alternately, what about a new subpacket type that simply includes the entire 160 bits of the issuer's fingerprint? (the "full fingerprint" proposal) A third proposal would be a new subpacket type that simply includes the entire public key of the issuer (the "full pubkey" proposal). I lean toward "high 96", since using it in conjunction with the issuer subpacket retains backward compatibility with existing tools (which know how to interpret the issuer subpacket) while introducing the smallest amount of additional data per signature. Given that the size of a signature from a 2048-bit RSA key is 256 bytes already, adding an additional 12 bytes (plus a few bytes of subpacket overhead) per signature doesn't seem particularly excessive. I'm also assuming that the typical use of this subpacket would be in the unhashed section of a signature packet, since it is an advisory field and not intended to address attacks against an adversary capable of tampering directly with the data in the signature itself. I will write code to implement this using an experimental subpacket ID, but i'd like to know if anyone has any caveats, concerns, or preferences between the proposals i've outlined above (or entirely different proposals that would address the underlying concern). Any thoughts? Regards, --dkg