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