Zusammenfassung

  • RFC 2015 setzte PGP in multipart/signed um: eine lesbare erste MIME-Komponente und eine abgetrennte Signatur in der zweiten, wobei auch die Inhaltsköpfe signiert wurden.
  • Sieben-Bit-Form, CRLF, Transferkodierung, führendes From und abschließender Leerraum gehörten zur Beweisgrenze, weil Gateways sie verändern konnten.
  • Erfolgreiche Prüfung belegt eine Beziehung zwischen Bytes, Signatur und Schlüssel; Identität, Absicht, Zustellung und Befugnis brauchen eigene Nachweise.

Der Aufbau löste zunächst ein Zugriffsproblem. Frühere application/pgp-Formen konnten verlangen, PGP-interne Strukturen zu zerlegen, nur um an den signierten Text zu gelangen. RFC 1847 definierte dagegen einen protokollneutralen Sicherheits-Multipart mit genau zwei Teilen. RFC 2015 legte das signierte MIME-Objekt in den ersten und application/pgp-signature in den zweiten. Ein MIME-Programm konnte den Inhalt finden, ohne PGP vollständig zu beherrschen.

Lesbarkeit bedeutete jedoch keine Austauschbarkeit. Für Text legte der Absender die Darstellung fest, wandelte Zeilenenden in CRLF um, setzte Content-Transfer-Encoding ein, fügte MIME-Inhaltsköpfe hinzu und signierte erst dann Köpfe und kodierte Daten. Die Köpfe waren eingeschlossen, weil eine Änderung von Inhaltstyp oder Kodierungslabel die Auslegung unveränderter Bytes verschieben kann.

Das Sieben-Bit-Erbe von SMTP machte die Reihenfolge betrieblich wichtig. Vor einem alten nächsten Hop konnte ein Gateway Acht-Bit-Inhalt in Quoted-Printable oder Base64 umwandeln. Das half der Zustellung, ersetzte aber nach der Signatur deren Hash-Eingabe. Deshalb musste schon der Absender die transportsichere Darstellung signieren.

RFC 2015 wählte bemerkenswert kleine Beispiele. Mailbox-Software konnte einer mit From beginnenden Zeile ein > voranstellen; andere Übergänge entfernten nachlaufende Leerzeichen. RFC 3156 präzisierte später die Wiederherstellung von CRLF, den Schutz des Leerraums und die letzte Zeile. Für Menschen blieb der Text gleich, für die Prüfung nicht.

Nur verschlüsselte Daten durften Acht-Bit-Zeichen behalten, weil der Empfänger das innere Objekt aus undurchsichtigen OpenPGP-Daten gewann. Bei einer abgetrennten Signatur besaß er den lesbaren Teil separat und musste dieselbe Darstellung erneut hashen. Auch Signieren vor Verschlüsseln hob diese Anforderung für das innere Objekt nicht auf.

RFC 2480 beschrieb den Konflikt am Übergang zu einer Umgebung ohne MIME. Das Gateway musste Sicherheits-Multiparts unverändert tunneln können. Alternativ durfte es multipart/signed zerlegen, um den Inhalt zugänglich zu machen, zerstörte damit aber die Signatur. Dann sollten Signatur und Warnung erhalten bleiben. Prüfen oder Neusignieren am Gateway schuf eine neue Schlüsselverwahrung und Vertrauensstelle und sollte standardmäßig abgeschaltet sein.

Ein positives Ergebnis sagt, dass der Prüfer die erwartete MIME-Entität rekonstruierte und die Signatur mit einem bestimmten öffentlichen Schlüssel bestätigte. Wem der Schlüssel gehört, entscheidet ein separates Vertrauensverfahren. Autorschaft, organisatorische Befugnis, Zustellung, Anzeige und Handlungsergebnis folgen daraus nicht. Auch ein Fehlschlag benennt keinen Angreifer: Umwandlung, Speicherung, falscher Schlüssel oder fehlerhafte Konstruktion können ihn ebenso verursachen.

Die bleibende Leistung von RFC 2015 war damit eine operative Grenze: Vor der Kryptografie musste feststehen, welche Darstellung ein Vermittler nicht mehr verbessern durfte.

Quellen