Gap analysis
Cargando…
Cargando…
| Control | Tema | Requisito | Aplicab. | Estado | Severidad | Owner | WP |
|---|---|---|---|---|---|---|---|
| EN 319 422 §4.1.1 | T07 | 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 | T07 | El cliente debería soportar los campos `reqPolicy`, `nonce` y `certReq` en la petición. | Recomendada | TBD | TBD | — | — |
| EN 319 422 §4.1.3 | T07 | 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 | T07 | 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) | T07 | El cliente debe soportar el campo `accuracy`. | Obligatoria | TBD | TBD | — | — |
| EN 319 422 §4.2.2 (b) | T07 | 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) | T07 | 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 | T07 | 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 | T07 | 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 | T07 | 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) | T07 | El servidor debe soportar el campo `reqPolicy`. | Obligatoria | TBD | TBD | — | — |
| EN 319 422 §5.1.2 (b) | T07 | El servidor debe soportar el campo `nonce`. | Obligatoria | TBD | TBD | — | — |
| EN 319 422 §5.1.2 (c) | T07 | El servidor debe soportar el campo `certReq`. | Obligatoria | TBD | TBD | — | — |
| EN 319 422 §5.1.3 | T07 | 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 | T07 | 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) | T07 | 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) | T07 | 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) | T07 | 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) | T07 | El campo `ordering` no debe estar presente o debe estar a `false`. | Obligatoria | TBD | TBD | — | — |
| EN 319 422 §5.2.2 (e) | T07 | Ninguna extensión del token debe marcarse como crítica. | Obligatoria | TBD | TBD | — | — |
| EN 319 422 §5.2.2 (f) | T07 | 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 | T07 | 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 §6.1 | T04 | El certificado del TSU debe cumplir ETSI EN 319 412-2 (TSA persona física) o ETSI EN 319 412-3 (TSA persona jurídica), con las modificaciones de las cláusulas siguientes. | Obligatoria | TBD | TBD | — | — |
| EN 319 422 §6.2 (a) | T04 | El atributo `countryName` debe especificar el país donde el TSA está establecido (no necesariamente el país del TSU). | Obligatoria | TBD | TBD | — | — |
| EN 319 422 §6.2 (b) | T04 | Para TSA persona jurídica (o física asociada a jurídica), `organizationName` debe contener el nombre completo registrado del TSA responsable de gestionar el TSU; debería ser el nombre oficialmente registrado. | Obligatoria | TBD | TBD | — | — |
| EN 319 422 §6.2 (c) | T04 | El `commonName` especifica un identificador del TSU. Dentro del TSA, `commonName` identifica unívocamente al TSU usado. | Obligatoria | TBD | TBD | — | — |
| EN 319 422 §6.2 (d) | T04 | Para TSA persona física, debería incluirse una instancia del atributo `serialNumber` en el subject. | Recomendada | TBD | TBD | — | — |
| EN 319 422 §6.3 | T04 | La longitud de clave para el algoritmo de firma del certificado del TSU debería ajustarse a cl. 9.3 de ETSI TS 119 312. | Recomendada | TBD | TBD | — | — |
| EN 319 422 §6.4 (a) | T04 | El `extendedKeyUsage` del certificado TSU debe ser el definido en IETF RFC 3161, cl. 2.3 (id-kp-timeStamping, único, marcado crítico). | Obligatoria | TBD | TBD | — | — |
| EN 319 422 §6.4 (b) | T04 | La extensión `privateKeyUsagePeriod` debería usarse para limitar la validez de la clave de firma del TSU. | Recomendada | TBD | TBD | — | — |
| EN 319 422 §6.5 | T04 | La clave pública del TSU y la firma del certificado deberían usar los algoritmos especificados en cl. A.9 de ETSI TS 119 312. | Recomendada | TBD | TBD | — | — |
| EN 319 422 §7 (a) | T07 | 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) | T07 | Debería usarse HTTPS en lugar de HTTP. | Recomendada | TBD | TBD | — | — |
| EN 319 422 §8 | T07 | 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 §9.1 (a) | T04 | [CONDITIONAL] Si el token se declara sello cualificado conforme a 910/2014, debería contener la extensión `qcStatements` en el campo `extension` del TST con la sintaxis de IETF RFC 3739, cl. 3.2.6. | Recomendada | TBD | TBD | — | — |
| EN 319 422 §9.1 (b) | T04 | [CONDITIONAL] Si la extensión `qcStatements` está presente, debe contener una instancia del statement `esi4-qtstStatement-1` definido en el Anexo B (OID `id-etsi-tsts-EuQCompliance`). | Obligatoria | TBD | TBD | — | — |
| EN 319 422 §9.1 (c) | T04 | La extensión `qcStatements` no debe marcarse como crítica. | Obligatoria | TBD | TBD | — | — |
| EN 319 422 Anexo A | T07 | 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 | T07 | 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 | T07 | 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 | — | — |