Resumen

  • RFC 9879 incorpora PBMAC1 a PKCS #12, fija PBKDF2/HMAC-SHA-256 como base interoperable y corrige la codificación de contraseña de RFC 9579.
  • Un lector antiguo puede llegar al material cifrado aunque no interprete el MAC nuevo, y ni una contraseña débil ni parámetros pobres mejoran por cambiar de identificador.
  • La migración debe probar por separado parámetros efectivos, resultado del MAC, conducta ante fallos y custodia posterior de la clave.

PKCS #12 sirve para mover certificados, claves y otros secretos entre máquinas y aplicaciones. En ese trayecto, «se importó» es una conclusión demasiado grande. El contenedor pudo parsearse; la parte cifrada pudo abrirse; el MAC pudo ser correcto; los parámetros pudieron superar la política local; la clave pudo quedar en el almacén previsto. Cada verbo requiere su propia evidencia.

RFC 9879 actúa sobre el tercero. Publicado en septiembre de 2025 como RFC informativo del IETF, deja obsoleto RFC 9579 y actualiza RFC 7292 y RFC 8018. Permite que id-PBMAC1 aparezca como algoritmo de integridad en DigestInfo. En ese caso, PBMAC1-params debe existir y ser coherente, y el valor del resumen debe resultar del cálculo sobre authSafe con esos parámetros.

El beneficio es una derivación extensible. El método histórico de PKCS #12 ligaba la clave MAC a una función propia del formato. PBMAC1 hace explícitos el KDF y el mecanismo de autenticación. Todo implementador debe admitir PBKDF2 junto con HMAC-SHA-256 para el control y para la función pseudoaleatoria de PBKDF2. Puede añadir otros HMAC de SHA-2, SHA-3 o KDF como scrypt.

Pero la flexibilidad reside en campos que hay que leer. La longitud derivada debe figurar expresamente. Si keyLength falta en los parámetros PBKDF2, el archivo no debe aceptarse; con HMAC-SHA-256, la salida debería medir 32 octetos. PBKDF2 con HMAC-SHA-1 no es recomendable, y otros resúmenes de 160 bits o menos están prohibidos.

Además, los antiguos macSalt e iterations exteriores dejan de gobernar cuando se selecciona PBMAC1. Deben ignorarse, aunque RFC 9879 recomienda conservar un valor no vacío y positivo para no sorprender a lectores anteriores. Un escáner que muestra esa iteración exterior, sin abrir los parámetros de PBMAC1, puede certificar un coste que nunca participó en la derivación.

La compatibilidad tampoco equivale a validación. La sintaxis se diseñó para que una aplicación heredada aún pueda descifrar el material de clave si no interpreta la nueva protección, siempre que sea capaz de ignorar el fallo de verificación MAC. Es un puente útil para no romper todos los consumidores a la vez. También significa que la capacidad de abrir el contenido no prueba que el lector haya aceptado su integridad. La especificación no atribuye esa conducta a ningún producto concreto.

La corrección de codificación enseña otra frontera. RFC 9579 pedía convertir la contraseña a BMPString con terminador NULL. El erratum 7974, verificado, explica que el programa usado para crear los vectores mantuvo en realidad UTF-8. RFC 9879 establece ahora UTF-8 sin NULL final ni BOM. Para reproducir un resultado no basta con conocer los caracteres: hay que saber qué octetos llegaron al KDF.

Los vectores de prueba incluyen casos válidos con combinaciones SHA-256 y SHA-512 y casos inválidos por iteración, sal o longitud ausente. Pasarlos confirma una operación concreta. No mide la entropía de la contraseña, la cobertura del despliegue, la conducta frente a un algoritmo desconocido ni el lugar donde terminó la clave privada.

La propia RFC advierte que una KDF puede admitir salidas de un solo octeto. Como los parámetros KDF no están protegidos criptográficamente, una longitud mínima facilita probar claves HMAC por fuerza bruta. Se recomienda rechazar longitudes inferiores a 20 octetos y se permite negar otros parámetros débiles. Ese «puede rechazar» exige un responsable local; no describe un comportamiento universal.

PKCS #5 completa el límite: la criptografía basada en contraseña permite búsqueda fuera de línea. La sal y las iteraciones elevan el precio de cada intento, pero no mejoran una contraseña predecible. Scrypt busca añadir coste de memoria frente al paralelismo especializado; RFC 9879 solo lo permite. Por eso dos archivos PBMAC1 pueden tener posturas de riesgo muy distintas.

El expediente correcto registra el orden completo: recepción, versión del productor y lector, OID, parámetros efectivos, decisión de política, codificación exacta, resultado MAC, descifrado independiente, permiso de uso, almacén de destino y perfil de una eventual reexportación. Si falta una etapa, la siguiente no debe rellenarla por inferencia.

Fuentes