Beispiel

In einem Web of Trust funktioniert das so:

1. Alice erzeugt für sich ein Schlüsselpaar und signiert es. Außerdem schickt sie den öffentlichen Teil an einen Schlüsselserver (key server), damit andere Teilnehmer leichten Zugriff darauf haben.
2. Bob möchte mit Alice verschlüsselt kommunizieren. Dazu besorgt er sich Alices Schlüssel von einem Schlüsselserver, muss aber noch sicherstellen, dass er wirklich den richtigen Schlüssel bekommen hat: Ein Angreifer könnte sich für Alice ausgeben und einen von ihm erzeugten Schlüssel an den Schlüsselserver schicken. Jeder, der meint, eine Nachricht nur für Alice zu verschlüsseln, würde sie in Wirklichkeit für den Angreifer verschlüsseln.
3. Bob bittet Alice (z. B. bei einem Telefonanruf oder einem persönlichen Treffen) um den Fingerprint ihres öffentlichen Schlüssels. Diesen vergleicht er mit dem des Schlüssels, den er vom Schlüsselserver erhalten hat.
4. Stimmen beide Fingerprints überein, kann Bob davon ausgehen, den richtigen Schlüssel erhalten zu haben. Darum signiert er den öffentlichen Schlüssel von Alice (genauer: eine oder mehrere ihrer User-IDs) mit seinem privaten und schickt diese Signatur an den Schlüsselserver.
5. Möchte jetzt Carl mit Alice verschlüsselt kommunizieren, besorgt er sich genau wie Bob Alices öffentlichen Schlüssel vom Schlüsselserver. Dann stellt er fest, dass Bob Alices Schlüssel bereits überprüft hat. Wenn Carl Bobs Schlüssel schon kennt und er Bob vertraut, dass Bob vor der Signatur fremder Schlüssel eine gründliche Überprüfung durchführt, dann muss er nicht erst Alice treffen und diese Prüfung wiederholen. Er vertraut dem Schlüssel von Alice allein aufgrund Bobs vertrauenswürdiger Signatur. Wenn Carl sein Sicherheitsniveau erhöhen möchte oder er speziell Bobs Signaturen nur eingeschränkt vertraut, kann er sein Kryptosystem so konfigurieren, dass mehrere von ihm akzeptierte Signaturen vorhanden sein müssen, damit ein Schlüssel automatisch als gültig angesehen wird.

Owner Trust

Den Wert für Owner Trust legt jeder Benutzer für die Schlüssel in seinem öffentlichen Schlüsselbund selbst fest (d. h., diese Information wird nicht öffentlich); zur Auswahl stehen bei GnuPG (der RfC macht dazu überhaupt keine Angaben) folgende Werte:

• „unbekannt“ („unknown“) für Schlüssel, für die man noch keine explizite Angabe gemacht hat (Standardwert)
• „kein Vertrauen“ („not trusted“) für Schlüssel, deren Zertifizierungen explizit nicht vertraut wird (d. h., Signaturen dieser Schlüssel werden für die Gültigkeitsberechnungen ignoriert)
• „geringes Vertrauen“ („marginal“) für Schlüssel, denen nur eingeschränkt vertraut wird (d. h., standardmäßig werden drei Signaturen von solchen Schlüsseln benötigt, um einen Schlüssel gültig zu machen)
• „volles Vertrauen“ („complete“) für Schlüssel, denen voll vertraut wird (d. h., standardmäßig reicht eine solche Signatur aus, um einen Schlüssel gültig zu machen)
• „absolutes Vertrauen“ („ultimate“) für Schlüssel, die man selber erzeugt hat (diese Beziehung ist nicht fest; man kann eigenen Schlüsseln einen anderen Wert geben und ebenso fremden Schlüsseln diesen Wert zuweisen; bei solchen Schlüsseln reicht immer eine einzige Signatur aus, um einen Schlüssel gültig zu machen)

Beim Standardverfahren zur Gültigkeitsberechnung (WoT) braucht GnuPG mindestens einen Schlüssel mit absolutem Vertrauen im Keyring, weil ansonsten kein Schlüssel gültig wird (und nur die Signaturen gültiger Schlüssel werden berücksichtigt).

Normale Signaturen wirken sich nur auf die Gültigkeit des signierten Schlüssels aus, nicht aber auf dessen owner trust! Der muss für jeden Schlüssel einzeln in der lokalen Datenbank festgelegt werden (bei GnuPG; der RfC erlaubt auch entsprechende Signaturen („Trust Packet“) im Keyring).

Signatory Trust

Signiert Alice den öffentlichen Schlüssel von Bob und überträgt diese Signatur anschließend an einen Schlüsselserver, so kann diese Signatur von Dritten zur Beurteilung der Authentizität des öffentlichen Schlüssels von Bob benutzt werden. Dazu überprüfen sie (im Wesentlichen),

1. ob der öffentliche Schlüssel von Alice für sie gültig ist (weil sie ihn selbst signiert haben oder er über das WoT gültig wurde) und
2. ob sie dem öffentlichen Schlüssel von Alice einen positiven owner trust („marginal“ oder „complete“) zugeordnet haben.

Ist beides der Fall, dann wird Bobs Schlüssel entweder schon allein durch die Signatur von Alice gültig („complete“) oder eventuell zusammen mit weiteren („marginal“). Der owner trust von Bobs Schlüssel ändert sich dadurch nicht.

Welchen owner trust Alice für Bobs Schlüssel festgelegt hat, spielt für diesen Vorgang schon deshalb keine Rolle, weil diese Information nicht öffentlich bekannt ist. Der Öffentlichkeit wird nur mitgeteilt, dass Alice von der Identität des Schlüsselbesitzers (Bob) überzeugt ist. Was Alice von Bobs Signaturen hält, hat auf das WoT der anderen Nutzer keinerlei Einfluss.

Key Legitimacy

Das Vertrauen in die Authentizität eines öffentlichen Schlüssels wird durch den „Key-Legitimacy“-Wert ausgedrückt. Er wird aus dem Signatory Trust der signierenden Schlüssel wie folgt berechnet:

• sei ${\displaystyle x}$ die Anzahl von Signaturen, deren Signatory Trust „marginal“ ist
• sei ${\displaystyle X}$ die Anzahl von Signaturen mit einem Signatory Trust „marginal“, die erforderlich ist, damit ein Schlüssel als authentisch eingestuft wird
• sei ${\displaystyle y}$ die Anzahl von Signaturen, deren Signatory Trust „complete“ ist
• sei ${\displaystyle Y}$ die Anzahl von Signaturen mit einem Signatory Trust „complete“, die erforderlich ist, damit ein Schlüssel als authentisch eingestuft wird

Dann sei ${\displaystyle L={\frac {x}{X}}+{\frac {y}{Y}}}$

Ist ${\displaystyle L=0}$, so gilt der überprüfte Schlüssel als nicht authentisch. Bei ${\displaystyle 0<L<1}$ wird er als „teilweise authentisch“ angesehen und bei ${\displaystyle L\geq 1}$ als „vollkommen authentisch“. Im Regelfall wählt man ${\displaystyle X=2}$ und ${\displaystyle Y=1}$, es sind also zwei Signaturen von teilweise vertrauenswürdigen Personen oder eine Signatur einer voll vertrauenswürdigen Person erforderlich, damit ein Schlüssel als authentisch eingestuft wird. Prinzipiell kann aber jeder die Werte für ${\displaystyle X}$ und ${\displaystyle Y}$ je nach persönlichem Paranoia-Grad frei wählen.

Probleme mit dem Datenschutz durch Schlüsselserver

Ein grundsätzliches Problem besteht darin, dass der Inhaber eines Schlüssels bei den derzeit gebräuchlichen Implementierungen technisch keinen Einfluss darauf nehmen kann,

• wer seinen öffentlichen Schlüssel signiert und
• ob jemand seinen öffentlichen Schlüssel auf einen öffentlichen Schlüsselserver hochlädt (oder mit neuen Signaturen erneut hochlädt).

Dem Schlüssel haften jedoch personenbezogene Daten an, die mitveröffentlicht werden: Durch die Signaturen anderer Personen, dem wichtigsten Element des Web of Trust, beinhaltet der Schlüssel eine Liste der Personen, die die Identität des Schlüsselinhabers geprüft haben, inklusive Prüfungsdatum. Auf einem Schlüsselserver sind diese Daten öffentlich einsehbar und automatisiert abrufbar, und können so leicht analysiert und somit die Beteiligung des Schlüsselinhabers an sozialen Netzwerken ermittelt werden.

Außerdem sammelt sich mit der Zeit eine öffentliche Liste aller früheren E-Mail-Adressen des Schlüsselinhabers an, solange der Schlüsselinhaber seinen Schlüssel nicht wechselt.

Nicht jedem ist von Anfang an bewusst, dass er durch die Teilnahme am Web of Trust Daten freigibt, die er vielleicht nicht für öffentlich erklären wollte und dass es keine Möglichkeit gibt, sie jemals wieder entfernen zu lassen.

Einmal auf Schlüsselserver exportierte öffentliche Schlüssel können nicht mehr gelöscht werden. Die Schlüsselserver synchronisieren sich ständig untereinander, sodass ein neuer oder ergänzter Schlüssel einschließlich aller Signaturen und Kommentare innerhalb von kürzester Zeit nach dem (erneuten) Hochladen auf allen Schlüsselservern der Welt abrufbar ist, ganz gleich wer den Schlüssel hochgeladen hat und ob der Schlüssel ihm auch gehört.

Die Möglichkeit des Schlüsselwiderrufs (englisch key revocation) besteht bei den gebräuchlichen Implementierungen nur aus dem Erstellen eines Schlüsselwiderrufszertifikats, das dann ebenfalls auf den Schlüsselserver hochgeladen werden muss, dort aber praktisch nichts weiter bewirkt, als den vorhandenen Schlüssel mit dem Hinweis zu versehen, der Schlüssel solle nicht mehr benutzt werden. Software kann, aber muss nicht, solche Schlüssel zum Verschlüsseln verweigern. Mit einer Löschung von Schlüsseln, Signaturen oder Kommentaren hat der Schlüsselwiderruf aber nichts zu tun.

Der Schlüsselinhaber hat damit keine Möglichkeit, Einfluss auf die Verbreitung der Daten zu nehmen, die für das Funktionieren des Web of Trusts notwendig sind. Dies steht im Widerspruch zu dem Zweck von Verschlüsselungsprogrammen, persönliche Daten zu schützen.