Es ist im Sinne eines effizienten Ablaufs nicht sinnvoll, dass die Teilnehmer unvorbereitet in die Veranstaltung kommen. Es ist auch für sie nachteilig, wenn die Dozenten die begrenzte Zeit einer Schulung mit unnötigen Erklärungen verplempern; dadurch fallen dann wichtige Teile der Schulung weg, und am Ende rächt sich die Bequemlichkeit dadurch, dass man am Ende der Veranstaltung eben kein funktionierendes System hat. Bestimmte Entscheidungen müssen die Teilnehmer vernünftigerweise schon vor der Schulung treffen; das sind keine technischen, sondern organisatorische Entscheidungen, die sowieso kein Dozent den Teilnehmern abnehmen kann.
Welche Vorbereitungen wie nachdrücklich von den Teilnehmern erwartet werden – ob man sie im einen Extrem nur lieb bittet oder im anderen die Vorlage der geforderten Entscheidungen zur Voraussetzung für die Anmeldung zu einem Termin macht – muss jeder Dozent für sich entscheiden. Das wird im Einzelfall nicht nur vom Charakter des Dozenten abhängen, sondern auch davon,
wie viel Zeit zur Verfügung steht
wie viele Teilnehmer die Veranstaltung haben wird
wie viele unvorbereitete Teilnehmer man ggf. erwartet
wie viele Helfer man hat, die zumindest diese Vorbereitung während der Veranstaltung übernehmen können
welches Niveau die Teilnehmer haben
wem die Schulung wichtiger ist: den Teilnehmern oder den Dozenten...
Dies ist eine Übersicht bedenkenswerter Aspekte. Man sollte die Teilnehmer auffordern, lieber vor der Schulung zu fragen, wenn es Probleme oder Unklarheiten gibt. Es dürfte meist angenehmer sein, solche Probleme vorab per Mail oder Chat zu klären, als sich im Termin darüber zu ärgern.
Per Klick auf das jeweilige Stichwort kommt man zu der ausführlichen Erklärung des Stichworts weiter unten auf dieser Seite.
| X | Stichwort | Erklärung |
|---|---|---|
| geeignetes Mailsystem (Adresse und Client) | Um OpenPGP ohne Verrenkungen nutzen zu können, benötigt man ein geeignetes Mailprogramm (ggf. parallel zu dem ungeeigneten, das man verwendet). E-Mail-Adressen, die sich nicht per Mailprogramm (POP3, IMAP) nutzen lassen, sondern nur per Webmail, kommen also nicht in Frage. In diesem Fall muss man sich eine zusätzliche Adresse zulegen. | |
| User-IDs | User-IDs (+primäre User-ID) für alle zu erzeugenden Schlüssel festlegen |
| X | Stichwort | Erklärung | Standardwert |
|---|---|---|---|
| Kommunikationspaare oder -gruppen | Es hat wenig Sinn, OpenPGP zu lernen, wenn man keinen regelmäßigen E-Mail-Kontakt hat, der das auch nutzt. In diesem Zusammenhang lohnt es sich, schon mal vorab die Möglichkeiten zu sichten, wie Einzelpersonen zu einer erhöhten Verbreitung von OpenPGP beitragen können. |
||
| eigene Domain | Denken Sie mal ernsthaft darüber nach, eine eigene Domain zu registrieren, das kostet fast nichts. Ihre (offiziellen) E-Mail-Adresse(n) sollten Ihnen gehören und Sie nicht an T-Online, GMX, Google oder wen auch immer binden. | ||
| policy URL | Soll der Schlüssel (ggf. später) eine Schlüsselrichtlinie bekommen? Eigener Webspace vorhanden? (siehe gpg.conf: set-policy-url)? | http://www.openpgp-schulungen.de/users/${SHORTID}__policy.1.html | |
| die nötige Software installieren | spart Zeit, wenn das nicht während der Veranstaltung gemacht werden muss | ||
| Passphrase festlegen | spart Zeit und erhöht die Sicherheit, wenn das nicht während der Veranstaltung gemacht werden muss | ||
| Schlüssel von Bekannten | falls Bekannte OpenPGP nutzen: Schlüssel und (aus sicherer Quelle!) Fingerprint besorgen (auf Papier oder einem sicheren, nicht beschreibbaren Medium); dann können die gleich zertifiziert werden | ||
| sicheres Bootmedium | eigenes Bootmedium oder Knoppix? Rechtzeitig prüfen, ob das auf dem jeweiligen Rechner ohne Zicken bootet (ggf.: funktionierende Bootparameter notieren) | Knoppix | |
| Schlüsselrichtlinie | ggf. die Vorlage der Schlüsselrichtlinie anpassen | ||
| Keyserver | ggf. den bevorzugten Keyserver anpassen | hkp://eu.pool.sks-keyservers.net/ | |
| Sicherheitsniveau festlegen | Sicherheitsniveau festlegen: (nur) Alltagsschlüssel und / oder Hochsicherheits-Schlüssel? | Alltagsschlüssel |
Die auf dieser Seite genannten Punkte sind sehr konkret auf die Schlüsselerzeugung bezogen. Und natürlich ist das schon genug Arbeit. Grundsätzlich ist es aber wünschenswert, ein paar sehr grundlegende Dinge verstanden zu haben. Falls also nach dem Abarbeiten dieser Seite noch Ressourcen frei sind, empfehle ich, diese Seiten mal zu sichten:
E-Mail ←
Wer bisher gar kein Mailprogramm, sondern nur Webmail verwendet, muss sich sowohl ein geeignetes Mailprogramm zulegen als auch sicherstellen, dass er einen Account mit diesem Mailclient nutzen kann. Das mag die Webmail-Adresse sein, aber nicht jeder Webmail-Anbieter ermöglicht den Zugriff mit einem Mailclient (IMAP). In diesem Fall muss man sich vorab eine weitere E-Mail-Adresse zulegen (siehe eigene Domain) und dafür sorgen, dass sie mit dem Mailprogramm nutzbar ist.
User-IDs festlegen ←
Die Festlegung von User-IDs ist kein kryptografisches Problem. Die Sicherheit des Systems wird dadurch nicht erhöht und nicht reduziert. Was allerdings schwanken kann, sind Akzeptanz und Verwirrung auf Seiten anderer Nutzer. Deshalb an dieser Stelle ein paar Informationen und Anregungen zum Thema.
User-IDs sind einfach nur Text, der per Konvention folgendermaßen strukturiert ist:
Vorname Name (Kommentar) <E-Mail-Adresse>
Natürlich erzwingt die Konvention keinen Kommentar (und der ist meist unnötig). Die Einhaltung dieser Konvention ermöglicht / erleichtert es Anwendungen, die passenden Schlüssel zu einer E-Mail-Adresse zu finden (was einem die Verifizierung des Fingerprints aber nicht erspart!).
Ein OpenPGP-Schlüssel muss mindestens eine User-ID enthalten, kann aber beliebig viele enthalten. Ein einziger Schlüssel kann also beliebig viele E-Mail-Adressen abdecken. Die Frage ist, in welchem Umfang das sinnvoll ist.
Der offensichtliche Vorteil darin, mehrere User-IDs zu haben, ist, dass der Aufwand der Schlüsselbeglaubigung sinkt, denn User-IDs sind einfacher zu prüfen (sofern die anderen das überhaupt machen) als Hauptschlüssel; oftmals sind die E-Mail-Adressen den anderen sowieso schon bekannt. Aber für jeden Hauptschlüssel muss man den Fingerprint auf sicherem Weg zum Kommunikationspartner schaffen. Die meisten sind leider schon zu schlampig, einmal so was wie
7D82 FB9F D25A 2CE4 5241 6C37 BF4B 8EEF 1A57 1DF5
zu prüfen. Aber das dann auch noch fünfmal? Für dieselbe Person? Da ist das Motivationsproblem in Griffweite.
Der wesentliche Nachteil mehrerer User-IDs ist, dass damit (sozial) eine Beziehung zwischen den Adressen bzw. der Person und Aktivitäten hergestellt werden kann, die unerwünscht sein mag. Zumal man User-IDs effektiv nur hinzufügen, nicht aber löschen kann. Auch wenn man mit einer Organisation (Arbeitgeber, Verein, Hochschule, ...) schon lange nichts mehr zu tun hat: Die offensichtliche Verbindung verfolgt einen ewig. Wenn man dagegen für jede Organisation einen eigenen Schlüssel hat, widerruft man den zu gegebener Zeit, und das war's. Dann kursiert der zwar weiter und damit auch zumeist der eigene Name (der aber bei den meisten nicht eindeutig ist), aber das Maß an Offensichtlichkeit ist geringer. Außerdem gibt man üblicherweise nicht jedem, mit dem man "offiziell" zu tun hat, auch seine privaten Adressen.
Ein weiteres Problem ist, dass man dadurch alle E-Mail-Adressen auf dasselbe Sicherheitsniveau zwingt (also auf das niedrigste von allen).
So viele gleichartige Adressen zusammenfassen wie möglich. Gleichartig bezieht sich dabei auf mehrere Kategorien:
sie sind alle privat oder gehören alle zur selben Organisation
sie sind gleich seriös, man wird nicht irgendwann das Bedürfnis haben, (von der Allgemeinheit) mit einer dieser Adressen nicht mehr assoziiert zu werden. hauke.laging@example.com und hauke.laging@example.net können im allgemeinen problemlos in denselben Schlüssel. Auf eine Adresse schnutzibutzi@example.com trifft das nur bedingt zu.
Das Sicherheitsniveau ist gleich. Wenn man hauke.laging@example.com nur auf dem eigenen, gut gesicherten Computer liest, @example.net aber auch per Webmail (inklusive Signaturen und Entschlüsselung!), dann hat es wenig Sinn, denselben Schlüssel für beide zu nehmen.
Es bietet sich an, eine User-ID ohne E-Mail-Adresse zu haben. E-Mail-Adressen können ungültig werden (so dass die User-ID widerrufen wird). Bei Namen (und dem Schlüsselkommentar) kann das kaum passieren (selbst eine Heirat o.Ä. ändert daran wenig). Diese User-ID bietet sich für einen Kommentar zum Schlüssel an. Der ersetzt die Schlüsselrichtlinie nicht, ist aber auf den ersten Blick verfügbar und gibt schon mal einen guten Hinweis darauf, womit man es zu tun hat. Folgendes wäre ein sinnvoller (nicht zu langer) Kommentar:
Alltagsschlüssel mit sicherem Offline-Hauptschlüssel und policy URL
Wenn man viel mit "Ausländern" zu tun hat, mag es sinnvoll sein, eine oder mehrere User-IDs ohne E-Mail-Adresse zu ergänzen, die den Kommentar in Übersetzung enthalten.
"Normale" User-IDs (mit E-Mail-Adresse) brauchen normalerweise keinen Kommentar. Man sollte den nicht erzwingen. Zertifikate werden über die E-Mail-Adressen gefunden; sie dienen den anderen nicht als Auswahl von E-Mail-Adressen, deshalb sollten derartige Erklärungen nicht erforderlich sein.
Wenn man schon weiß oder ahnt, dass man eine Adresse nicht mehr lange nutzt, dürfte es in der Regel sinnvoller sein, sie nicht mit aufzunehmen. Wenn Bekannte sich schon darauf einstellen müssen, dass man OpenPGP nutzt (und wenn sie sich nicht darauf einstellen, bringt ein Schlüssel wenig), dann können sie sich sicherlich auch problemlos darauf einstellen, in Zukunft eine andere E-Mail-Adresse zu nutzen. Und natürlich gibt es keinen zwingenden Grund, mit allen Adressen OpenPGP zu nutzen. Es spricht nichts bis wenig gegen die Entscheidung, dass nur die example.com-Adresse einen Schlüssel bekommt, example.net aber nicht.
Wenn Schlüssel nicht komplett angezeigt werden, sondern an anderer Stelle erwähnt werden (wenn z.B. eine Signatur von ihnen angezeigt wird), dann wird neben der ID (der Nummer) nur eine User-ID angezeigt. Welche das ist, kann man festlegen. Das kann in der aktuellen Version des Scripts nicht in dieser Konfigurationsdatei festgelegt werden, aber man sollte es sich vorab überlegen. Man kann (was Vor- und Nachteile hat) dafür die allgemeine User-ID (ohne E-Mail-Adresse) nehmen, aber auch die mit der bevorzugten E-Mail-Adresse.
Kommunikationspaare oder -gruppen ←
Ich rate dringend dazu, dass jeder Teilnehmer jemanden mitbringt, mit dem er häufig per E-Mail kommuniziert, wenn er nicht unter seinen häufigen E-Mail-Kontakten schon jemanden hat, der OpenPGP verwendet (dann sollte man sich die Fingerprints derjenigen auf einem sicheren Weg (persönlich übergeben auf Papier, notfalls telefonisch) besorgen und mitbringen). Ausnahmen:
Man ist wirklich sehr entschlossen (etwa, weil man die Technik später anderen beibringen will).
Man hat seine bestehenden Kontakte schon erfolglos abgeklappert.
Wenn man die Technik nicht regelmäßig verwendet, wird von der Schulung bald nicht mehr viel übrig sein (außer Frust). Ohne OpenPGP-Kontakte, wenn man es also nur für sich selber verwendet, braucht man außerdem einen Großteil der Technik und des Wissens nicht. Entweder schult man jemanden so, dass aus ihm ein regelmäßiger Anwender wird, ober besser erst mal gar nicht.
Wenn man noch niemanden dafür hat, sollte man die eigene Teilnahme erst mal aufschieben und statt dessen das eigene Umfeld abklappern und jemanden dafür gewinnen. Oder sich gezielt "Krypto-Brieffreundschaften" suchen.
Falls jemand alleine kommt, weil er jemanden kennt, der schon OpenPGP nutzt, dann muss er natürlich dessen Schlüssel und auf Papier den Fingerprint des Schlüssels mitbringen.
In diesem Zusammenhang lohnt es sich, schon mal vorab die Möglichkeiten zu sichten, wie Einzelpersonen zu einer erhöhten Verbreitung von OpenPGP beitragen können.
eigene Domain ←
Auch ganz unabhängig von Kryptografie liegt es nahe, sich eine eigene Domain zu registrieren. Wenn man sich aber einen (neuen) Schlüssel erzeugt, drängt es sich auf, darüber (noch) mal ernsthaft nachzudenken. Für weniger als einen Euro pro Monat hat man damit:
Adressen für die Ewigkeit
Flexibilität (weil man, ohne dass die Absender das merken, zu seinem bevorzugten Maildienst – Google, GMX, was auch immer – weiterleiten und diese Weiterleitung jederzeit zu einem anderen Mailanbieter ändern kann, ohne dass die Absender sich umstellen müssen); wenn man allerdings Webmail nutzt, mag es sein, dass die eigenen Mails als Absenderadresse die Anbieteradresse haben statt der eigenen Domain. Dennoch kann man die eigenen Kontakte nach und nach dazu "erziehen", die Domainadresse anzuschreiben (als Kontakt zu speichern).
"beliebig" viele Adressen (ohne Aufpreis); damit kann man z.B. unterschiedliche Adressen (mit unterschiedlichen Passwörtern) für persönliche Mails, Mailinglisten/Newsletter und – sicherheitsrelevant! – Accountregistrierungen einrichten
die Möglichkeit, mit der ganzen Domain (also allen Adressen) zu einem anderen Provider zu wechseln
automatisch auch Webspace; selbst wenn man kein Interesse an einer Webseite im üblichen Sinn hat, hat man dann wenigstens einen Ort, an dem man ganz offiziell seine Schlüsselaktualisierungen und seine Schlüsselrichtlinie ablegen kann
Nichts und niemand zwingt einen, für eine Domain auch eine Website einzurichten. Es ist völlig legitim, die nur für E-Mail zu nutzen. Und die Einrichtung von Mailboxen und Weiterleitungen ist ein Klacks; technische Kenntnisse erfordert das nicht.
Da sich die meisten Leute ohne eigene Domain mit den Anbietern nicht auskennen und niemand auf Lockangebote hereinfallen soll, liste ich hier ein paar attraktive Angebote auf. Hinweise auf ähnliche Angebote nehme ich gern entgegen; natürlich auch darauf, dass eins dieser Angebote nicht mehr besteht. Geeignet erscheinen mir in diesem Zusammenhang Angebote, die E-Mail-Basisfunktionen abdecken (IMAP, mehrere Mailboxen) und möglichst auch Webspace umfassen (minimal reicht, ohne technische Extras). Weiterleitungen für Webadressen ersetzen zwar echten Webspace nicht, aber man kann dann auch Webspace nutzen, den man nur kurz hat, und dafür sorgen, dass die Adresse für die Öffentlichkeit konstant bleibt. Für den automatischen Abruf von Schlüsseln klappt das zwar nicht in jedem Fall, aber für eine policy URL ist das OK.
Ein weiterer Aspekt, der für die Auswahl eines Anbieters relevant sein kann, den ich aber für diese Liste nicht überprüft habe: Manche Provider bieten einem auch einen XMPP-Server für die eigene Domain, so dass man nicht nur eine ewig gültige E-Mail-Adresse, sondern auch eine ewig gültige XMPP-Adresse hat. Natürlich reduziert das die Möglichkeiten eines späteren Providerwechsels.
Und für die nutzlosen Rechtsverdreher: Natürlich garantiere ich nicht die Korrektheit dieser Angaben; auch ich kann mal was falsch verstehen. Dies ist lediglich eine Liste von Hinweisen auf möglicherweise interessante Angebote.
| monatliche Kosten | einmalige Kosten | Rabatt | Webspace | Anbieter | Stand | Kommentar |
|---|---|---|---|---|---|---|
| 1,48 € | 0 | erstes Jahr gratis | 5 GB | one.com | 18.08.2013 | |
| 1,49 € | 9,60 € | nein | 1und1 | 18.08.2013 | ||
| 5,- € / Jahr | 300 MB | united-domains | 18.08.2013 | de-Domain, E-Mail-Paket "Basis": nur eine E-Mail-Adresse | ||
| 2,30 € | 2 GB | united-domains | 18.08.2013 | de-Domain, E-Mail-Paket "Business": 50 E-Mail-Adressen | ||
| 9,90 € / Jahr | 0 | nur Weiterleitungen | domain24 | 18.08.2013 | E-Mail: nur Weiterleitungen | |
| 1,90 € | 9,90 € | 2 GB | Hetzner | 18.08.2013 | "Webhosting Level 1" | |
| 0,60 € | 4,99 € | nur Weiterleitung | Hosteurope | 18.08.2013 | Paket "Domain Basic" | |
| 0,55 € | 2,95 € | nur Weiterleitung | domain factory | 22.08.2013 | MyMail | |
| 1,15 € | 4,95 € | 5 GB | domain factory | 22.08.2013 | MyHome Plus |
policy URL ←
Dieser Punkt betrifft primär diejenigen, die eine eigene Webseite (nicht notwendigerweise eine ganze Domain) haben, also unter einer bestimmten Adresse (möglichst dauerhaft) eine Datei bereitstellen können; das kann im Prinzip auch eine Webadresse sein, die jemand anderem gehört – derjenige muss dann aber die Datei dort bereitstellen. Diejenigen, die das nicht können, bekommen einfach den Standardwert (http://www.openpgp-schulungen.de/users/0x12345678__policy.1.html).
Die Schlüsselrichtlinie sollte leicht zu finden sein. Dafür kann man die URL dieses Dokuments in den Schlüssel schreiben. Das kann (und sollte) man tun, bevor das Dokument fertig ist (also gleich bei der Schlüsselerzeugung). Man überlege sich also, unter welcher (dauerhaft verfügbaren) Adresse man dieses Dokument später mal ablegen wird (man kann auch mehrere Adressen angeben).
Es ist sinnvoll, eine URL zu wählen, die sowohl die short ID des Schlüssels als auch eine Versionsnummer enthält. Auf diese Weise kann man die URLs mehrerer Schlüssel und Versionen in einem einfachen, konsistenten Schema halten. Beispiel:
ich.example.org/openpgp/0x12345678__policy.1.html (oder .txt).
Wer keinen eigenen Webspace hat, kann seinen Schlüssel, seine Richtlinie und Hauptschlüsselsignaturen für beide Dateien unter http://www.openpgp-schulungen.de/users/ ablegen (0x12345678__policy.1.html, 0x12345678__policy.1.html.asc, 0x12345678.asc, 0x12345678.asc.asc, ).
Hauptschlüsselpassphrase (ggf. und Transportpassphrase) festlegen ←
Eine Passphrase ist nur dann garantiert stark, wenn sie rein zufällig ist. Das ist für Menschen schwer zu leisten, für Computer leicht. Aber eine Hauptschlüsselpassphrase kann man sinnvollerweise nur auf einem sicheren System erzeugen lassen. Aber auch eine nicht perfekt, aber weitgehend zufällige Passphrase entsprechender Länge – die man sich (ohne sie zu tippen) auf der Tastatur zusammensucht, möglichst ohne Umlaute, Satz- oder Sonderzeichen – stellt einen wirksamen Schutz dar, zumal es für einen Angreifer unattraktiv ist, zu wissen, dass seine Chance bestenfalls beinahe aussichtslos (statt garantiert aussichtslos) ist.
die nötige Software installieren ←
Unter Linux (u.Ä.): Pidgin & OTR (o.Ä.); ggf. Thunderbird & Enigmail
Unterstützt das verwendete Mailprogramm OpenPGP? Möglichkeiten:
standardmäßig
mit Hilfe von Add-ons / Plug-ins
gar nicht
Das muss jeder vorab klären (notfalls mit Hilfe des Dozenten) und ggf. schon mal das Add-on / Plug-in installieren (nicht aber schon konfigurieren). Zur Not muss man sich für die Nutzung von OpenPGP ein geeignetes Mailprogramm zulegen.
sicheres Bootmedium ←
Siehe hier.
Jeder muss sich vorher Gedanken darüber machen, ob er sein eigenes Bootmedium, dem er vertraut, mitbringen will oder in der Schulung eine (z.B.) Knoppix-CD bekommen will (wenn das angeboten wird); dafür muss der Bedarf angemeldet werden, sonst sind womöglich nicht genügend da (und wenn man das Bootmedium nicht behalten kann, kann man später nicht überprüfen, womit man da eigentlich seinen Schlüssel erzeugt hat; außerdem ist der Nichtbesitz eines sicheren Bootmediums wohl der zuverlässigste Weg, sichere Offline-Schlüssel durch Verwendung in einer unsicheren Umgebung zu kompromittieren...).
Die Integrität des Bootmediums ist aber nicht das einzige Kriterium, so dass es sinnvoll sein mag, etwas anderes als das angebotene Knoppix zu verwenden: Die sichere Umgebung wird nicht nur für die Schlüsselerzeugung benötigt, sondern jedesmal, wenn der Offline-Hauptschlüssel verwendet wird (zum Zertifizieren anderer Schlüssel; für Modifikationen des eigenen Schlüssels / Zertifikats; für hochsichere Signaturen (bei kritischen Daten wie etwa einer Schlüsselrichtlinie oder Verträgen)). Deshalb ist es wünschenswert, dass jeder ein System verwendet, mit dem er sich auskennt. Wenn man also mit XY vertraut ist (und die Integrität des Mediums nachweisen kann), dann nimmt man lieber XY als Knoppix. Also z.B. eine openSUSE-Live-DVD.
Schlüsselrichtlinie ←
Es ist sinnvoll, eine Schlüsselrichtlinie zu verfassen, also ein Dokument, das erklärt, wofür der Schlüssel genutzt wird (und wofür explizit nicht), welches Sicherheitsniveau er hat und unter welchen Voraussetzungen man andere Schlüssel zertifiziert. Dieses Dokument sollte dann mit dem Offline-Hauptschlüssel signiert werden. Der geplante Einsatz muss natürlich zur Schlüsselrichtlinie (s.u.) passen. Das ist für Anfänger zwar harter Tobak, aber sie müssen nur die Vorlage lesen und sich entscheiden, ob das so für sie in Ordnung ist, und sie ggf. abwandeln. Außerdem schafft das Lesen der eigenen Richtlinie mit etwas Glück das nötige Bewusstsein dafür, was alles nötig ist, damit Sicherheit erreicht wird.
Siehe die Vorlagen für unterschiedliche Schlüsselrichtlinien.
bevorzugter Keyserver ←
Es ist sinnvoll, in einen Schlüssel den bevorzugten Keyserver einzutragen, damit die Nutzer des Schlüssels wissen, wo sie die aktuelle Version des Schlüssels finden können. Ich nutze und empfehle dafür einen Pool von Keyservern: eu.pool.sks-keyservers.net. Man kann sich mit guten Gründen anders entscheiden, aber es ist wünschenswert, das vor der Schlüsselerzeugung zu tun.
Sicherheitsniveau – wofür ist der Schlüssel gedacht? ←
Jeder überlege sich vorab, für welche Sicherheitsniveaus er einen Schlüssel haben will (also auch, wie viele). Es ist unsinnig, mit einem mehrere abdecken zu wollen. Man kann problemlos Schlüssel "auf Vorrat" erzeugen (solange man die Passphrase nicht vergisst und entsprechend sicher verwahrt), aber das ist nicht für jeden nötig.
Als grobe Unterteilung:
Schlüssel, die auf von anderen administrierten Systemen genutzt werden (z.B. für die Nutzung mit Webmail).
Schlüssel, die auf vielen oder auf gefährdeten Systemen (z.B. Mobilgeräte) genutzt werden.
Schlüssel, die auf einem normalen (nicht speziell gesicherten) System für die üblichen Tätigkeiten (v.a. Internet) genutzt werden. Solche Schlüssel mag man verwenden, um alle seine E-Mails und "normal wichtige" veröffentlichte Daten (z.B. Webseiten) zu signieren und um nicht allzu kritische Daten zu verschlüsseln.
Schlüssel, die nur auf speziell gesicherten Systemen zum Einsatz kommen: offline, vom sicheren Medium gebootet, womöglich nur für "ungefährliche" Dateitypen verwendet (HTML, keine Office-Dokumente, kein PDF). Solche Schlüssel mag man für die Signierung bedeutender Verträge und die Verschlüsselung von Daten, deren Bekanntwerden schwerwiegende Konsequenzen hätte, verwenden.
Die meisten Leute haben zunächst nur Bedarf an einem Schlüssel für den "normalen" Einsatz.
Pidgin & OTR ←
Es hat mehrere Vorteile, zusammen mit OpenPGP auch einen OTR-fähigen XMPP-Client – z.B. Pidgin (OTR für Pidgin) – zu installieren, auch wenn das mit OpenPGP erst mal wenig zu tun hat:
der Support wird einfacher
natürlich kann man sinnvollerweise nur ein offenes Protokoll als Supportweg unterstützen; neben dem Supportnutzen lernen manche der Teilnehmer dadurch XMPP kennen
das Konzept Fingerprint funktioniert ganz ähnlich wie bei OpenPGP
Man hat ein praxisrelevantes Beispiel für einen Mediumwechsel und eine hochsichere Signatur (nämlich die OpenPGP-Hauptschlüsselsignatur für den OTR-Fingerprint)