Para almacenamiento de claves privadas , encontrará principalmente:
-
Lo que OpenSSL hace. En realidad, es el formato ASN.1 especificado al final de PKCS # 1 (escriba RSAPrivateKey
) . Cuando ese objeto está codificado en Base64 en formato PEM, el encabezado será: -----BEGIN RSA PRIVATE KEY-----
. El formato sin procesar (binario) es "tal como está", pero PEM incluye opciones para el cifrado simétrico (con una clave o una contraseña). Este formato PEM no está realmente estandarizado o documentado; es "lo que hace OpenSSL".
-
PKCS # 8 . Para una clave RSA, será una envoltura alrededor del formato ASN.1 de PKCS # 1, con una especificación explícita del tipo de clave (es decir, "esto es RSA"). PKCS # 8 también incluye opciones para el cifrado simétrico. OpenSSL también admite PKCS # 8 y puede codificarlo en PEM, esta vez con el encabezado: -----BEGIN PRIVATE KEY-----
(note la diferencia con el caso anterior: el tipo de clave ya no se especifica en el encabezado PEM, ya que la estructura ASN.1 contiene esa información). Si bien un archivo PKCS # 8 que está codificado con PEM podría contener cifrado de nivel PEM, esto rara vez se hace, ya que PKCS # 8 también puede hacerlo internamente. PKCS # 8 se beneficia del soporte en muchos marcos, por ejemplo. Java conoce ese formato de forma nativa.
-
PKCS # 12 , también conocido como "PFX". De hecho, este es un formato de archivo genérico que cuenta con controles opcionales de encriptación e integridad, y se puede usar para juntar una (o varias) claves privadas y los certificados X.509 correspondientes. Si almacena claves públicas en certificados, entonces querrá usar ese formato ya que muchos sistemas lo conocen de forma nativa (Windows y MacOS X pueden leerlo directamente, por ejemplo).
-
El formato OpenPGP . Esto es lo que se utilizará en la mayoría de los "llaveros" manejados por GnuPG . No se basa en ASN.1. Si tiene que volver a implementarlo usted mismo, entonces es algo más sencillo de administrar que PKCS # 8. Este formato rara vez se conoce de forma nativa por los marcos de programación existentes, pero hay bibliotecas de código abierto listas para usar (por ejemplo, GnuPG o Bouncy Castle ).
-
Lo que OpenSSH admite. SSH ha usado durante mucho tiempo sus propios formatos, pero para las claves privadas, OpenSSH puede alimentar los formatos OpenSSL (tanto los específicos de OpenSSL como los PKCS # 8).
Para claves públicas , hay algunos cambios:
-
En los mundos OpenSSL y X.509, las claves públicas no existen "como ellas mismas" sino solo como parte de los certificados X.509. Es posible que desee almacenar su clave pública en una estructura de certificado, que podría ser (por tradición) autofirmada, ya que hay un campo de "firma" en el formato de certificado X.509. La parte de un certificado que contiene la clave pública se llama SubjectPublicKeyInfo
(búsquelo en el estándar ) y es una envoltura alrededor de un formato específico de algoritmo, que nos lleva de nuevo a PKCS # 1. Las estructuras SubjectPublicKeyInfo
codificadas en DER se ven ocasionalmente en aplicaciones del mundo real, pero son bastante raras.
-
OpenPGP tiene sus propios formatos para claves públicas.
-
OpenSSH tiene sus propios formatos para claves públicas. Cuidado con el plural: hay varios. Comience aquí para obtener descripciones.
Para la interoperabilidad e integración , diría que es un empate entre X.509 + PKCS # 8 (con posible uso de PKCS # 12) y OpenPGP. Personalmente, usaría el primero, pero eso es sobre todo por costumbre.