2. General Considerations (Allgemeine Überlegungen)

Die textuelle Kodierung beginnt mit einer Zeile, die "-----BEGIN ", eine Bezeichnung (Label) und "-----" umfasst, und endet mit einer Zeile, die "-----END ", eine Bezeichnung und "-----" umfasst. Zwischen diesen Zeilen, oder "Kapselungsgrenzen" (encapsulation boundaries), befinden sich base64-kodierte Daten gemäß Section 4 von [RFC4648]. (PEM [RFC1421] bezeichnete diese Daten als den "encapsulated text portion", also gekapselte Textabschnitt.) Daten vor den Kapselungsgrenzen sind zulässig, und Parser DÜRFEN NICHT fehlerhaft funktionieren, wenn sie solche Daten verarbeiten. Darüber hinaus SOLLTEN Parser Whitespace und andere Nicht-base64-Zeichen ignorieren und MÜSSEN unterschiedliche Zeilenumbruchkonventionen handhaben.

Der Typ der kodierten Daten wird abhängig von der Typ-Bezeichnung in der "-----BEGIN "-Zeile (Pre-Encapsulation Boundary, Vor-Kapselungsgrenze) gekennzeichnet. Beispielsweise kann die Zeile "-----BEGIN CERTIFICATE-----" lauten, um anzuzeigen, dass der Inhalt ein PKIX-Zertifikat ist (siehe weiter unten). Generatoren MÜSSEN dieselbe Bezeichnung auf die "-----END "-Zeile (Post-Encapsulation Boundary, Nach-Kapselungsgrenze) setzen wie auf die entsprechende "-----BEGIN "-Zeile. Bezeichnungen sind formal case-sensitive (groß-/kleinschreibungsabhängig), in Großbuchstaben und bestehen aus null oder mehr Zeichen; sie enthalten keine aufeinanderfolgenden Leerzeichen oder Bindestriche, noch enthalten sie Leerzeichen oder Bindestriche an den Enden. Parser KÖNNEN die Bezeichnung in der Nach-Kapselungsgrenze ignorieren, anstatt einen Fehler zu signalisieren, wenn es eine Bezeichnungs-Nichtübereinstimmung gibt: Einige existierende Implementierungen erfordern, dass die Bezeichnungen übereinstimmen; andere tun dies nicht.

Es gibt genau ein Leerzeichen (SP) zwischen "BEGIN" oder "END" und der Bezeichnung. Es gibt genau fünf Bindestriche (auch bekannt als Gedankenstriche) ("-") an beiden Enden der Kapselungsgrenzen, nicht mehr, nicht weniger.

Die Bezeichnung impliziert, dass die kodierten Daten der spezifizierten Syntax folgen. Parser MÜSSEN nicht-konforme Daten mit Nachsicht behandeln. Allerdings verhalten sich nicht alle Parser oder Generatoren vor diesem Dokument konsistent. Ein konformer Parser KANN den Inhalt als eine andere Bezeichnung interpretieren, sollte sich aber der Sicherheitsimplikationen bewusst sein, die im Abschnitt Security Considerations diskutiert werden. Die in diesem Dokument beschriebenen Bezeichnungen identifizieren Container-Formate, die nicht spezifisch für einen bestimmten kryptografischen Algorithmus sind, eine Eigenschaft, die mit Algorithmus-Agilität konsistent ist. Diese Formate verwenden die ASN.1 AlgorithmIdentifier-Struktur wie in Section 4.1.1.2 von [RFC5280] beschrieben.

Im Gegensatz zu Legacy-PEM-Kodierung [RFC1421], OpenPGP ASCII armor und dem OpenSSH-Schlüsseldateiformat definiert oder erlaubt die textuelle Kodierung nicht, dass Header neben den Daten kodiert werden. Leerer Raum kann zwischen der Vor-Kapselungsgrenze und dem base64 erscheinen, aber Generatoren SOLLTEN NICHT solche Abstände ausgeben. (Die Vorkehrung für diesen leeren Bereich ist ein Rückgriff auf PEM, das einen "encapsulated header portion", also gekapselten Header-Abschnitt, definierte.)

Implementierer müssen sich bewusst sein, dass existierende Parser in der Handhabung von Whitespace erheblich divergieren. In diesem Dokument bedeutet "whitespace" (Leerraum) jedes Zeichen oder jede Zeichenfolge, die horizontalen oder vertikalen Raum in der Typografie darstellt. In US-ASCII bedeutet Whitespace HT (0x09), VT (0x0B), FF (0x0C), SP (0x20), CR (0x0D) und LF (0x0A); "blank" (leer) bedeutet HT und SP; Zeilen werden mit CRLF, CR oder LF unterteilt. Die gängige ABNF-Produktion WSP ist kongruent mit "blank"; eine neue Produktion W wird für "whitespace" verwendet. Die ABNF in Section 3 ist spezifisch für US-ASCII. Da diese textuellen Kodierungen auf vielen verschiedenen Systemen sowie auf langfristigen Archivierungsmedien wie Papier oder Gravuren verwendet werden können, sollte ein Implementierer den Geist und nicht den Buchstaben der Regeln verwenden, wenn er diese Formate in Umgebungen generiert oder parst, die nicht strikt auf US-ASCII beschränkt sind.

Die meisten existierenden Parser ignorieren Leerzeichen am Ende von Zeilen; Leerzeichen am Anfang von Zeilen oder in der Mitte der base64-kodierten Daten sind weit weniger kompatibel. Diese Beobachtungen sind in Figure 1 kodifiziert. Die nachsichtigsten Parser-Implementierungen sind überhaupt nicht zeilenorientiert und akzeptieren jede Mischung von Whitespace außerhalb der Kapselungsgrenzen (siehe Figure 2). Solch nachsichtiges Parsen kann das Risiko bergen, Text zu akzeptieren, der nicht zur Akzeptierung gedacht war (z.B. weil der Text ein Ausschnitt oder ein Beispiel war).

Generatoren MÜSSEN die base64-kodierten Zeilen so umbrechen, dass jede Zeile aus genau 64 Zeichen besteht, außer der letzten Zeile, die den Rest der Daten kodiert (innerhalb der 64-Zeichen-Zeilengrenze), und sie DÜRFEN NICHT überflüssiges Whitespace ausgeben. Parser KÖNNEN andere Zeilengrößen handhaben. Diese Anforderungen sind konsistent mit PEM [RFC1421].

Dateien KÖNNEN mehrere Instanzen textueller Kodierung enthalten. Dies wird beispielsweise verwendet, wenn eine Datei mehrere Zertifikate enthält. Ob die Instanzen geordnet oder ungeordnet sind, hängt vom Kontext ab.