Zusammenfassung

  • RFC 1421 siedelte Privacy Enhanced Mail an den Endpunkten an. Vorhandene SMTP-Relays mussten die Kryptografie nicht verstehen. Geschützt war der gekapselte Inhalt, nicht jedes äußere Feld und nicht die gesamte Zustellgeschichte.
  • MIC-CLEAR bot dieselbe Authentisierung und Integrität wie MIC-ONLY, verzichtete aber auf dessen druckbare Kodierung gegen Änderungen im Übertragungssystem. Empfänger ohne PEM konnten den Text lesen, seine Signatur jedoch nicht prüfen.
  • Der MIC bezog sich auf eine kanonische ASCII-Darstellung mit CRLF-Zeilenenden. Schon eine gewöhnliche Zeilenumwandlung konnte einen Fehlschlag auslösen; Ergebnis, Ursache und Einordnung als Sicherheitsereignis blieben deshalb getrennte Aussagen.

Sicheres E-Mail-Design begann nicht bei null. Es musste sich in eine Infrastruktur einfügen, deren Teilnehmer längst eigene Gewohnheiten hatten.

Ein User Agent erzeugte lokalen Text. Message Transfer Agents nahmen ihn an, reichten ihn weiter und stellten ihn zu. Gateways verbanden unterschiedliche Nachrichtenwelten. Rechner speicherten Zeichensätze und Zeilenenden nicht überall gleich. Bei einer Weiterleitung konnte die ursprüngliche Nachricht in eine neue Hülle geraten. Hätte jeder dieser Knoten eine neue Sicherheitsfunktion beherrschen müssen, wäre die weltweite Aufrüstung zur Voraussetzung jeder lokalen Einführung geworden.

RFC 1421 legte Privacy Enhanced Mail deshalb in den User Agent oder eine darüberliegende Schicht. Der Absender transformierte den Inhalt vor der Übergabe. Der Empfänger kehrte die Schritte nach der Zustellung um und prüfte sie. Dazwischen durfte SMTP gewöhnliches SMTP bleiben. Eine Organisation konnte PEM an ihren Rändern einsetzen, ohne den gesamten Pfad zu kontrollieren.

Dieser Vorteil beruhte auf einer engen Schutzgrenze. Felder, die Relays zwischen den PEM-Komponenten hinzufügten oder veränderten, fielen nicht unter die Privacy Enhancements. Das äußere Nachrichtensystem transportierte ein geschütztes Objekt; es wurde dadurch nicht selbst zu diesem Objekt. Envelope, Routing, Trace-Felder und spätere Anmerkungen erhielten keine Signatur durch räumliche Nähe.

Eine zugestellte Mail trägt daher mehrere Geschichten. Es gibt die SMTP-Übergaben, die Veränderungen der äußeren Nachricht, die Darstellung des gekapselten Objekts, den Prüfprozess und schließlich die Handlungen des Lesers. Ein einziges Sicherheitszeichen würde diese unterschiedlichen Belege unbrauchbar vermischen.

Die Mitte des Netzes musste nichts Neues lernen

RFC 1421 setzte auf Fähigkeiten an den Endpunkten statt auf Sicherheitspflichten für jeden SMTP-Server. Das Dokument wollte Nutzer befähigen und ihnen nicht technisch verbieten, ungeschützte Nachrichten zu senden. Es unterstellte auch nicht, jeder User Agent sei gegen lokale Manipulation vertrauenswürdig.

Die Kosten der Einführung verschoben sich. Relay-Betreiber konnten ihre Infrastruktur weiterbetreiben. Endpunktentwickler mussten nicht auf einen globalen Rollout warten. Dafür musste ein Absender vor der Transformation wissen, ob der Empfänger die gewählten Schritte rückgängig machen konnte. Schlüsselverwaltung und unterstützte Verfahren blieben eine zusätzliche Vereinbarung.

Die Annahme eines RCPT TO war nur die Zusage eines Transportknotens, die nächste Verantwortung zu übernehmen. Sie belegte weder PEM-Fähigkeit noch einen passenden Schlüssel am Ziel. Zustellbarkeit und Prüfbarkeit waren unterschiedliche Eigenschaften derselben Adresse.

Auch die Ausschlüsse des Standards begrenzten seine Aussagekraft. Er löste weder Zugriffskontrolle noch Vertraulichkeit des Verkehrsflusses, Genauigkeit von Adresslisten, Routensteuerung, Nachweis oder Nichtabstreitbarkeit des Empfangs, Zuordnung von Bestätigungen, Duplikaterkennung oder Schutz vor Replay. Ein gültiger MIC durfte nicht als Ersatzbeleg für diese Beziehungen dienen.

Signiert wurde eine Rekonstruktion, nicht der Bildschirmeindruck

Ausgangspunkt war die lokale Darstellung eines Hosts. RFC 1421 überführte sie in eine gemeinsame, an inter-SMTP angelehnte Form: ASCII-Zeichen und CRLF als Zeilenabschluss. Das Dot-Stuffing der SMTP-Transparenzregeln gehörte nicht zu diesem kanonischen Objekt.

Über diese Bytes wurde der Message Integrity Check gebildet. Falls Vertraulichkeit gewählt war, setzte auch die Verschlüsselung dort an. Die allgemeine Folge lautete Encode(Encrypt(Canonicalize(Local_Form))); bei einzelnen Nachrichtentypen entfielen nicht benötigte Schritte. Die Empfängerseite führte die passenden Umkehrungen aus und wandelte erst danach in ihre lokale Darstellung.

Das schuf Interoperabilität und eine harte Beweisgrenze. Ein MIC authentisierte nicht den Sinn eines Absatzes und nicht seine sichtbare Typografie. Er authentisierte die Bytes einer vorgeschriebenen Rekonstruktion. Zwei gleich aussehende Texte konnten sich in den Zeilenenden unterscheiden. Eine sichtbar veränderte Darstellung konnte dagegen wieder korrekt werden, wenn die verantwortliche Außenschicht ihre reversible Änderung entfernte.

RFC 822 hatte Nachrichten als Felder mit einem optionalen, zeilenorientierten ASCII-Inhalt beschrieben. RFC 821 definierte SMTP-DATA und Transparenz. PEM nutzte diese verbreitete Zeilendisziplin als gemeinsames Modell, ohne jede kanonische Zwischenform zu einer tatsächlich beobachteten SMTP-Transaktion zu erklären.

Drei Formate verteilten das Risiko verschieden

ENCRYPTED verband Vertraulichkeit mit Authentisierung und Integrität. Der kanonische Inhalt wurde verschlüsselt und anschließend in einem eingeschränkten druckbaren Alphabet dargestellt, das vielfältige Mailpfade passieren konnte.

MIC-ONLY verzichtete auf Geheimhaltung, stellte den Text aber nicht unmittelbar lesbar dar. Seine druckbare Kodierung hielt eine Klasse von Transformationen des Message Transfer System vom signierten Inhalt fern. Erst PEM-Software gewann den Inhalt zurück und prüfte den MIC.

MIC-CLEAR wählte dieselben Integritäts- und Authentisierungsdienste, ließ aber gerade diese Kodierung aus. Darin lag sein Kompatibilitätsangebot. Auch ein Empfänger ohne PEM konnte den Text verstehen. Er konnte daraus nicht folgern, die Signatur sei bestätigt.

Lesbarkeit entstand durch die sichtbare Darstellung. Prüfbarkeit benötigte Kontrollfelder, den richtigen Schlüsselweg, dieselbe kanonische Rekonstruktion und einen passenden MIC. Das erste Merkmal konnte vollständig vorhanden sein, während das zweite noch unbekannt war.

Diese Trennung hatte eine menschliche Seite. Verständliche Sprache wirkt, bevor Provenienz technisch geklärt ist. Ein klarer Auftrag kann Dringlichkeit und Autorität erzeugen, sobald er erscheint. Wer Kompatibilität durch frühe Lesbarkeit gewinnt, muss den noch offenen Vertrauenszustand ebenso deutlich zeigen.

Eine fehlgeschlagene Prüfung erklärte noch nichts

Die druckbare Kodierung von MIC-ONLY sollte den signierten Text gegen bestimmte Änderungen im Message Transfer System abschirmen. MIC-CLEAR gab diese Abschirmung zugunsten der Direktlesbarkeit auf. Sein MIC ließ sich nur prüfen, wenn das System den Inhalt nicht veränderte oder wenn sich seine Änderungen identifizieren und vor der Prüfung umkehren ließen.

Zeilenenden waren der naheliegende Fall. SMTP benutzte CRLF; ein Zielsystem konnte sie bereits in seine lokale Form verwandelt haben, bevor PEM den Inhalt erhielt. Der Prüfer musste diese lokale Fassung wieder kanonisieren, die inter-SMTP-Darstellung rekonstruieren und daraus den Referenz-MIC berechnen.

Bei Weiterleitungen kam eine weitere Schicht hinzu. RFC 1421 übernahm die Kapselungsgrenzen aus RFC 934. Begann eine MIC-CLEAR-Zeile mit einem Bindestrich und konnte sie wie eine Grenze wirken, durfte die äußere Schicht voranstellen. Der MIC war davor gebildet worden. Deshalb musste genau diese Hülle ihren Escape wieder entfernen, bevor die innere Prüfung begann.

Ein ungleicher MIC bewies, dass die Rekonstruktion das signierte Objekt nicht erreicht hatte. Er benannte nicht automatisch den Verursacher. Eine böswillige Änderung war möglich; ebenso eine gutartige Konvertierung, die die Empfangsseite nicht erkannt oder nicht umgekehrt hatte. RFC 1421 hielt daher ausdrücklich fest, dass ein MIC-CLEAR-Fehler nicht zwingend ein sicherheitsrelevantes Ereignis bedeutete.

Die Benutzerschnittstelle sollte diese Beweislage nicht in Rot oder Grün auflösen. Bei einer Fehlermeldung sollte sie den verarbeiteten PEM-Typ nennen. Eine syntaktisch gültige Nachricht mit fehlgeschlagenem MIC durfte nicht still als vertrauenswürdig erscheinen: Der Nutzer sollte vor zweifelhafter Authentizität und Integrität gewarnt werden und das Anzeigen ausdrücklich bestätigen. Der Messwert blieb wahr, die Ursache blieb zu untersuchen.

Eine Hülle erweitert keine Signatur

PEM-Kontrollfelder lagen in einem gekapselten Header innerhalb des äußeren Nachrichteninhalts. Außerhalb der Grenzen konnten ungeschützte Anmerkungen stehen; mehrere Schutzobjekte und verschachtelte Weiterleitungen waren möglich. Was auf dem Bildschirm daneben stand, gehörte nicht deshalb zum signierten Gegenstand.

Auch ein erfolgreicher MIC bestätigte weder die äußere Adressliste noch die Route, das richtige Postfach oder die menschliche Kenntnisnahme. Er verband einen kanonischen Inhalt mit Kontrollangaben und einem Schlüsselpfad. Identität, Befugnis, Empfang, Antwort und Wirkung brauchten eigene Beweise.

RFC 1423 lagerte Algorithmen, Modi und Kennungen in eine eigene Spezifikation aus. Die Nachrichtenverarbeitung konnte dadurch auf eine austauschbare kryptografische Oberfläche verweisen. RFC 1421 und RFC 1423 sind heute beide Historic. Die modulare Trennung bleibt lehrreich; die konkrete Algorithmusauswahl von 1993 ist keine aktuelle Sicherheitsempfehlung.

MIC-CLEAR versprach also keine reibungslose Sicherheit für ein altes Medium. Es dokumentierte einen Tausch. Die Relays blieben unverändert, der Inhalt blieb zugänglich. Dafür musste jede Transformation zwischen dem signierten kanonischen Objekt und der lokalen Anzeige rückführbar, zurechenbar oder ausdrücklich unbekannt sein. Die Mail blieb lesbar, und der Prüfer erbte ihren Weg.