ac/403796c9ae7c96e6856ac97950e6864abb7c55

   1 Return-Path: <dkg@fifthhorseman.net>\r
   2 X-Original-To: notmuch@notmuchmail.org\r
   3 Delivered-To: notmuch@notmuchmail.org\r
   4 Received: from localhost (localhost [127.0.0.1])\r
   5         by olra.theworths.org (Postfix) with ESMTP id 759FB431FB6\r
   6         for <notmuch@notmuchmail.org>; Mon, 17 Jan 2011 17:54:14 -0800 (PST)\r
   7 X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
   8 X-Spam-Flag: NO\r
   9 X-Spam-Score: 0\r
  10 X-Spam-Level: \r
  11 X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none]\r
  12         autolearn=disabled\r
  13 Received: from olra.theworths.org ([127.0.0.1])\r
  14         by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)\r
  15         with ESMTP id tOQne-EvelHk for <notmuch@notmuchmail.org>;\r
  16         Mon, 17 Jan 2011 17:54:13 -0800 (PST)\r
  17 X-Greylist: delayed 392 seconds by postgrey-1.32 at olra;\r
  18         Mon, 17 Jan 2011 17:54:13 PST\r
  19 Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108])\r
  20         by olra.theworths.org (Postfix) with ESMTP id 5AC46431FB5\r
  21         for <notmuch@notmuchmail.org>; Mon, 17 Jan 2011 17:54:13 -0800 (PST)\r
  22 Received: from [192.168.13.75] (lair.fifthhorseman.net [216.254.116.241])\r
  23         by che.mayfirst.org (Postfix) with ESMTPSA id CBC87F987;\r
  24         Mon, 17 Jan 2011 20:47:39 -0500 (EST)\r
  25 Message-ID: <4D34F133.3000807@fifthhorseman.net>\r
  26 Date: Mon, 17 Jan 2011 20:47:31 -0500\r
  27 From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>\r
  28 User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;\r
  29         rv:1.9.2.13) Gecko/20101213 Icedove/3.1.7\r
  30 MIME-Version: 1.0\r
  31 To: IETF OpenPGP Working Group <ietf-openpgp@imc.org>\r
  32 Subject: including the entire fingerprint of the issuer in an OpenPGP\r
  33         certification\r
  34 X-Enigmail-Version: 1.1.2\r
  35 Content-Type: multipart/signed; micalg=pgp-sha512;\r
  36         protocol="application/pgp-signature";\r
  37         boundary="------------enigFBFACFA426B5BF54C7C24A9A"\r
  38 Cc: notmuch <notmuch@notmuchmail.org>\r
  39 X-BeenThere: notmuch@notmuchmail.org\r
  40 X-Mailman-Version: 2.1.13\r
  41 Precedence: list\r
  42 Reply-To: IETF OpenPGP Working Group <ietf-openpgp@imc.org>\r
  43 List-Id: "Use and development of the notmuch mail system."\r
  44         <notmuch.notmuchmail.org>\r
  45 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
  46         <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
  47 List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
  48 List-Post: <mailto:notmuch@notmuchmail.org>\r
  49 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
  50 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
  51         <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
  52 X-List-Received-Date: Tue, 18 Jan 2011 01:54:14 -0000\r
  53 \r
  54 This is an OpenPGP/MIME signed message (RFC 2440 and 3156)\r
  55 --------------enigFBFACFA426B5BF54C7C24A9A\r
  56 Content-Type: text/plain; charset=UTF-8\r
  57 Content-Transfer-Encoding: quoted-printable\r
  58 \r
  59 Hi OpenPGP folks (and Cc'ed notmuch developers/users)--\r
  60 \r
  61 Some recent discussion about verifying OpenPGP signatures for the\r
  62 notmuch mail user agent got me thinking about different ways one might\r
  63 interpret a negative result from a signature made over a message.\r
  64 \r
  65 Most OpenPGP signatures i've seen use the (unhashed) issuer subpacket to\r
  66 refer to the low 64 bits of the fingerprint of the issuer's key (the\r
  67 issuer's "key ID"):\r
  68 \r
  69  https://tools.ietf.org/html/rfc4880#section-5.2.3.5\r
  70 \r
  71 Given that we can't assume that key IDs are unique with any high degree\r
  72 of confidence, this creates some ambiguity between these states:\r
  73 \r
  74  A) "you don't have the key that made this signature"\r
  75 \r
  76  B) "this signature is bad"\r
  77 \r
  78 a user-friendly MUA that thinks it is in state A might do something\r
  79 sensible like offer to do a keyserver lookup (if it is online), while\r
  80 simply reporting "signature error" if it thinks it is in state B.\r
  81 \r
  82 But a devious attacker could potentially create a colliding Key ID (i\r
  83 believe collisions of the low 64 bits of SHA1 are within reach today,\r
  84 i'd love to be corrected if this is not the case) and cause the\r
  85 user-friendly MUA to assume it is in state B when it is actually in\r
  86 state A.  The attacker doesn't even need access to the message or\r
  87 signature in question to do this.  They'd only need to have been able to\r
  88 supply a key to the user at some time in the past.  (e.g. push a new\r
  89 subkey to the keyservers which a user pulls during a keyring refresh)\r
  90 \r
  91 One way around this ambiguity would be to include the issuer's entire\r
  92 fingerprint instead of just the low 64 bits, which would make the\r
  93 certainty of state A vs. state B much clearer.\r
  94 \r
  95 Would there be any objection to a new subpacket type for OpenPGPv4 that\r
  96 would include the remaining 96 bits of the issuer's fingerprint?  (the\r
  97 "high 96" proposal)\r
  98 \r
  99 Alternately, what about a new subpacket type that simply includes the\r
 100 entire 160 bits of the issuer's fingerprint?   (the "full fingerprint"\r
 101 proposal)\r
 102 \r
 103 A third proposal would be a new subpacket type that simply includes the\r
 104 entire public key of the issuer (the "full pubkey" proposal).\r
 105 \r
 106 I lean toward "high 96", since using it in conjunction with the issuer\r
 107 subpacket retains backward compatibility with existing tools (which know\r
 108 how to interpret the issuer subpacket) while introducing the smallest\r
 109 amount of additional data per signature.\r
 110 \r
 111 Given that the size of a signature from a 2048-bit RSA key is 256 bytes\r
 112 already, adding an additional 12 bytes (plus a few bytes of subpacket\r
 113 overhead) per signature doesn't seem particularly excessive.\r
 114 \r
 115 I'm also assuming that the typical use of this subpacket would be in the\r
 116 unhashed section of a signature packet, since it is an advisory field\r
 117 and not intended to address attacks against an adversary capable of\r
 118 tampering directly with the data in the signature itself.\r
 119 \r
 120 I will write code to implement this using an experimental subpacket ID,\r
 121 but i'd like to know if anyone has any caveats, concerns, or preferences\r
 122 between the proposals i've outlined above (or entirely different\r
 123 proposals that would address the underlying concern).\r
 124 \r
 125 Any thoughts?\r
 126 \r
 127 Regards,\r
 128 \r
 129         --dkg\r
 130 \r
 131 \r
 132 --------------enigFBFACFA426B5BF54C7C24A9A\r
 133 Content-Type: application/pgp-signature; name="signature.asc"\r
 134 Content-Description: OpenPGP digital signature\r
 135 Content-Disposition: attachment; filename="signature.asc"\r
 136 \r
 137 -----BEGIN PGP SIGNATURE-----\r
 138 Version: GnuPG v1.4.11 (GNU/Linux)\r
 139 Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/\r
 140 \r
 141 iQIcBAEBCgAGBQJNNPEzAAoJEMzS7ZTSFznpto0P/2cuF3qAuFZQru7IABrZiYvx\r
 142 r7W45B1wY+wlniVtgPqlviDuxY6AOIaubIMU+Tkp+805C8XfvZVLNRExlOAxF/K9\r
 143 paoNHkX18dys2HVK9EHosS71c866iK+cK736U9XUIKvI9w5pTFXPevFLnCDTbuge\r
 144 ZWVG6LCJ22UqIDsRpMSlO6NmR7w0+0DBwfNS56K6FwXZxWUc9VgPq7O7H3B0/S1K\r
 145 qFUktRg4W6Rs0jZbiIVVNa9n6YJFfQnjZC0Nl1suJmJECm0zx3KJGu0CUeegqnmj\r
 146 15G7TytUv1EELxlHMjMXRjBs3MLuSytL1aPu8v+Fbg1NyRuNdZWDqCoxCedXzJJ+\r
 147 7x9Ztbk/XcQllXGQTnrJcicmVjDapp2wGge2YYwdzVLzxcNdEaO+vBYDewx2/QCN\r
 148 4xIWtghVACDaImFgvX5KnbFkYlyHIudlLSEdFqmXS70U1R50JS6MtePTQEFxohAB\r
 149 j3MaDUSrMcp7oKRBg/0HPHw4n0iKnTpG40XeKodSM52KU+RPvjtJQPb/gP/alBmb\r
 150 nwp1bqpBzIaboXYnmA1AhFZg9sILj930OJN97A1Ipu5ucSvvLjeSn/ndZgLDFXcm\r
 151 64Xq+Bdxvyfv7B+rveqQCiaZgYKBvDGM/p4MlRyCUAx7VZHbbvOY3PL0L3ikbK1F\r
 152 77U94cUaFjqGgW0N9k8p\r
 153 =zeOX\r
 154 -----END PGP SIGNATURE-----\r
 155 \r
 156 --------------enigFBFACFA426B5BF54C7C24A9A--\r