Resumen

  • En PBMAC1, el DigestAlgorithmIdentifier de MacData identifica el esquema y contiene el KDF y el MAC anidados.
  • PBKDF2 con HMAC-SHA-256, keyLength explícito y bytes de contraseña UTF-8 directos forman la referencia interoperable.
  • RFC 9879 fija sintaxis y validaciones, pero no demuestra soporte universal, seguridad de una contraseña ni certificación de un producto.

El límite de integridad del PFX es el MAC sobre el contenido de authSafe. PBMAC1 incluye por separado la función de derivación basada en contraseña y el esquema de autenticación del mensaje dentro de los parámetros del DigestAlgorithmIdentifier de MacData. El lector debe analizar y validar ambas decisiones, no inferirlas de los campos antiguos.

Los campos macSalt e iterations de MacData pertenecen a la forma heredada. Para PBMAC1 se ignoran, aunque RFC 9879 recomienda que los productores codifiquen valores no vacíos y distintos de cero para atravesar lectores antiguos que comprueban primero la estructura tradicional. No deben convertirse en entradas activas del PBMAC1. Si un lector los usa como sal o iteraciones, la interoperabilidad desaparece.

La implementación obligatoria debe admitir PBKDF2 con HMAC-SHA-256. Los parámetros PBKDF2 deben incluir keyLength de manera explícita; si falta, el lector debe rechazar el uso definido por RFC 9879 y no completar el valor por cuenta propia. La contraseña se transforma directamente en bytes UTF-8, sin terminador nulo ni marca de orden de bytes. No es la representación histórica de contraseñas de PKCS #12, y mezclar ambas reglas causa discrepancias.

KDF y MAC son decisiones independientes. Hay que validar sus identificadores, parámetros y tamaños. HMAC-SHA-1 se desaconseja, y no se permiten algoritmos cuyo resultado tenga 160 bits o menos para PBMAC1. También se recomienda rechazar claves derivadas de menos de 20 octetos. Esto no vuelve segura una contraseña débil ni aporta confidencialidad: aquí se analiza protección de integridad.

scrypt puede admitirse, pero es opcional. Su presencia no autoriza a aceptar cualquier coste. El lector debe comprobar memoria, trabajo, paralelismo y límites locales antes de iniciar una derivación cara. Las RFC no fijan un coste suficiente para todas las amenazas y tampoco prueban que las implementaciones existentes de PKCS #12 soporten PBMAC1.

La decisión práctica es migrar productor y lector juntos. El productor debe generar parámetros PBMAC1 anidados, keyLength explícito, UTF-8 directo y algoritmos aceptables. Puede conservar campos heredados no vacíos como ayuda de compatibilidad, nunca como entradas de seguridad. El lector debe validar lo anidado, rechazar omisiones y opciones débiles y acotar el consumo. La aceptación de legado debe tener alcance, registro y fecha de salida definidos.

Fuentes