¿Qué exige este criterio?
Los tokens deben cumplir el perfil EN 319 422, que restringe y extiende RFC 3161 para garantizar interoperabilidad. Campos obligatorios: version=1, policy (OID), messageImprint (algoritmo hash + hash del dato), serialNumber (único por token), genTime (tiempo en UTC), tsa (GeneralName del TSA). El token debe estar firmado con la clave de la TSU y la cadena de certificados debe estar embebida o accesible.

¿Qué hay que revisar al cliente?

• Tokens de muestra verificados con herramientas (OpenSSL ts -verify, DSS).
• Presencia de todos los campos obligatorios en el TSTInfo.
• SerialNumber único por token (no reutilizado).
• Formato de genTime en UTCTime o GeneralizedTime conforme RFC.
• Cadena de certificados embebida o referenciada accesiblemente.
• Compatibilidad con clientes estándar (herramientas de firma, Adobe, etc.).

Preguntas clave para las entrevistas

• ¿Se validan los tokens emitidos contra el perfil EN 319 422 en los tests automáticos?
• ¿El serialNumber de los tokens es garantizadamente único? ¿Cómo se gestiona?
• ¿Los tokens son compatibles con herramientas de verificación estándar (OpenSSL, eIDAS DSS)?
• ¿Hay algún cliente que haya reportado problemas de compatibilidad con los tokens?

¿Por qué es esencial para QERDS y TSA?
La conformidad de los tokens con EN 319 422 es lo que hace que el QERDS funcione correctamente: los tokens de la TSA se embeben en las evidencias QERDS. Si el formato del token tiene defectos, toda la cadena de evidencias del QERDS puede ser cuestionada en una verificación.

Evidencia que demostraría conformidad

• Tokens de muestra validados con OpenSSL o eIDAS DSS (captura o log).
• Test automático de conformidad de tokens con EN 319 422.
• Gestión del serialNumber único (base de datos o secuencia garantizada).