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