Re: including the entire fingerprint of the issuer in an OpenPGP certification

[Jon Callas <[e-mail]>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On the one hand, my only disagreement with you is to suggest that your proposal be tied into using SHA256 for a fingerprint. If you're going to expand the keyid to a fingerprint, why not get a better fingerprint?

On the other hand, this has never been a problem. It's harder than you think, because you have to generate a new key each time, which takes a while on RSA. 

Nonetheless, I think it's a good idea. I'd just go all the way to a better fingerprint.

	Jon


On Jan 17, 2011, at 5:47 PM, Daniel Kahn Gillmor wrote:

> * PGP Signed by an unknown key
> 
> 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
> 
> 
> * Unknown Key
> * 0xD21739E9


-----BEGIN PGP SIGNATURE-----
Version: PGP Universal 2.10.0 (Build 554)
Charset: us-ascii

wj8DBQFNNPeJsTedWZOD3gYRAm4YAJ4nuTf1aPoh4xoUGsH9c7PgDqSiyACguVMs
Ht6Zmyj72mx7JzoKHFrX6PY=
=XIxu
-----END PGP SIGNATURE-----