Hi Nico-- thanks for your work on this; i'm really glad to see people thinking it through in detail.
Responses in more detail below, along with a more radical proposal that
hopefully we can use to think through the desired behavior.
On 04/21/2014 04:11 PM, Nicolai Josuttis wrote:
> Let me try to find a wording both experts and novices can live with
> (IMO that's key for a better acceptance of PGP).
yes, clearer understanding is important.
> We have owners.
I'd say "we have keys", and there are people who control those keys.
Some keys might be held or controlled or owned by multiple people.
> We can specify how much we trust them.
since the term "trust" is so beleaguered, perhaps we should say "we can
specify how much we're willing to rely on any given key to certify other
certificates.
> We have keys.
> Keys belong to email addresses.
again, i'd say that keys are distributed within certificates, and (most)
certificates have e-mail addresses associated with them.
> So the hard part is how the following:
> - a key is valid means different thing for experts and novices
I think we should be talking about a (key,userid) being valid, or a "key
being valid for a given e-mail address". Saying "a key is valid" isn't
really what we want to say. In particular, a key could be valid for one
e-mail address, and it could be not valid for another e-mail address.
> - we trust a key is nothing useful for an expert
> but for a novice.
i'm not sure what you mean by this. can you explain more?
> Now we have to formulate an option:
> - we accept all keys except disabled/expired/revoked ones.
> AH, may be "accept" is a word we can use
> (I used it here incidentally...)
"accept" needs to be clearer, i think, because it may not be just "we
are willing to encrypt to this key" -- it may also be "we are willing to
believe that signatures made by this key actually come from the person
identified in the user ID of the key's certificate"
> So may be we allow to change both options into the following:
>
> Accepted keys to send encrypted:
> - All valid keys according to the web of trust
> - All except disabled/expired/revoked keys
how about:
For a given e-mail address, encrypt messages to:
* all keys valid for that e-mail address
* all usable keys that claim to belong to that e-mail address
Note that enigmail's current default behavior is to simply choose the
*first* key in GPG's keyring that claims to be associated with the
e-mail address in question. This is true, even if the first key in the
keyring with a given e-mail address is *not valid* for that e-mail
address, and another later key *is valid* for that e-mail address :(
> Automatically send encrypted
> - never
> - if we have accepted keys for all e-mail addresses
> And for the first option of the first option we NEED a very short but
> compelling explanation (ideally as help text),
> which I still try to find reading all the documentation.
> May be:
> - According to the web-of-trust, a key is valid if:
> - it is your key (has ultimate owner trust)
> - you signed it
> - another owner you fully trust signed it
> - at least 3 other owners you marginally trust signed it
this may or may not be true, depending on the certification patterns.
It's certainly possible for users of gpg to modify how gpg interprets
the network of identity certifications it knows about. See
"--marginals-needed" and "--max-cert-depth" and "--trust-model"
arguments to gpg.
> But, BTW, I just saw that we also use the term "trusted" instead of
> "valid" in the key manager.
> So currently "trusted key" is used more or less consistently
> as non-technical term for "valid key".
Any place you find enigmail using "trusted" to mean "valid" is a bug,
and needs to be fixed. it's not surprising that there are more cases
that still linger in the codebase; gpg didn't clarify its own
terminology until several years ago, and enigmail has done some cleanup
on this recently, but seems to be reintroducing some of the conflated
terminology in some places. We should really try to avoid that.
(for example, the recent "trust the keys of all recipients" should
probably be something like "don't validate keys of recipients" -- we
don't know if the keys in questions actually belong to the recipients,
and we don't plan to actually indicate any ownertrust in them)
> So, let me ask again:
> May be you and we all can live with the term "trusted key"
> (as contrast to trust for owners),
no, i think that's one of the root causes of a lot of ongoing confusion.
non-expert users and expert users alike will be confused if we use the
same term ("trusted") to mean two different things.
All of this discussion has me thinking more widely about what the ideal
user interface *should* be, if we could get to it, rather than making
incremental improvements. I've tried to do a brief sketch below on a
new UI proposal that i think would address these concerns more helpfully
for regular use. the proposal itself is probably programmatically
complex, but what is exposed to the user are simple, sensible choices
for daily use. i welcome any edits that might make the user experience
smoother (or the code simpler, though not at the cost of making the user
experience clunkier),
The basic idea is to expose the encryption decision-making process
during the message composition, rather than during message sending.
I'd be happy to try to have a discussion/brainstorming on this in
realtime, if folks wanted to set up a chat on IRC, or a webrtc session
or something. here's a (very rough) pitch on what i think would be useful:
* by default, messages are not encrypted
* there is a clear visual indication to the user that indicates whether
or not the message will be encrypted.
* for each recipient in the message composition pane, we should have an
icon that indicates the status of the recipient: if we know of no key
that has the e-mail address associated to it in any way, we can call
that icon [nokey]. do we know of a valid key for that e-mail address,
we can call that icon [valid]. if we know of a well-formed key that
includes their e-mail address but know of no valid keys for the address,
we can call that [unverified]. (this initial analysis leaves out
expired, revoked, or disabled keys, but perhaps we could flesh it out to
include them). (note that some e-mail addresses have multiple keys that
are in different states; the default icon will show the "strongest"
association). (note also that this might be made more complicated by
any existing per-recipient rules, which might override the keys found by
gpg)
* if all of the recipients are [valid], then the default state for a
message should move to "encrypted".
* if the user manually chooses to encrypt the message when some users
are not [valid, then the non-[valid] icons should be highlighted or made
bigger or flash or blink or something to draw attention to them.
* clicking (or right-clicking?) on the icons next to each recipient
should show a (hopefully short) dropdown menu of options to consider for
each recipient. the dropdown menu should probably be different based on
the state of the various key(s) associated in some way with the
recipent's e-mail address. since the address might have several keys,
this menu will probably need to be dynamically populated.
* so what's in the context menu?
* probably all of them could have "search for more keys for this
address on the keyservers"
* for addresses which have some keys, "refresh your keys for this
address from the keyservers"
* for [unverified] addresses, "encrypt to key 0xCCDFFEEA00332261 for
al...@example.org" (selecting this might open a dialog box with a
checkbox for "always use this key for al...@example.org", which could
then be used to make a local certification with an ultimately-trusted key)
what do people think of this proposal? if implemented, do you think it
would address the concerns that Nico is trying to address with his
patch? I'm aware that some of it might not be currently possible (we
might need changes or hooks in thunderbird itself, for example), but i
think it's worth thinking about what we think the endgame outcome would
be if we could make it so. maybe that will help to identify fixes we
*can* do more easily that address some of the concerns.
--dkg
signature.asc
Description: OpenPGP digital signature
_______________________________________________ enigmail-users mailing list enigmail-users@enigmail.net https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net
