Re: [openpgp] Unuploadable Keys

[Daniel Kahn Gillmor <[e-mail]>]

On Sat 2015-07-25 11:13:36 -0400, Neal H. Walfield wrote:
> 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.

these UI/UX difficulties seem like they're inherent in how GnuPG
interacts with the "non-exportable" flag, but not necessarily a
requirement from the OpenPGP protocol perspective.  Maybe there are
UI/UX improvements that could be done in GnuPG to treat these flags more
conveniently?

> 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.

Are you aware that SKS currently doesn't discard local signatures at
all? :(  (see the link in my previous e-mail)

> 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.

I think you're saying that there should be an extra flag that is similar
in semantics to the "non-exportable" flag, but that is slightly
different.  OpenPGP implementations should support both semantics.

I worry that this would lead to more confusion, not less: Can a key be
both "exportable" and "not for wide distribution"?  what about a key
that is marked as "local (non-exportable)" but also marked "for wide
distribution"?  how can we explain what these options mean to users?  Or
should we define a new value (other than 0 or 1) for the exportable
subpacket?  https://tools.ietf.org/html/rfc4880#section-5.2.3.11

I note that the spec doesn't say what to do if there are multiple
Exportable Certification subpackets of different values in a single
certification.

>> 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.

I just meant "would issuing only non-exportable self-sigs (as i proposed
above) be sufficient to do what you're looking for?"  -- you've answered
this somewhat above with your concerns about the difficult ui/ux of
--export-options export-local, etc, but it seems like that answer
relates more to the GnuPG implementation than to the OpenPGP protocol.

So i think the things we'd need to do to sort this out more clearly are:

 0) figure out what the explicit semantics are (and how they differ
 from/relate to the existing exportable semantics)

 1) figure out where they should apply -- should they belong to the
 primary key, to User IDs, or somewhere else?

 2) figure out how to represent them in the bytes on the wire

 3) come up with implementation guidance about how to handle keys/certs
 marked in this way.

regards,

 --dkg