¿Qué exige este criterio?
El campo messageImprint del TSTInfo contiene el hash del dato a sellar junto con el identificador del algoritmo. Este algoritmo debe estar en la lista de algoritmos aceptados de TS 119 312: SHA-256, SHA-384, SHA-512, SHA3-256+. SHA-1 fue roto criptográficamente (SHAttered, 2017): colisiones prácticas demostradas. MD5 fue roto mucho antes. Ambos deben estar desactivados en el endpoint del TSA.

¿Qué hay que revisar al cliente?

• Configuración del TSA: lista de algoritmos de hash aceptados.
• Configuración de rechazo de algoritmos deprecados (SHA-1, MD5).
• Análisis de tokens de muestra: algoritmo presente en messageImprint.
• Tests automáticos de rechazo de peticiones con SHA-1.

Preguntas clave para las entrevistas

• ¿Está SHA-1 explícitamente desactivado en el endpoint del TSA?
• ¿Cuál es el algoritmo de hash por defecto del servicio?
• ¿Acepta el TSA SHA-256? ¿SHA-384? ¿SHA-512?
• ¿Hay un test que verifica el rechazo de peticiones con SHA-1?

¿Por qué es esencial para QERDS y TSA?
SHA-1 en un token TSA es una no-conformidad crítica que el CAB detectará inmediatamente. Con colisiones SHA-1 disponibles públicamente, un atacante podría falsificar el hash del documento sellado. Es el hallazgo más frecuente y más fácil de evitar en auditorías de TSA.

Evidencia que demostraría conformidad

• Configuración del TSA (lista de hash aceptados/rechazados).
• Prueba de rechazo de petición con SHA-1 (captura o log).
• Token de muestra con SHA-256 en messageImprint.