Resumen

  • RFC 9688 asigna reglas distintas a roles distintos: ausencia para digest, ECDSA, HMAC y HKDF; NULL obligatorio para RSA PKCS#1 v1.5 con SHA3; ausencia o Customization exacta para KMAC.
  • Reconocer el OID o validar una firma no demuestra que el receptor haya preservado la codificación, ejecutado la rama prevista, aplicado la política correcta ni obtenido el resultado de negocio esperado.

Pensemos en dos copias de un mismo mensaje. La primera conserva los bytes recibidos. La segunda es el resultado de decodificar y volver a codificar con una biblioteca nueva. Ambas pantallas muestran RSA con SHA3-256. Sin embargo, la segunda ha eliminado el NULL del identificador de firma. El nombre no cambió; el contrato sí.

No se afirma que un producto concreto haga esto. El escenario delimita la evidencia. Un OID nombra un algoritmo, pero no demuestra por sí solo el campo CMS, la forma de parámetros, el identificador interior, los bytes de entrada, la clave usada, la ruta de implementación ni la autorización posterior.

La presencia también es un valor

Los cuatro digest SHA3 definidos por RFC 9688 deben llevar parámetros ausentes. La regla se aplica allí donde CMS coloca identificadores de digest. Ausente no es un sinónimo de NULL.

ECDSA con SHA3 conserva esa ausencia. HMAC con SHA3 también. Los cuatro identificadores HKDF con SHA3 hacen lo mismo. Por ello, una rutina que inserta NULL en todo AlgorithmIdentifier no está completando información: está cambiando una rama cuyo estado correcto era la ausencia.

RSA PKCS#1 v1.5 con SHA3 exige lo contrario. Los identificadores pertinentes deben contener NULL. Una normalización que borra todos los valores nulos daña precisamente el camino que pretendía simplificar.

KMAC introduce un interruptor semántico. Sin etiqueta S, los parámetros deben faltar. Si el originador proporciona S, el campo debe existir y contener esa personalización como OCTET STRING. Un campo ausente y una cadena vacía presente tienen distinta procedencia y no deben colapsarse sin registro.

Esta matriz es una especificación mínima común: pequeña, determinista y suficiente para que dos implementaciones hablen del mismo objeto. La política local puede decidir si permite RSA, ECDSA, HMAC o una KDF. No puede alterar los bytes recibidos y seguir llamándolos originales.

KMAC necesita contexto, longitud y personalización

KMAC128-KDF y KMAC256-KDF consumen K, X, L y S. La clave K puede proceder de una decapsulación KEM. X incorpora el contexto y, con RFC 9629, la codificación DER de CMSORIforKEMOtherInfo. L fija la longitud de salida. S separa usos mediante personalización.

Registrar solo id-kmac128 deja fuera entradas que cambian cada bit derivado. Incluso registrar los parámetros no basta si faltan X y L. Dos implementaciones pueden anunciar el mismo algoritmo y no compartir la misma construcción de contexto.

KDF2 y KDF3 contienen un AlgorithmIdentifier de digest dentro de sus parámetros. Cuando ese identificador selecciona SHA3, también debe omitir parámetros. La conformidad exterior no subsana una representación interior equivocada.

El recibo debe sobrevivir al parser

Muchos decodificadores aceptan más de una representación y las reducen a una estructura única. Si se descartan los bytes de entrada, ya no se puede distinguir entre tolerancia de lectura y conformidad del emisor. Si después se reserializa, una copia normalizada puede adquirir una falsa apariencia de originalidad.

La cadena mínima registra: hash de bytes recibidos; ruta de campo; OID; estado y hash de parámetros; identificadores anidados; versión del parser; transformación realizada; proveedor criptográfico; referencia de clave; operación y resultado; decisión de certificado y política; autorización; resultado de aplicación.

Una firma válida es importante, pero acotada. No establece por sí sola la vigencia de la cadena de certificados, la autoridad del firmante, la frescura, el significado del contenido ni la ejecución del acto solicitado.

IANA coordina nombres, no despliegues

Los identificadores asignados por IANA permiten que implementaciones independientes se refieran al mismo mecanismo. No son una certificación de producto ni una encuesta de código instalado. La prueba operacional vive en vectores, capturas, diferencias de parser y resultados reproducibles.

Separar el registro del código ejecutado protege ambas funciones. El registro conserva unicidad. La evidencia de ejecución conserva realidad. El error aparece cuando una entrada simbólica se promociona a resultado operacional.

Fuentes