Gap analysis
Cargando…
Cargando…
CTO + Operaciones · 62 de 62 controles esperados
| Control | Norma | Requisito | Aplicab. | Estado | Severidad | Owner | WP |
|---|---|---|---|---|---|---|---|
| EN 319 421 §5.1 OVR-5.1-01 | 421-qtsa-policy | El TSA puede definir su propia política que mejore la BTSP definida en el documento. | Recomendada | TBD | TBD | — | — |
| EN 319 421 §5.1 OVR-5.1-02 | 421-qtsa-policy | [CONDITIONAL] Si el TSA define política propia, ésta debe incorporar o restringir más los requisitos de la BTSP. | Obligatoria | TBD | TBD | — | — |
| EN 319 421 §5.1 OVR-5.1-03 | 421-qtsa-policy | [CONDITIONAL] Si la exactitud declarada es mejor de 1 segundo, debe indicarse en el TSA disclosure statement y en cada sello emitido con esa exactitud. | Obligatoria | TBD | TBD | — | — |
| EN 319 421 §5.2 OVR-5.2-01 | 421-qtsa-policy | Incluir el identificador (OID) de las políticas soportadas en el TSA disclosure statement disponible para suscriptores y RP. | Obligatoria | TBD | TBD | — | — |
| EN 319 421 §5.2 OVR-5.2-01A | 421-qtsa-policy | Soportar e incluir el identificador BTSP en la política de tiempo y en el disclosure statement como prueba de conformidad. | Obligatoria | TBD | TBD | — | — |
| EN 319 421 §5.2 OVR-5.2-02 | 421-qtsa-policy | [CONDITIONAL] Si se usan identificadores adicionales/propios, indicar todos ellos junto con el OID BTSP en la política y disclosure statement. | Obligatoria | TBD | TBD | — | — |
| EN 319 421 §5.3.1 OVR-5.3-01 | 421-qtsa-policy | La BTSP puede usarse para servicios públicos o dentro de comunidades cerradas. | Recomendada | TBD | TBD | — | — |
| EN 319 421 §7.7.1 TIS-7.7.1-01 | 421-qtsa-policy | Los sellos deben conformar al perfil definido en ETSI EN 319 422. | Obligatoria | TBD | TBD | — | — |
| EN 319 421 §7.7.1 TIS-7.7.1-02 | 421-qtsa-policy | Los sellos deben ser emitidos de manera segura. | Obligatoria | TBD | TBD | — | — |
| EN 319 421 §7.7.1 TIS-7.7.1-03 | 421-qtsa-policy | Los sellos deben incluir el tiempo correcto. | Obligatoria | TBD | TBD | — | — |
| EN 319 421 §7.7.1 TIS-7.7.1-04 | 421-qtsa-policy | El tiempo del TSU debe ser trazable a al menos un valor de tiempo real distribuido por un laboratorio UTC(k). | Obligatoria | TBD | TBD | — | — |
| EN 319 421 §7.7.1 TIS-7.7.1-05 | 421-qtsa-policy | El tiempo en el sello debe estar sincronizado con UTC (ITU-R TF.460-6) dentro de la exactitud definida en la política. | Obligatoria | TBD | TBD | — | — |
| EN 319 421 §7.7.1 TIS-7.7.1-06 | 421-qtsa-policy | [CONDITIONAL] Si la exactitud se incluye en el sello, el tiempo debe estar sincronizado dentro de esa exactitud. | Obligatoria | TBD | TBD | — | — |
| EN 319 421 §7.7.1 TIS-7.7.1-07 | 421-qtsa-policy | [CONDITIONAL] Si se detecta que el reloj está fuera de la exactitud declarada, no se deben emitir sellos. | Obligatoria | TBD | TBD | — | — |
| EN 319 421 §7.7.1 TIS-7.7.1-08 | 421-qtsa-policy | El sello debe firmarse con una clave generada exclusivamente para ese propósito. | Obligatoria | TBD | TBD | — | — |
| EN 319 421 §7.7.1 TIS-7.7.1-09 | 421-qtsa-policy | El sistema de generación de sellos debe rechazar cualquier intento de emisión cuando se ha alcanzado la fecha de expiración de la clave privada del TSU. | Obligatoria | TBD | TBD | — | — |
| EN 319 421 §7.7.2 TIS-7.7.2-01 | 421-qtsa-policy | El reloj del TSU debe sincronizarse con UTC dentro de la exactitud declarada según los requisitos siguientes. | Obligatoria | TBD | TBD | — | — |
| EN 319 421 §7.7.2 TIS-7.7.2-02 | 421-qtsa-policy | Calibrar los relojes del TSU para que no deriven fuera de la exactitud declarada. | Obligatoria | TBD | TBD | — | — |
| EN 319 421 §7.7.2 TIS-7.7.2-03 | 421-qtsa-policy | La exactitud declarada debe ser de 1 segundo o mejor. | Obligatoria | TBD | TBD | — | — |
| EN 319 421 §7.7.2 TIS-7.7.2-04 | 421-qtsa-policy | Proteger el reloj del TSU frente a amenazas que puedan provocar cambios no detectados (manipulación, descargas eléctricas, RF). | Obligatoria | TBD | TBD | — | — |
| EN 319 421 §7.7.2 TIS-7.7.2-05 | 421-qtsa-policy | El TSA debe detectar derivas o saltos del reloj del TSU fuera de sincronización con UTC. | Obligatoria | TBD | TBD | — | — |
| EN 319 421 §7.7.2 TIS-7.7.2-06 | 421-qtsa-policy | [CONDITIONAL] Si se detecta deriva o salto fuera de sincronía con UTC, el TSU debe detener la emisión de sellos. | Obligatoria | TBD | TBD | — | — |
| EN 319 421 §7.7.2 TIS-7.7.2-07 | 421-qtsa-policy | Mantener la sincronización cuando ocurra un segundo intercalar (leap second) notificado. | Obligatoria | TBD | TBD | — | — |
| EN 319 421 §7.7.2 TIS-7.7.2-08 | 421-qtsa-policy | El cambio para reflejar el leap second debe ocurrir en el último minuto del día programado. | Obligatoria | TBD | TBD | — | — |
| EN 319 421 §7.7.2 TIS-7.7.2-09 | 421-qtsa-policy | Mantener registro del momento exacto (dentro de la exactitud declarada) en que ocurrió el cambio referido en TIS-7.7.2-08. | Obligatoria | TBD | TBD | — | — |
| EN 319 421 §8.1 TIS-8.1-01 | 421-qtsa-policy | [CONDITIONAL] Si el sello se declara cualificado conforme a 910/2014, el certificado de verificación del TSU debe emitirse conforme a la política NCP+ definida en ETSI EN 319 411-1. | Obligatoria | TBD | TBD | — | — |
| EN 319 421 §8.1 TIS-8.1-02 | 421-qtsa-policy | [CONDITIONAL] Si el sello se declara cualificado, el certificado debería emitirse conforme a una política de certificado adecuada de ETSI EN 319 411-2. | Recomendada | TBD | TBD | — | — |
| EN 319 421 §8.2 TIS-8.2-01 | 421-qtsa-policy | [CONDITIONAL] Un TSU que emita sellos cualificados conforme a 910/2014 no debe emitir sellos no cualificados. | Obligatoria | TBD | TBD | — | — |
| EN 319 421 §8.2 TIS-8.2-02 | 421-qtsa-policy | [CONDITIONAL] Un TSA que emita sellos cualificados y no cualificados debe usar TSU diferentes identificados por subject names distintos en el certificado público. | Obligatoria | TBD | TBD | — | — |
| EN 319 421 §8.2 TIS-8.2-03 | 421-qtsa-policy | [CONDITIONAL] Un TSA que emita sellos cualificados y no cualificados debe usar TSU accesibles a través de puntos de acceso al servicio separados. | Obligatoria | TBD | TBD | — | — |
| EN 319 422 §4.1.1 | 422-qtsa-protocol | El cliente de sellado debe soportar la petición conforme a IETF RFC 3161 cl. 2.4.1 con las modificaciones de las cláusulas siguientes. | Obligatoria | TBD | TBD | — | — |
| EN 319 422 §4.1.2 | 422-qtsa-protocol | El cliente debería soportar los campos `reqPolicy`, `nonce` y `certReq` en la petición. | Recomendada | TBD | TBD | — | — |
| EN 319 422 §4.1.3 | 422-qtsa-protocol | Los algoritmos de hash usados para hashear los datos a sellar deberían ser los especificados en cl. A.8 de ETSI TS 119 312, considerando duración esperada del sello vs cl. 9.2 de TS 119 312. | Recomendada | TBD | TBD | — | — |
| EN 319 422 §4.2.1 | 422-qtsa-protocol | El cliente debe soportar la respuesta conforme a IETF RFC 3161 cl. 2.4.2 con las modificaciones siguientes. | Obligatoria | TBD | TBD | — | — |
| EN 319 422 §4.2.2 (a) | 422-qtsa-protocol | El cliente debe soportar el campo `accuracy`. | Obligatoria | TBD | TBD | — | — |
| EN 319 422 §4.2.2 (b) | 422-qtsa-protocol | El cliente debería soportar el campo `nonce`. Si la petición incluyó nonce, la respuesta debe incluirlo con el mismo valor. | Recomendada / Obligatoria si nonce presente | TBD | TBD | — | — |
| EN 319 422 §4.2.2 (c) | 422-qtsa-protocol | El cliente no debería depender de un orden de los sellos (un TSU no necesita soportar `ordering`). | Recomendada | TBD | TBD | — | — |
| EN 319 422 §4.2.3 | 422-qtsa-protocol | Los algoritmos de firma del token soportados deberían ser los especificados en cl. A.8 de ETSI TS 119 312. | Recomendada | TBD | TBD | — | — |
| EN 319 422 §4.2.4 | 422-qtsa-protocol | Las longitudes de clave para el algoritmo de firma seleccionado deberían soportarse según cl. 9.3 de ETSI TS 119 312. | Recomendada | TBD | TBD | — | — |
| EN 319 422 §5.1.1 | 422-qtsa-protocol | El servidor TSA debe soportar la petición conforme a IETF RFC 3161 cl. 2.4.1 con las modificaciones siguientes. | Obligatoria | TBD | TBD | — | — |
| EN 319 422 §5.1.2 (a) | 422-qtsa-protocol | El servidor debe soportar el campo `reqPolicy`. | Obligatoria | TBD | TBD | — | — |
| EN 319 422 §5.1.2 (b) | 422-qtsa-protocol | El servidor debe soportar el campo `nonce`. | Obligatoria | TBD | TBD | — | — |
| EN 319 422 §5.1.2 (c) | 422-qtsa-protocol | El servidor debe soportar el campo `certReq`. | Obligatoria | TBD | TBD | — | — |
| EN 319 422 §5.1.3 | 422-qtsa-protocol | Los algoritmos de hash a soportar para los datos a sellar deberían ser los de cl. A.8 de ETSI TS 119 312, teniendo en cuenta la duración esperada del sello. | Recomendada | TBD | TBD | — | — |
| EN 319 422 §5.2.1 | 422-qtsa-protocol | El servidor debe soportar la respuesta conforme a IETF RFC 3161 cl. 2.4.2 con las modificaciones siguientes. | Obligatoria | TBD | TBD | — | — |
| EN 319 422 §5.2.2 (a) | 422-qtsa-protocol | El campo `policy` debe estar presente como identificador de la política de sellado y conformar al Anexo A. | Obligatoria | TBD | TBD | — | — |
| EN 319 422 §5.2.2 (b) | 422-qtsa-protocol | El campo `genTime` debe tener un valor con precisión suficiente para soportar la exactitud declarada. | Obligatoria | TBD | TBD | — | — |
| EN 319 422 §5.2.2 (c) | 422-qtsa-protocol | El campo `accuracy` debe estar presente y debe soportar al menos una exactitud mínima de 1 segundo. | Obligatoria | TBD | TBD | — | — |
| EN 319 422 §5.2.2 (d) | 422-qtsa-protocol | El campo `ordering` no debe estar presente o debe estar a `false`. | Obligatoria | TBD | TBD | — | — |
| EN 319 422 §5.2.2 (e) | 422-qtsa-protocol | Ninguna extensión del token debe marcarse como crítica. | Obligatoria | TBD | TBD | — | — |
| EN 319 422 §5.2.2 (f) | 422-qtsa-protocol | El identificador del certificado del TSU (`ESSCertID` de RFC 3161 o `ESSCertIDv2` de RFC 5816) debe incluirse como atributo `signerInfo` dentro de `SigningCertificate` o `SigningCertificateV2`. | Obligatoria | TBD | TBD | — | — |
| EN 319 422 §5.2.3 | 422-qtsa-protocol | Los algoritmos de hash y de firma del token deberían ajustarse a cl. A.8 de ETSI TS 119 312. | Recomendada | TBD | TBD | — | — |
| EN 319 422 §7 (a) | 422-qtsa-protocol | Cliente y servidor de sellado deben soportar el protocolo sobre HTTP (RFC 7230-7235) o HTTPS (RFC 2818) según cl. 3.4 de IETF RFC 3161. | Obligatoria | TBD | TBD | — | — |
| EN 319 422 §7 (b) | 422-qtsa-protocol | Debería usarse HTTPS en lugar de HTTP. | Recomendada | TBD | TBD | — | — |
| EN 319 422 §8 | 422-qtsa-protocol | Los OID para los algoritmos de hashing y firma recomendados se especifican en cl. 11 de ETSI TS 119 312. | Recomendada | TBD | TBD | — | — |
| EN 319 422 Anexo A | 422-qtsa-protocol | Cuando el TST es emitido por un TSA conforme a EN 319 421, el campo `policy` del TSTInfo debe incluir el identificador de cl. 5.2 de EN 319 421 (BTSP), o el identificador propio del TSA cuando éste incorpore o restrinja la política BTSP. | Obligatoria | TBD | TBD | — | — |
| EN 319 422 Anexo B | 422-qtsa-protocol | OIDs definidos: `id-etsi-tsts` = `{itu-t(0) identified-organization(4) etsi(0) id-tst-profile(19422) 1}`; `id-etsi-tsts-EuQCompliance` = `{id-etsi-tsts 1}`; statement `esi4-qtstStatement-1`. La inclusión de este statement implica reclamación de cumplimiento con 910/2014. | Obligatoria | TBD | TBD | — | — |
| EN 319 422 Anexo C | 422-qtsa-protocol | El TST debe identificarse con: Media Type `application/vnd.etsi.timestamp-token`, codificación binaria, sin parámetros, extensión de archivo `.tst` (RFC 6838). | Obligatoria | TBD | TBD | — | — |
| eIDAS §41.2 | eidas-legales | Garantizar presunción de exactitud de fecha/hora e integridad de los datos | Obligatoria | TBD | TBD | — | — |
| eIDAS §42.1.a | eidas-legales | Vincular fecha/hora a los datos de forma que se elimine razonablemente posibilidad de modificación sin detección | Obligatoria | TBD | TBD | — | — |
| eIDAS §42.1.b | eidas-legales | Basarse en fuente temporal vinculada a UTC | Obligatoria | TBD | TBD | — | — |
| eIDAS §42.1.c | eidas-legales | Firmado con firma o sello electrónico avanzado del QTSP | Obligatoria | TBD | TBD | — | — |