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 CD8F9431FB6 for ; Fri, 4 Feb 2011 09:30:34 -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 XSvKy0+0VGRV for ; Fri, 4 Feb 2011 09:30:34 -0800 (PST) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by olra.theworths.org (Postfix) with ESMTP id 49FEF431FB5 for ; Fri, 4 Feb 2011 09:30:34 -0800 (PST) Received: from [192.168.23.207] (dsl254-070-154.nyc1.dsl.speakeasy.net [216.254.70.154]) by che.mayfirst.org (Postfix) with ESMTPSA id C8A71F98B; Fri, 4 Feb 2011 12:30:32 -0500 (EST) Message-ID: <4D4C37B0.1090202@fifthhorseman.net> Date: Fri, 04 Feb 2011 12:30:24 -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: micah anderson Subject: Re: new "crypto" branch providing full PGP/MIME support References: <4CF15D67.1070904@fifthhorseman.net> <87aak08fu8.fsf@servo.finestructure.net> <87fwsf9mip.fsf@servo.finestructure.net> <87tygl29vu.fsf@servo.finestructure.net> <87hbclkrvh.fsf@algae.riseup.net> <4D4B0761.7040603@fifthhorseman.net> <87r5bn68hs.fsf@algae.riseup.net> In-Reply-To: <87r5bn68hs.fsf@algae.riseup.net> X-Enigmail-Version: 1.1.2 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enigC2820EB67D53802FCCAABF1E" Cc: notmuch X-BeenThere: notmuch@notmuchmail.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: "Use and development of the notmuch mail system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2011 17:30:34 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigC2820EB67D53802FCCAABF1E Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 02/04/2011 11:59 AM, micah anderson wrote: > On Thu, 03 Feb 2011 14:52:01 -0500, Daniel Kahn Gillmor wrote: >> when you say "encrypted by" do you mean "encrypted to"? do you have >> access to the corresponding secret key? >=20 > If I open a message that was sent to me and was encrypted by the sender= > using a key that they have since revoked, or has expired, I saw this. so you hold key A, the sender holds key B, they encrypt the message with B, and then revoke key B, and then you try to read the message (without holding key B)? or are you saying you hold key A, sender holds key B, they encrypt to A, *sign* the message with B, and then revoke B? If it's this case, does the same thing happen even if the message is not encrypted? Sorry for the nit-picking pedantry here -- I'm trying to get a clear workflow for a test case. > Most humans I know reference their key by the keyid, where keyid means > the 8 character representation of their key. When they need to ensure > that their key is not being spoofed they either rely on the tools to do= > cryptographic verification, or inspect the fingerprint. I dont think > moving towards using a longer format of the keyid helps here. The key i= s > unknown, and to get it known requires going through a key signing > process, or fingerprint verification, which isn't aided by having a > longer form keyid.=20 >=20 > If I am presented with a short form keyid, and I go and try and receive= > that key from the keyservers and then I am presented with two different= > options, then I'm going to inspect the two and determine then which one= > is the right one. I dont need to front-load that knowledge in the > interface. and if you're presented with only one key, you will just accept that one? that puts you at the mercy of the network (or the keyserver operator at least, and we can't all have the luxury of being or knowing the keyserver operator directly). If you're arguing "i would like to be able to recognize the key by 32-bit key ID" i don't think it's actually possible to do so because of the spoofability; a tool that provides cryptographic assurances should discourage attempts to make the user vulnerable to spoofing. If you're saying we should remove the 64-bit keyID entirely and just say "signature from unknown, non-validated key", i think that's a defensible position, though it's not one i would take. >> is this really a use case worth bothering with? >=20 > No. :) >> do you have a suggestion for how you think it should behave >> differently? >=20 > I think my suggestion was already made: short form. and as i said above, i think this is a mistake if we're trying to provide tools that give cryptographic assurances. thanks for the testing and the corner cases! --dkg --------------enigC2820EB67D53802FCCAABF1E 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/ iQJ8BAEBCgBmBQJNTDewXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQwRUU1QkU5NzkyODJEODBCOUY3NTQwRjFD Q0QyRUQ5NEQyMTczOUU5AAoJEMzS7ZTSFznpImAP/3/b21EHQZrKjVA5dYuPhAfN WUbz2U6bvZ5RCE7FJpf5yuFHIefuCdEYH9DW9tsqlzeBJ9NvvuPibwZa381LsTQb kvLGrzqNuoy6kjBVb0nQvomPrJZEEtyUEO/SkZKyTkFB0ihdRtDRKXjFOXij70yc 4P3CwEm/09L8ovrTBy6/93WluziK7e2v/0s1vbxIk0OL0O/E2AKcN8UBdjl7mVTK MFAxiWtOgplLjx1hyOSVlOecGzk4+IkeAy5iHj1k1Nsq0hp2u+iZJDs3ewirzlzM 9YWM5hEa0MDrwVCTyfIjF0Rl0nRIEqBJ43JNhDeCRlxMTB36LTG8x0EM56T403lN IDLUXj1/4DGHlF0/f5+ezglvObdV6PmxtxGRYUtHcFQqoYVMOXPQ84CFWXq5RZth xJDEDt5AFnnstrBnXNZyh9m3kaQE6YvV38dj+zZDU76zIA62MTjaUSHLVY7LLWsG cjehEmgkDklkrT+VGdzO6qASAByNt06afvEJ1ZdQfdWBwfntbCfAE6SRBt+QCXGu +vnApCXWfFLLaOEZ9zAm391W2RvhSH6uqZkQh0QQZHjB9VBzkgI1e083SF+EKSK2 FhvjRrcuIRn7qVYUcOCB+G5ryolwGr5yIc/iK3zDhFpMgHEK78YSyTXF9bqpikOR 9UnkbGXHbMyMCtAtMsMB =oXES -----END PGP SIGNATURE----- --------------enigC2820EB67D53802FCCAABF1E--