Subject: [openpgp] Unuploadable Keys

From: "Neal H. Walfield" <[email-masked]>
Date: Wed, 15 Jul 2015 16:21:52 +0200

Hi,

OpenPGP has support for local signatures.  It would be nice to have
something similar for keys as well.  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 very difficult.

Concretely, it should be possible to mark a key as not exportable to a
keyserver or to provide a list of key servers (perhaps described using
regular expressions as per Section 8 of RFC 4880) to which it may be
exported.

  This could be implemented as a new signature subpacket.

  When the key is exported (e.g., using gpg2 --export KEYID), a
  warning should be issued that the key is not intended for public
  distribution.

I realize that this proposal is very informal.  However, I'd like to
hear if something like this is interesting for RFC 4880bis.  If so,
I'd be happy to try and come up with some more formal.

Thanks!

:) Neal

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Tue, 21 Jul 2015 23:11:40 +0200

Hi Neal--

>   warning should be issued that the key is not intended for public

I like this idea, though i'm not sure how useful it is as currently
proposed.

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.

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:

 0) Any existing key (one with a self-sig that does *not* have this
    feature set) can't add this feature in a reliable way -- a new
    self-sig can just be stripped out of the certificate and the
    remaining certificate (with the previous self-sig) will be back to
    being "exportable".

 1) The keyservers would need to respect the value and decline to accept
    or propagate such keys.  SKS currently doesn't even respect the
    non-exportable flag for non-self-sigs
    (https://bitbucket.org/skskeyserver/sks-keyserver/pull-request/20),
    let alone verify the cryptographic validity of signatures.

 2) GnuPG doesn't currently let you make non-exportable self-sigs, as
    far as i can tell (i just tested 2.1.6 with gpg2 --expert --lsign;
    maybe this is a bug in gpg, though)

 3) anyone can just post the key publicly in a non-keyserver way
    (e.g. to the web) if they really want to do so.

So the question is whether having this as an advisory mechanism (not a
perfect bulwark against adversarial publication) is worthwhile.  If it
is worthwhole, would this interpretation of non-exportable self-sigs be
a sufficient mechanism?

This is certainly something worth considering clarifying in rfc4880,
whether it's introduced as a separate subpacket, or a clearer
recommendation of how to treat non-exportable subpackets in a self-sig.

  --dkg

---

From: Werner Koch <[email-masked]>
Date: Thu, 23 Jul 2015 11:12:20 +0200

> perfect bulwark against adversarial publication) is worthwhile.  If it

I would really like to see such a standard flag.  For whatever reasons
some people do not like to have there keys on a keyserver and only make
them available by other means.  Such a flag would also help with testing
to avoid accidental uploads of a key.

This can be implemented with a new flag value for the key server
preferences.  The only defined 0x80 flag is not really useful because
there is no definition on now a keyserver can check that an update
request comes from the key holder.  A new 
 
  0x40 = Do not send or refresh from a keyserver

could be used for this.  Of course it is still possible to export
(e.g. "gpg --export") them and send them to a keyserver with other tools
but it makes administyration (e.g. "gpg --refresh-keys") easier.

An additional flag

  0x20 = Do not use any public service to send or refresh this key

could be used in the same way for DNS or other network based lookups.

Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.

---

From: "Neal H. Walfield" <[email-masked]>
Date: Sat, 25 Jul 2015 17:13:36 +0200

Hi Daniel,

At Tue, 21 Jul 2015 23:11:40 +0200,
> 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.

> 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

---

From: Gregory Maxwell <[email-masked]>
Date: Sat, 25 Jul 2015 17:46:54 +0000

> to avoid accidental uploads of a key.

A related flag, though sadly more complex to implement, would be
making it so the list of signatures on a key must be signed by a
selected subkey.

This would prevent an irritating attack where people create random and
sometimes harassing or offensive keyids and use them to sign your key
and upload the result to the keyservers-- which is one of the most
common reasons I've seen cited for people not wanting their keys on
keyservers.

---

From: Vincent Breitmoser <[email-masked]>
Date: Sat, 25 Jul 2015 22:20:33 +0200

On 23 Jul 2015, Werner Koch wrote:
> I would really like to see such a standard flag.  For whatever
> reasons some people do not like to have there keys on a keyserver
> and only make them available by other means.

I concur. We ask users during creation of keys whether they want it
uploaded or not, and it would be helpful to associate this setting with
the key in a standardized way.

 - V