121 lines
12 KiB
Handlebars
121 lines
12 KiB
Handlebars
<div class="about">
|
|
<center><h2>
|
|
<a href="/about">Übersicht</a> | <a href="/about/news">News</a> | <a href="/about/usage">Nutzung</a> | FAQ | <a href="/about/stats">Statistik</a> | <a href="/about/privacy">Privacy Policy</a>
|
|
</h2></center>
|
|
|
|
<p><strong>Für Details zur Nutzung, siehe <a href="/about/usage">Nutzungshinweise</a>.</strong></p>
|
|
|
|
<h3 id="sks-pool"><a href="#sks-pool">Ist dieser Server Teil des "SKS Pools"?</a></h3>
|
|
|
|
<p>Nein. Das Föderations-Modell des SKS Pools hat mehrere Probleme bezüglich Zuverlässigkeit, Widerstandsfähigkeit gegen Vandalismus, und Nutzbarkeit. Wir werden in Zukunft möglicherweise eine ähnlich verteilte Infrastruktur einführen, aber <span class="brand">keys.openpgp.org</span> wird nie Teil des SKS Pools werden.</p>
|
|
|
|
<h3 id="federation"><a href="#federation">Ist keys.openpgp.org föderiert? Kann ich mit einer eigenen Instanz mithelfen?</a></h3>
|
|
|
|
<p>Aktuell nein. Wir planen, <span class="brand">keys.openpgp.org</span> zu dezentralisieren. Mit mehreren Servern, die von unabhängigen Administratoren gepflegt werden, wäre es möglich die Zuverlässigkeit des Dienstes noch weiter verbessern.</p>
|
|
|
|
<p>Einige Leute haben bereits ihre Hilfe angeboten, eine Server-Instanz von Hagrid zu pflegen. Das wissen wir zu schätzen, allerdings würden wir voraussichtlich kein "offenes" Föderations-Modell wie SKS verwenden. Dafür gibt es zwei Gründe:</p>
|
|
<ol>
|
|
<li>Für eine Föderation mit offener Teilnahme müssen alle Server-Daten ebenfalls öffentlich sein. Dies ist ein signifikantes Privacy-Problem, weil so auch alle Email-Adressen unserer Nutzer abrufbar würden.</li>
|
|
<li>Server, die als Hobby betrieben werden, können unseren Anspruch an Zuverlässigkeit und Performance nicht erfüllen.</li>
|
|
</ol>
|
|
<h3 id="non-email-uids"><a href="#non-email-uids">Warum werden Identitäten, die keine E-Mail Adressen sind, nicht unterstützt?</a></h3>
|
|
|
|
<p>Die Veröffentlichung von Identitäts-Informationen erfordert explizite Zustimmung ihres Besitzers. Für Identitäten die keine Email-Adressen sind, beispielsweise Bilder oder Links zu Webseiten, gibt es keine einfache Möglichkeit, diese Zustimmung einzuholen.</p>
|
|
|
|
<p>Hinweis: Manche OpenPGP-Anwendungen generieren Email-Adressen mit inkorrekter Formatierung. Diese Adressen werden möglicherweise von <span class="brand">keys.openpgp.org</span> nicht richtig erkannt.</p>
|
|
|
|
<h3 id="verify-multiple"><a href="#verify-multiple">Ist es möglich, mehr als einen Schlüssel unter der gleichen E-Mail Adresse zu veröffentlichen?</a></h3>
|
|
|
|
<p>Eine Email-Adresse kann zu jedem Zeitpunkt mit nur genau einem Schlüssel veröffentlicht werden. Wenn eine Adresse für einen neuen Schlüssel bestätigt wird, entfernt diese Operation automatisch auch die Assoziation mit dem vorigen Schlüssel. <a href="/about">Nicht-Identitäts Informationen</a> sind davon nicht betroffen, und werden immer für alle Schlüssel verteilt.</p>
|
|
|
|
<p>Auf diese Weise wird sichergestellt, dass eine Suche per Email-Adresse zu jedem Zeitpunkt genau ein oder kein Ergebnis hat, niemals mehrere Kandidaten. Dies vermeidet eine unmögliche Rückfrage an den Nutzer ("Welcher Schlüssel ist der richtige?"), und macht so die Schlüssel-Suche per Email-Adresse deutlich nutzbarer.</p>
|
|
|
|
<h3 id="email-protection"><a href="#email-protection">Wie werden ausgehende Bestätigungs-Emails geschützt?</a></h3>
|
|
|
|
<p>Wir verwenden den modernen <a href="https://www.hardenize.com/blog/mta-sts" target="_blank">MTA-STS</a>-Standard in Kombination mit <a href="https://starttls-everywhere.org/" target="_blank">STARTTLS Everywhere</a>, um unerlaubtem Zugriff durch Angreifer während der Zustellung vorzubeugen.</p>
|
|
|
|
<p>Der MTA-STS-Mechanismus hängt von einer kompatiblen Konfiguration des empfangenden Email-Servers ab. Du kannst <a href="https://www.hardenize.com/">hier überprüfen</a>, ob dein Email-Provider dies unterstützt. Falls der "MTA-STS" Eintrag auf der linken Seite kein grünes Häkchen anzeigt, erkundige dich am Besten bei deinem Provider, ob sie ihre Konfiguration updaten können.</p>
|
|
|
|
<h3 id="third-party-signatures"><a href="#third-party-signatures">Werden "Signaturen" von fremden Schlüsseln unterstützt?</a></h3>
|
|
|
|
<p>Kurze Antwort: Nein.</p>
|
|
|
|
<p>Eine "Drittsignatur" auf einem Schlüssel ist eine Signatur, die von einem Dritten ausgestellt wurde. Diese Signaturen kommen üblicherweise zustande, indem man "den Schlüssel von jemand anders signiert", und sie sind die Basis des sogenannten "<a href="https://en.wikipedia.org/wiki/Web_of_trust" target="_blank">Web of Trust</a>". Derartige Signaturen werden aktuell aus verschiedenen Gründen von <span class="brand">keys.openpgp.org</span> nicht verteilt.</p>
|
|
|
|
<p>Der mit Abstand wichtigste Grund ist <strong>Spam</strong>. Drittsignaturen ermöglichen es jedem, beliebige Daten an den Schlüssel von jemand anders anzuhängen. Auf diese Weise können so große Datenmengen an einen Schlüssel angehängt werden, dass der Schlüssel effektiv unbrauchbar wird. Schlimmstenfalls kann ein Angreifer anstößige oder illegale Daten anhängen.</p>
|
|
|
|
<p>Es gibt einige Ideen, dieses Problem zu lösen. Beispielsweise können Drittsignaturen mit dem Aussteller, statt dem Empfänger, ausgeliefert werden. Alternativ können Drittsignaturen erst nach Bestätigung durch den Empfänger ausgeliefert werden. Sollte genug Interesse an einer solchen Lösung bestehen, sind wir gerne bereit mit OpenPGP-Projekten für eine Umsetzung zu kooperieren.</p>
|
|
|
|
<h3 id="no-sign-verified"><a href="#no-sign-verified">Warum werden Schlüssel nicht nach Bestätigung signiert?</a></h3>
|
|
|
|
<p>Der Dienst auf <span class="brand">keys.openpgp.org</span> ist gedacht für die Verteilung und das Auffinden von Schlüsseln, nicht als de-facto "Certificate Authority". OpenPGP-Software, die verifizierte Kommunikation ermöglichen möchte, sollte dafür ein entsprechendes Vertrauens-Modell implementieren.</p>
|
|
|
|
<h3 id="revoked-uids"><a href="#revoked-uids">Warum werden widerrufene Identitäten nicht als solche verbreitet?</a></h3>
|
|
|
|
<p>Wenn ein OpenPGP-Schlüssel eine seiner Identitäten als widerrufen markiert, ist diese ab diesem Zeitpunkt nicht mehr gültig. Diese Information sollte dann nach Möglichkeit an alle Clients verteilt werden, die bereits vorher Kenntnis von der Identität hatten.</p>
|
|
<p>Leider gibt es keinen guten Weg, eine derart widerrufene Identität zu verteilen, ohne die Identität an sich zu offenbaren. Da widerrufene Identitäten nicht weiter verteilt werden sollten, können wir entsprechende Identitäten (mit oder ohne Widerruf) nicht mehr verteilen.</p>
|
|
<p>Es gibt Lösungsansätze für dieses Problem, die eine Verteilung von Widerrufen erlauben, ohne die Identitäten an sich zu offenbaren. Bislang gibt es dafür allerdings keine fertige Spezifikation, oder Unterstützung in verwendeter OpenPGP-Software. Sobald sich hier die Situation verändert, werden wir natürlich auch auf <span class="brand">keys.openpgp.org</span> entsprechende Unterstützung einbauen.</p>
|
|
|
|
<h3 id="search-substring">Warum ist es nicht möglich nach einem Teil einer E-Mail-Adresse zu suchen, beispielsweise nur der Domain?</h3>
|
|
|
|
<p>Manche Schlüsselserver unterstützen die Suche nach einem Teil einer E-Mail Adresse.
|
|
Das ermöglicht nicht nur das Finden von Schlüsseln sondern auch von Adressen, wenn man Suchanfragen wie "Schlüssel für Adressen at gmail Punkt com" nutzt.
|
|
Das erzeugt im Ergebnis eine öffentlich einsehbare Auflistung der Adressen aller Schlüssel auf solchen Schlüsselservern.</p>
|
|
|
|
<p>Die Suche mittels einer E-Mail Adresse auf <span class="brand">keys.openpgp.org</span> zeigt nur dann einen Schlüssel an, wenn sie exakt der E-Mail Adresse entspricht.
|
|
Auf diese Weise kann ein normaler Nutzer die Schlüssel von Adressen finden, die er bereits kennt, nicht jedoch die von ihm nicht nicht bekannten Adressen.
|
|
Das verhindert, dass ein böswilliger Nutzer oder Spammer einfach an eine Liste aller E-Mail Adressen auf diesem Server gelangt.</p>
|
|
|
|
<p>Wir haben diese Einschränkung zu einem Teil unserer <a href="/about/privacy">Datenschutzrichtlinie</a> gemacht,
|
|
wir können die Einschränkung nicht ohne das Einverständnis des Nutzers abändern.</p>
|
|
|
|
<h3 id="tor"><a href="#tor">Wird Tor untertützt?</a></h3>
|
|
|
|
<p>Na klar!
|
|
Wenn du Tor installiert hast,
|
|
kannst du <span class="brand">keys.openpgp.org</span> anonym
|
|
als
|
|
<a href="https://support.torproject.org/onionservices/#onionservices-2" target="_blank">Onion-Service</a> verwenden:
|
|
<br><a href="http://zkaan2xfbuxia2wpf7ofnkbz6r5zdbbvxbunvp5g2iebopbfc4iqmbad.onion">zkaan2xfbuxia2wpf7ofnkbz6r5zdbbvxbunvp5g2iebopbfc4iqmbad.onion</a></p>
|
|
|
|
<h3 id="encrypt-verification-emails"><a href="#encrypt-verification-emails">Warum werden die ausgehenden Bestätigungs-E-Mails nicht verschlüsselt?</a></h3>
|
|
|
|
Dafür gibt es mehrere Gründe:
|
|
<ol>
|
|
<li>Es ist komplizierter, sowohl für den Empfänger als auch für uns.</li>
|
|
<li>Es hilft gegen kein Angriffs-Szenario - ein Angreifer hat keinen Vorteil davon, einen Schlüssel hochzuladen, zu dem er selbst keine Zugriff hat.</li>
|
|
<li>Das Löschen von Identitäten muss auch dann möglich sein, wenn der entsprechende Schlüssel verloren gegangen ist.</li>
|
|
<li>Das Bestätigen von Schlüsseln, die nur für Signaturen verwendet werden, würde einen weiteren (und komplizierten) Mechanismus erfordern.</li>
|
|
</ol>
|
|
<h3 id="older-gnupg"><a href="#older-gnupg">Ich erhalte beim Aktualisieren von Schlüsseln mittels GnuPG eine Fehlermeldung. Handelt es sich um einen Bug?</a></h3>
|
|
|
|
<p>GnuPG sieht Schlüssel, die keine Identitätsinformationen beinhalten, als ungültig und weigert sich die Schlüssel zu importieren.
|
|
Allerdings kann ein Schlüssel, der <a href="/about">keine überprüfte E-Mail-Adresse beinhaltet</a> trotzdem nützliche Informationen beinhalten.
|
|
So ist es noch möglich zu prüfen, ob der Schlüssel zurückgerufen ist oder nicht.</p>
|
|
<p>Im Juni 2019 hat die <span class="brand">keys.openpgp.org</span>-Gruppe einen Patch erstellt, der es GnuPG erlaubt Aktualisierungen von Schlüsseln ohne Identitätsinformationen zu verarbeiten.
|
|
Dieser Patch wurde schnell in vielen Distributionen von GnuPG, wie Debian, Fedora, NixOS und GPG Suite for macOS, übernommen.</p>
|
|
<p>Im März 2020 hat die GnuPG-Gruppe den Patch abgelehnt und hat den Problemstatus auf "Wontfix" gesetzt.
|
|
Das bedeutet, dass <strong>GnuPG-Versionen ohne den Patch keine Aktualisierungen von <span class="brand">keys.openpgp.org</span> für Schlüssel ohne eine überprüfte E-Mail Adresse empfangen können</strong>.
|
|
Sie können die Diskussion im Problem <a href="https://dev.gnupg.org/T4393#133689">T4393</a> auf dem GnuPG Fehler-Tracker verfolgen.</p>
|
|
<p>Sie können mit den folgenden Anweisungen überprüfen, ob Ihre Version von GnuPG betroffen ist.</p>
|
|
<blockquote>
|
|
<span style="font-size: larger;">Test-Schlüssel importieren:</span><br><br>
|
|
$ curl https://keys.openpgp.org/assets/uid-test.pub.asc | gpg --import<br>
|
|
gpg: key F231550C4F47E38E: "Alice Lovelace <alice@openpgp.example>" imported<br>
|
|
gpg: Total number processed: 1<br>
|
|
gpg: imported: 1<br><br>
|
|
</blockquote>
|
|
<blockquote>
|
|
<span style="font-size: larger;">Mit dem Patch wird der Schlüssel aktualisiert, wenn er lokal bekannt ist:</span><br><br>
|
|
$ gpg --recv-keys EB85BB5FA33A75E15E944E63F231550C4F47E38E<br>
|
|
gpg: key F231550C4F47E38E: "Alice Lovelace <alice@openpgp.example>" not changed<br>
|
|
gpg: Total number processed: 1<br>
|
|
gpg: unchanged: 1<br><br>
|
|
</blockquote>
|
|
<blockquote>
|
|
<span style="font-size: larger;">Ohne den Patch wird ein Schlüssel ohne Identitätsinformationen immer abgelehnt:</span><br><br>
|
|
$ gpg --recv-keys EB85BB5FA33A75E15E944E63F231550C4F47E38E<br>
|
|
gpg: key EB85BB5FA33A75E15E944E63F231550C4F47E38E: no user ID<br>
|
|
</blockquote>
|
|
</div>
|