Resumen

  • PrivateKeyInfo de RFC 5208 y OneAsymmetricKey de RFC 5958 definen cómo transportar material privado. La forma sin cifrar no acredita confidencialidad, control de acceso, residencia en hardware ni borrado seguro.
  • Descifrar, validar, emparejar la clave pública, importar, autorizar, ejecutar y aceptar son comprobaciones distintas. El éxito del parser no puede sustituirlas.

La sintaxis no es una caja fuerte

PKCS #8 dio a implementaciones diferentes una envoltura común. RFC 5208 reúne una versión, el identificador del algoritmo, un OCTET STRING con la clave privada y atributos opcionales. El registro del algoritmo determina cómo interpretar el contenido interno.

El contrato termina ahí. Un objeto correcto no revela dónde se generó, si pasó por un archivo temporal, quién lo copió o qué sistema de copias de seguridad lo retuvo. El parser certifica una gramática; no reconstruye la custodia.

RFC 5958, sucesor Standards Track, cambia el nombre a OneAsymmetricKey, permite incluir una clave pública y define paquetes con una o más claves. También afirma que esos contenidos no están protegidos. Pueden envolverse en tipos CMS que firmen, autentiquen o cifren. La protección es otra capa y debe dejar otro recibo.

PRIVATE KEY no significa cifrado

RFC 7468 asigna PRIVATE KEY a la forma sin cifrar y ENCRYPTED PRIVATE KEY a EncryptedPrivateKeyInfo. Esta última estructura contiene un identificador del cifrado y los datos cifrados. Primero se codifica la información de clave; después se cifra el resultado.

Una operación responsable registra ambos momentos: parseo de la envoltura protegida y descifrado con parámetros concretos. Debe conservar KDF, sal, coste, algoritmo, comprobación de integridad, credencial utilizada y vida del texto claro. Importado no basta para saber cuándo terminó la protección.

RFC 8018 añade una advertencia práctica: las contraseñas suelen proceder de espacios reducidos, por lo que el procesamiento debe resistir búsquedas. Un OID no demuestra que la contraseña fuera fuerte, que el coste cumpliera la política ni que el operador limitara intentos.

El mismo objeto atraviesa autoridades distintas

Una clave PKCS #8 puede nacer en memoria, caer en disco, adjuntarse a una incidencia, cruzar un canal, entrar en un almacén software y acabar en un HSM. Su representación puede permanecer idéntica aunque cambien completamente el control y la exposición.

Por eso .p8, application/pkcs8 o una frontera PEM correcta no prueban residencia hardware. Un identificador de objeto HSM tampoco descarta copias previas, exportabilidad, una réplica menos protegida o permisos excesivos.

La cadena de custodia necesita huella de origen, transporte, identidad del importador, destino, política de exportación, réplicas, auditoría de uso y recibos de eliminación. Son hechos operativos, no campos que el ASN.1 pueda inventar.

La clave correcta para el algoritmo puede ser la equivocada para la cuenta

RFC 5958 admite una clave pública opcional y algunas estructuras específicas contienen componentes públicos. Eso facilita el intercambio, pero no acredita la asociación con el certificado o la identidad prevista. Hay que derivar o validar el público y compararlo con una referencia independiente.

RFC 8479 permite guardar parámetros necesarios para validar cierta generación RSA o DSA. Conservar los insumos mejora la posibilidad de revisar; no demuestra que un validador se ejecutó ni que aprobó el resultado.

Incluso después de la correspondencia queda la autorización. La política puede impedir el uso. Una firma puede producirse y aun así fracasar en la aplicación por el mensaje, el contexto, la hora, la cadena o la política de algoritmos. Cada frontera necesita un estado propio.

Citar RFC 5958 no actualiza las herramientas

RFC 5208 se publicó como Informational en 2008. RFC 5958 la sustituyó en 2010, añadió el campo público, reglas de versión y un tipo CMS, manteniendo compatibilidad. Esa compatibilidad permite que material con forma antigua siga circulando.

Un inventario que dice RFC 5958 no demuestra que exportadores, importadores, respaldos y recuperación entiendan lo mismo. La migración se prueba con bytes observados, vectores, casos negativos, tratamiento de versiones, viajes de ida y vuelta y restauraciones ensayadas. La referencia documental no reemplaza al código en ejecución.

Mantener cada recibo en su capa

Para cada movimiento registrar por separado: bytes y procedencia; decodificación textual; versión ASN.1 y parámetros; tipo claro o protegido; KDF y cifrado; descifrado e integridad; validación matemática; correspondencia pública; destino y exportabilidad; autorización; operación; verificación; aceptación de la aplicación; revocación y borrado.

PRIVATE KEY nombra la representación. Descifrar demuestra acceso al claro. Comparar el público demuestra correspondencia. Un evento HSM demuestra una operación en un límite. Verificar una firma demuestra un resultado para un mensaje. Ninguno tiene autoridad automática sobre el siguiente.

La decisión ejecutiva es preservar la especificación común mínima y hacer explícita la política local de custodia. El resultado verificable del sistema en funcionamiento es evidencia primaria; la procedencia explica cómo llegó la clave, sin fingir que ya produjo el efecto.

Fuentes

  1. Información RFC 5208
  2. RFC 5208 HTML
  3. RFC 5208 texto
  4. IETF Datatracker: RFC 5208
  5. Historial RFC 5208
  6. Referencias RFC 5208
  7. Erratas RFC 5208
  8. Información RFC 5958
  9. RFC 5958 HTML
  10. RFC 5958 texto
  11. IETF Datatracker: RFC 5958
  12. Historial RFC 5958
  13. Referencias RFC 5958
  14. Erratas RFC 5958
  15. RFC 8018 — criptografía basada en contraseñas
  16. RFC 8351 — tipo de medio EncryptedPrivateKeyInfo
  17. RFC 7468 — codificaciones textuales
  18. RFC 8479 — parámetros de validación en PKCS #8
  19. RFC 5915 — estructura de clave privada EC
  20. Heng Lu — capas de realidad y poder simbólico
  21. Heng Lu — especificación inicial mínima
  22. Heng Lu — primacía del código en ejecución