[yet another] Adressvervollständigung extrem verzögert

Hallo saljut7,
und willkommen im Forum!

Bitte mache zuerst mal ein Update aller drei beteiligter Programme, also Thunderbird, SOGo (deine Version ist für den 24er Thunderbird!) und Lightning. (Und auch der anderen Add-ons.)

MfG Peter

Danke für deine Antwort.
Vermutlich hat dir das neue virtuelle Adressbuch "Alle Adressbücher" übel mitgespielt. Die Suche auf einem LDAP läuft ja völlig anders, als beim TB sonst üblich.

Aber das Thema mit den Zertifikaten interessiert mich schon.
Ich hatte ja in der "Vor-*DAV-Zeit" auch mehrere Jahre als gemeinsame Datenbasis einen LDAP benutzt. Damals wohl als einziger hier im Forum. Und dort, wo ich bis vor ein paar Monaten gearbeitet habe, gab es auch einen wirklich sehr großen "Verzeichnisdienst" mit vielen (!) Tausend Einträgen. Auf beiden wurden neben den üblichen Angaben auch die öffentlichen X.509-Zertifikate der Nutzer gehostet. Also auch auf meinem eigenen kleinen LDAP.
Nur, auf Arbeit wurden bei der Adressierung automatisch auch die Zertifikate des Adressaten aus dem LDAP entnommen und in Notes zur Verschlüsselung genutzt. Beim Thunderbird habe ich damals keinen Weg gefunden, dieses Verfahren auch zu nutzen. Die Zertifikate mussten also immer vorher in den Zertifikatsstore des TB importiert werden, bevor ich sie zum Verschlüsseln nutzen konnte.

Hast du dafür eine Lösung?

MfG Peter

Hallo saljut7!

Ich danke dir für die Informationen.
Ja, SO soll es sein! Ein Verzeichnisdienst mit sämtlichen Daten einschließlich den Benutzerzertifikaten - und der Thunderbird holt sich nicht nur die Mailadressen sondern auch die Zertifikate von dort. Und zwar, ohne dass selbige erst in den Zertifikatsstore des TB importiert werden müssen.

Vermutlich habe ich meine kleinen LDAP-Tests zu zeitig gemacht. Obwohl ich meinen LDAP wirklich mit den richtigen Schemata betrieben habe und auch die Zertifikate dort gespeichert und den jeweiligen Personen zugeordnet waren (konnte ich ja mit dem LDAP-Browser sehen), wurden sie vom Thunderbird dort nicht gefunden. Aber das hat sich ja nun alles erledigt.
Ein weiterer großer Nachteil des LDAP-Adressbuches ist auch noch, dass der TB keine Möglichkeit zum Editieren und Ergänzen des Datenbestandes bietet. In der Firma ist das ja zentral geregelt. Aber wenn ich meinen LDAP auch privat nutzen will, will ich eben auch Änderungen vornehmen können, ohne jedes mal einen LDAP-Browser zu bemühen. Und das vorhandene Add-on wurde ja nie erwachsen und ist wohl mittlerweile auch eingestellt.

Zitat von saljut7

Btw: Ich will mich nicht zu weit aus dem Fenster lehnen, aber wirkliche Selbstbestimmung darüber, "wer meine Mails lesen kann", gibt es doch dank durchgehender Dezentralität nur bei GPG, oder?

Nein, so kannst du das nicht sagen!
Ohne, dass ich diesen sinnlosen Krieg zwischen den beiden Fraktionen der Bewahrer unserer Privatsphäre befeuern will, ein paar Argumente:
Grundsätzlich sind beide Verfahren fast identisch. Beides sind hybride Verfahren und nutzen asymmetrische Kryptologie für die Sicherung des zur symmetrischen Verschlüsselung des Contents verwendeten Schlüssels.

Die große Frage ist, wo bekommst du deinen privaten Schlüssel her, inwieweit kannst oder solltest du dem Hersteller dieses Schlüssels vertrauen. Es gibt nämlich zwei grundsätzliche Methoden der Erzeugung dieses Schlüssels:

• Der Nutzer erzeugt auf seinem Rechner den privaten Schlüssel und aus diesem den öffentlichen. Dieser und nur dieser wird dann als so genannter Zertifikatsrequest an das TrustCenter gesandt, und dort lediglich mit ein paar weiteren Angaben ergänzt und mit dessen privatem Schlüssel signiert. Dieses somit erzeugte Zertifikat wird dann wieder an den Nutzer zurück geschickt, wo es dann im Browser wieder zu einem Schlüsselpaar verknüpft wird und als solches exportiert werden kann.
  Vorteil: der private Schlüssel bleibt auf dem Rechner des Nutzers. Nachteil: Es handelt sich bei diesem Schlüssel um einen primitiven Pseudo-Zufallsschlüssel, wie ihn ein PC eben nur erzeugen kann. (Das gleiche trifft im Übrigen auch bei GnuPG zu! Dieser schlechte Schlüssel ist DIE Schwachstelle, über welche sich die "Dienste" und Kryptoanalytiker freuen.)
• Die zweite Methode ist (bei einem seriösen TrustCenter!) die Erzeugung des privaten Schlüssels auch bei diesem.Klar, hier musst du dem TrustCenter vertrauen. Aber bei einem seriösen Anbieter werden die Schlüsselpaare in einem so genannten Hardware-Sicherheitsmodul (HSM) erzeugt. Und das sind dann echte hochwertige Zufallszahlen. Auch werden hier ohne menschlichen Zugriff die erzeugten .p12 oder .pfx-Schlüsseldateien mit einem Transportpasswort automatisch verschlüsselt und dieses Transportpasswort - ohne dass dieses je ein Mensch sehen konnte - automatisch in einen Sicherheitsumschlag gedruckt, gefalzt und mit Heißkleber zum Umschlag verklebt. (Du ahnst bestimmt, woher ich das weiß ... .)
  Derartige Informationen findest du bei jedem akkreditierten dt. TrustCenter als "Zertifikatsrichtlinie" (Policy) auf deren Webseite. Für Jedermann zum Nachlesen.Eine andere Methode ist, dass die Schlüsselpaare komplett auf einer Mikroprozessor-Chipkarte erzeugt und sicher gespeichert werden. Dabei wird der auf diesen Chipkarten vorhandene qualifizierte Zufallszahlengenerator per Befehl zum Erzeugen des privaten Schlüssels aufgefordert. Dieser Schlüssel ist nicht exportierbar, er verlässt also niemals den Chip, welcher ihn erzeugt hat. Dann wird mit dem kryptografischen Coprozessor des Chips per RSA-Verfahren der öffentliche Schlüssel erzeugt, welcher automatisch zum Zertifikat ergänzt und exportiert wird.So erzeugte Karten sind Unikate, sie sind mit einem Passwort versehen und bei dreimaliger Falscheingabe wird die Karte gesperrt. Durch die "Physik" der Karte wird garantiert, dass es den Schlüssel nur 1x gibt, dass er nicht exportierbar ist und (IMHO ganz wichtig), dass die Karte durch die max. 3 Fehleingabe auch bei einem Verlust/Diebstahl nicht missbraucht werden kann. (Bei GnuPG und erbeutetem privatem Schlüssel hast du unendlich viele Versuche zum BruteForce-Angriff auf den verschlüsselten Key.)

Bevor du fragst: Der verschlüsselte symmetrische Schlüssel der E-Mail wird zum Entschlüsseln immer via Kartenleser zur Karte gesendet und dort im kryptografischen Coprozessor entschlüsselt und wieder an den Rechner zurück geschickt. Auf gleichem Wege geschieht das Verschlüsseln des Hashes für die Signatur. Der Rechner "sieht" niemals den privaten Schlüssel!

Aber grundsätzlich ist sowohl bei GnuPG als auch bei S/MIME davon auszugehen, dass eine abgegriffene E-Mail (und wir dürfen wohl davon ausgehen, dass zumindest bei unseren amerikanischen "Freunden" sämtliche verschlüsselte E-Mails gespeichert werden, in der Hoffnung, sie irgendwann später entschlüsseln zu können ...) nur mit einem enormen Zeit- und Rechenaufwand unbefugt entschlüsselt werden kann.
Das einzige, was wir zur Wahrung unserer Privatsphäre (und natürlich zum Schutz von Firmen- und Dienstgeheimnissen) tun können, ist möglichst viel oder fast alles zu verschlüsseln. Je mehr wir verschlüsseln, umso größer ist die kryptologische Rauschglocke! Wer nur die wenigen sensiblen Daten verschlüsselt (und dann auch noch einen interessanten Betreff einträgt), ist einfach nur dumm.

NOCH dürfen wir in Deutschland unsere Privatsphäre durch Verschlüsselung vor den privaten und dienstlichen Schnüfflern schützen - wir sollten dieses Recht effektiv nutzen!

edit:
Ich habe doch noch was vergessen. Ich betreibe seit gut 10 Jahren eine gar nicht mehr so kleine "Privat-CA". Angefangen mit ein paar Zertifikaten für Familie und gute Freunde hat sich das mittlerweile so entwickelt, dass ich jährlich ein paar Hundert Zertifikate für entsprechend viele Leute herstelle. Und es werden immer mehr ... .
JA, Vertrauen kann man sich auch erarbeiten.

MfG Peter