Hasta ahora no encontré una especificación (RFC o similar) para el formato de archivo que usa el prefijo BEGIN RSA PRIVATE KEY y el sufijo END RSA PRIVATE KEY. ¿Dónde está definido? ¿Tiene un nombre oficial? Parece estar al menos relacionado con la serie de RFC de PEM.
Estoy buscando información de referencia sobre los detalles del manejo de espacios en blanco, detalles base64 , unión de diferentes claves en un archivo, etc.
Esta pregunta NO es sobre la codificación ASN de la carga útil.
Comentarios
- La especificación OpenPGP describe formatos ASCII-Armor similares.
- tls.mbed.org/kb/cryptography/asn1-key-structures-in- der-and-pem
- La mayoría de los formatos PEM (también distintos de la clave privada RSA) están documentados en RFC 7468: Codificaciones textuales de Estructuras PKIX, PKCS y CMS . Hay, por ejemplo, alguna orientación sobre el tema del manejo de espacios en blanco. Ese RFC básicamente señala que los detalles varían según el analizador.
- Gracias a user4982: Este es el tipo de fuente que estoy buscando. Sin embargo, RFC 7468 contiene información sobre la etiqueta » LLAVE PRIVADA CIFRADA «, pero no ‘ t para » RSA PRIVATE KEY «.
- PEM se define en RFC 1421 que describe el formato general del encabezado, etc. Pero no pude ‘ t encontrar sobre el » CLAVE PRIVADA RSA «. Este artículo de 1997 ya menciona que OpenSSL lo usa.
Respuesta
Estoy aquí, porque, me hago la misma pregunta que el OP.
PKCS # 1 (RFC 3447) define la estructura ASN.1: RSAPrivateKey, permitiendo la expresión de una clave privada RSA solamente.
PKCS # 8 (RFC 5208) define la estructura ASN.1: PrivateKeyInfo, permitiendo la expresión de cualquier clave privada. (Para una clave privada RSA, PrivateKeyInfo es cierta información de empaquetado y una reutilización de RSAPrivateKey de PKCS # 1).
PEM (Correo mejorado con privacidad), es un método obsoleto para correo electrónico seguro. Pero, su formato de contenedor se tomó prestado para empaquetar elementos criptográficos.
RFC 7468 (Introducción): « Por razones que básicamente se reducen a la falta de coordinación o falta de atención, muchas bibliotecas PKIX, PKCS y CMS implementar una codificación basada en texto que sea similar, pero no idéntica a, la codificación PEM . «
Lo que se lee como: Um, la gente ha decidido usar bits de PEM para empaquetar sus archivos criptográficos . Aquí tenemos un gran esfuerzo para tratar de formalizar eso …
Por desgracia, RFC 7468 aclara el paquete PKCS # 8 / PrivateKeyInfo como «BEGIN PRIVATE KEY». Pero no el paquete de PKCS # 1 / RSAPrivateKey como «BEGIN RSA PRIVATE KEY».
El paquete «BEGIN RSA PRIVATE KEY» a veces se denomina: «formato SSLeay» o «formato tradicional» para la clave privada. Lo que, al menos, nos da un nombre para este formato, pero, como usted, no puedo encontrar, y agradecería, algo que se acerque a una descripción formal de este formato. Sospecho que esto no existe.
Comentarios
-
I'm here, because, I'm asking myself the same question as the OP.– – Para aclarar: ¿es esta su respuesta a la pregunta anterior o en realidad se está haciendo la misma pregunta?
Responder
El formato del contenido base64 dentro:
-----BEGIN RSA PRIVATE KEY----- ...base64 encoded DER ASN.1 RSAPrivateKey... -----END RSA PRIVATE KEY----- está documentado en RFC3447 – Apéndice A.1.2 – Sintaxis de clave privada RSA :
RSAPrivateKey ::= SEQUENCE { version Version, modulus INTEGER, -- n publicExponent INTEGER, -- e privateExponent INTEGER, -- d prime1 INTEGER, -- p prime2 INTEGER, -- q exponent1 INTEGER, -- d mod (p-1) exponent2 INTEGER, -- d mod (q-1) coefficient INTEGER, -- (inverse of q) mod p otherPrimeInfos OtherPrimeInfos OPTIONAL } Ya sabes cómo codificar eso usando DER sabor de ASN.1; y la pregunta es sobre cómo escribir esos datos binarios DER en un archivo.
El siguiente paso está documentado en RFC 1421 – 4.3.2.4 Paso 4 : Codificación imprimible
- documentan la codificación de los datos binarios en base64
- codifican la salida como líneas de texto
- con cada línea ( excepto el último) que contiene exactamente 64 caracteres imprimibles
- y la línea final contiene 64 o menos caracteres imprimibles
Luego está el «Límite de encapsulación» (EB), utilizado para delimitar mensajes PEM encapsulados.
- la cadena pre-EB es:
-----BEGIN PRIVACY-ENHANCED MESSAGE----- - la cadena post-EB es:
-----END PRIVACY-ENHANCED MESSAGE-----
Fue el correo de privacidad mejorado que usó:
- cinco guiones (
-----) -
BEGINsomething - cinco guiones (
-----)
seguidos de
- cinco guiones (
-----) -
ENDsomething - cinco guiones (
-----)
Esas convenciones de PEM se transfirieron para la clave pública, la clave privada y los certificados, pero con redacción modificada:
-----BEGIN RSA PUBLIC KEY----- ...base64 encoded DER ASN.1 RSAPublicKey... -----END RSA PUBLIC KEY-----
-----BEGIN RSA PRIVATE KEY----- ...base64 encoded DER ASN.1 RSAPrivateKey... -----END RSA PRIVATE KEY-----
-----BEGIN PUBLIC KEY----- ...base64 encoded DER ASN.1 SubjectPublicKeyInfo... -----END PUBLIC KEY-----
-----BEGIN PRIVATE KEY----- ...base64 encoded DER ASN.1 PrivateKeyInfo... -----END PUBLIC KEY-----
-----BEGIN CERTIFICATE----- ...base64 encoded DER ASNl.1 Certificate... -----END CERTIFICATE----- Responder
Sí. RFC7468 – Codificaciones textuales de estructuras PKIX, PKCS y CMS
Este documento articula las reglas de facto por las que operan las implementaciones existentes y las define para que las implementaciones futuras puedan interoperar.
Aquí «un extracto relevante:
10. Una clave asimétrica y la codificación textual de PKCS # 8 Información de clave privada
Las estructuras de sintaxis de información de clave privada PKCS # 8 no cifradas (PrivateKeyInfo), renombradas como paquetes de claves asimétricas (OneAsymmetricKey), se codifican mediante la etiqueta «CLAVE PRIVADA». Los datos codificados DEBEN ser una BER ( DER preferido; consulte el Apéndice B) estructura ASN.1 PrivateKeyInfo codificada como se describe en PKCS # 8 [RFC5208], o una estructura OneAsymmetricKey como se describe en [RFC5958]. Las dos son semánticamente idénticas y se pueden distinguir por el número de versión.
-----BEGIN PRIVATE KEY----- MIGEAgEAMBAGByqGSM49AgEGBSuBBAAKBG0wawIBAQQgVcB/UNPxalR9zDYAjQIf jojUDiQuGnSJrFEEzZPT/92hRANCAASc7UJtgnF/abqWM60T3XNJEzBv5ez9TdwK H0M6xpM2q+53wmsN/eYLdgtjgBd3DBmHtPilCkiFICXyaA8z9LkJ -----END PRIVATE KEY----- Comentarios
- Estoy preguntando acerca de » LLAVE PRIVADA RSA «, no sobre » SOLICITUD DE CERTIFICADO «. Por cierto, esperaría PKCS # 8 o PKCS # 1, no PKCS # 10. El capítulo 10 estaría más cerca. Pero no ‘ t especifica RSA en la etiqueta, por lo que tiene sentido usar PKCS # 8 aquí. Como el algoritmo de clave se especificaría de forma redundante, podría estar bien (y vi ejemplos) poner PKCS # 1 en una » RSA PRIVATE KEY » archivo.
- @Como ya dije, estoy buscando » RSA PRIVATE KEY «, no para » CLAVE PRIVADA «. Por lo tanto, incluso el capítulo 10 no es aplicable y RFC7468 es una respuesta incorrecta.
- @Gustave Yo ‘ sé que escribió » RSA PRIVATE KEY «, sin embargo, especificar el formato de la clave privada en el encabezado no es necesario y la especificación es relevante.
- El ABNF dice < < textualmsg = preeb * WSP (…) > > y < < preeb = » —- -BEGIN » etiqueta » —– » (…) > >. Entonces, ¿por qué crees que el encabezado es innecesario?
- PKCS # 1 ( tools.ietf.org/html/rfc8017#appendix-A.1.2 ) no ‘ t especifica ninguna codificación ASCII base64, y tampoco ‘ t especifica el
-----BEGIN RSA PRIVATE KEY-----encabezado. PKCS # 8 tampoco ‘ t especifica ninguna codificación ASCII base64. El capítulo 10 de hecho especifica-----BEGIN PRIVATE KEY-----. ¿Tiene un enlace a un estándar que especifica el encabezado-----BEGIN RSA PRIVATE KEY-----?