From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/85057 Path: news.gmane.org!not-for-mail From: Daiki Ueno Newsgroups: gmane.emacs.gnus.general Subject: Re: Default encryption for Message Date: Sun, 28 Sep 2014 09:16:57 +0900 Message-ID: <871tqw1tvq.fsf-ueno@gnu.org> References: <86wq8xffpv.fsf@informationelle-selbstbestimmung-im-internet.de> <864mvx5bw9.fsf@informationelle-selbstbestimmung-im-internet.de> <86y4t7vfkm.fsf@informationelle-selbstbestimmung-im-internet.de> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1411863501 6225 80.91.229.3 (28 Sep 2014 00:18:21 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 28 Sep 2014 00:18:21 +0000 (UTC) To: ding@gnus.org Original-X-From: ding-owner+M33301@lists.math.uh.edu Sun Sep 28 02:18:12 2014 Return-path: Envelope-to: ding-account@gmane.org Original-Received: from util0.math.uh.edu ([129.7.128.18]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1XY2Bn-0008Pi-B1 for ding-account@gmane.org; Sun, 28 Sep 2014 02:18:11 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.math.uh.edu) by util0.math.uh.edu with smtp (Exim 4.63) (envelope-from ) id 1XY2Ao-0001wi-5q; Sat, 27 Sep 2014 19:17:10 -0500 Original-Received: from mx1.math.uh.edu ([129.7.128.32]) by util0.math.uh.edu with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1XY2Am-0001wJ-AQ for ding@lists.math.uh.edu; Sat, 27 Sep 2014 19:17:08 -0500 Original-Received: from quimby.gnus.org ([80.91.231.51]) by mx1.math.uh.edu with esmtps (TLSv1:AES128-SHA:128) (Exim 4.76) (envelope-from ) id 1XY2Aj-0006vc-W6 for ding@lists.math.uh.edu; Sat, 27 Sep 2014 19:17:07 -0500 Original-Received: from fencepost.gnu.org ([208.118.235.10] ident=Debian-exim) by quimby.gnus.org with esmtp (Exim 4.80) (envelope-from ) id 1XY2Ai-0002pa-DM for ding@gnus.org; Sun, 28 Sep 2014 02:17:04 +0200 Original-Received: from du-a.org ([2001:e41:db5e:fb14::1]:35130 helo=debian) by fencepost.gnu.org with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1XY2Ag-0005SC-Ne for ding@gnus.org; Sat, 27 Sep 2014 20:17:03 -0400 In-Reply-To: <86y4t7vfkm.fsf@informationelle-selbstbestimmung-im-internet.de> (Jens Lechtenboerger's message of "Thu, 25 Sep 2014 18:18:49 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux) X-Spam-Score: -8.8 (--------) List-ID: Precedence: bulk Xref: news.gmane.org gmane.emacs.gnus.general:85057 Archived-At: Jens Lechtenboerger writes: > I was interested in mml2015-encrypt-to-self and looked at its doc > string. Setting to t fails. You explained that > mml2015-sign-with-sender or mml2015-signers are necessary. > However, I don=E2=80=99t want to sign and suggested gpg.conf/Bcc instead. So, maybe improving the documentation of mml2015-encrypt-to-self would be a good start? > In your scenario, I see two choices, say concerning Alice with those > three keys. > > (1) Friend Bob wants to send a message to Alice and is supposed to > choose the correct key B (but neither A nor C). > > (2) Alice wants to send an encrypted message to colleague Charlie, > and she wants to make sure that the message is encrypted to her key > A (but neither B nor C) in addition to Charlie=E2=80=99s key. > > For (1), my code sets mm-encrypt-option to 'guided to enforce a > manual choice so that Bob learns about the existence of those three > public keys in the first place. (Ted Zlatanov suggested to save > that choice.) I don't think this is a good idea. I know some people ("security" fans) like this kind of verbose behavior, but others don't even want to remember key IDs and are prone to choose wrong keys. There are criticisms about a related topic: http://www.superlectures.com/guadec2013/more-secure-with-less-security > For (2), I think that another variable would be necessary to > customize what key to use for what recipient. (Gnus could ask if it > detects multiple encryption keys.) No objection on that. > I don=E2=80=99t see how either case is supported by mml2015, though. What > is your configuration? It can be done by dynamically setting mml2015-signers upon sending. For some reason I use hooks (namely message-header-hook), but it can be done more easily by using group parameters or BBDB. (info "(gnus) Group Parameters") > Besides, what is the intended meaning for signatures if > mml2015-signers contains multiple keys? This is certainly for the case when one wants to sign a message with multiple keys.