including the entire fingerprint of the issuer in an OpenPGP certification

[Daniel Kahn Gillmor <[e-mail]>]

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