Subject: Re: including the entire fingerprint of the issuer in an OpenPGP
	certification
Mime-Version: 1.0 (Apple Message framework v1082)
From: Jon Callas <jon@callas.org>
In-Reply-To: <4D34F133.3000807@fifthhorseman.net>
Date: Mon, 17 Jan 2011 18:14:31 -0800
Message-Id: <AFC1EADB-7F7E-4090-A858-8C0012C9ED94@callas.org>
References: <4D34F133.3000807@fifthhorseman.net>
To: IETF OpenPGP Working Group <ietf-openpgp@imc.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Cc: notmuch <notmuch@notmuchmail.org>
Precedence: list

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.=20

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
>=20
> Hi OpenPGP folks (and Cc'ed notmuch developers/users)--
>=20
> 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.
>=20
> 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"):
>=20
> https://tools.ietf.org/html/rfc4880#section-5.2.3.5
>=20
> Given that we can't assume that key IDs are unique with any high =
degree
> of confidence, this creates some ambiguity between these states:
>=20
> A) "you don't have the key that made this signature"
>=20
> B) "this signature is bad"
>=20
> 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.
>=20
> 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)
>=20
> 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.
>=20
> 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)
>=20
> Alternately, what about a new subpacket type that simply includes the
> entire 160 bits of the issuer's fingerprint?   (the "full fingerprint"
> proposal)
>=20
> A third proposal would be a new subpacket type that simply includes =
the
> entire public key of the issuer (the "full pubkey" proposal).
>=20
> 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.
>=20
> 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.
>=20
> 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.
>=20
> 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).
>=20
> Any thoughts?
>=20
> Regards,
>=20
> 	--dkg
>=20
>=20
> * Unknown Key
> * 0xD21739E9