Non esiste uno standard reale per le cose nel formato "PEM". C'era uno standard proposto chiamato Posta elettronica ottimizzata per la privacy , da cui "PEM "l'acronimo era derivato; tuttavia, questo standard non ha mai ottenuto trazione rispetto alla sua concorrenza (PGP e S / MIME) e nessuno lo implementa.

OpenSSL ha rilevato PEM e ha "migliorato" il formato PEM con funzionalità e intestazioni extra, senza alcuna specifica o documentazione reale che valesse quel nome , così oggi "PEM" significa veramente "qualunque cosa OpenSSL produca e possa analizzare". Altri venditori seguirono, ad es. Microsoft, il cui software può decodificare i certificati codificati PEM.

Il principio di PEM (dati codificati Base64, con un'intestazione '----- BEGIN XXX -----' e corrispondente '----- END XXX --- - "trailer" è stato utilizzato per altre cose; PGP lo chiama "armatura ASCII". Il punto di quel modo di fare le cose è essere in grado di localizzare i dati interessanti all'interno di una sequenza di dati testuali, indipendentemente dalle varie torture inflitte a quel testo mentre viene trasferito (ad esempio, inviato come e-mail, copia e incollato, incluso in un documento Word, stampato e scansionato ...). Questo è un punto importante: significa che il punto intero di PEM deve essere in grado di memorizzare i certificati insieme e a casaccio senza dover seguire uno standard specifico e preciso. In questo senso, uno standard per un "pacchetto PEM" sarebbe contraddittorio: un "pacchetto PEM" è ciò che fai quando non c'è uno standard.

Non è errato definirlo uno "standard de facto".

Quando vuoi codificare e inviare certificati, ci sono in realtà più di due metodi; le possibilità includono:

• Codifica ogni certificato separatamente, usando la codifica DER ASN.1 (che è standard).
• Utilizzare PEM per rendere questi certificati più resilienti al trasferimento basato su ASCII; questo permette anche di archiviarne parecchi in un singolo file (quello che chiami "pacchetto PEM");
• Archivia i certificati in un oggetto PKCS # 7 (noto anche come CMS ) SignedData . Un SignedData è nominalmente un formato per incorporare i dati che sono firmati; ma puoi omettere i dati e includere esattamente la firma zero, nel qual caso hai una sorta di shell che include un campo per incorporare "certificati extra" (nominalmente, questi certificati sono lì per aiutare nella convalida delle firme). Questo è il riutilizzo di uno standard esistente per qualcosa che lo standard non avrebbe dovuto fare, ma il software esistente lo fa. Microsoft chiama "certificato PKCS # 7" o "file P7B".
• Usa un PKCS # 7% diSignedData ma anche PEM-encode (in modo che tu possa archiviare concettualmente molti di essi in un singolo file).
• PKCS # 12 (noto anche come "PFX"). Questo formato consente anche di archiviare altri tipi di oggetti e include disposizioni per la crittografia basata su password, quindi è comunemente usato per memorizzare un certificato e la sua chiave privata. (A quanto pare nessuno ha mai pensato alla codifica PEM di un archivio PKCS # 12.)

Anche le chiavi private hanno i loro formati. Ad esempio, PKCS # 1 definisce una codifica basata su ASN.1 per le chiavi private RSA, che OpenSSL utilizzerà goffamente e quindi Codifica PEM con intestazione "BEGIN RSA PRIVATE KEY". Tale formato può essere ulteriormente inserito in un oggetto PKCS # 8 , che include un identificatore basato su ASN.1 per l'algoritmo, e anche supporto opzionale della crittografia basata su password; e quindi , OpenSSL anche codificherà un file PKCS # 8, questa volta con "BEGIN PRIVATE KEY" o "BEGIN PRINCIPE PRIVATO KEY" (nessuna indicazione dell'algoritmo nel Intestazione PEM), a seconda che sia stata utilizzata o meno la crittografia basata su password. In alternativa, il formato raw PKCS # 1 può anche essere crittografato con password, utilizzando le estensioni a PEM che OpenSSL implementa ma non documenta (il codice sorgente di OpenSSL dovrebbe essere la specifica).

Per riassumere: è un casino.