¿Qué exige este criterio?
El TSTInfo se encapsula en un CMS SignedData (RFC 5652). Para cumplir EN 319 422 el SignedData debe: (1) incluir la cadena de certificados completa del TSU hasta la CA raíz (campo certificates); (2) incluir la información de revocación (OCSP response o CRL) para validación a largo plazo; (3) usar el identificador de ContentType id-ct-TSTInfo; (4) incluir el atributo signingCertificateV2. La cadena completa permite la validación sin necesidad de resolver URLs.

¿Qué hay que revisar al cliente?

• SignedData con cadena de certificados completa (hasta CA raíz).
• Información de revocación incluida (OCSP o CRL).
• ContentType correcto (id-ct-TSTInfo).
• Atributo signingCertificateV2 presente.
• Verificación completa con eIDAS DSS o herramienta equivalente.

Preguntas clave para las entrevistas

• ¿El token incluye la cadena completa de certificados en el SignedData?
• ¿Se incluye información de revocación (OCSP stapled o CRL) en el token?
• ¿El token es verificable con eIDAS DSS sin resolver URLs externas?

¿Por qué es esencial para QERDS y TSA?
Incluir la cadena completa y la información de revocación en el token es fundamental para la verificación a largo plazo: cuando las URLs de los repositorios del TSP ya no estén disponibles (p. ej. tras el cese), el token debe poder verificarse de forma autónoma.

Evidencia que demostraría conformidad

• Token de muestra con cadena completa (análisis OpenSSL o eIDAS DSS).
• Verificación completa del token sin URLs externas.
• Especificación técnica del SignedData generado.