On Sun, Jan 26, 2003 at 07:46:10PM +0100, Kristian Koehntopp wrote: > Schlie�lich konzentrieren sich die Angriffe der Gegner mittlerfreie > Kommunikation mehr und mehr auf die wenigen identifizerbaren Endpunkte, also > die Provider von Connectivity und die Betreiber von Katalogen wie zum > Beispiel Google (aber auch Napster und Kazaa). Daher m�ssen sich die > Bef�rworter mittlerfreie Kommunikation �berlegen, wie sie bisher noch > existierende zentrale Kataloge dezentralisieren und im Netz nicht verortbar > machen k�nnen. Wie lassen sich Vertrauen und Qualit�tskontrolle in einem > System etablieren, in dem nur mit leicht wechselbaren Pseudonymen gearbeitet > werden kann und in dem prinzipbedingt kein realweltlicher Bezug zu diesen > Pseudonymen hergestellt werden kann und darf?
Sehr viele Angriffm�glichkeiten auf die existierende Infrastruktur
r�hren durch die Verwendung von nicht-selbstauthentifizierenden
Namenspaces her.
Denn wo immer ich eine Domain-Namen oder eine IP-Adresse oder einen
anderen zentralverwalteten Namen weitergebe (und damit bei jeder
Weitergabe von EMail-Adressen und URLs) schalte ich implizit einen
Mittler in die Kommunikation dieser Adresse ein! Das ist fatal, weil
mit der Kommunikation von Adressen Vertrauensverh�ltnis transportiert
werden ("Frag mal bei [EMAIL PROTECTED] nach, der wei� da gut Bescheid." oder
"Unter http://bla.de/xy.html findest Du eine gute Einf�hrung zu diesem
Thema.").
Das ganze Scheitern von PGP und dem Web-Of-Trust kann man letztlich
darauf zur�ckf�hren, da� man dies nicht erkannt hat. Wenn man statt
Email-Adressen Fingerprints weitergeben w�rde, br�uchte man kein
Web-Of-Trust. (Der reale Name ist f�r digitale Kommunikation ja
sowieso meistens unerheblich.)
Hashes von Public-Keys als Pseudonyme eliminieren mit einem Schlag
die Notwendigkeit zentral verwalteter Namensr�ume und damit
solche mi�brauchsanf�lligen Systeme wie das DNS. Da� Hashes keine
leicht zu merkenden Keyw�rter sind, ist dabei kein Problem, denn
auch mit einem zentralen System kann man nicht jedem einen solchen
Namen geben. (wie bei ICU und Telefonnummern w�rde man es einem
lokalen Client �berlassen, ein "Telefonbuch" mit Kurzname
zu verwalten.)
Dies w�rde au�erdem die opportunistische Verschl�sselung *aller*
Kommunikation erm�glichen, was einen weiteren Haufen von Problemem
l�sen w�rde.
Content-Hashes f�r Daten l�sen einen weiteren Haufen von
Sicherheitsproblemen und lie�en eine Dezentralisation jeder Art
von Informationspeicherung zu.
Die restlichen Vertrauens- und Qualit�tskontrollprobleme lassen sich
relativ leicht und denzentral mit Trust-Metriken l�sen. Google bezieht
seiene Qualit�t auch letztendlich auch aus den denzentral gespeicherten
Trust-Beziehungen, die in der Link-Struktur des WWW codiert sind.
Erst die k�nstliche Zentralisierung in einer kommerziellen Suchmaschine
provoziert die bekannten Zensurerscheinungen bei Google.
Viele nette Informationen stecken sicher auch in den References- und
In-Reply-To-Headern in Mail und News. (Leider sind sowohl URLs als auch
Message-IDs keine selbstauthentifizierenden Namen, weshalb diese
Trust-Verh�ltnisse kryptographisch nicht abgesichert sind.)
Man m��te es nur wollen. Der RFC zu SPKI z.B. verstaubt schon seit
einigen Jahren.
Und �brigens: Auch in komplett dezentralisierten Informationsystemen
lie�e sich eine Policy zur Verhinderung der �ffentlichen Verbeitung
bestimmer Informationen implementieren. Diese Policy m��te nur von
dem �berwiegenden Anteil der Teilnehmer gewollt und implementiert
werden.
Martin
--
"Truth and Technology will triumph over Bullshit and Bureaucracy"
-- Rene Anselmo
pgp00000.pgp
Description: PGP signature
