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 mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp