¿Qué exige este criterio?
El endpoint HTTP del TSA debe: (1) aceptar POST con Content-Type application/timestamp-query; (2) devolver 200 OK con Content-Type application/timestamp-reply; (3) ser accesible por HTTPS con TLS 1.2+ y suites conformes ENISA; (4) estar documentado en el TSPS con su URL; (5) estar incluido en la extensión AccessDescription del certificado TSU.

¿Qué hay que revisar al cliente?

• URL del endpoint publicada en el TSPS.
• Content-Type de request y response conformes RFC 3161.
• TLS configurado (versión, suites de cifrado).
• Referencia al endpoint en la extensión del certificado TSU.
• Prueba funcional: request de sello y respuesta correcta.

Preguntas clave para las entrevistas

• ¿Cuál es la URL del endpoint TSA? ¿Está publicado en el TSPS?
• ¿Está el endpoint en la extensión AccessDescription del certificado TSU?
• ¿El endpoint requiere autenticación o es accesible públicamente?
• ¿Se ha realizado una prueba funcional con OpenSSL ts -query/-verify?

¿Por qué es esencial para QERDS y TSA?
Un endpoint no documentado o no estándar impide que los clientes integren la TSA automáticamente. Muchas herramientas de firma buscan el endpoint en el certificado TSU. Si no está ahí, la integración falla.

Evidencia que demostraría conformidad

• URL del endpoint en el TSPS.
• Prueba funcional con OpenSSL (request + response exitosos, captura).
• Configuración TLS del endpoint.