Message-ID: <4D34F133.3000807@fifthhorseman.net>
Date: Mon, 17 Jan 2011 20:47:31 -0500
From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
	rv:1.9.2.13) Gecko/20101213 Icedove/3.1.7
MIME-Version: 1.0
To: IETF OpenPGP Working Group <ietf-openpgp@imc.org>
Subject: including the entire fingerprint of the issuer in an OpenPGP
	certification
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature";
	boundary="------------enigFBFACFA426B5BF54C7C24A9A"
Cc: notmuch <notmuch@notmuchmail.org>
Precedence: list
Reply-To: IETF OpenPGP Working Group <ietf-openpgp@imc.org>

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigFBFACFA426B5BF54C7C24A9A
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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


--------------enigFBFACFA426B5BF54C7C24A9A
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBCgAGBQJNNPEzAAoJEMzS7ZTSFznpto0P/2cuF3qAuFZQru7IABrZiYvx
r7W45B1wY+wlniVtgPqlviDuxY6AOIaubIMU+Tkp+805C8XfvZVLNRExlOAxF/K9
paoNHkX18dys2HVK9EHosS71c866iK+cK736U9XUIKvI9w5pTFXPevFLnCDTbuge
ZWVG6LCJ22UqIDsRpMSlO6NmR7w0+0DBwfNS56K6FwXZxWUc9VgPq7O7H3B0/S1K
qFUktRg4W6Rs0jZbiIVVNa9n6YJFfQnjZC0Nl1suJmJECm0zx3KJGu0CUeegqnmj
15G7TytUv1EELxlHMjMXRjBs3MLuSytL1aPu8v+Fbg1NyRuNdZWDqCoxCedXzJJ+
7x9Ztbk/XcQllXGQTnrJcicmVjDapp2wGge2YYwdzVLzxcNdEaO+vBYDewx2/QCN
4xIWtghVACDaImFgvX5KnbFkYlyHIudlLSEdFqmXS70U1R50JS6MtePTQEFxohAB
j3MaDUSrMcp7oKRBg/0HPHw4n0iKnTpG40XeKodSM52KU+RPvjtJQPb/gP/alBmb
nwp1bqpBzIaboXYnmA1AhFZg9sILj930OJN97A1Ipu5ucSvvLjeSn/ndZgLDFXcm
64Xq+Bdxvyfv7B+rveqQCiaZgYKBvDGM/p4MlRyCUAx7VZHbbvOY3PL0L3ikbK1F
77U94cUaFjqGgW0N9k8p
=zeOX
-----END PGP SIGNATURE-----

--------------enigFBFACFA426B5BF54C7C24A9A--