b5/ba32a442fe8865f930ebf12a3955adc08a2da7

   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 CD8F9431FB6\r
   6         for <notmuch@notmuchmail.org>; Fri,  4 Feb 2011 09:30:34 -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 XSvKy0+0VGRV for <notmuch@notmuchmail.org>;\r
  16         Fri,  4 Feb 2011 09:30:34 -0800 (PST)\r
  17 Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108])\r
  18         by olra.theworths.org (Postfix) with ESMTP id 49FEF431FB5\r
  19         for <notmuch@notmuchmail.org>; Fri,  4 Feb 2011 09:30:34 -0800 (PST)\r
  20 Received: from [192.168.23.207] (dsl254-070-154.nyc1.dsl.speakeasy.net\r
  21         [216.254.70.154])\r
  22         by che.mayfirst.org (Postfix) with ESMTPSA id C8A71F98B;\r
  23         Fri,  4 Feb 2011 12:30:32 -0500 (EST)\r
  24 Message-ID: <4D4C37B0.1090202@fifthhorseman.net>\r
  25 Date: Fri, 04 Feb 2011 12:30:24 -0500\r
  26 From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>\r
  27 User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;\r
  28         rv:1.9.2.13) Gecko/20101213 Icedove/3.1.7\r
  29 MIME-Version: 1.0\r
  30 To: micah anderson <micah@riseup.net>\r
  31 Subject: Re: new "crypto" branch providing full PGP/MIME support\r
  32 References: <4CF15D67.1070904@fifthhorseman.net>\r
  33         <87aak08fu8.fsf@servo.finestructure.net>\r
  34         <87fwsf9mip.fsf@servo.finestructure.net>\r
  35         <87tygl29vu.fsf@servo.finestructure.net>\r
  36         <87hbclkrvh.fsf@algae.riseup.net>\r
  37         <4D4B0761.7040603@fifthhorseman.net>\r
  38         <87r5bn68hs.fsf@algae.riseup.net>\r
  39 In-Reply-To: <87r5bn68hs.fsf@algae.riseup.net>\r
  40 X-Enigmail-Version: 1.1.2\r
  41 Content-Type: multipart/signed; micalg=pgp-sha512;\r
  42         protocol="application/pgp-signature";\r
  43         boundary="------------enigC2820EB67D53802FCCAABF1E"\r
  44 Cc: notmuch <notmuch@notmuchmail.org>\r
  45 X-BeenThere: notmuch@notmuchmail.org\r
  46 X-Mailman-Version: 2.1.13\r
  47 Precedence: list\r
  48 List-Id: "Use and development of the notmuch mail system."\r
  49         <notmuch.notmuchmail.org>\r
  50 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
  51         <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
  52 List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
  53 List-Post: <mailto:notmuch@notmuchmail.org>\r
  54 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
  55 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
  56         <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
  57 X-List-Received-Date: Fri, 04 Feb 2011 17:30:34 -0000\r
  58 \r
  59 This is an OpenPGP/MIME signed message (RFC 2440 and 3156)\r
  60 --------------enigC2820EB67D53802FCCAABF1E\r
  61 Content-Type: text/plain; charset=UTF-8\r
  62 Content-Transfer-Encoding: quoted-printable\r
  63 \r
  64 On 02/04/2011 11:59 AM, micah anderson wrote:\r
  65 > On Thu, 03 Feb 2011 14:52:01 -0500, Daniel Kahn Gillmor <dkg@fifthhorse=\r
  66 man.net> wrote:\r
  67 >> when you say "encrypted by" do you mean "encrypted to"?  do you have\r
  68 >> access to the corresponding secret key?\r
  69 >=20\r
  70 > If I open a message that was sent to me and was encrypted by the sender=\r
  71 \r
  72 > using a key that they have since revoked, or has expired, I saw this.\r
  73 \r
  74 so you hold key A, the sender holds key B, they encrypt the message with\r
  75 B, and then revoke key B, and then you try to read the message (without\r
  76 holding key B)?\r
  77 \r
  78 or are you saying you hold key A, sender holds key B, they encrypt to A,\r
  79 *sign* the message with B, and then revoke B?  If it's this case, does\r
  80 the same thing happen even if the message is not encrypted?\r
  81 \r
  82 Sorry for the nit-picking pedantry here -- I'm trying to get a clear\r
  83 workflow for a test case.\r
  84 \r
  85 > Most humans I know reference their key by the keyid, where keyid means\r
  86 > the 8 character representation of their key. When they need to ensure\r
  87 > that their key is not being spoofed they either rely on the tools to do=\r
  88 \r
  89 > cryptographic verification, or inspect the fingerprint. I dont think\r
  90 > moving towards using a longer format of the keyid helps here. The key i=\r
  91 s\r
  92 > unknown, and to get it known requires going through a key signing\r
  93 > process, or fingerprint verification, which isn't aided by having a\r
  94 > longer form keyid.=20\r
  95 >=20\r
  96 > If I am presented with a short form keyid, and I go and try and receive=\r
  97 \r
  98 > that key from the keyservers and then I am presented with two different=\r
  99 \r
 100 > options, then I'm going to inspect the two and determine then which one=\r
 101 \r
 102 > is the right one. I dont need to front-load that knowledge in the\r
 103 > interface.\r
 104 \r
 105 and if you're presented with only one key, you will just accept that\r
 106 one?  that puts you at the mercy of the network (or the keyserver\r
 107 operator at least, and we can't all have the luxury of being or knowing\r
 108 the keyserver operator directly).\r
 109 \r
 110 If you're arguing "i would like to be able to recognize the key by\r
 111 32-bit key ID" i don't think it's actually possible to do so because of\r
 112 the spoofability; a tool that provides cryptographic assurances should\r
 113 discourage attempts to make the user vulnerable to spoofing.\r
 114 \r
 115 If you're saying we should remove the 64-bit keyID entirely and just say\r
 116 "signature from unknown, non-validated key", i think that's a defensible\r
 117 position, though it's not one i would take.\r
 118 \r
 119 >> is this really a use case worth bothering with?\r
 120 >=20\r
 121 > No.\r
 122 \r
 123 :)\r
 124 \r
 125 >> do you have a suggestion for how you think it should behave\r
 126 >> differently?\r
 127 >=20\r
 128 > I think my suggestion was already made: short form.\r
 129 \r
 130 and as i said above, i think this is a mistake if we're trying to\r
 131 provide tools that give cryptographic assurances.\r
 132 \r
 133 thanks for the testing and the corner cases!\r
 134 \r
 135         --dkg\r
 136 \r
 137 \r
 138 --------------enigC2820EB67D53802FCCAABF1E\r
 139 Content-Type: application/pgp-signature; name="signature.asc"\r
 140 Content-Description: OpenPGP digital signature\r
 141 Content-Disposition: attachment; filename="signature.asc"\r
 142 \r
 143 -----BEGIN PGP SIGNATURE-----\r
 144 Version: GnuPG v1.4.11 (GNU/Linux)\r
 145 Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/\r
 146 \r
 147 iQJ8BAEBCgBmBQJNTDewXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w\r
 148 ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQwRUU1QkU5NzkyODJEODBCOUY3NTQwRjFD\r
 149 Q0QyRUQ5NEQyMTczOUU5AAoJEMzS7ZTSFznpImAP/3/b21EHQZrKjVA5dYuPhAfN\r
 150 WUbz2U6bvZ5RCE7FJpf5yuFHIefuCdEYH9DW9tsqlzeBJ9NvvuPibwZa381LsTQb\r
 151 kvLGrzqNuoy6kjBVb0nQvomPrJZEEtyUEO/SkZKyTkFB0ihdRtDRKXjFOXij70yc\r
 152 4P3CwEm/09L8ovrTBy6/93WluziK7e2v/0s1vbxIk0OL0O/E2AKcN8UBdjl7mVTK\r
 153 MFAxiWtOgplLjx1hyOSVlOecGzk4+IkeAy5iHj1k1Nsq0hp2u+iZJDs3ewirzlzM\r
 154 9YWM5hEa0MDrwVCTyfIjF0Rl0nRIEqBJ43JNhDeCRlxMTB36LTG8x0EM56T403lN\r
 155 IDLUXj1/4DGHlF0/f5+ezglvObdV6PmxtxGRYUtHcFQqoYVMOXPQ84CFWXq5RZth\r
 156 xJDEDt5AFnnstrBnXNZyh9m3kaQE6YvV38dj+zZDU76zIA62MTjaUSHLVY7LLWsG\r
 157 cjehEmgkDklkrT+VGdzO6qASAByNt06afvEJ1ZdQfdWBwfntbCfAE6SRBt+QCXGu\r
 158 +vnApCXWfFLLaOEZ9zAm391W2RvhSH6uqZkQh0QQZHjB9VBzkgI1e083SF+EKSK2\r
 159 FhvjRrcuIRn7qVYUcOCB+G5ryolwGr5yIc/iK3zDhFpMgHEK78YSyTXF9bqpikOR\r
 160 9UnkbGXHbMyMCtAtMsMB\r
 161 =oXES\r
 162 -----END PGP SIGNATURE-----\r
 163 \r
 164 --------------enigC2820EB67D53802FCCAABF1E--\r