Zusammenfassung

  • RFC 3548 nahm sich eines unscheinbaren Interoperabilitätsproblems an: Protokolle sagten „base64“, ohne Alphabet, Zeilenumbrüche, Padding oder den Umgang mit fremden Zeichen festzulegen.
  • Die zentrale Klarstellung: MIMEs Verhalten beim Nachrichtentransport ist ein bestimmtes Profil, kein universeller Vertrag für jeden Decoder.

Ein Texteditor kann eine Base64-Zeichenfolge öffnen. Das legt eine falsche Einfachheit nahe: Bytes hinein, druckbare Zeichen heraus, und jeder Decoder könne den Vorgang umkehren. Die von RFC 3548 dokumentierte Geschichte sieht anders aus. Implementierungen hatten kleine Unterschiede angesammelt, während Protokolle „base64“ so verwendeten, als kläre der Name sämtliche Einzelheiten.

Der Streit betraf nicht die Sechs-Bit-Arithmetik, sondern die Regeln an ihrem Rand. Fügt der Encoder Zeilenumbrüche ein? Muss das abschließende = vorhanden sein? Weist der Decoder ein unerwartetes Zeichen zurück oder ignoriert er es? Welche Symbole belegen die 64 Stellen? Die Antwort eines benachbarten Formats kann dort funktionieren und bei einem Gegenüber scheitern, das ein anderes Verhalten voraussetzt.

RFC 3548 erschien im Juli 2003 als Informational RFC und sollte diese Mehrdeutigkeit reduzieren. In der Einleitung beschreibt sie einen verbreiteten Kurzschluss: Protokollspezifikationen verwendeten „base64“ ohne präzise Beschreibung oder Referenz und beriefen sich häufig auf MIME, ohne die Folgen von Zeilenfaltung oder Zeichen außerhalb des Alphabets zu bedenken. Das Dokument stellte daher gängige Base16-, Base32- und Base64-Verfahren samt ihrer Randbedingungen zusammen.

MIME war gerade deshalb eine Quelle der Verwechslung, weil es einen eigenen Kontext definiert. RFC 2045 beschreibt Base64 als Content-Transfer-Encoding für Nachrichtenkörper. Die Grenze von 76 Zeichen je Zeile gehört in diesen Mail-Kontext; PEM verwendete in einem verwandten Umfeld 64 Zeichen. Die allgemeine Regel von RFC 3548 für verweisende Spezifikationen lautet, keine Zeilenumbrüche einzufügen, sofern die Spezifikation sie nicht ausdrücklich verlangt. Ein Umbruch ist keine bloße Typografie, wenn die Gegenseite ihn als Daten zählen oder ablehnen kann.

Auch Padding und Toleranz sind Profilentscheidungen. RFC 3548 verlangt geeignetes Padding, sofern eine verweisende Spezifikation nichts anderes festlegt. Zeichen außerhalb des Alphabets sollen zurückgewiesen werden, außer eine ausdrückliche Regel bestimmt ein anderes Verhalten. MIME darf solche Zeichen einschließlich CRLF ignorieren; diese Ausnahme gilt aber für MIME. Wird sie in ein anderes Protokoll übernommen, verändert sie die Menge akzeptierter Eingaben. RFC 3548 nennt verdeckte Kanäle und Implementierungsfehler als Gründe für Vorsicht, nicht als Bericht über einen Angriff auf ein bestimmtes Produkt.

Auch das Alphabet brauchte einen eindeutigen Namen. Das übliche Base64 verwendet + und / für die Werte 62 und 63. RFC 3548 dokumentiert eine URL- und dateinamensichere Variante, die diese Zeichen durch und _ ersetzt. Sie solle nicht als dasselbe Verfahren oder bloß als „base64“ bezeichnet werden. Pfade, Dateinamen und Kennungen stellen andere Anforderungen als ein Mailkörper.

Im Oktober 2006 löste RFC 4648 RFC 3548 als Standards-Track-Dokument ab. Sie behielt den profilbezogenen Ansatz bei und ergänzte Regeln für kanonische Kodierung: Padding-Bits bei Base64 und Base32 müssen null sein, sonst können verschiedene Zeichenfolgen dieselben Bytes ergeben. Das ist eine andere Frage als MIMEs Zeilenumbruch. Zusammen zeigen beide RFCs, warum „Dekodierung erfolgreich“ noch keine vollständige Protokollbeschreibung ist: Die Beteiligten müssen Form, Padding, Toleranz und die Ebene der Interpretation festlegen.

Basiskodierung ist weder Verschlüsselung noch Authentisierung. Sie stellt Oktette als Text dar, wenn ein Transport das erfordert. Der bleibende Beitrag von RFC 3548 war nüchtern: Ein vertrauter Name ist noch kein vollständiges Regelwerk.

Quellen