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

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

Zitat von 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.:

$ gpg --edit-key alt@example.com
gpg (GnuPG) 2.2.0; Copyright (C) 2017 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Geheimer Schlüssel ist vorhanden.
sec  rsa2048/C66D7E6CFE5689D3
     erzeugt: 2018-01-08  verfällt: 2020-01-08  Nutzung: SC  
     Vertrauen: ultimativ     Gültigkeit: ultimativ
ssb  rsa2048/16197C0B4F4C8160
     erzeugt: 2018-01-08  verfällt: 2020-01-08  Nutzung: E   
[ ultimativ ] (1). Max Mustermann <alt@example.com>
gpg> adduid
Ihr Name ("Vorname Nachname"): Max Mustermann
Email-Adresse: neu@example.com
Kommentar: 
Sie haben diese User-ID gewählt:
    "Max Mustermann <neu@example.com>"
Ändern: (N)ame, (K)ommentar, (E)-Mail oder (F)ertig/(A)bbrechen? f
sec  rsa2048/C66D7E6CFE5689D3
     erzeugt: 2018-01-08  verfällt: 2020-01-08  Nutzung: SC  
     Vertrauen: ultimativ     Gültigkeit: ultimativ
ssb  rsa2048/16197C0B4F4C8160
     erzeugt: 2018-01-08  verfällt: 2020-01-08  Nutzung: E   
[ ultimativ ] (1)  Max Mustermann <alt@example.com>
[ unbekannt ] (2). Max Mustermann <neu@example.com>
gpg> uid 1
sec  rsa2048/C66D7E6CFE5689D3
     erzeugt: 2018-01-08  verfällt: 2020-01-08  Nutzung: SC  
     Vertrauen: ultimativ     Gültigkeit: ultimativ
ssb  rsa2048/16197C0B4F4C8160
     erzeugt: 2018-01-08  verfällt: 2020-01-08  Nutzung: E   
[ ultimativ ] (1)* Max Mustermann <alt@example.com>
[ unbekannt ] (2). Max Mustermann <neu@example.com>
gpg> revuid
Diese User-ID wirklich widerrufen? (j/N) j
Grund für den Widerruf:
  0 = Kein Grund angegeben
  4 = User-ID ist nicht mehr gültig
  Q = Abbruch
(Wahrscheinlich möchten Sie hier 4 auswählen)
Ihre Auswahl? 4
Geben Sie eine optionale Beschreibung ein. Beenden mit einer leeren Zeile:
> Existiert nicht mehr; bitte stattdessen neu@example.com verwenden
> 
Grund für Widerruf: User-ID ist nicht mehr gültig
Existiert nicht mehr; bitte stattdessen neu@example.com verwenden
Ist das OK? (j/N) j
sec  rsa2048/C66D7E6CFE5689D3
     erzeugt: 2018-01-08  verfällt: 2020-01-08  Nutzung: SC  
     Vertrauen: ultimativ     Gültigkeit: ultimativ
ssb  rsa2048/16197C0B4F4C8160
     erzeugt: 2018-01-08  verfällt: 2020-01-08  Nutzung: E   
[ widerrufen] (1)  Max Mustermann <alt@example.com>
[ unbekannt ] (2). Max Mustermann <neu@example.com>
gpg> save

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.

Zitat 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?

Zitat von 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!

Zitat von Drehmoment

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.

Zitat von Hanisch

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.

Zitat von Hanisch

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).

[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:

Zitat von Drehmoment

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]

[OT]

Zitat von Drehmoment

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]

Hallo,

Zitat von generalsync

Wenn weiterer Diskussionsbedarf zu dem Thema besteht, sollte dafür aber ein anderer Thread verwendet werden.

danke für den Hinweis, der unbedingt beachtet werden sollte.