From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from localhost (localhost [127.0.0.1]) by olra.theworths.org (Postfix) with ESMTP id 759FB431FB6 for ; Mon, 17 Jan 2011 17:54:14 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at olra.theworths.org X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none] autolearn=disabled Received: from olra.theworths.org ([127.0.0.1]) by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tOQne-EvelHk for ; Mon, 17 Jan 2011 17:54:13 -0800 (PST) X-Greylist: delayed 392 seconds by postgrey-1.32 at olra; Mon, 17 Jan 2011 17:54:13 PST Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by olra.theworths.org (Postfix) with ESMTP id 5AC46431FB5 for ; Mon, 17 Jan 2011 17:54:13 -0800 (PST) Received: from [192.168.13.75] (lair.fifthhorseman.net [216.254.116.241]) by che.mayfirst.org (Postfix) with ESMTPSA id CBC87F987; Mon, 17 Jan 2011 20:47:39 -0500 (EST) Message-ID: <4D34F133.3000807@fifthhorseman.net> Date: Mon, 17 Jan 2011 20:47:31 -0500 From: Daniel Kahn Gillmor 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 Subject: including the entire fingerprint of the issuer in an OpenPGP certification X-Enigmail-Version: 1.1.2 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enigFBFACFA426B5BF54C7C24A9A" Cc: notmuch X-BeenThere: notmuch@notmuchmail.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: IETF OpenPGP Working Group List-Id: "Use and development of the notmuch mail system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jan 2011 01:54:14 -0000 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--