Re: [openpgp] Unuploadable Keys
"Neal H. Walfield" <neal@walfield.org> Sat, 25 July 2015 15:14 UTC
Return-Path: <neal@walfield.org>
X-Original-To: openpgp@ietfa.amsl.com
Delivered-To: openpgp@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38B301A1B1E for <openpgp@ietfa.amsl.com>; Sat, 25 Jul 2015 08:14:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.348
X-Spam-Level:
X-Spam-Status: No, score=0.348 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FuwtVk3wBJdE for <openpgp@ietfa.amsl.com>; Sat, 25 Jul 2015 08:14:04 -0700 (PDT)
Received: from mail.dasr.de (mail.dasr.de [217.69.77.164]) by ietfa.amsl.com (Postfix) with ESMTP id 3DEF41A87E7 for <openpgp@ietf.org>; Sat, 25 Jul 2015 08:13:45 -0700 (PDT)
Received: from p50813e87.dip0.t-ipconnect.de ([80.129.62.135] helo=mail.huenfield.org) by mail.dasr.de with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.76) (envelope-from <neal@walfield.org>) id 1ZJ18u-0000np-C3; Sat, 25 Jul 2015 15:13:40 +0000
Received: from grit.huenfield.org ([192.168.20.253]) by mail.huenfield.org with esmtps (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <neal@walfield.org>) id 1ZJ18r-0000bv-OP; Sat, 25 Jul 2015 17:13:39 +0200
Received: from ip6-localhost.huenfield.org ([::1] helo=grit.huenfield.org.walfield.org) by grit.huenfield.org with esmtp (Exim 4.84) (envelope-from <neal@walfield.org>) id 1ZJ18q-0008RZ-KP; Sat, 25 Jul 2015 17:13:36 +0200
Date: Sat, 25 Jul 2015 17:13:36 +0200
Message-ID: <87io98nucf.wl-neal@walfield.org>
From: "Neal H. Walfield" <neal@walfield.org>
To: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
In-Reply-To: <87615dkygj.fsf@alice.fifthhorseman.net>
References: <87a8uxlcvz.wl-neal@walfield.org> <87615dkygj.fsf@alice.fifthhorseman.net>
User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM/1.14.9 (Gojō) APEL/10.8 EasyPG/1.0.0 Emacs/24.4 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO)
MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue")
Content-Type: text/plain; charset="US-ASCII"
X-SA-Exim-Connect-IP: 192.168.20.253
X-SA-Exim-Mail-From: neal@walfield.org
X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 17:06:47 +0000)
X-SA-Exim-Scanned: Yes (on mail.huenfield.org)
Archived-At: <http://mailarchive.ietf.org/arch/msg/openpgp/05OMx_fIG3sn8EkyOGmrWeDI1W8>
Cc: IETF OpenPGP <openpgp@ietf.org>
Subject: Re: [openpgp] Unuploadable Keys
X-BeenThere: openpgp@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Ongoing discussion of OpenPGP issues." <openpgp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/openpgp>, <mailto:openpgp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/openpgp/>
List-Post: <mailto:openpgp@ietf.org>
List-Help: <mailto:openpgp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/openpgp>, <mailto:openpgp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 25 Jul 2015 15:14:05 -0000
Hi Daniel, At Tue, 21 Jul 2015 23:11:40 +0200, Daniel Kahn Gillmor wrote: > However, this arrangement (or your signature subpacket proposal) has a > set of problems that make it far from ideal protection, especially in > the face of potentially adversarial users: My proposal was explicitly not about adversarial users. I'm convinced that if an attacker has access to the data, there is nothing we can do at the OpenPGP level to stop them from publishing it. The motivation for this feature is: some people have keys that they don't want to have widely distributed and training others to respect this is not easy. In other words, it is too easy to inadvertently publish a key. My proposal is to provide a mechanism that allows users to mark keys that they share with others as not intended for wide distribution. In other words, my proposal is about providing a better way to communicate the desired policy and provide a way for tools to help realize that policy. > You could craft an OpenPGP certificate with all its self-sigs marked > non-exportable, and that should have roughly the same effect for other > users of GnuPG. You'd have to use --import-options import-local to > import it at all, or else it would have no valid self-sigs, which GnuPG > should reject as a poorly-formed certificate. I think this would make sharing non-exportable keys a pain, because it overloads the meaning of local in a confusing way. Further, the current mechanism is simply not enough to realize all interesting policies. So, if we are forced to add something new, we should do it properly. Consider the following two scenarios. When Alice wants to share her key with Bob, but not with the world, she could sends it to him via email. To import her key, Bob has to do something like: `gpg2 --import-options import-local'. There should be no reason for Bob to have to do this in this situation. The policy that Alice wants to implement is about exporting keys, not importing them. When Bob wants to export Alice's key to forward it to Carol via email, he needs to run `gpg2 --export-options export-local'. This is annoying. Instead, when he exports the key, he should get a warning or a prompt saying that Alice has indicated that this key shouldn't be widely distributed. Of course, we can't enable `--import-options import-local' and `--export-options export-local' by default, because local signatures really shouldn't be imported or exported by default. The problem goes from a usability problem to a security problem when we consider private key servers. Now, the private key server needs to be configured to not discard local signatures. But, is this always the right decision? Sometimes signatures really are local and should not be discarded or they are intended for a different key server. > would this interpretation of non-exportable self-sigs be > a sufficient mechanism? I'm sorry, but I'm not clear on what definition you mean. I've read your mail several times, but I can't figure it out. Can you please repeat it. Thanks for your comments, :) Neal
- [openpgp] Unuploadable Keys Neal H. Walfield
- Re: [openpgp] Unuploadable Keys Daniel Kahn Gillmor
- Re: [openpgp] Unuploadable Keys Werner Koch
- Re: [openpgp] Unuploadable Keys Neal H. Walfield
- Re: [openpgp] Unuploadable Keys Gregory Maxwell
- Re: [openpgp] Unuploadable Keys Vincent Breitmoser
- Re: [openpgp] Unuploadable Keys Daniel Kahn Gillmor