¿Qué exige este criterio?
EN 319 422 §5 define restricciones al formato de petición RFC 3161: (1) el campo hashAlgorithm debe contener un algoritmo aceptado por TS 119 312; (2) el campo reqPolicy (si está presente) debe contener el OID de una política publicada por el TSP; (3) el campo nonce (si está presente) debe ser un entero no predecible; (4) el campo certReq debe estar a true para que el token incluya la cadena de certificados. El TSA debe rechazar peticiones que no cumplan el perfil.

¿Qué hay que revisar al cliente?

• Documentación del endpoint: ¿describe los campos aceptados y sus restricciones?
• Comportamiento del TSA ante peticiones fuera del perfil: ¿las rechaza con error adecuado?
• Registro de peticiones rechazadas por formato incorrecto.
• Ejemplos de peticiones válidas para verificar el perfil con openssl.

Preguntas clave para las entrevistas

• ¿El TSA rechaza peticiones con algoritmos de hash deprecados (SHA-1, MD5)?
• ¿Está documentado el comportamiento del endpoint ante peticiones fuera de perfil?
• ¿Se pueden generar peticiones de prueba con OpenSSL para verificar el funcionamiento?

¿Por qué es esencial para QERDS y TSA?
Si el TSA acepta peticiones fuera del perfil (p. ej. con SHA-1), puede emitir tokens técnicamente inválidos que comprometan la cualificación. El perfil de petición es la primera barrera de seguridad del servicio TSA.

Evidencia que demostraría conformidad

• Documentación del endpoint con campos aceptados y restricciones.
• Prueba de rechazo de petición con SHA-1 (log o captura).
• Ejemplo de petición válida verificada con OpenSSL.