1. Introduction

1. Introduction

Plusieurs normes liées à la sécurité utilisées sur Internet définissent des formats de données ASN.1 qui sont normalement encodés en utilisant les Règles d'Encodage de Base (BER) ou les Règles d'Encodage Distingué (DER) [X.690], qui sont des encodages binaires orientés octets. Ce document traite des encodages textuels des formats suivants:

1. Certificats, Listes de Révocation de Certificats (CRL) et structures d'Informations de Clé Publique de Sujet dans le Profil de Certificat et de Liste de Révocation de Certificat (CRL) de l'Infrastructure à Clés Publiques Internet X.509 [RFC5280].

2. PKCS #10: Syntaxe de Demande de Certification [RFC2986].

3. PKCS #7: Syntaxe de Message Cryptographique [RFC2315].

4. Syntaxe de Message Cryptographique [RFC5652].

5. PKCS #8: Syntaxe d'Informations de Clé Privée [RFC5208], renommé Clé Asymétrique Unique (OneAsymmetricKey) dans Package de Clé Asymétrique [RFC5958], et Syntaxe d'Informations de Clé Privée Chiffrée dans les mêmes documents.

6. Certificats d'Attributs dans Un Profil de Certificat d'Attribut Internet pour l'Autorisation [RFC5755].

Un inconvénient d'un format de données binaire est qu'il ne peut pas être échangé dans des transports textuels, tels que le courrier électronique ou les documents texte. Un avantage des encodages basés sur du texte est qu'ils sont faciles à modifier en utilisant des éditeurs de texte courants; par exemple, un utilisateur peut concaténer plusieurs certificats pour former une chaîne de certificats avec des opérations de copier-coller.

La tradition au sein de la série des RFC remonte au Courrier à Confidentialité Améliorée (PEM) [RFC1421], basé sur une proposition de Marshall Rose dans Message Encapsulation [RFC934]. Initialement appelé "mécanisme d'encapsulation PEM", "message PEM encapsulé", ou (de manière discutable) "encodage imprimable PEM", aujourd'hui le format est parfois désigné comme "encodage PEM". Les variations incluent l'armure ASCII OpenPGP [RFC4880] et le format de fichier de clé OpenSSH [RFC4716].

Pour des raisons qui se résument essentiellement à une non-coordination ou à une inattention, de nombreuses bibliothèques PKIX, PKCS et CMS implémentent un encodage basé sur du texte qui est similaire à -- mais non identique avec -- l'encodage PEM. Ce document spécifie le format d'encodage textuel, articule les règles de facto selon lesquelles la plupart des implémentations opèrent, et fournit des recommandations qui favoriseront l'interopérabilité à l'avenir. Ce document fournit également une nomenclature commune pour les éléments de syntaxe, reflétant l'évolution de ce format standard de facto. Le "Guide de Style X.509" de Peter Gutmann [X.509SG] contient une section "encodage base64" qui décrit les formats et contient des suggestions similaires à ce qui est dans ce document. Toutes les figures sont des exemples réels et fonctionnels, avec des longueurs de clés et des contenus internes choisis pour être aussi petits que possible dans la pratique.

Les mots-clés "MUST" (DOIT), "MUST NOT" (NE DOIT PAS), "REQUIRED" (REQUIS), "SHALL" (DOIT), "SHALL NOT" (NE DOIT PAS), "SHOULD" (DEVRAIT), "SHOULD NOT" (NE DEVRAIT PAS), "RECOMMENDED" (RECOMMANDÉ), "NOT RECOMMENDED" (NON RECOMMANDÉ), "MAY" (PEUT), et "OPTIONAL" (OPTIONNEL) dans ce document doivent être interprétés comme décrit dans le RFC 2119 [RFC2119].