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

diff --git a/69/317da7aaf7f24dd4a2cb4dabb1987a21625e50 b/69/317da7aaf7f24dd4a2cb4dabb1987a21625e50
new file mode 100644 (file)
index 0000000..91fda43
--- /dev/null
+++ b/69/317da7aaf7f24dd4a2cb4dabb1987a21625e50
@@ -0,0 +1,118 @@
+Return-Path: <nagydani@epointsystem.org>\r
+X-Original-To: notmuch@notmuchmail.org\r
+Delivered-To: notmuch@notmuchmail.org\r
+Received: from localhost (localhost [127.0.0.1])\r
+       by olra.theworths.org (Postfix) with ESMTP id CAFC3431FB6\r
+       for <notmuch@notmuchmail.org>; Tue, 18 Jan 2011 02:01:08 -0800 (PST)\r
+X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
+X-Spam-Flag: NO\r
+X-Spam-Score: -0.7\r
+X-Spam-Level: \r
+X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5\r
+       tests=[RCVD_IN_DNSWL_LOW=-0.7] autolearn=disabled\r
+Received: from olra.theworths.org ([127.0.0.1])\r
+       by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)\r
+       with ESMTP id BuqwooiSfE1Z for <notmuch@notmuchmail.org>;\r
+       Tue, 18 Jan 2011 02:01:08 -0800 (PST)\r
+Received: from mail-bw0-f53.google.com (mail-bw0-f53.google.com\r
+       [209.85.214.53])\r
+       by olra.theworths.org (Postfix) with ESMTP id C4FC7431FB5\r
+       for <notmuch@notmuchmail.org>; Tue, 18 Jan 2011 02:01:07 -0800 (PST)\r
+Received: by bwg12 with SMTP id 12so3644117bwg.26\r
+       for <notmuch@notmuchmail.org>; Tue, 18 Jan 2011 02:01:04 -0800 (PST)\r
+Received: by 10.204.45.150 with SMTP id e22mr3019021bkf.125.1295344864413;\r
+       Tue, 18 Jan 2011 02:01:04 -0800 (PST)\r
+Received: from [192.168.55.151] ([213.163.35.18])\r
+       by mx.google.com with ESMTPS id b6sm2522506bkb.22.2011.01.18.02.01.02\r
+       (version=TLSv1/SSLv3 cipher=RC4-MD5);\r
+       Tue, 18 Jan 2011 02:01:03 -0800 (PST)\r
+Message-ID: <4D3564E4.1010203@epointsystem.org>\r
+Date: Tue, 18 Jan 2011 11:01:08 +0100\r
+From: "Daniel A. Nagy" <nagydani@epointsystem.org>\r
+Organization: ePoint Systems Ltd.\r
+User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;\r
+       rv:1.9.2.13) Gecko/20101208 Thunderbird/3.1.7\r
+MIME-Version: 1.0\r
+To: IETF OpenPGP Working Group <ietf-openpgp@imc.org>\r
+Subject: Re: including the entire fingerprint of the issuer in an OpenPGP\r
+       certification\r
+References: <4D34F133.3000807@fifthhorseman.net>\r
+In-Reply-To: <4D34F133.3000807@fifthhorseman.net>\r
+X-Enigmail-Version: 1.1.2\r
+Content-Type: multipart/signed; micalg=pgp-sha1;\r
+       protocol="application/pgp-signature";\r
+       boundary="------------enig29B4C3D13C4C40618B3DA1EA"\r
+X-Mailman-Approved-At: Tue, 18 Jan 2011 12:27:11 -0800\r
+Cc: notmuch <notmuch@notmuchmail.org>\r
+X-BeenThere: notmuch@notmuchmail.org\r
+X-Mailman-Version: 2.1.13\r
+Precedence: list\r
+List-Id: "Use and development of the notmuch mail system."\r
+       <notmuch.notmuchmail.org>\r
+List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
+       <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
+List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
+List-Post: <mailto:notmuch@notmuchmail.org>\r
+List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
+List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
+       <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
+X-List-Received-Date: Tue, 18 Jan 2011 10:01:09 -0000\r
+\r
+This is an OpenPGP/MIME signed message (RFC 2440 and 3156)\r
+--------------enig29B4C3D13C4C40618B3DA1EA\r
+Content-Type: text/plain; charset=UTF-8\r
+Content-Transfer-Encoding: quoted-printable\r
+\r
+On 01/18/2011 02:47 AM, Daniel Kahn Gillmor wrote:\r
+> i believe collisions of the low 64 bits of SHA1 are within reach today,=\r
+\r
+> i'd love to be corrected if this is not the case\r
+\r
+I'd suggest using the entire fingerprint as a reference and leaving the\r
+creation date out of the fingerprint calculation for v5 for the\r
+following reasons:\r
+\r
+Yes, generating two keys with identical long key ID's is feasible (and\r
+not even particularly expensive on 64-bit machines with dozens of\r
+gigabytes of RAM), but generating a new key with the same 64-bit key ID\r
+as an existing key is on the very far end of the realm of feasibility.\r
+Given the dubious gains from success, I would rule out this attack as\r
+impractical.\r
+\r
+Another problem with fingerprints and key IDs is that they are generated\r
+over the key and the creation date, meaning that the same key can have\r
+different key ID's. Since the signature subpacket with the reference is\r
+not part of the hashed data, one can change both the key ID and the\r
+reference and keep the signature valid. Again, I don't know what the\r
+practical value of such an attack might be, but just like in the first\r
+case, it creates an odd situation potentially undermining the trust in\r
+the security of the system. When arguing in front of a non-expert judge,\r
+such quirks erode the claims of rock-solid evidence very badly.\r
+\r
+The key ID itself (especially the long one) is not a bad idea, however.\r
+It is a nice compromise in the middle of Zooko's triangle (almost\r
+memorable, almost globally unique and almost secure). In order to make\r
+it more useful, I'd suggest using 20-digit decimal identifiers (like\r
+credit card numbers) instead of 16-digit hexadecimal ones.\r
+\r
+Regards,\r
+\r
+--=20\r
+Daniel\r
+\r
+\r
+--------------enig29B4C3D13C4C40618B3DA1EA\r
+Content-Type: application/pgp-signature; name="signature.asc"\r
+Content-Description: OpenPGP digital signature\r
+Content-Disposition: attachment; filename="signature.asc"\r
+\r
+-----BEGIN PGP SIGNATURE-----\r
+Version: GnuPG v1.4.10 (GNU/Linux)\r
+Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/\r
+\r
+iEYEARECAAYFAk01ZOgACgkQ28D1wCI06YWaKACffiStcNXJhiUxxNBCwpXK9Pg2\r
+3LYAnjEnlPZ4Nxb6HrEFihVD72//UIWh\r
+=7Gg2\r
+-----END PGP SIGNATURE-----\r
+\r
+--------------enig29B4C3D13C4C40618B3DA1EA--\r