No hay un estándar real para cosas en formato "PEM". Hubo un estándar propuesto llamado Correo electrónico con privacidad , desde el cual el "PEM se derivó el acrónimo; sin embargo, ese estándar nunca ganó fuerza contra su competencia (PGP y S / MIME) y nadie lo implementa.

OpenSSL seleccionó PEM y "mejoró" el formato de PEM con funcionalidades y encabezados adicionales, sin ninguna especificación o documentación real digna de ese nombre , de modo que hoy en día, "PEM" realmente significa "lo que OpenSSL produce y puede analizar". Otros proveedores siguieron, por ejemplo, Microsoft, cuyo software puede decodificar certificados codificados PEM.

El principio de PEM (datos codificados en Base64, con un encabezado '----- BEGIN XXX -----' y el correspondiente '----- END XXX --- - 'trailer' ha sido utilizado para otras cosas; PGP lo llama "armadura ASCII". El punto de esta forma de hacer las cosas es poder ubicar los datos interesantes dentro de una secuencia de datos de texto, independientemente de las diversas torturas infligidas a ese texto a medida que se transfiere (por ejemplo, se envía como correo electrónico, copia y pegado, incluido). En un documento de Word, impreso y escaneado ...). Este es un punto importante: significa que el punto entero de PEM es poder almacenar los certificados de forma conjunta y aleatoria sin tener que seguir un estándar específico y preciso. En ese sentido, un estándar para un "paquete PEM" sería una autocontradicción: un "paquete PEM" es lo que haces cuando no hay un estándar.

No es incorrecto llamarlo un "estándar de facto".

Cuando desea codificar y enviar certificados, de hecho hay más de dos métodos; las posibilidades incluyen:

• Codifique cada certificado por separado, utilizando la codificación ASN.1 DER (que es estándar).
• Use PEM para hacer que estos certificados sean más resistentes a la transferencia basada en ASCII; esto también permite almacenar varios de ellos en un solo archivo (lo que usted llama un "paquete PEM");
• Almacene los certificados en un PKCS # 7 (también conocido como CMS ) SignedData object. Un SignedData es nominalmente un formato para incrustar datos que están firmados; pero puede omitir los datos e incluir exactamente la firma cero, en cuyo caso tiene algún tipo de shell que incluye un campo para insertar "certificados adicionales" (nominalmente, estos certificados están ahí para ayudar a validar las firmas). Esta es la reutilización de un estándar existente para algo que el estándar no estaba destinado a hacer, pero el software existente hace eso. Microsoft llama a eso un "certificado PKCS # 7" o un "archivo P7B".
• Use un PKCS # 7 SignedData pero también codifíquelo con PEM (para que conceptualmente pueda almacenar varios de ellos en un solo archivo).
• PKCS # 12 (también conocido como "PFX"). Este formato también permite almacenar otro tipo de objetos e incluye disposiciones para el cifrado basado en contraseñas, por lo que se suele utilizar para almacenar un certificado y su clave privada. (Al parecer, nadie pensó nunca en codificar PEM en un archivo PKCS # 12).

Las claves privadas también tienen sus propios formatos. Por ejemplo, PKCS # 1 define una codificación basada en ASN.1 para claves privadas RSA, que OpenSSL usará alegremente y luego Codifique PEM con un encabezado "BEGIN RSA PRIVATE KEY". Ese formato puede incluirse en un objeto PKCS # 8 , que incluye un identificador basado en ASN.1 para el algoritmo, y también soporte opcional de cifrado basado en contraseña; y luego , OpenSSL también codificará un archivo PKCS # 8, esta vez con "BEGIN PRIVATE KEY" o "BEGIN ENCRYPTED PRIVATE KEY" (no hay indicación del algoritmo en el Encabezado PEM), dependiendo de si se usó o no el cifrado basado en contraseña. Alternativamente, el formato PKCS # 1 sin procesar también puede estar cifrado con una contraseña, utilizando las extensiones a PEM que OpenSSL implementa pero no documenta (se supone que el código fuente de OpenSSL es la especificación).

Para resumir: es un desastre.