From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/85040 Path: news.gmane.org!not-for-mail From: Jens Lechtenboerger Newsgroups: gmane.emacs.gnus.general Subject: Re: Default encryption for Message Date: Thu, 25 Sep 2014 18:18:49 +0200 Message-ID: <86y4t7vfkm.fsf@informationelle-selbstbestimmung-im-internet.de> References: <86wq8xffpv.fsf@informationelle-selbstbestimmung-im-internet.de> <864mvx5bw9.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 1411662062 20667 80.91.229.3 (25 Sep 2014 16:21:02 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 25 Sep 2014 16:21:02 +0000 (UTC) Cc: ding@gnus.org To: Daiki Ueno Original-X-From: ding-owner+M33284@lists.math.uh.edu Thu Sep 25 18:20:55 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 1XXBmm-00013Q-A0 for ding-account@gmane.org; Thu, 25 Sep 2014 18:20:52 +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 1XXBlL-0004aB-Bw; Thu, 25 Sep 2014 11:19:23 -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 1XXBlH-0004ZY-JZ for ding@lists.math.uh.edu; Thu, 25 Sep 2014 11:19:19 -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 1XXBl4-0002zv-MT for ding@lists.math.uh.edu; Thu, 25 Sep 2014 11:19:16 -0500 Original-Received: from mx1.mailbox.org ([80.241.60.212]) by quimby.gnus.org with esmtp (Exim 4.80) (envelope-from ) id 1XXBl2-00068W-2S for ding@gnus.org; Thu, 25 Sep 2014 18:19:04 +0200 Original-Received: from smtp1.mailbox.org (smtp1.mailbox.org [80.241.60.240]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.mailbox.org (Postfix) with ESMTPS id 8BC68424F9; Thu, 25 Sep 2014 18:18:57 +0200 (CEST) X-Virus-Scanned: amavisd-new at heinlein-support.de Original-Received: from smtp1.mailbox.org ([80.241.60.240]) (using TLS with cipher AES256-GCM-SHA384) by hefe.heinlein-support.de (hefe.heinlein-support.de [91.198.250.172]) (amavisd-new, port 10030) with ESMTPS id DYfOpVU20HTC; Thu, 25 Sep 2014 18:18:51 +0200 (CEST) OpenPGP: id=0xA142FD84; url=http://www.informationelle-selbstbestimmung-im-internet.de/A142FD84.asc Mail-Followup-To: Daiki Ueno , ding@gnus.org In-Reply-To: (Daiki Ueno's message of "Thu, 25 Sep 2014 12:06:02 +0900") User-Agent: Gnus/5.130012 (Ma Gnus v0.12) Emacs/24.3.50 (gnu/linux) X-Spam-Score: -2.9 (--) List-ID: Precedence: bulk Xref: news.gmane.org gmane.emacs.gnus.general:85040 Archived-At: On 2014-09-25, Daiki Ueno wrote: > Jens Lechtenboerger writes: > >> I fail to see why encrypt-to-self should be tied to sign-related >> variables. > > The variable name might not be too intuitive, but maybe you could > imagine how GPG signing and encryption work. Decryption keys are > usually same as signing keys. I=E2=80=99m not sure about that, but this may be a side issue. GnuPG creates an encryption subkey by default. > Suppose that one has three keys associated with his e-mail address. Key > A is for encrypted e-mail communication with his colleagues, key B is > for communicating with friends, and key C is for automatic signing of > tarballs. > > Here, those keys are more securely protected in order of A, B, and C. > He doesn't want to use key C for any e-mail encryption. He doesn't want > to use key B for confidential communication within his company. > > This might sound hypothetical but I do have a similar setting. How do > you address this situation with ~/.gnupg/gpg.conf options and Bcc? Apparently, we have been talking about different things. 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. 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.) 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.) I don=E2=80=99t see how either case is supported by mml2015, though. What is your configuration? Besides, what is the intended meaning for signatures if mml2015-signers contains multiple keys? Best wishes Jens