1. Introduction (Einführung)

Mehrere sicherheitsrelevante Standards, die im Internet verwendet werden, definieren ASN.1-Datenformate, die normalerweise mit den Basic Encoding Rules (BER) oder Distinguished Encoding Rules (DER) [X.690] kodiert werden, welche binäre, oktetorientierte Kodierungen sind. Dieses Dokument behandelt die textuellen Kodierungen der folgenden Formate:

1. Certificates (Zertifikate), Certificate Revocation Lists (CRLs, Zertifikatsperrlisten) und Subject Public Key Info-Strukturen in der Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile [RFC5280].

2. PKCS #10: Certification Request Syntax (Zertifizierungsanfrage-Syntax) [RFC2986].

3. PKCS #7: Cryptographic Message Syntax (Kryptografische Nachrichtensyntax) [RFC2315].

4. Cryptographic Message Syntax (Kryptografische Nachrichtensyntax) [RFC5652].

5. PKCS #8: Private-Key Information Syntax (Private-Key-Informationssyntax) [RFC5208], umbenannt in One Asymmetric Key (Ein asymmetrischer Schlüssel) in Asymmetric Key Package [RFC5958], und Encrypted Private-Key Information Syntax (Verschlüsselte Private-Key-Informationssyntax) in denselben Dokumenten.

6. Attribute Certificates (Attributzertifikate) in An Internet Attribute Certificate Profile for Authorization [RFC5755].

Ein Nachteil eines binären Datenformats ist, dass es nicht in textuellen Transportmechanismen wie E-Mail oder Textdokumenten ausgetauscht werden kann. Ein Vorteil von textbasierten Kodierungen ist, dass sie einfach mit gängigen Texteditoren modifiziert werden können; beispielsweise kann ein Benutzer mehrere Zertifikate mit Kopier- und Einfügeoperationen zu einer Zertifikatskette zusammenfügen.

Die Tradition innerhalb der RFC-Serie kann bis zu Privacy-Enhanced Mail (PEM) [RFC1421] zurückverfolgt werden, basierend auf einem Vorschlag von Marshall Rose in Message Encapsulation [RFC934]. Ursprünglich "PEM encapsulation mechanism", "encapsulated PEM message" oder (wohl) "PEM printable encoding" genannt, wird das Format heute manchmal als "PEM encoding" bezeichnet. Varianten umfassen OpenPGP ASCII armor [RFC4880] und das OpenSSH-Schlüsseldateiformat [RFC4716].

Aus Gründen, die im Grunde auf mangelnde Koordination oder Unaufmerksamkeit zurückzuführen sind, implementieren viele PKIX-, PKCS- und CMS-Bibliotheken eine textbasierte Kodierung, die ähnlich zu PEM-Kodierung ist, aber nicht identisch damit. Dieses Dokument spezifiziert das Format der textuellen Kodierung, formuliert die De-facto-Regeln, nach denen die meisten Implementierungen operieren, und bietet Empfehlungen, die die Interoperabilität in Zukunft fördern werden. Dieses Dokument bietet auch eine gemeinsame Nomenklatur für Syntaxelemente, die die Entwicklung dieses De-facto-Standardformats widerspiegelt. Peter Gutmanns "X.509 Style Guide" [X.509SG] enthält einen Abschnitt "base64 Encoding", der die Formate beschreibt und Vorschläge enthält, die denen in diesem Dokument ähneln. Alle Abbildungen sind echte, funktionale Beispiele, wobei Schlüssellängen und innere Inhalte so klein wie praktisch gewählt wurden.

Die Schlüsselwörter "MUST" (MUSS), "MUST NOT" (DARF NICHT), "REQUIRED" (ERFORDERLICH), "SHALL" (SOLL), "SHALL NOT" (SOLL NICHT), "SHOULD" (SOLLTE), "SHOULD NOT" (SOLLTE NICHT), "RECOMMENDED" (EMPFOHLEN), "NOT RECOMMENDED" (NICHT EMPFOHLEN), "MAY" (KANN) und "OPTIONAL" (OPTIONAL) in diesem Dokument sind wie in RFC 2119 [RFC2119] beschrieben zu interpretieren.