UI terminology for calculated validities
Hauke Laging
mailinglisten at hauke-laging.de
Fri May 2 04:02:30 CEST 2014
Am Fr 25.04.2014, 12:47:46 schrieb Daniel Kahn Gillmor:
> > c) I would like to handle that with an generic notation. I see a
> > strong need for an expression about the relation of the signer to
> > the owner of the signed key. It makes a big difference whether I
> > say "This is some foreigner which has shown me some ID (see
> > separate notation for details)" or "This is my sister". Thus I
> > would like to have a notation "relation@" which would in this case
> > have a value like "identity" or "self", maybe with some additional
> > information like "self: business".
> with the possible exception of "self" indications, which i can see as
> useful for key transitions and multi-key-holding individuals, i don't
> want to see any of these other relationships embedded in the network
> of identity certifications which are published. The social graph
> exposed by the public keyservers is rich enough to be useful for
> networked identity certifications, but no richer. it should stay
> that way, since rich published social graphs can be used against
> their participants,
That is not a crypto-related argument. I would never suggest to build
key management software in a way that forces people to reveal this
information. But I strongly argue against making the decision for the
users what information they may offer and which not.
I am not a privacy expert but I assume that for most of the Internet
users it is not difficult to find out who their family members or their
close friends are. If this information is available anyway then it makes
little sense to "protect" this information in the OpenPGP area.
> and it's not clear how to use the additional
> relationship information in an effective way.
I am convinced that future crypto software will have to attribute both
security and authenticity assessments with keys. Currently most users
are just playing crypto (or rather: playing IT security; crypto is not
the weak part of it; its organizational handling is). There will be
limits similar to --min-cert-level which restrict the accepting of
signatures (for certain security levels).
> let's keep it simple, and minimize the amount of social graph leakage.
Let's not try to protect the users against themselves even in non-
technical contexts. Your opinion about leaking social information is not
better that that of somebody who likes to leak it. The result should not
be you making that impossible for him but quite simple: He leaks, you
don't.
Hauke
--
Crypto für alle: http://www.openpgp-schulungen.de/fuer/unterstuetzer/
http://userbase.kde.org/Concepts/OpenPGP_Help_Spread
OpenPGP: 7D82 FB9F D25A 2CE4 5241 6C37 BF4B 8EEF 1A57 1DF5
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: This is a digitally signed message part.
URL: </pipermail/attachments/20140502/df87ef59/attachment.sig>
More information about the Gnupg-users
mailing list