Base64-Standards: von PEM und MIME bis RFC 4648

Zeitleiste

PEM: wo Base64 begann

Das Alphabet, das wir heute verwenden, erschien zuerst in RFC 989, „Privacy Enhancement for Internet Electronic Mail“, veröffentlicht im Februar 1987. Verschlüsselte E-Mails mussten Gateways passieren, die nur druckbaren Text verarbeiteten, daher brauchte PEM einen Weg, binären Chiffretext mit Zeichen zu schreiben, die jedes Mailsystem überstehen. Es nahm jeweils 6 Bit und bildete sie auf A-Z, a-z, 0-9, + und / ab, mit = als Padding. Die Tabelle in RFC 989 ist identisch mit der Alphabet-Tabelle auf dieser Website. Außerdem reservierte es * zur Kennzeichnung unverschlüsselter Abschnitte, eine Funktion, die nicht überlebt hat.

PEM durchlief RFC 1040 und RFC 1113 und fand seine endgültige Form in RFC 1421 (Februar 1993), das die Zeilenlänge festlegte: Jede Zeile außer der letzten enthält „genau 64 druckbare Zeichen“, die letzte Zeile 64 oder weniger. Als Grund wurden das Drucken und das SMTP-Limit von 1000 Zeichen pro Zeile genannt. PEM als sicheres Mailsystem setzte sich nie durch, sein Dateiformat dagegen schon. Jeder Block -----BEGIN CERTIFICATE----- stammt davon ab, und RFC 7468 (2015) schreibt die Regeln heute ausdrücklich fest: Erzeuger müssen bei genau 64 Zeichen umbrechen, Parser dürfen andere Breiten akzeptieren. Solche Dateien untersuchen Sie mit dem Zertifikat-Decoder.

MIME: Base64 für jeden E-Mail-Anhang

MIME (RFC 1341 im Jahr 1992, RFC 1521 im Jahr 1993, RFC 2045 im Jahr 1996) brauchte einen Weg, Bilder und Dokumente in E-Mails unterzubringen, und übernahm die Kodierung von PEM. RFC 2045 ist bis heute die Referenz für E-Mail und unterscheidet sich in zwei Punkten von PEM:

• Kodierte Zeilen dürfen nicht länger als 76 Zeichen sein und werden durch CRLF getrennt.
• Zeichen außerhalb des Base64-Alphabets sind in Base64-kodierten Daten zu ignorieren. Decoder überspringen Zeilenumbrüche, Leerzeichen und alles andere, was nicht zum Alphabet gehört.

Die zweite Regel ist der Grund, warum so viele Decoder ungültige Zeichen stillschweigend verwerfen. Ausgabe im MIME-Stil erzeugen Sie mit dem MIME-Base64-Encoder, und unter Base64 in E-Mails sehen Sie, wie Anhänge aufgebaut sind.

RFC 3548 und RFC 4648: eine Referenz für alle

Bis 2003 verwies jedes Protokoll, das Base64 nutzte, auf MIME oder PEM und erbte deren Regeln für Zeilenlänge und tolerantes Dekodieren, ob es wollte oder nicht. RFC 3548 (Juli 2003) definierte base64, base64url, base32 und base16 als eigenständige Kodierungen. RFC 4648 (Oktober 2006) ersetzte es mit kleinen Änderungen: Es ergänzte base32hex, das die Sortierreihenfolge der kodierten Daten bewahrt, und eine Reihe von Testvektoren:

BASE64("")       = ""
BASE64("f")      = "Zg=="
BASE64("fo")     = "Zm8="
BASE64("foo")    = "Zm9v"
BASE64("foobar") = "Zm9vYmFy"

Die Regeln in RFC 4648 sind strenger als die von MIME, sofern die verweisende Spezifikation nichts anderes sagt:

• Zeilenvorschübe: Implementierungen dürfen keine einfügen (Abschnitt 3.1).
• Padding: Implementierungen müssen das =-Padding enthalten (Abschnitt 3.2).
• Zeichen außerhalb des Alphabets: Decoder müssen sie ablehnen (Abschnitt 3.3).
• Kanonische Kodierung: Encoder müssen ungenutzte Bits auf null setzen, und Decoder dürfen Eingaben ablehnen, bei denen das nicht der Fall ist (Abschnitt 3.5). Ohne diese Regel werden SGk/Pg== und SGk/Ph== beide zu Hi?> dekodiert.

Die Formulierung „sofern die Spezifikation, die auf dieses Dokument verweist, nicht ausdrücklich etwas anderes festlegt“ leistet viel. So darf JWS das Padding weglassen und MIME seine 76-Zeichen-Zeilen behalten, und beide verwenden trotzdem „Base64 nach RFC 4648“. Die Tools Base32 und Base16 implementieren die beiden anderen Kodierungen aus demselben RFC.

Varianten aus anderen Standards

JWS und JWT: Base64URL ohne Padding

RFC 7515 (Mai 2015) definiert BASE64URL(x) als das Alphabet aus Abschnitt 5, bei dem alle = am Ende weggelassen werden, ohne Zeilenumbrüche oder Leerraum. JWT, JWE, JWK und der größte Teil der JOSE-Familie verwenden das. Details unter Base64 in JWT.

IMAP: modifiziertes UTF-7 mit Komma

IMAP-Postfachnamen sind 7-Bit-Zeichenketten, daher kodiert RFC 3501 (Abschnitt 5.1.3) Ordnernamen mit Nicht-ASCII-Zeichen in „modifiziertem UTF-7“. Folgen von Nicht-ASCII-Zeichen werden in UTF-16 umgewandelt, ohne Padding und mit , statt / in Base64 kodiert und in & und - eingeschlossen. Das Beispiel aus dem RFC selbst, &U,BTFw-, ist der chinesische Name 台北, und ein deutscher Ordner Entwürfe wird zu Entw&APw-rfe. Einfaches UTF-7 (RFC 2152) schreibt denselben Namen als Entw+APw-rfe.

OpenPGP: Radix-64 mit CRC-24

Die ASCII-Armor von OpenPGP ist MIME-Base64 plus eine Prüfsummenzeile. RFC 4880 definiert eine CRC-24 (Generator 0x864CFB, Startwert 0xB704CE) über die Binärdaten, Base64-kodiert und mit vorangestelltem =. GnuPG erzeugt für die 12 Bytes Hello world! Folgendes:

-----BEGIN PGP ARMORED FILE-----
Comment: Use "gpg --dearmor" for unpacking

SGVsbG8gd29ybGQh
=s4Gu
-----END PGP ARMORED FILE-----

RFC 4880 erlaubt Zeilen mit bis zu 76 Zeichen; GnuPG schreibt 64. RFC 9580 (Juli 2024) behält das Format bei, sagt aber, dass die CRC-24-Zeile nicht erzeugt werden sollte („SHOULD NOT be generated“) und dass Implementierungen einen Block nicht ablehnen dürfen, weil sie fehlt oder falsch ist.

Tabelle der Base64-Varianten

In den letzten beiden Zeilen ist das ganze Alphabet umgeordnet. Sie werden auf der Alphabet-Seite behandelt. Viele andere Formate verweisen auf eine der Zeilen oben, ohne etwas zu ändern: HTTP-Basic-Authentifizierung (RFC 7617), Data-URIs (RFC 2397), base64Binary aus XML Schema und Subresource-Integrity-Hashes verwenden alle Standard-Base64 mit Padding.

Häufige Fragen