2. Considérations Générales
2. Considérations Générales
L'encodage textuel commence par une ligne comprenant "-----BEGIN ", une étiquette (label), et "-----", et se termine par une ligne comprenant "-----END ", une étiquette, et "-----". Entre ces lignes, ou "limites d'encapsulation" (encapsulation boundaries), se trouvent des données encodées en base64 selon la Section 4 du [RFC4648]. (PEM [RFC1421] faisait référence à ces données comme la "portion de texte encapsulé".) Les données avant les limites d'encapsulation sont autorisées, et les analyseurs NE DOIVENT PAS mal fonctionner lors du traitement de telles données. De plus, les analyseurs DEVRAIENT ignorer les espaces blancs et autres caractères non-base64 et DOIVENT gérer différentes conventions de retour à la ligne.
Le type de données encodées est étiqueté selon l'étiquette de type dans la ligne "-----BEGIN " (limite de pré-encapsulation). Par exemple, la ligne peut être "-----BEGIN CERTIFICATE-----" pour indiquer que le contenu est un certificat PKIX (voir plus bas). Les générateurs DOIVENT mettre la même étiquette sur la ligne "-----END " (limite de post-encapsulation) que la ligne "-----BEGIN " correspondante. Les étiquettes sont formellement sensibles à la casse, en majuscules, et composées de zéro ou plusieurs caractères; elles ne contiennent pas d'espaces consécutifs ou de traits d'union-moins, ni ne contiennent d'espaces ou de traits d'union-moins aux deux extrémités. Les analyseurs PEUVENT ignorer l'étiquette dans la limite de post-encapsulation au lieu de signaler une erreur s'il y a une non-correspondance d'étiquette: certaines implémentations existantes exigent que les étiquettes correspondent; d'autres non.
Il y a exactement un caractère espace (SP) séparant le "BEGIN" ou "END" de l'étiquette. Il y a exactement cinq caractères trait d'union-moins (également connus sous le nom de tirets) ("-") aux deux extrémités des limites d'encapsulation, ni plus, ni moins.
Le type d'étiquette implique que les données encodées suivent la syntaxe spécifiée. Les analyseurs DOIVENT gérer les données non conformes avec élégance. Cependant, tous les analyseurs ou générateurs antérieurs à ce document ne se comportent pas de manière cohérente. Un analyseur conforme PEUT interpréter le contenu comme un autre type d'étiquette mais devrait être conscient des implications de sécurité discutées dans la section Considérations de Sécurité. Les étiquettes décrites dans ce document identifient des formats de conteneurs qui ne sont pas spécifiques à un algorithme cryptographique particulier, une propriété cohérente avec l'agilité algorithmique. Ces formats utilisent la structure ASN.1 AlgorithmIdentifier comme décrit dans la Section 4.1.1.2 du [RFC5280].
Contrairement à l'encodage PEM hérité [RFC1421], à l'armure ASCII OpenPGP et au format de fichier de clé OpenSSH, l'encodage textuel ne définit pas et ne permet pas l'encodage d'en-têtes aux côtés des données. Un espace vide peut apparaître entre la limite de pré-encapsulation et le base64, mais les générateurs NE DEVRAIENT PAS émettre un tel espacement. (La disposition pour cette zone vide est un vestige de PEM, qui définissait une "portion d'en-tête encapsulée".)
Les implémenteurs doivent être conscients que les analyseurs existants divergent considérablement sur la gestion des espaces blancs. Dans ce document, "whitespace" (espace blanc) signifie tout caractère ou série de caractères qui représentent un espace horizontal ou vertical en typographie. En US-ASCII, les espaces blancs signifient HT (0x09), VT (0x0B), FF (0x0C), SP (0x20), CR (0x0D), et LF (0x0A); "blank" (vide) signifie HT et SP; les lignes sont divisées avec CRLF, CR, ou LF. La production ABNF commune WSP est congruente avec "blank"; une nouvelle production W est utilisée pour "whitespace". L'ABNF dans la Section 3 est spécifique à US-ASCII. Comme ces encodages textuels peuvent être utilisés sur de nombreux systèmes différents ainsi que sur des supports de stockage d'archivage à long terme tels que le papier ou les gravures, un implémenteur devrait utiliser l'esprit plutôt que la lettre des règles lors de la génération ou de l'analyse de ces formats dans des environnements qui ne sont pas strictement limités à US-ASCII.
La plupart des analyseurs existants ignorent les blancs à la fin des lignes; les blancs au début des lignes ou au milieu des données encodées en base64 sont beaucoup moins compatibles. Ces observations sont codifiées dans la Figure 1. Les implémentations d'analyseurs les plus laxistes ne sont pas du tout orientées lignes et accepteront n'importe quel mélange d'espaces blancs en dehors des limites d'encapsulation (voir Figure 2). Une telle analyse laxiste peut courir le risque d'accepter du texte qui n'était pas destiné à être accepté en premier lieu (par exemple, parce que le texte était un extrait ou un échantillon).
Les générateurs DOIVENT envelopper les lignes encodées en base64 de sorte que chaque ligne soit constituée d'exactement 64 caractères sauf pour la ligne finale, qui encodera le reste des données (dans la limite de ligne de 64 caractères), et ils NE DOIVENT PAS émettre d'espaces blancs superflus. Les analyseurs PEUVENT gérer d'autres tailles de lignes. Ces exigences sont cohérentes avec PEM [RFC1421].
Les fichiers PEUVENT contenir plusieurs instances d'encodage textuel. Ceci est utilisé, par exemple, lorsqu'un fichier contient plusieurs certificats. Que les instances soient ordonnées ou non ordonnées dépend du contexte.