Version 1.0, 15.07.2014
OpenPGP wird in erster Linie bei E-Mails (bewusst) eingesetzt. Dadurch entsteht das Problem, dass es einerseits möglich sein muss, beliebige Daten zu verschlüsseln und signieren, andererseits aber nicht beliebige Daten über E-Mail-Systeme transportiert werden können. Dieses Problem betrifft nicht die Verschlüsselung oder Signierung von Attachments, denn das Problem, beliebige Daten verlustfrei als Attachment verschicken zu können, musste schon für unverschlüsselte, unsignierte Dateien gelöst werden.
Im RfC 1847 wurde schon 1995 – vor der Definition von OpenPGP und S/MIME – ein allgemeines Containerformat für signierte oder verschlüsselte Daten geschaffen, als gemeinsame Basis für PGP/MIME und S/MIME. Eine Motivation dafür war, dass Mailclients, die Kryptografie nicht verstehen, zumindest signierte Daten fehlerfrei darstellen können sollten (so, als wären sie nicht signiert). Trotz dieses lösblichen Ansatzes hat Microsoft sich auch an dieser Stelle als Plage für die IT-Welt erwiesen. Bis ca. 2007 war die – letztlich triviale – Handhabung von PGP/MIME-Mails in Outlook / Outlook Express ein Alptraum. Brauchbar ist sie bis heute nicht.
Um OpenPGP auch mit Mailclients (Webmail war damals noch kein Thema) verwenden zu können, die dafür nicht vorbereitet sind, wurde ein Kompatibilitätsformat eingeführt. Der Trick ist, scheinbar normale Textmails zu produzieren und die – auf Verlustfreiheit angewiesenen – OpenPGP-Informationen dort unterzubringen, wo die Mailclients nur Text erwarten. Das hat den Nachteil, dass Mailclients, die dieses Format nicht erkennen, die OpenPGP-Daten als Text anzeigen, was störend bis verwirrend ist. Außerdem klappt es natürlich nicht mit HTML-Mails. Aus dem Text
Lieber Michael, denk bitte daran, die Unterlagen nachher mitzubringen. Bis dann Hauke
wird dadurch
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Lieber Michael, denk bitte daran, die Unterlagen nachher mitzubringen. Bis dann Hauke -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQEcBAEBCAAGBQJTxFxeAAoJEEhrF6s/lq2OkpgIALDH98cLPDQ33fXaLMhaRSDr AsPxcpcCOF/MgjqSdgDFxzAyo77gLP58Rqng9uHPswnbsUEe2hMJOjB8FAVZLzL6 eQmzsDn9Sq4/w3ExVeSbTtUjhPOxQIE24slVThIQnWOzhpRqC9j0kZAnaXlnucLE vZKpLbBurRaqLYz/F3yFBrIo5moGLv/vOSQDJfCQXqdu69EdfRF0GuaAUQvHYFYJ zec/lGtTbPf0LjSho7JMWPiCrNlCF8KHd17lp72D47JvSCkaSwBRfd2JVOOArvQQ qnSlRK2I78JbIjlKapUj9BhToySlSuEEEmYCti8x4rNPqWAqXqByViBgc5xYTE4= =8kcQ -----END PGP SIGNATURE-----
beziehungsweise
-----BEGIN PGP MESSAGE----- Version: GnuPG v2.0.22 (GNU/Linux) hQEMA3ZDEfKB8GFpAQf/SU0e/R/Bda8Cg9uwPZhSUkWYHcT4uuItVns0PnYsl3wl mFhBM2pp//vzTXed6hyPk/aSWUpdC4W0ck2vZUoDw1uOVHgoRiEhSKmlINthGk0O sziUjL+OdIJNhu1b+QfhXfTqAIHfyJfCYPZdtHJpAvzsbd9MgUYO0n3Q3juYvvPm zkor7X2befhEUU1+IWBGhc/CW8U3LOo+hnFliUILxYE1JTUo7zlM7UxUpxMVue7z Id1JUYPGAyyvwQm74st+LTqwpgL+zUcrvpxdwCf2nTYpwVPsVzGh0GXafGx11YHd 4TFCOX7F/3z3jSQOV54aIMNHS/ZldTrHR4h76IT/G9KLAafcHEo4JTfGrKHA4QzX R4jXfRTdq6Ja2FXn/EugOPUqryiE4ir4k1DP7U5oMQanpVnTM0YhOm0y5A3i6saJ 2P4bI6k/Iz06iRBnCWlm23Ox66YXVcVbq6j/LuHf+B7cNJhyGrpsBF5OR106vVmM QLkeoKZ7co6qBl88jGdlDFcRI06S/2IZgM86vQ== =7Xl7 -----END PGP MESSAGE-----
Man kann notfalls den Text mit einem OpenPGP-Tool vorbereiten und als Text ins Mailprogramm einfügen bzw. ihn aus der Mail in ein OpenPGP-Tool kopieren und dort bearbeiten (entschlüsseln oder die Signatur prüfen). Das funktioniert auch mit Webmail. Man kann auf diese Weise auch signierte oder verschlüsselte Daten – ganz unabhängig von E-Mail – in z.B. Webseiten oder Office-Dokumente einfügen.
Das funktioniert auch ganz gut – solange keine Umlaute im Spiel sind. Denn die Mailsysteme gehen davon aus, dass sie die Daten im Textbereich umschreiben dürfen; es gibt Mechanismen, die sicherstellen, dass danach immer noch derselbe Text angezeigt wird, nur stimmen die Binärdaten eben nicht mehr überein, wodurch die Signatur zerstört wird. Im Fall von Verschlüsselung sieht das Mailprogramm keine Umlaute mehr (weil base64 die Binärdaten in ASCII-Zeichen umschreibt), so dass es den verwendeten Zeichensatz typischerweise nicht einträgt – weil US-ASCII ja völlig ausreicht, um den "Mailinhalt" darzustellen. Das Empfängersystem entschlüsselt die Daten, erhält dabei (ggf.) auch nicht-ASCII-Zeichen, weiß aber nicht, wie es die darstellen soll, weil die Zeichensatz-Information fehlt.
Attachments werden bei PGP/Inline dadurch realisiert, dass die Dateien ganz unabhängig von E-Mail einzeln verschlüsselt und/oder signiert werden und dann als veränderte Datei ganz normal an die Mail gehängt werden. Auch das ist ohne jede Unterstützung durch den Mailclient (auch mit Webmail) realisierbar.
Wenn man OpenPGP-Mails verschickt, muss man sich entscheiden, in welchem Format man die erzeugt. Nicht immer hat man wirklich die Wahl: Nicht alle Programme, die mit OpenPGP umgehen können, kommen mit PGP/MIME klar. Das gilt insbesondere für Webmail-Lösungen, denen einen prinzipielle Grenze dadurch gesetzt ist, dass der Webmail-Provider dies unterstützen müsste (jedenfalls den Versand und den Empfang unverschlüsselter signierter Daten). Wenn man weiß, dass ein Empfänger ein solches Mailsystem verwendet, kann man in vielen OpenPGP-Mailprogrammen für diese Adresse eine Ausnahme definieren: Auch wenn normalerweise als PGP/MIME verschickt wird, werden E-Mails an diese Adresse dann automatisch als PGP/Inline erzeugt.
Zunächst einmal spricht für PGP/MIME, dass es das Verfahren darstellt, wie Krypto-Mails von (fast) Anfang an gedacht waren. Seine Nachteile sind teils prinzipieller Natur (d.h. gleichzeitig Vorteile), teils – hoffentlich – vorübergehender Natur (fehlende Tools zur Handhabung von PGP/MIME-Daten außerhalb von E-Mail).
| Vorteile | Kommentar |
|---|---|
| Erlaubt HTML-Mails. | |
| saubere Handhabung von Umlauten (inhalt unzweifelhaft belegbar) | |
| Signatur sichert die komplette (unverschlüsselte) Nachricht. Es kann nichts entfernt werden. Etwas (das der Absender in anderem Zusammenhang signiert hat) hinzuzufügen, wäre auffällig (jedenfalls technisch; wie die Clients das anzeigen würden, ist eine andere Sache). | |
| sieht bei brauchbaren Mailclients nicht komisch aus, wenn sie OpenPGP nicht unterstützen (z.B. Thunderbird ohne Enigmail) | |
| performanter: nur je eine asymmetrische Krypto-Operation für Verschlüsselung und Signierung für die ganze Mail statt für den Body und jedes Attachment | Das ist auf normalen Systemen nicht relevant; eventuell auf Servern, die massenhaft Mails mit Attachments erzeugen. |
| Nachteile | Kommentar |
|---|---|
| Es muss zur Entschlüsselung bzw. Signaturprüfung immer die komplette Mail (also mit allen Attachments) runtergeladen werden. | Das betrifft nur IMAP und macht einen IMAP-Vorteil zunichte. Andererseits ist es viel wert, dass man die Integrität der Gesamtnachricht prüfen kann, was anders grundsätzlich nicht möglich wäre. |
| Ist bei technischen Problemen schwieriger nachzuvollziehen | Leider wird Crypto noch nicht in einem Ausmaß genutzt, dass alle Fehler (v.a. zwischen verschiedenen Clients) schnell auffielen und behoben würden. |
| Vorteile | Kommentar |
|---|---|
| Die signierten Daten können in andere Medien übernommen werden (allerdings mit der Umlautproblematik), sogar Teil einer anderen Mail werden. | Bei PGP/MIME wäre das – nicht prinzipiell, sondern mit der heutigen (Nicht-Krypto-)Software – nur mit Tricks und auch nur in Ausnahmefällen (nur ASCII-Zeichen; Textmodus-Signatur) möglich. |
| Nachteile | Kommentar |
|---|---|
| Umlaut-Probleme | |
| Nicht mit HTML-Mails möglich |
| Feature | PGP/MIME | PGP/Inline |
|---|---|---|
| ohne Unterstützung des Mailsystems nutzbar | X | |
| mit HTML-Mails nutzbar | X | |
| saubere Handhabung von Umlauten | X | |
| Sicherung der kompletten Mail gegen Veränderung | X | |
| keine komischen Zeichen bei guten Mailclients ohne Krypto-Unterstützung | X | |
| IMAP-typische Handhabung von Attachments | X | |
| Übernahme der signierten Daten mit Signatur in andere Dokumente | X |
Die Standardeinstellung bei Enigmail ist PGP/Inline.