2. General Considerations (Considerazioni Generali)
2. General Considerations (Considerazioni Generali)
La codifica testuale inizia con una riga composta da "-----BEGIN ", un'etichetta e "-----", e termina con una riga composta da "-----END ", un'etichetta e "-----". Tra queste righe, o "confini di incapsulamento", ci sono dati codificati in base64 secondo la Sezione 4 di [RFC4648]. (PEM [RFC1421] si riferiva a questi dati come "porzione di testo incapsulato".) I dati prima dei confini di incapsulamento sono consentiti, e i parser NON DEVONO malfunzionare durante l'elaborazione di tali dati. Inoltre, i parser DOVREBBERO ignorare gli spazi bianchi e altri caratteri non-base64 e DEVONO gestire diverse convenzioni di nuova riga.
Il tipo di dati codificati è etichettato a seconda dell'etichetta di tipo nella riga "-----BEGIN " (confine di pre-incapsulamento). Ad esempio, la riga può essere "-----BEGIN CERTIFICATE-----" per indicare che il contenuto è un certificato PKIX (vedi più avanti). I generatori DEVONO inserire la stessa etichetta sulla riga "-----END " (confine di post-incapsulamento) come la corrispondente riga "-----BEGIN ". Le etichette sono formalmente sensibili alle maiuscole/minuscole, in maiuscolo e composte da zero o più caratteri; non contengono spazi consecutivi o trattini, né contengono spazi o trattini alle estremità. I parser POSSONO ignorare l'etichetta nel confine di post-incapsulamento invece di segnalare un errore se c'è una mancata corrispondenza di etichetta: alcune implementazioni esistenti richiedono che le etichette corrispondano; altre no.
C'è esattamente un carattere di spazio (SP) che separa il "BEGIN" o "END" dall'etichetta. Ci sono esattamente cinque caratteri trattino (noti anche come dash) ("-") su entrambe le estremità dei confini di incapsulamento, non di più, non di meno.
Il tipo di etichetta implica che i dati codificati seguano la sintassi specificata. I parser DEVONO gestire i dati non conformi con eleganza. Tuttavia, non tutti i parser o generatori precedenti a questo documento si comportano in modo coerente. Un parser conforme PUÒ interpretare i contenuti come un altro tipo di etichetta ma dovrebbe essere consapevole delle implicazioni di sicurezza discusse nella sezione Security Considerations. Le etichette descritte in questo documento identificano formati contenitore che non sono specifici di alcun particolare algoritmo crittografico, una proprietà coerente con l'agilità algoritmica. Questi formati utilizzano la struttura ASN.1 AlgorithmIdentifier come descritto nella Sezione 4.1.1.2 di [RFC5280].
A differenza della codifica PEM legacy [RFC1421], dell'ASCII armor OpenPGP e del formato di file di chiave OpenSSH, la codifica testuale non definisce o consente l'inclusione di intestazioni insieme ai dati. Può apparire spazio vuoto tra il confine di pre-incapsulamento e il base64, ma i generatori NON DOVREBBERO emettere tale spaziatura. (La disposizione per quest'area vuota è un richiamo a PEM, che definiva una "porzione di intestazione incapsulata".)
Gli implementatori devono essere consapevoli che i parser esistenti divergono considerevolmente nella gestione degli spazi bianchi. In questo documento, "whitespace" (spazio bianco) significa qualsiasi carattere o serie di caratteri che rappresentano spazio orizzontale o verticale nella tipografia. In US-ASCII, whitespace significa HT (0x09), VT (0x0B), FF (0x0C), SP (0x20), CR (0x0D) e LF (0x0A); "blank" (vuoto) significa HT e SP; le righe sono divise con CRLF, CR o LF. La comune produzione ABNF WSP è congruente con "blank"; una nuova produzione W è utilizzata per "whitespace". L'ABNF nella Sezione 3 è specifico per US-ASCII. Poiché queste codifiche testuali possono essere utilizzate su molti sistemi diversi così come su supporti di archiviazione a lungo termine come carta o incisioni, un implementatore dovrebbe utilizzare lo spirito piuttosto che la lettera delle regole quando genera o analizza questi formati in ambienti che non sono strettamente limitati a US-ASCII.
La maggior parte dei parser esistenti ignora gli spazi vuoti alle estremità delle righe; gli spazi vuoti all'inizio delle righe o nel mezzo dei dati codificati in base64 sono molto meno compatibili. Queste osservazioni sono codificate nella Figura 1. Le implementazioni di parser più permissive non sono orientate alle righe e accettano qualsiasi miscela di spazi bianchi al di fuori dei confini di incapsulamento (vedi Figura 2). Tale analisi permissiva può correre il rischio di accettare testo che non era destinato ad essere accettato in primo luogo (ad esempio, perché il testo era un frammento o un esempio).
I generatori DEVONO avvolgere le righe codificate in base64 in modo che ogni riga consista di esattamente 64 caratteri tranne per la riga finale, che codificherà il resto dei dati (entro il limite di riga di 64 caratteri), e NON DEVONO emettere spazi bianchi estranei. I parser POSSONO gestire altre dimensioni di riga. Questi requisiti sono coerenti con PEM [RFC1421].
I file POSSONO contenere più istanze di codifica testuale. Questo è utilizzato, ad esempio, quando un file contiene diversi certificati. Se le istanze sono ordinate o non ordinate dipende dal contesto.