UI terminology for calculated validities

[Nicolai Josuttis]

First, thanks to all for helping to clarify the issue (for me)

Here is an example of a real world novice problem based on the current
terminology and what we discuss (a real example from today):

In enigmail a user enabled the option "trust_model always"
(it's currently named there as "Always trust people's keys" ;-) ).
When I asked why, the user told me:
 If I don't do that, I always get error messages.
So the dialog between me and the user ("he") continued
roughly as follows:
 me: so the keys are missing
 he:   no, I downloaded them from keyserver xy
 me: oh, but you need trust for the keys
     (meaning they have to be valid)
 he:   yes, it works if I assign ultimate trust to the key
       (he meant the owner)
 me: no, no, don#t do that.
     ultimate is if you created the key
 he:   so what?
 me: you either can sign the key
     or trust somebody else who signed the key
     (such as pgpca at ct.heise.de)
 he:   Oh, I even registered my email/key there
       but what else is missing?
 me: load the key for pgpca at ct.heise.de
 he:   done, but trust is still missing
 me: oh, yes, you also have to express trust for this key/owner
Then it worked ...

That's a summary of learning step by step what has to be done
to benefit from the web-of-trust
(and BTW "he" was even an IT guy).

BTW, the dialog would have been different
     if I would have used "valid" instead of "trusted".
E.g. as follows:
 me: oh, but you need valid(!) keys
 he:  but they are! Look, neither expired or revoked!
 me: no, no, valid in the sense that you can trust them
 he   ah, I need to trust the keys ...

The essence, we have to teach is:
- create a key
- and then either
  - exchange the key
  - and sign then key you got
    (after validating the fingerprint)
  or
  - load the key for pgpca at ct.heise.de
    or other central "trust agencies"
  - AND express trust for that key/owner

Thus, I am really surprised that you suggest to teach "validity"
instead of "trust".
And I agree that "owner" make things unnecessary complicated.
I am more and more convinced that we simply always should
talk about trust:
- If I trust the key/owner that/who signs other keys,
  I can trust these keys and safely use them

Note that although we can skip the term "owner" we need
the term trust, because without trusting any owner
the trust model doesn't work.


Am 23.04.2014 00:11, Peter Lebbing schrieb/wrote:
> On 22/04/14 23:58, Daniel Kahn Gillmor wrote:
>> If i grant "marginal" ownertrust to both A and B, then X only needs one
>> other friend to collaborate to get my gnupg implementation to accept
>> certificates that i'm not intending to accept.
> 
> I might have snipped my quote too much. Hauke was arguing that the term
> "ownertrust" is not correct because it is not about trust in the owner, but
> trust in specific keys.
> 
> In your example, you do not trust the two keys differently[1]. However, due to a
> technicality, you can't assign both the same ownertrust, because they would add
> up. I don't think this is a fundamental thing that changes the concept of
> ownertrust, it is an unfortunate technicality. If GnuPG were somehow enhanced
> that you could mark them as "this is the same person", you would assign both
> "marginal" and benefit from certifications of either key. If it's that easily
> fixed, it's not a fundamental issue in my book.
> 
> Peter.
> 
> [1] Although you might mistrust a key that's no longer considered secure by
> current cracking standards. Again, not an issue with trust in the owner, but a
> technicality.
> 
> ---
> I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
> You can send me encrypted mail if you want some privacy.
> My key is available at <http://digitalbrains.com/2012/openpgp-key-peter>
> 
> _______________________________________________
> Gnupg-users mailing list
> Gnupg-users at gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-users
> 
> 

-- 
Nicolai M. Josuttis
www.josuttis.de