Import der PGP-Schlüssel bei neuer e-Mail Adresse

  • Um Rückfragen vorzubeugen, bitten wir um folgende Angaben:

    • Thunderbird-Version: 52.2.1 mit enigmail 1.9.7
    • Betriebssystem + Version: Ubuntu 14.04 bzw. Windows 7
    • Kontenart (POP / IMAP): IMAP/POP
    • Postfachanbieter (z.B. GMX): neu T-Online
    • PGP-Software / PGP-Version: gpg2
    • Eingesetzte Antivirensoftware:
    • Firewall (Betriebssystem-intern/Externe Software):


    Hier können Sie Ihren Text schreiben:

    Hallo,


    da ich den Provider gewechselt habe und nun bei T-Online eine neue e-Mail Adresse bekomme, möchte ich meinen PGP-Schlüsselbund exportieren und mit der neuen e-Mail Adresse vderbinden.


    Wie geht das?


    Genügt es, in Einstelliungen des neuen e-Mail Kontos -> OpenPGP-Sicherheit -> Haken rein bei "OpenPGP-Unterstützung (Enigmail) für diese Identität aktivieren" -> Haken rein bei "Bestimmte OpenPGP-Schlüsselkennung verwenden (0x1234ABCD):" -> Schlüssel auswählen... ->


    Kann ich dann das alte e-Mail Konto gefahrlos löschen?


    Gruß

    Ch. Hanisch

    PS:Wie melde ich mich in diesem Forum wieder ab?

  • Hallo,


    wozu exportieren?

    Zitat

    Genügt es, in Einstelliungen des neuen e-Mail Kontos -> OpenPGP-Sicherheit -> Haken rein bei "OpenPGP-Unterstützung (Enigmail) für diese Identität aktivieren" -> Haken rein bei "Bestimmte OpenPGP-Schlüsselkennung verwenden (0x1234ABCD):" -> Schlüssel auswählen... ->



    Kann ich dann das alte e-Mail Konto gefahrlos löschen?

    Zweimal ja. Es könnte aber Risiken und Nebenwirkungen geben (Irritation beim Mailpartner).

    Vielleicht doch neues Schlüsselpaar passend zur E-Mail-Adresse erzeugen und den public key verteilen?

    Zitat

    PS:Wie melde ich mich in diesem Forum wieder ab?

    Mein Profil -> Benutzerkonto -> Verwaltung


    Gruß, muzel

  • Hallo,

    ich habe den öffentlichen Schlüssel für das verfallene e-Mail Konto auf dem Key-Server hochgeladen. Wie kann ich diesen alten Eintrag deaktivieren bzw.löschen?


    Ich möchte meinen unveränderten öffentlichen Schlüssel mit der jeweiligen neuen e-Mai Adresse auf den Key-Server hochladen.

    Wie geht das?


    Gruß

    Ch. Hanisch

  • Hallo,


    da solche Schlüssel immer passend zur Mailadresse erstellt werden, dürfte so ein nicht zur neuen Adresse passender Schlüssel bei allen Partnern zu Warnungen und Irritation führen und daher der Sicherheit eher abträglich sein.


    MfG

    Drachen

  • Das ist richtig, allerdings kann man einen Schlüssel mit mehreren Mailadressen (Benutzerkennungen) verknüpfen.

    Schlüssel verwalten - (Schlüssel auswählen) - Benutzerkennungen verwalten...


    Gruß, muzel

  • Hallo,

    noch einmal meine Situation:

    1) Der Provider hat meine e-Mail Adresse gelöscht, d.h. diese e-Mail Adresse existiert nicht mehr; wohl aber der öffentliche Schlüssel auf dem Keyserver 'pool.sks-keyservers.net' verknüpft mit der 'alten' nicht mehr existierenden e-Mail Adresse.


    2) Inzwischen habe ich bei anderen Providern neue e-Mail Adressen erhalten, für die ich mir keine neuen Schlüsselpaare generieren möchte.

    Bearbeiten -> Konten-Einstellungen -> OpenPGP-Sicherheit -> x Aktivieren OpenPGP-Unterstützung (Enigmail) für diese Identität -> x Bestimmte OpenPGP-Schlüsselkennung verwenden (0x1234ABCD): -> Schlüssel auswählen ... Hier habe ich den 'alten' geheimen Schlüssel der nicht mehr existierenden e-Mail Adresse aus meinem Schlüsselbund gewählt.


    Für meine e-Mail Partner habe ich folgende Signatur am Schluß aller meiner e-Mails eingetragen.

    Bearbeiten -> Konten-Einstellungen -> Signaturtext:

    Mein öffentlicher Schlüssel ist auf dem Keyserver 'pool.sks-keyservers.net' unter <'alte' e-Mail Adresse>


    Oder würde das Hochladen des 'alten' öffentlichen Schlüssels aus meinem Schlüsselbund mit den jeweiligen neuen e-Mail Adressen das Problem noch eleganter lösen?


    Dann müßten sich die e-Mail Partner den öffentlichen Schlüssel vom Keyserver einmalig erneut in ihren Schlüsselbund runterladen.

    Danach sind dann auch die neuen e-Mail Adressen in ihrem Schlüsselbund enthalten.

    Das scheint mir besser und nutzerfreundlicher zu sein als für die neuen e-Mail Adressen jeweils neue Schlüsselpaare zu generieren.

    Ist das richtig? Was macht Ihr in einem solchen Falle?


    Gruß

    Ch. Hanisch


  • Oder würde das Hochladen des 'alten' öffentlichen Schlüssels aus meinem Schlüsselbund mit den jeweiligen neuen e-Mail Adressen das Problem noch eleganter lösen?

    Die offizielle/saubere Lösung wäre das Hinzufügen einer neuen User-Id (mit der neuen E-Mail-Adresse) und das Zurückziehen der alten User-Id. Anschließend den so veränderten Key erneut hochladen. Über die Kommandozeile z.B.:

    Vielleicht geht es auch irgendwie in der GUI, damit kenne ich mich aber nicht so aus. Wenn der neue öffentliche Schlüssel hochgeladen wurde, sollte der Keyserver auch korrekt anzeigen, dass die alte E-Mail-Adresse nicht mehr gültig ist.

  • Hallo,

    Oder würde das Hochladen des 'alten' öffentlichen Schlüssels aus meinem Schlüsselbund mit den jeweiligen neuen e-Mail Adressen das Problem noch eleganter lösen?

    Die offizielle/saubere Lösung wäre das Hinzufügen einer neuen User-Id (mit der neuen E-Mail-Adresse) und das Zurückziehen der alten User-Id. Anschließend den so veränderten Key erneut hochladen.

    Genau das möchte ich aber vermeiden.

    Es erscheint mir nutzerfreundlicher, die alte User-Id auf dem Keyserver zu belassen und mit den neuen e-Mail Adressen zu erweitern.

    Enigmail -> Schlüssel verwalten -> 'alte' e-Mail Adresse auswählen -> Bearbeiten -> Benutzerkennung verwalten -> Hinzufügen: Neue e-Mail Adressen

    Enigmail -> Schlüssel verwalten -> 'alte' e-Mail Adresse auswählen -> Schlüsselserver -> Öffentlichen Schlüssel hochladen...


    Damit sind dann auf dem Keyserver auch die neuen e-Mail Adressen mit dem 'alten' öffentlichen Schlüssel verbunden.


    Gruß

    Ch. Hanisch

    Einmal editiert, zuletzt von Hanisch ()

  • Es erscheint mir nutzerfreundlicher, die alte User-Id auf dem Keyserver zu belassen

    Vielleicht habe ich dich auch missverstanden, aber Mails an die alte E-Mail-Adresse erreichen dich doch nicht mehr, oder? Diese Tatsache vor deinen Kontakten zu "verheimlichen" ist aus meiner Sicht ziemlich nutzerunfreundlich. Die Information, dass du früher mit demselben Key eine andere User-Id verwendet hast (und ob und wer diese beglaubigt hat), bleibt ja ohnehin sichtbar. Auch deine Key-Id und der Fingerabdruck ändern sich nicht. Insofern verstehe ich nicht, worin du einen Vorteil beim behalten der alten User-Id siehst?

  • Es erscheint mir nutzerfreundlicher, die alte User-Id auf dem Keyserver zu belassen

    Vielleicht habe ich dich auch missverstanden, aber Mails an die alte E-Mail-Adresse erreichen dich doch nicht mehr, oder? Diese Tatsache vor deinen Kontakten zu "verheimlichen" ist aus meiner Sicht ziemlich nutzerunfreundlich. Die Information, dass du früher mit demselben Key eine andere User-Id verwendet hast (und ob und wer diese beglaubigt hat), bleibt ja ohnehin sichtbar. Auch deine Key-Id und der Fingerabdruck ändern sich nicht. Insofern verstehe ich nicht, worin du einen Vorteil beim behalten der alten User-Id siehst?

    Natürlich erreichen mich e-Mails an die 'alte' e-Mail Adresse nicht mehr; aber das ist unabhängig von der PGP-Verschlüsselung. Da gibt es nichts zu verheimlichen.

    Mit meiner Signatur zeige ich an, daß ich

    1. PGP habe und

    2. die öffentlichen Schlüssel vom Keyserver geholt werden sollen.

    Wer mit mir kommunizieren will, der muß eine meiner gültigen e-Mail Adressen kennen und wenn er das verschlüsselt tun möchte, die zugehörigen öffentlichen Schlüssel in seinem Schlüsselbund haben.

    Beglaubigungen und Fingerabdruck bleiben erhalten, was bei neu generierten Schlüsselpaaren nicht wäre.


    Gruß

    Ch. Hanisch

  • was bei neu generierten Schlüsselpaaren nicht wäre

    Ein neues Schlüsselpaar stand doch gar nicht zur Debatte? User-Ids können unabhängig vom Primärschlüssel angelegt und zurückgezogen werden, ohne den Fingerabdruck zu ändern. Beglaubigungen der alten User-Id "verliert" man natürlich, diese gelten jedoch ohnehin nicht für die neue User-Id und bleiben auch nach dem Widerruf sichtbar.


    Enigmail und andere Clients prüfen (derzeit) tatsächlich nicht, ob die Absender- und Signaturadresse übereinstimmen. Wenn du ohnehin allen deinen Gesprächspartnern "von Hand" deine neue Adresse bekannt gibst, kann es also aus deiner Sicht eventuell von Vorteil sein, weiterhin die alte User-Id zu behalten und mit ihr zu signieren.


    Grüße!

  • Enigmail und andere Clients prüfen (derzeit) tatsächlich nicht, ob die Absender- und Signaturadresse übereinstimmen.

    Mich würde deine dazu Meinung interessieren. Hältst du das für ein Problem? Ich bin mir nicht schlüssig. Einerseits denke, ich, diese Überprüfung sollte stattfinden und auch einen deutlichen Hinweis produzieren, dass Absender- und Signaturadresse nicht gleich sind.

    Andererseits zeigt Thunderbird gut lesbar an, welche E-Mailadresse zu der Signatur gehört. Wenn man hinschaut, sieht man, dass etwas nicht stimmt.

    Auf so eine krude Idee ist in meinem Bekanntenkreis noch niemand gekommen. Von uns benutzt aber auch niemand die Keyserver. Ich würde einem solchen Schlüssel in jedem Fall erst einmal das Vertrauen entziehen, und den Absender um Klärung bitten. Ich würde ihn im Web of Trust auch nicht unterschreiben. Das ist so schon kaputt genug.

  • Hallo,

    Enigmail und andere Clients prüfen (derzeit) tatsächlich nicht, ob die Absender- und Signaturadresse übereinstimmen.

    Mich würde deine dazu Meinung interessieren. Hältst du das für ein Problem? Ich bin mir nicht schlüssig. Einerseits denke, ich, diese Überprüfung sollte stattfinden und auch einen deutlichen Hinweis produzieren, dass Absender- und Signaturadresse nicht gleich sind.

    Andererseits zeigt Thunderbird gut lesbar an, welche E-Mailadresse zu der Signatur gehört. Wenn man hinschaut, sieht man, dass etwas nicht stimmt.

    Auf so eine krude Idee ist in meinem Bekanntenkreis noch niemand gekommen. Von uns benutzt aber auch niemand die Keyserver. Ich würde einem solchen Schlüssel in jedem Fall erst einmal das Vertrauen entziehen, und den Absender um Klärung bitten. Ich würde ihn im Web of Trust auch nicht unterschreiben. Das ist so schon kaputt genug.

    Wenn Ihr keinen Keyserver benutzt, dann entgeht Euch ja ein wesentlicher Teil des PGP-Gerassels.

    Eine wirklich umfassende Verbreitung der PGP-Verschlüsselung ist meiner Meinung nach nur möglich über die Keyserver.

    Wenn man jemandem eine e-Mail schicken will, dann schaut man erst einmal auf dem Keyserver nach, ob es dort einen öffentlichen Schlüssel zu seiner e-Mail Adresse gibt.

    Wenn das zutrifft, dann kann man dem Empfänger sofort eine verschlüsselte e-Mail senden, denn dann hat er PGP.


    Wieso willst Du einem Schlüssel, dessen ursprünglich zugeordnete e-Mail Adresse nicht mehr existiert, das Vertrauen entziehen?

    Der Schlüssel ist nach wie vor Ok. Man kann mit ihm verschlüsseln wie bisher auch, nur an andere Empfängeradressen.

    Mit meiner Signatur gebe ich an, wo dieser Schlüssel unter welcher Bezeichnung nun zu holen ist und wie er zu benutzen ist mit meinen neuen e-Mail Adressen.


    Gruß

    Ch. Hanisch

    Einmal editiert, zuletzt von Hanisch ()

  • Mich würde deine dazu Meinung interessieren. Hältst du das für ein Problem?

    Ich fände es besser, wenn die Leiste in diesem Fall nicht grün werden würde. Aber wie du richtig sagst ist es kein größeres Problem, da die Signatur-UID korrekt angezeigt wird. Auf der anderen Seite: rot ist definitiv zu viel. Entweder blau (wie für korrekte unvertraute Unterschriften), oder noch besser ein Zwischenstatus (gelb? grün mit deutlicher Warnung?). Es gibt schließlich legitime Anwendungen, der Nutzer muss nur bemerken, dass er sich nicht auf das "Von"-Feld verlassen sollte.


    Beispiel für eine legitime Anwendung: eine Mailingliste leitet PGP-signierte E-Mails mit veränderten Headern weiter. Das "Von"-Feld enthält die Adresse der Mailingliste, der Body samt Signatur kommt jedoch vom eigentlichen Sender.


    Wieso willst Du einem Schlüssel, dessen ursprünglich zugeordnete e-Mail Adresse nicht mehr existiert, das Vertrauen entziehen?

    Ich vermute, er will nicht dem Schlüssel, sondern der User-ID das vertrauen entziehen. Auf deine "neue" User-ID auf demselben Schlüssel hat dieser Schritt keine Auswirkung. Eventuell würde er dir sogar eine neue Beglaubigung für die neue User-ID ausstellen.


    Zur Begründung: weil das die Nutzer, die meinen Beglaubigungen vertrauen, so von mir erwarten.


    Zumindest meine Keysigning-Richtlinie (die ja öffentlich an meinen Beglaubigungen hängt) beinhaltet die der E-Mail-Adresse und einer Option, ungültig gewordenen User-IDs das Vertrauen zu entziehen. Eine User-ID mit falscher E-Mail-Adresse ist also entsprechend meiner Policy ungültig. Wenn ich über eine ungültige, nicht-zurückgerufene User-ID Kenntnis erlangen würde, würde ich deren Beglaubigung zurücknehmen. Im Gegensatz zum Anwendungsfall von Drehmoment würde ich jedoch sagen, dass das vor allem für Keyserver-Nutzer relevant ist: ansonsten wird das Update schließlich nicht in absehbarer Zeit verteilt.


    Es mag andere Menschen mit anderen Keysigning-Policies geben (z.B. "Ich prüfe nur Namen, nicht aber E-Mail-Adressen oder Kommentare") und viele Nutzer verwenden überhaupt keine explizite Richtlinie (letztendlich also "Ich signiere, was mir subjektiv richtig erscheint"). Diese Menschen haben eventuell andere Anforderungen an eine gültige User-ID.

    Und das ist ja gerade das schöne an PGP: jeder Nutzer kann (bzw. muss) selbst auswählen, welchen anderen Nutzern (incl. deren impliziten oder expliziten Keysigning-Richtlinien) die Möglichkeit zugestanden wird, vertrauenswürdige Signaturen auszustellen.


    Mit meiner Signatur gebe ich an, wo dieser Schlüssel unter welcher Bezeichnung nun zu holen ist und wie er zu benutzen ist mit meinen neuen e-Mail Adressen.

    Wofür benutzt du dann Keyserver? Du könntest den Key doch auch einfach in den Anhang oder auf einen X-beliebigen Webspace packen, wenn er ohne deine persönliche Anleitung nicht genutzt werden soll? Ich habe das einige Jahre so gemacht, das hat super funktioniert (aus Angst von Keyserver-Spam).

  • Ich fände es besser, wenn die Leiste in diesem Fall nicht grün werden würde.

    Ja, das finde ich auch. Die Farbwahl in Enigmail ist schon komisch. Solange der Schlüssel bekannt und gültig ist, erscheint alles von "Unbekannt" über "Explizit kein Vertrauen" bis hin zu "Volles Vertrauen" in Blau. Lediglich "absolutes Vertrauen" erscheint in Grün. Das fand ich schon immer strange.


    Beispiel für eine legitime Anwendung: eine Mailingliste leitet PGP-signierte E-Mails mit veränderten Headern weiter.

    Danke! Soweit hatte ich nicht gedacht. Mir ist kein legitimer und gleichzeitig unvermeidbarer Anwendungsfall in den Sinn gekommen.


    Ich vermute, er will nicht dem Schlüssel, sondern der User-ID das vertrauen entziehen.

    Ich würde, außer im Fall einer legitimen Anwendung, beides machen. Wenn mein Kumpel mir eine E-Mail schickt, die mit dem privaten Schlüssel seiner Freundin signiert ist, würde ich mir so meine Gedanken machen. Ok, wenn's der meiner Freundin wäre, noch mehr. ;-)


    Der User-ID würde ich in jedem Fall das Vertrauen entziehen, weil, wie du sagst, "die Nutzer, die meinen Beglaubigungen vertrauen, [das] so von mir erwarten" dürfen. Es wäre schön, wenn in einem Web of Trust alle so denken und handeln würden.


    Eine User-ID mit falscher E-Mail-Adresse ist also entsprechend meiner Policy ungültig.

    Das gefällt mir gut!


    Ich habe das einige Jahre so gemacht, das hat super funktioniert (aus Angst von Keyserver-Spam).

    Es kenne das nur aus Berichten meiner Eltern. Sie haben tonnenweise solchen Spam bekommen. Damit war das Experiment Keyserver beendet.

    Dabei hat vermutlich niemand den Server genutzt, um sich den Schlüssel holen. Die Zahl der Verschlüsselungspartner war und ist gering. Die wenigen, die mitmachten, hatten den Schlüssel schon bekommen.

  • [OT]

    Wir kommen gerade etwas vom Thema ab, ich denke für eine längere Diskussion von Enigmail oder Keyservern sollte man in ein anderes Thema ausweichen. Dennoch eine kurze Bemerkung:

    Solange der Schlüssel bekannt und gültig ist, erscheint alles von "Unbekannt" über "Explizit kein Vertrauen" bis hin zu "Volles Vertrauen" in Blau. Lediglich "absolutes Vertrauen" erscheint in Grün.

    Enigmail sollte eigentlich blau ausschließlich bei unvertrauten Schlüsseln verwenden.


    Beachte aber, dass "(signatory) trust" (Vertrauen in die Identität des Schlüsselinhabers) und "owner trust" (Vertrauen in Beglaubigungen des Schlüsselinhabers) zwei unterschiedliche Dinge sind. Für die Balkenfarbe ist nur signatory trust entscheidend (die Frage ist: "ist diese E-Mail tatsächlich von der Person?"), nicht aber owner trust. Für die Beurteilung einer Beglaubigung eines anderen Keys ist dagegen nur owner trust relevant ("ist diese Beglaubigung vertrauenswürdig?"). Direkt einstellen kannst du nur owner trust:

    • absolut (ultimate): "Ich vertraue den Beglaubigungen, selbst wenn die Identität nicht gesichert ist"
    • voll (full): "Ich vertraue den Beglaubigungen in Kombination mit signatory trust"
    • gering (marginal): "Ich vertraue den Beglaubigungen in Kombination mit signatory trust und weiteren Beglaubigungen anderer Aussteller"
    • kein (none) / Standard: "Ich ignoriere Beglaubigungen von diesem Aussteller, selbst wenn für diesen signatory trust besteht"

    Wenn du einer User-ID vertrauen willst, solltest du diese daher beglaubigen (mit deiner eigenen, absolut vertrauenswürdigen Identität). Anschließend wird der Balken grün, denn die User-ID erhält durch deine Beglaubigung signatory trust. Owner trust sollte zusätzlich dann gesetzt werden, wenn du Beglaubigungen dieser Person vertrauen willst, und auch dann i.d.R. nicht auf absolut, sondern höchstens auf voll. Absolutes Vertrauen sollte eigenen Keys vorbehalten sein.

    [/OT]

  • Beachte aber, dass "(signatory) trust" (Vertrauen in die Identität des Schlüsselinhabers) und "owner trust" (Vertrauen in Beglaubigungen des Schlüsselinhabers) zwei unterschiedliche Dinge sind.

    Das ist mir schon klar. Ich sprach nur von signatory trust. Und da wird mir nur "Absolutes Vertrauen" in Grün angezeigt. Selbst "Volles Vertrauen" bleibt noch blau.

    Du hast aber recht: Wenn ich den fremden Schlüssel unterschreibe, dann wird die Anzeige grün. Logisch, da ich meinem eigenen Schlüssel ja absolut vertraue.

  • [OT]

    Ich sprach nur von signatory trust. Und da wird mir nur "Absolutes Vertrauen" in Grün angezeigt. Selbst "Volles Vertrauen" bleibt noch blau.

    Signatory trust ist entweder "vertraut" oder "nicht vertraut". Dazwischen gibt es nichts. Im Gegensatz zu owner trust, kannst du signatory trust nicht direkt einstellen!


    Die Begriffe "absolut", "voll", "gering" und "kein" werden ausschließlich für owner trust verwendet. Einem Key "volles" Vertrauen (=full owner trust) auszustellen wirkt sich erst aus, wenn einem seiner UIDs anderweitig signatory trust zugewiesen wurde. War der Balken davor blau (signatory trust: "nicht vertraut"), bleibt der Balken also auch weiterhin blau. Owner trust in einen Key hat also in den meisten Fällen keine Auswirkungen auf signatory trust in die UIDs desselben Keys.


    Ausnahme: absolutes Vertrauen (=ultimate owner trust) wird auch ohne vorher bestehenden signatory trust wirksam, dementsprechend wird der Balken hier direkt grün, auch ohne dass eine UID beglaubigt wurde (jeder Key beglaubigt sich selbst). Die Keys mit absolutem Vertrauen sind also deine Eintrittspunkte in das Web of Trust, jeglicher signatory trust lässt sich also auf mindestens einen absolut vertrauten Key zurückführen.


    Enigmail macht also (zumindest in deinem Beispiel) alles genau richtig, da selbst bei vollem Vertrauen noch kein signatory trust besteht.


    Wenn weiterer Diskussionsbedarf zu dem Thema besteht, sollte dafür aber ein anderer Thread verwendet werden. Die Enigmail-Farben haben schließlich nur bedingt etwas mit der Änderung einer E-Mail-Adresse zu tun. ;)

    [/OT]