keysigning, web of trust, ano/pseudonyme keys etc.

Autor: christian mock (cm@tahina.priv.at)
Datum: Die Jun 04 2002 - 16:42:44 CEST


aaron@lo-res.org said:
> aber im sinne von cm werde ich jetzt nicht mehr (noch mal) ueber das
> thema diskutieren (auszer in priv. mails)

jetzt wird's aber fuer mich wieder interessant (benehm ich mich wie
ein verzogener fratz? -- wurscht), wenn wir nicht beim anlaesslich
der keysigning-party durchgekauten steckenbleiben, sondern versuchen,
loesungen zu finden.

wir koennen das thema aber auch auf die keysigning-liste migrieren,
die ist momentan eh still.

ich probier die problemkreise einmal auseinanderzudividieren:

- generell

was ist das ziel? mit einer identitaet (und ich schreib jetzt
bewusst nicht person) vertraulich zu kommunizieren, evtl. signiert.

dazu ist es notwendig, wenn man die identitaet nicht persoenlich
kennt, zu einem vertrauenswuerdigen key (bzw. einem mapping key-id ->
identitaet) zu kommen, sonst droht die man-in-the-middle gefahr.

solang ich die identitaet persoenlich kenne, reicht eine lokale sig
in meinem keyring.

- namentliche keys

klar, web of trust, keysigning-parties as usual.

pro: hilft der verbreitung des web of trust, durch die namentlichkeit
erhaelt die PGP-verwendung einen touch von "seriositaet".

contra: je nach signing-gewohntheiten/umstaenden gute
identifizierbarkeit sozialer beziehungen.

- pseudonyme keys

problem: mapping pseudonym -> key-id. eine signature auf einem key
bedeutet daher, dass ich mehr als den ausweis des eigentuemers kenne
-- ich bestaetige ja, dass mir der key von der person, die ich als
$pseudonym kenne, vorgelegt wurde. daher groessere
identifizierbarkeit sozialer beziehungen.

prinzipiell anschlussmoeglichkeit an das weltweite web-of-trust, aber
mit der moeglichkeit der identifizierung sozialer beziehungen.

teil-loesung: automatisches signieren auf basis von email-adressen --
dh. der signierende bekommt eine email mit dem wunsch nach einer
signature, signiert vom betreffenden key, signiert den key, schickt
verschluesselt an die email-adresse im key zurueck. laesst sich
automatisieren, certification authorities (zb. a-sign light) machen
es mit x.509-certs bestimmter klassen genauso.

das man-in-the-middle risiko bleibt dabei allerdings, ist evtl
durch mehrere signaturen unabhaengiger "email-signer" reduzierbar.

sub-problem: PGP bietet keine moeglichkeit, bei einer signature zu
sagen "ich bestaetige, dass ich $fakten ueberprueft habe". loesbar
durch spezielle "email-signer"-keys, i.e. ich wuerde mit einem
speziellen key "cm@tahina.priv.at (I only checked the email address)"
signieren [0].

weiteres problem: geprueft wird maximal die email-adresse --
"me@quintessenz.at (aaron)" koennte verwirrung stiften, schlimm
wird's bei "x1234567@foobar.ac.at".

damit keine identifizierbarkeit sozialer beziehungen mehr.

- anonyme keys

frage: was sind "anonyme keys"? haben die keine user-id, haben sie
keinen namen, keine email-adresse?

wenn sie eine email-adresse haben, s.o.

generell betreten wir damit IMHO den bereich, in dem es um "aufbau
von vertrauen" geht -- diverse leute aus dem remailer/
alt.privacy.*-umfeld machen das so, etwa "stray cat" -- senden ueber
remailer, erreichbarkeit ueber alt.anonymous.messages, zuordenbarkeit
der postings zueinander nur ueber den PGP-key.

wenn also jemand mit dem gleichen PGP-key und der gleichen identitaet
oft irgendwo im netz zugange ist, glauben die regulars an die
zuordnung zwischen key und identitaet. das koennten sie bestaetigen
-- wieder mit dem problem, dass signatures keine "eigenschaften"
haben, sondern einfach da sind oder nicht.

soweit meine gedanken,

cm.

[0] wenn das sinnvoll erscheint, wuerd ich sowas durchaus
implementieren, wenn ich damit nicht unters signaturgesetz falle.

-- 
> Ich habe neulich ein paar Salate kennengelernt, die hatten eine
> ausgesprochen schlechte Meinung über Vegetarier.
Iß keinen Salat, weil du Tiere liebst, sondern weil du _Pflanzen haßt_!
                      -- Roger Schwentker und Felix von Leitner in dasr

[ Um sich von dieser Liste abzumelden, sende bitte "unsubscribe" ]
[ an <linuxevent-request@mlist.austria.eu.net>. ]




Dieses Archiv wurde generiert von hypermail 2.1.7 : Fre Mär 14 2003 - 22:19:20 CET