MoonKid
Anmeldungsdatum: 9. Februar 2012
Beiträge: 1379
|
Mein eigener Schlüssel läuft im September ab. Wie sollte ich hier vorgehen (generell gemeint, nicht technisch), beim Erzeugen eines neuen Paares?
Ok, ich muss neue Visitenkarten mit neuem Fingerprint machen. Was ist mit den Schlüsseleinträgen auf den Public KeyServern? Verschwinden die automatisch, weil der Schlüssel ja abläuft?
|
TheDarkRose
Anmeldungsdatum: 28. Juli 2010
Beiträge: 3459
|
Du kannst deinen Schlüssel jederzeit ein neues Ablaufdatum verpassen. Kein Grund einen neuen Schlüssel zu erzeugen. Damit würdest du ja alle Signaturen verlieren. http://www.stephan-nix.de/2009/01/12/gnupg-gultigkeit-eines-schlussels-verlangern/
|
V_for_Vortex
Anmeldungsdatum: 1. Februar 2007
Beiträge: 12085
Wohnort: Berlin
|
TheDarkRose schrieb: Du kannst deinen Schlüssel jederzeit ein neues Ablaufdatum verpassen.
Du musst dann ggf. nur damit leben, dass Dich immer mal wieder Leute auf Deinen angeblich abgelaufenen Key aufmerksam machen, weil sie oder ihr bevorzugter Keyserver den aktualisierten Schlüssel noch nicht haben. Das ist mir erst neulich viele Jahre nach der Verlängerung passiert (und da war es tatsächlich der Keyserver-Pool https://sks-keyservers.net/, soviel zu deren automatischer Abgleichung untereinander). Man sollte also jedwede Schlüsselveränderung möglichst auf mehrere der verbreitetsten Keyserver hochladen.
|
V_for_Vortex
Anmeldungsdatum: 1. Februar 2007
Beiträge: 12085
Wohnort: Berlin
|
MoonKid schrieb: Was ist mit den Schlüsseleinträgen auf den Public KeyServern? Verschwinden die automatisch, weil der Schlüssel ja abläuft?
Nein, die bleiben für immer dort, sind halt nur abgelaufen.
|
jug
Ehemalige
Anmeldungsdatum: 19. März 2007
Beiträge: 12335
Wohnort: Berlin
|
Wenn man wirklich auf einen neuen Schlüssel wechseln will, zum Beispiel weil man einen größeren Schlüssel verwenden möchte, dann kann man das mit einer sogenannten Transition machen. Wichtig ist, dass man das nicht machen darf, wenn der Schlüssel kompromittiert wurde – dann sollte man diesen zurückziehen und damit auf den Schlüssel-Servern als ungültig und nicht mehr vertrauenswürdig markieren. Und stattdessen ganz von vorne anfangen. Und ansonsten ist die Kurzfassung so, dass man einen neuen Schlüssel erstellt, diesem Schlüssel vertraut und den Schlüssel mit dem alten Schlüssel signiert. Anschließend wird der neue Schlüssel veröffentlicht. Außerdem erstellt man ein „Transition statement. Einfach eine Textdatei, in der man beide Schlüssel benennt, erklärt, dass man den Schlüssel wechselt und ab sofort der neue Schlüssel gelten und verwendet werden soll. Dieses Dokument signiert man dann mit beiden Schlüsseln. Und schließlich veröffentlicht man das Dokument oder sendet es an die Kontakte die dann beide Schlüssel prüfen können. Je nachdem wie streng man dann ist, kann man den neuen Schlüssel direkt so übernehmen oder man setzt halt ein neues Keysigning an. 😉 Übrigens bleiben Schlüssel auch in Zukunft verwendbar. Die laufen nicht ab, du kannst deinen Schlüssel behalten und auch in Zukunft alles entschlüsseln was dir jemand in der Vergangenheit gemailt hat. Das Ablaufdatum hat im Grunde genommen keine weitere Bedeutung und kann wie schon geschrieben wurde beliebig verlängert werden. Das ist eher eine Empfehlung an die Absender und wird häufig als eine Art Warrant_canary genutzt. Sollte die Kontrolle über den Schlüssel verloren gegangen sein, dann kann man das Datum auch nicht mehr verlängern und dann sollte dem Schlüssel von anderen Nutzern nicht mehr vertraut werden. Und nachdem man eine Transition durchgemacht hat verlängert man das Datum natürlich auch nicht mehr. ~jug
|
MoonKid
(Themenstarter)
Anmeldungsdatum: 9. Februar 2012
Beiträge: 1379
|
Nach dem Verlängern sieht das so aus
gpg: nächste "Trust-DB"-Pflichtüberprüfung am 2016-12-23
pub 2048R/xxxxxxxx erzeugt: 2014-09-04 verfällt: 2016-12-23 Aufruf: SC
Vertrauen: uneingeschränkt Gültigkeit: uneingeschränkt
sub 2048R/xxxxxxxx erzeugt: 2014-09-04 verfällt: 2015-09-04 Aufruf: E
[uneingeschränkt] (1). name <name@world.any> pub bezieht sich vermutlich auf den öffentlichen Schlüssel, den ich auf die keyserver hochlade und in die signatur meiner Mails einbaue? sub ist was? Warum wird der nicht automatisch mitverlängert? Ich musste ihn stattdessen mit key 1 anwählen und die Prozedur wiederholen. Nebenfrage:
Checkt den gpg gelegentlich die key-server ab, ob sich bei den bereits importierten Schlüssel etwas (z.B. Ablaufdatum) verändert hat? Oder muss ich beim Verlängern und Hochladen meines keys, jedem sagen, er soll ihn neu importieren?
|
V_for_Vortex
Anmeldungsdatum: 1. Februar 2007
Beiträge: 12085
Wohnort: Berlin
|
MoonKid schrieb: Checkt den gpg gelegentlich die key-server ab, ob sich bei den bereits importierten Schlüssel etwas (z.B. Ablaufdatum) verändert hat? Oder muss ich beim Verlängern und Hochladen meines keys, jedem sagen, er soll ihn neu importieren?
Meines Wissens muss man das händisch machen, oder halt z.B. als Cronjob automatisieren.
|
user32847
Anmeldungsdatum: 29. Januar 2014
Beiträge: 332
|
Persönlich finde ich es immer praktischer, wenn der Key kein Ablaufdatum hat. Dann hat man nicht die Probleme, die V for Vortex beschrieben hat. Wichtig ist halt dann, dass man auf einem sicheren Platz ein Widerufszertifikat für den Notfall gelagert hat.
|
V_for_Vortex
Anmeldungsdatum: 1. Februar 2007
Beiträge: 12085
Wohnort: Berlin
|
user32847 schrieb: Persönlich finde ich es immer praktischer, wenn der Key kein Ablaufdatum hat. Dann hat man nicht die Probleme, die V for Vortex beschrieben hat. Wichtig ist halt dann, dass man auf einem sicheren Platz ein Widerufszertifikat für den Notfall gelagert hat.
Oder den Key selbst, mit dem man es erzeugen kann. Da regelmäßige Backups mit Lagerung an anderen Orten als dem des Originals selbstverständlich sein sollten, sollte das genauso selbstverständlich kein Problem sein. 😉 Mein Key ist seit längerer Zeit auch nicht mehr zeitlich beschränkt, genau aus den o.g. Erfahrungen.
|
MoonKid
(Themenstarter)
Anmeldungsdatum: 9. Februar 2012
Beiträge: 1379
|
Könnt ihr das bitte mal praktisch erläutern, wie das aussehen würde, wenn ich einen ablauflosen Key mit einem Widerrufszertifikat (was ist das überhaupt? Datei? Wo und wie lagern? Ausdrucken? *fg*) ungültig machen möchte.
|
user32847
Anmeldungsdatum: 29. Januar 2014
Beiträge: 332
|
Wenn du den Vorschlag von uns umsetzen möchtest, hast du jetzt grundsätzlich zwei Möglichkeiten: OpenPGP-Schlüssel behalten und Ablaufdatum entfernen
Zuerst musst du wieder die Ablaufzeit (sowohl für Key 0 als auch Key 1) ändern, in diesem Fall "0 = Schlüssel verfällt nie" auswählen. Nun das Widerrufszertifikat erstellen. Den neuen OpenPGP-Schlüssel mit Widerrufszertifikat am besten auf einem verschlüsselten Datenträger (z. B. USB-Stick) aufbewahren. Den Kontakten den veränderten (nun ohne Ablaufdatum) OpenPGP-Key schicken und (wenn gewünscht) auf Keyserver hochladen.
Sollte dein Schlüssel in Zukunft kompromittiert werden, kannst du mit Hilfe des Widerrufszertifikats, das du deinen Kontakten zukommen lasst und auf den Keyserver hochlädst, mitteilen, dass dein öffentlicher Schlüssel nicht mehr sicher ist und nicht mehr verwendet werden sollte.
Wenn man es ganz sicher haben will, könnte man z. B. noch Subkeys verwenden, Anleitung z. B. hier: https://alexcabal.com/creating-the-perfect-gpg-keypair/
|
MoonKid
(Themenstarter)
Anmeldungsdatum: 9. Februar 2012
Beiträge: 1379
|
user32847 Sollte dein Schlüssel in Zukunft kompromittiert werden, kannst du mit Hilfe des Widerrufszertifikats, das du deinen Kontakten zukommen lasst und auf den Keyserver hochlädst, mitteilen, dass dein öffentlicher Schlüssel nicht mehr sicher ist und nicht mehr verwendet werden sollte.
Hier ist mein Verständnisproblem: Wie kommt das Zertifkat mit meinen zwei Keys zusammen? Was stellt einer meiner Empfänger mit dem Zertifikat an? Warum soll ich das erstmal "verstecken" und beim Widerruf dann doch an jeden verteilen? Warum kann nicht jemand anderes ein (anderes) Widerufszertifikat auf meinen Schlüssel anwenden? Welche Rolle spielen hier die KeyServer? Das Prinzip dahinter ist mir nicht klar.
|
jug
Ehemalige
Anmeldungsdatum: 19. März 2007
Beiträge: 12335
Wohnort: Berlin
|
MoonKid schrieb: Hier ist mein Verständnisproblem: Wie kommt das Zertifkat mit meinen zwei Keys zusammen? Was stellt einer meiner Empfänger mit dem Zertifikat an? Warum soll ich das erstmal "verstecken" und beim Widerruf dann doch an jeden verteilen? Warum kann nicht jemand anderes ein (anderes) Widerufszertifikat auf meinen Schlüssel anwenden? Welche Rolle spielen hier die KeyServer? Das Prinzip dahinter ist mir nicht klar.
Im Grunde genommen ist ein Revocation Certificate nicht viel mehr als eine kleine Anmerkung die an den Schlüssel angehängt wird und dem Client sagt: »Obacht, diesen Schlüssel nicht mehr verwenden, der wurde als ungültig markiert.« Das gehört zu den Metadaten eines Schlüsselpaares und wird über den Keyserver genauso an alle Nutzer verteilt, wie alle anderen Bestandteile des öffentlichen Schlüssels auch. Und verstecken sollst du es deshalb, weil das deinen Schlüssel praktisch unbrauchbar macht. Also du kannst den Schlüssel noch weiter verwenden, aber alle anderen Nutzer werden deinen Schlüssel halt nicht mehr benutzen, weil sie glauben, dass er ungültig ist. Sowas veröffentlichst du nur, wenn dein Schlüssel wirklich in fremde Hände gefallen sein könnte. Das Widerrufszertifikat muss von einem autorisierten Schlüssel erstellt und signiert werden – normalerweise also dein Schlüssel selbst. In seltenen Fällen kann man auch jemanden delegieren, der das Recht hätte einen Schlüssel zurück zu ziehen, kann man in größeren Organisationen machen, Privatmenschen brauchen das eher nicht. Nehmen wir an, dein Schlüssel wird gestohlen, der Dieb hat deinen privaten Schlüssel, damit könnte er ein Widerrufszertifikat erstellen und den Schlüssel widerrufen … aber warum sollte er das machen? Dann kann er deine Kommunikation ja in Zukunft nicht mehr lesen, wenn alle den Schlüssel als ungültig betrachten. Du hingegen willst in solchen Fällen unbedingt deinen Schlüssel möglichst schnell ungültig machen, aber du hast deinen Schlüssel nicht mehr, der wurde ja gestohlen. Und jetzt kannst du kein Widerrufszertifikat erzeugen … Deshalb sollst du das schon bei Schlüsselerstellung machen und dann an einem (oder mehreren) sicheren Ort aufbewahren, so dass niemand unbefugtes deinen Schlüssel ungültig machen kann und du aber auf jeden Fall dran kommst. ~jug
|
MoonKid
(Themenstarter)
Anmeldungsdatum: 9. Februar 2012
Beiträge: 1379
|
Wie lang ist das Zertifikat?
Wieviele A4-Seiten wären es? (mal so spinnert gefragt) 😉
|
user32847
Anmeldungsdatum: 29. Januar 2014
Beiträge: 332
|
MoonKid schrieb: Wie lang ist das Zertifikat?
Wieviele A4-Seiten wären es? (mal so spinnert gefragt) 😉
Was spricht denn dagegen, es auf einem verschlüsselten Datenträger aufzubewahren? Mehr als eine DIN-A4-Seite dürfte es nicht sein.
|