02021D1073 — ES — 25.04.2022 — 003.001

Este texto es exclusivamente un instrumento de documentación y no surte efecto jurídico. Las instituciones de la UE no asumen responsabilidad alguna por su contenido. Las versiones auténticas de los actos pertinentes, incluidos sus preámbulos, son las publicadas en el Diario Oficial de la Unión Europea, que pueden consultarse a través de EUR-Lex. Los textos oficiales son accesibles directamente mediante los enlaces integrados en este documento

►B DECISIÓN DE EJECUCIÓN (UE) 2021/1073 DE LA COMISIÓN de 28 de junio de 2021 por la que se establecen especificaciones técnicas y normas relativas a la aplicación del marco de confianza para el certificado COVID digital de la UE establecido por el Reglamento (UE) 2021/953 del Parlamento Europeo y del Consejo (Texto pertinente a efectos del EEE) (DO L 230 de 30.6.2021, p. 32)

Modificada por:









▼B

DECISIÓN DE EJECUCIÓN (UE) 2021/1073 DE LA COMISIÓN

de 28 de junio de 2021

por la que se establecen especificaciones técnicas y normas relativas a la aplicación del marco de confianza para el certificado COVID digital de la UE establecido por el Reglamento (UE) 2021/953 del Parlamento Europeo y del Consejo

(Texto pertinente a efectos del EEE)







Artículo 1

En el anexo I figuran las especificaciones técnicas del certificado COVID digital de la UE, que establecen la estructura de datos genérica, los mecanismos de codificación y el mecanismo de codificación de transporte en un formato óptico legible por máquina.

Artículo 2

En el anexo II de la presente Decisión figuran las normas relativas a la cumplimentación de los certificados a que se refiere el artículo 3, apartado 1, del Reglamento (UE) 2021/953.

Artículo 3

En el anexo III figuran los requisitos que establecen la estructura común del identificador único de certificado.

▼M1

Artículo 4

En el anexo IV figuran las normas de gobernanza aplicables a los certificados de clave pública en lo que respecta a la pasarela del Certificado COVID digital de la UE y que regulan los aspectos de interoperabilidad del marco de confianza.

▼M1

Artículo 5

En el anexo V de la presente Decisión se establece una estructura de datos común y coordinada en relación con los datos que deben incluirse en los certificados a que se refiere el artículo 3, apartado 1, del Reglamento (UE) 2021/953, utilizando un sistema JSON (JavaScript Object Notation, «notación de objetos en JavaScript»).

▼M3

Artículo 5 bis

Intercambio de listas de revocación de certificados

1. El marco de confianza para el certificado COVID digital de la UE permitirá el intercambio de listas de revocación de certificados a través de la pasarela central del certificado COVID digital de la UE («pasarela»), de conformidad con las especificaciones técnicas del anexo I.

2. Cuando los Estados miembros revoquen los certificados COVID digitales de la UE, podrán presentar listas de revocación de certificados en la pasarela.

3. Cuando los Estados miembros presenten listas de revocación de certificados, las autoridades expedidoras mantendrán una lista de certificados revocados.

4. Cuando los datos personales se intercambien a través de la pasarela, la finalidad de su tratamiento se limitará a apoyar el intercambio de información relativa a la revocación. Dichos datos personales solo se utilizarán para verificar el estado de revocación de los certificados COVID digitales de la UE expedidos en el ámbito de aplicación del Reglamento (UE) 2021/953.

5. La información presentada en la pasarela incluirá los siguientes datos, de conformidad con las especificaciones técnicas establecidas en el anexo I: a) los identificadores únicos de certificado seudonimizados de los certificados revocados; b) una fecha de expiración de la lista de revocación de certificados que se ha presentado.

6. Cuando una autoridad expedidora revoque certificados COVID digitales de la UE que ella misma haya expedido en virtud del Reglamento (UE) 2021/953 o del Reglamento (UE) 2021/954, y tenga la intención de intercambiar información pertinente a través de la pasarela, transmitirá la información a que se refiere el apartado 5 en forma de listas de revocación de certificados en la pasarela en un formato seguro, de conformidad con las disposiciones técnicas establecidas en el anexo I.

7. Las autoridades expedidoras proporcionarán, en la medida de lo posible, una solución para informar a los titulares de certificados revocados sobre el estado de revocación de sus certificados y el motivo de la revocación en el momento que esta se produzca.

8. La pasarela recopilará las listas de revocación de certificados recibidas. Proporcionará herramientas para la distribución de las listas a los Estados miembros. Suprimirá automáticamente las listas de conformidad con las fechas de caducidad indicadas por la autoridad en cuestión para cada lista que haya presentado.

9. Las autoridades nacionales o los organismos oficiales designados de los Estados miembros que traten datos personales en la pasarela serán corresponsables del tratamiento de dichos datos. Las respectivas responsabilidades de los corresponsables del tratamiento se asignarán de acuerdo con el anexo VI.

10. La Comisión será la encargada del tratamiento de los datos personales tratados dentro de la pasarela. En su calidad de encargada del tratamiento de los datos en nombre de los Estados miembros, la Comisión garantizará la seguridad de la transmisión y del alojamiento de datos personales en la pasarela y cumplirá las obligaciones del encargado del tratamiento establecidas en el anexo VII.

11. La eficacia de las medidas técnicas y organizativas para garantizar la seguridad del tratamiento de los datos personales en la pasarela será sometida a ensayo, valorada y evaluada con regularidad por la Comisión y por los corresponsables del tratamiento.

Artículo 5 ter

Presentación de listas de revocación de certificados por terceros países

Los terceros países que expidan certificados COVID-19 respecto de los cuales la Comisión haya adoptado un acto de ejecución con arreglo al artículo 3, apartado 10, o al artículo 8, apartado 2, del Reglamento (UE) 2021/953 podrán presentar en la pasarela listas de certificados COVID-19 revocados cubiertos por dicho acto de ejecución para que sean tratadas por la Comisión en nombre de los corresponsables del tratamiento, tal como se refiere en el artículo 5 bis, de conformidad con las especificaciones técnicas establecidas en el anexo I.

Artículo 5 quater

Gobernanza del tratamiento de datos personales en la pasarela central del certificado COVID digital de la UE

1. El proceso de toma de decisiones de los corresponsables del tratamiento se regirá por un grupo de trabajo creado en el marco del Comité a que se refiere el artículo 14 del Reglamento (UE) 2021/953.

2. Las autoridades nacionales o los organismos oficiales designados de los Estados miembros que traten datos personales en la pasarela como corresponsables de su tratamiento designarán representantes en dicho grupo.

▼M1

Artículo 6

La presente Decisión entrará en vigor el día de su publicación en el Diario Oficial de la Unión Europea.

▼B

La presente Decisión entrará en vigor el día de su publicación en el Diario Oficial de la Unión Europea.









ANEXO I

GESTIÓN DEL FORMATO Y DE LA CONFIANZA

Estructura de datos genérica, mecanismos de codificación y mecanismo de codificación de transporte en un formato óptico legible por máquina (en lo sucesivo denominado «QR»)

1. Introducción

Las especificaciones técnicas establecidas en este anexo contienen una estructura de datos genérica y mecanismos de codificación para el certificado COVID digital de la UE («CCD»). También detallan un mecanismo de codificación de transporte en un formato óptico legible por máquina («QR»), que puede mostrarse en la pantalla de un dispositivo móvil o imprimirse. Los formatos de contenedor de certificados sanitarios electrónicos de estas especificaciones son genéricos, pero en este contexto se utilizan para contener el CCD.

2. Terminología

A efectos del presente anexo, se entenderá por «emisores» las organizaciones que utilicen estas especificaciones para expedir certificados sanitarios y por «verificadores» las organizaciones que acepten los certificados sanitarios como prueba del estado de salud. Por «participantes» se entiende los emisores y los verificadores. Algunos de los aspectos establecidos en el presente anexo deben coordinarse entre los participantes, como la gestión de un espacio de nombres y la distribución de claves criptográficas. Se parte de la premisa de que una parte, en adelante denominada «Secretaría», lleva a cabo estas tareas.

3. Formato de contenedor de certificados sanitarios electrónicos

El formato de contenedor de certificados sanitarios electrónicos («HCERT») está diseñado para proporcionar una solución uniforme y estandarizada para los certificados sanitarios de diferentes emisores («emisores»). El objetivo de estas especificaciones es armonizar la forma en que se representan, codifican y firman estos certificados sanitarios con el fin de facilitar la interoperabilidad.

La capacidad de leer e interpretar un CCD expedido por cualquier emisor requiere una estructura de datos común y un consenso sobre la importancia de cada campo de datos de la carga útil. Para facilitar esta interoperabilidad, se define una estructura de datos coordinada común mediante el uso de un esquema «JSON» que constituye el marco del CCD.

3.1. Estructura de la carga útil

La carga útil está estructurada y codificada como CBOR con una firma digital COSE. Esto se conoce comúnmente como «CBOR Web Token» (CWT), y se define en RFC 8392 ( 1 ). La carga útil, tal y como se define en las siguientes secciones, se transporta en una notificación hcert.

El verificador debe comprobar la integridad y autenticidad del origen de los datos de la carga útil. Para proporcionar este mecanismo, el emisor debe firmar el CWT utilizando un esquema de firma electrónica asimétrica, tal como se define en la especificación COSE (RFC 8152 ( 2 )).

3.2. Notificaciones CWT

3.2.1. Descripción de la estructura del CWT

Encabezado protegido

— Algoritmo de firma (alg, etiqueta 1)

— Identificador de clave (kid, etiqueta 4)

Carga útil

— Emisor (iss, clave de notificación 1, opcional, ISO 3166-1 alfa-2 del emisor)

— Emitido a las (iat, clave de notificación 6

— Hora de expiración (exp, clave de notificación 4)

— Certificado sanitario (hcert, clave de notificación -260)

— Certificado COVID digital de la UE v1 (eu_DCC_v1, clave de notificación 1)

Firma

3.2.2. Algoritmo de firma

El parámetro Algoritmo de Firma(alg) indica qué algoritmo se utiliza para la creación de la firma. Debe cumplir o superar las directrices actuales de SOG-IS que se resumen a continuación.

Se define un algoritmo primario y otro secundario. El algoritmo secundario solo debe utilizarse si el algoritmo primario no es aceptable dentro de las normas y reglamentos impuestos al emisor.

Para garantizar la seguridad del sistema, todas las implementaciones deben incorporar el algoritmo secundario. Por esta razón, deben implementarse tanto el algoritmo primario como el secundario.

Los niveles del conjunto SOG-IS para los algoritmos primario y secundario son:

— Algoritmo principal: El algoritmo principal es el algoritmo de firma digital de curva elíptica (ECDSA) definido en la sección 2.3 de la norma (ISO/IEC 14888-3:2006), que utiliza los parámetros P-256 definidos en el apéndice D (D.1.2.3) de la norma (FIPS PUB 186-4) en combinación con el algoritmo de hash SHA-256 definido en la función 4 de la norma (ISO/IEC 10118-3:2004).

Esto corresponde al parámetro ES256 del algoritmo COSE.

— Algoritmo secundario: El algoritmo secundario es el RSASSA-PSS definido en (RFC 8230 ( 3 )) con un módulo de 2048 bits en combinación con el algoritmo de hash SHA-256 definido en la función 4 (ISO/IEC 10118-3:2004).

Esto corresponde al parámetro del algoritmo COSE: PS256.

3.2.3. Identificador de clave

La notificación de identificador de clave (kid) indica el certificado de firmante de documentos (DSC) que contiene la clave pública que debe utilizar el verificador para comprobar la exactitud de la firma digital. La gobernanza de los certificados de clave pública, incluidos los requisitos aplicables a los DSC, se describe en el anexo IV.

Los verificadores utilizan la notificación de identificador de clave(kid) para seleccionar la clave pública correcta de una lista de claves pertenecientes al emisor indicado en la notificación de emisor (iss). Un emisor puede utilizar varias claves en paralelo por razones administrativas y al realizar sustituciones de claves. El identificador de clave no es un campo crítico para la seguridad. Por esta razón, también puede colocarse en un encabezado no protegido si es necesario. Los verificadores deben aceptar ambas opciones. Si se dan ambas opciones, se debe utilizar el identificador de clave del encabezado protegido.

Debido al acortamiento del identificador (por razones de limitación del espacio), existe una posibilidad pequeña, pero no nula, de que la lista general de DSC aceptada por un verificador contenga DSC con kid duplicados. Por esta razón, un verificador debe comprobar todos los DSC con ese kid.

3.2.4. Emisor

La notificación de emisor (iss) es un valor de cadena que, a título facultativo, puede contener el código de país ISO 3166-1 alfa-2 de la entidad que emite el certificado sanitario. Un verificador puede usar esta notificación para identificar qué conjunto de DSC debe utilizarse para la validación. La clave de notificación 1 se utiliza para identificar esta notificación.

3.2.5. Hora de expiración

La notificación de hora de expiración (exp) deberá contener un sello de tiempo en el formato NumericDate (como se especifica en la sección 2 de RFC 8392 ( 4 )) que indique durante cuánto tiempo se considerará válida esta firma particular sobre la carga útil, después de lo cual un verificador deberá rechazar la carga útil como expirada. La finalidad del parámetro de expiración es forzar un límite del período de validez del certificado sanitario. La clave de notificación 4 se utiliza para identificar esta notificación.

La hora de expiración no debe exceder el período de validez del DSC.

3.2.6. Emitido a las

La notificación «emitido a las» (iat) deberá contener un sello de tiempo en el formato NumericDate (como se especifica en la sección 2 de RFC 8392 ( 5 )), que indique la hora de creación del certificado sanitario.

El valor del campo Emitido a las no debe ser anterior al período de validez del DSC.

Los verificadores pueden aplicar políticas adicionales con el fin de restringir la validez del certificado sanitario en función de la hora de su emisión. La clave de notificación 6 se utiliza para identificar esta notificación.

3.2.7. Notificación de certificado sanitario

La notificación de certificado sanitario (hcert) es un objeto JSON (RFC 7159 ( 6 )) que contiene la información sobre el estado de salud. Pueden existir varios tipos diferentes de certificados sanitarios bajo la misma notificación, uno de los cuales es el CCD.

El JSON sirve meramente para fines de esquema. El formato de representación es CBOR, como se define en (RFC 7049 ( 7 )). Es posible que los desarrolladores de aplicaciones no decodifiquen nunca, ni codifiquen desde y hacia el formato JSON, sino que utilicen la estructura en memoria.

La clave de notificación que se utiliza para identificar esta notificación es -260.

Las cadenas del objeto JSON deben normalizarse de acuerdo con la composición canónica de formato de normalización (NFC) definida en la norma Unicode. Sin embargo, las aplicaciones de decodificación deben ser permisivas y robustas en estos aspectos, y se recomienda encarecidamente la aceptación de cualquier conversión de un tipo razonable. Si se encuentran datos no normalizados durante la decodificación, o en funciones de comparación posteriores, las implementaciones deben comportarse como si la entrada estuviera normalizada con respecto a NFC.

4. Serialización y creación de la carga útil del CCD

Como patrón de serialización, se utiliza el siguiente esquema:

El proceso comienza con la extracción de datos, por ejemplo, de un repositorio de datos sanitarios (o de alguna fuente de datos externa), y los datos extraídos se estructuran según los esquemas de CCD definidos. En este proceso, la conversión al formato de datos definido y la transformación para la legibilidad humana pueden tener lugar antes de que comience la serialización a CBOR. Las siglas de las notificaciones se asignarán en todos los casos a los nombres de visualización antes de la serialización y después de la deserialización.

No se permite contenido opcional de datos nacionales en los certificados emitidos conforme al Reglamento (UE) 2021/953 ( 8 ). El contenido de los datos se limita a los elementos de datos definidos en el conjunto mínimo de datos especificado en el anexo de dicho Reglamento (UE) 2021/953.

5. Codificaciones de transporte

5.1. Sin procesar

Para interfaces de datos arbitrarias, el contenedor HCERT y sus cargas útiles pueden transferirse «tal cual», utilizando cualquier transporte de datos subyacente, seguro y fiable de 8 bits. Estas interfaces pueden incluir comunicación de campo próximo (NFC), Bluetooth o la transferencia a través de un protocolo de capa de aplicación, por ejemplo, la transferencia de un HCERT del emisor al dispositivo móvil del titular.

Si la transferencia del HCERT del emisor al titular se basa en una interfaz de solo presentación (por ejemplo, SMS, correo electrónico), la codificación de transporte sin procesar obviamente no es aplicable.

5.2. Código de barras

5.2.1. Compresión de la carga útil (CWT)

Para reducir el tamaño y mejorar la velocidad y la fiabilidad en el proceso de lectura del HCERT, el CWT deberá comprimirse utilizando ZLIB ((RFC 1950 ( 9 )) y el mecanismo de compresión Deflate en el formato definido en (RFC 1951 ( 10 )).

5.2.2. Código de barras QR 2D

Para poder manejar mejor los equipos heredados diseñados para operar con cargas útiles ASCII, el CWT comprimido se codifica como ASCII utilizando Base45 antes de ser codificado en un código de barras 2D.

Se utilizará el formato QR definido en (ISO/IEC 18004:2015) para la generación de códigos de barras 2D. Se recomienda una tasa de corrección de errores «Q» (alrededor del 25 %). Dado que se utiliza Base45, el código QR debe utilizar codificación alfanumérica (modo 2, indicado por los símbolos 0010).

Para que los verificadores puedan detectar el tipo de datos codificados y seleccionar el esquema de decodificación y procesamiento adecuado, los datos codificados en Base45 (según esta especificación) deberán llevar como prefijo la cadena de identificador de contexto «HC1:». Las futuras versiones de esta especificación que afecten a la retrocompatibilidad deberán definir un nuevo identificador de contexto, mientras que el carácter que sigue a «HC» deberá tomarse del conjunto de caracteres [1-9A-Z]. El orden de los incrementos se define en ese orden, es decir, primero [1-9] y luego [A-Z].

Se recomienda que el código óptico se represente en el soporte de presentación con una diagonal de entre 35 mm y 60 mm para adaptarse a los lectores con óptica fija en los que se requiere que el soporte de presentación se coloque en la superficie del lector.

Si el código óptico se imprime en papel con impresoras de baja resolución (< 300 ppp), debe prestarse atención a que cada símbolo (punto) del código QR se represente con cuadrados exactos. Una escala no proporcional llevará a que algunas filas o columnas del QR tengan símbolos rectangulares, lo que en muchos casos dificultará la legibilidad.

6. Formato de listas de confianza (lista de DSC y CSCA)

Cada Estado miembro tiene la obligación de proporcionar una lista de una o más autoridades nacionales de firma de certificados (CSCA) y una lista de todos los certificados de firmante de documentos (DSC) válidos, y de mantener estas listas actualizadas.

6.1. CSCA/DSC simplificados

A partir de esta versión de las especificaciones, los Estados miembros no partirán del principio de que se utiliza información alguna de la lista de revocación de certificados (CRL), ni que el período de uso de la clave privada es verificado por los implementadores.

En cambio, el principal mecanismo de validez es la presencia del certificado en la versión más reciente de esa lista de certificados.

6.2. Infraestructura de clave pública (PKI) de e-DVLM de la OACI y centros de confianza

Los Estados miembros pueden utilizar una CSCA diferente, pero también pueden presentar sus certificados CSCA de e-DVLM y/o DSC existentes, e incluso pueden optar por obtenerlos en estos centros de confianza (comerciales) y presentarlos. Ahora bien, todo DSC debe estar siempre firmado por la CSCA presentada por ese Estado miembro.

7. Consideraciones de seguridad

Cuando diseñen un sistema utilizando esta especificación, los Estados miembros deberán identificar, analizar y supervisar determinados aspectos de seguridad.

Como mínimo, deben tenerse en cuenta los siguientes aspectos:

7.1. Tiempo de validez de la firma HCERT

El emisor de HCERT debe limitar el período de validez de la firma especificando una hora de expiración de la misma. Esto obliga al titular de un certificado sanitario a renovarlo a intervalos periódicos.

El período de validez aceptable puede estar determinado por limitaciones prácticas. Por ejemplo, un viajero puede no tener la posibilidad de renovar el certificado sanitario durante un viaje al extranjero. Sin embargo, también puede darse el caso de que un emisor esté considerando la posibilidad de que se produzca algún tipo de ataque a la seguridad que exija que el emisor retire un DSC (invalidando todos los certificados sanitarios emitidos con esa clave que aún estén dentro de su período de validez). Las consecuencias de un incidente de este tipo pueden limitarse alternando periódicamente las claves del emisor y exigiendo la renovación de todos los certificados sanitarios, con un intervalo razonable.

7.2. Gestión de claves

Esta especificación se basa en gran medida en fuertes mecanismos criptográficos para asegurar la integridad de los datos y la autenticación de su origen. Por lo tanto, es necesario mantener la confidencialidad de las claves privadas.

La confidencialidad de las claves criptográficas puede verse comprometida de diferentes maneras, por ejemplo:

— El proceso de generación de claves puede ser defectuoso, dando lugar a claves débiles.

— Las claves pueden quedar expuestas por un error humano.

— Las claves pueden ser robadas por agentes externos o internos.

— Las claves pueden calcularse mediante criptoanálisis.

Para mitigar el riesgo de que el algoritmo de firma sea débil, lo cual permitiría que las claves privadas se vieran comprometidas por medio del criptoanálisis, esta especificación recomienda a todos los participantes que implementen un algoritmo de firma secundario de reserva basado en parámetros diferentes o en un problema matemático distinto del primario.

En cuanto a los riesgos mencionados relacionados con los entornos operativos de los emisores, se aplicarán medidas de mitigación para garantizar un control eficaz, como la generación, el almacenamiento y la utilización de las claves privadas en módulos de seguridad de hardware (HSM). Se recomienda encarecidamente el uso de HSM para la firma de certificados sanitarios.

Independientemente de que un emisor decida utilizar HSM o no, debe establecerse un calendario de sustitución de claves en el que la frecuencia de sustitución sea proporcional a la exposición de las claves a redes externas, otros sistemas y otro personal. Un calendario de sustitución bien elegido también limita los riesgos asociados a los certificados sanitarios emitidos de manera errónea y permite a un emisor revocar dichos certificados sanitarios por lotes, retirando una clave, si es necesario.

7.3. Validación de datos de entrada

Estas especificaciones pueden utilizarse de forma que impliquen la recepción de datos de fuentes no fiables en sistemas que pueden ser de naturaleza crítica. Para minimizar los riesgos asociados a este vector de ataque, todos los campos de entrada deben ser validados adecuadamente por tipos de datos, longitudes y contenidos. La firma del emisor también se deberá verificar antes de que tenga lugar cualquier procesamiento del contenido del HCERT. Sin embargo, la validación de la firma del emisor implica en primer lugar el análisis sintáctico del encabezado del emisor protegido, en el que un posible atacante puede intentar inyectar información cuidadosamente diseñada para comprometer la seguridad del sistema.

8. Gestión de la confianza

La firma del HCERT requiere una clave pública para su verificación. Los Estados miembros harán públicas estas claves. En última instancia, cada verificador necesita tener una lista de todas las claves públicas en las que está dispuesto a confiar (ya que la clave pública no forma parte del HCERT).

El sistema consta de (solo) dos capas; para cada Estado miembro, uno o varios certificados a nivel de país que firman uno o varios certificados de firmante de documentos que se utilizan en las operaciones cotidianas.

Los certificados de los Estados miembros se denominan certificados de las autoridades nacionales de firma de certificados y son (por lo general) certificados autofirmados. Los Estados miembros pueden tener más de uno (por ejemplo, en caso de descentralización regional). Estos certificados CSCA firman periódicamente los certificados de firmante de documentos (DSC) utilizados para firmar los HCERT.

La «Secretaría» desempeña un papel funcional. Agregará y publicará periódicamente los DSC de los Estados miembros, después de haberlos cotejado con la lista de certificados CSCA (que se han transmitido y verificado por otros medios).

La lista resultante de DSC proporcionará entonces el conjunto agregado de claves públicas aceptables (y los correspondientes identificadores de clave) que los verificadores pueden utilizar para validar las firmas sobre los HCERT. Los verificadores deben obtener y actualizar esta lista periódicamente.

Estas listas específicas de los Estados miembros pueden adaptarse en el formato para su propio entorno nacional. Por consiguiente, el formato de archivo de esta lista de confianza puede variar, por ejemplo, puede ser un JWKS firmado (formato del conjunto JWK según la sección 5 de RFC 7517 ( 11 )) o cualquier otro formato específico de la tecnología utilizada en ese Estado miembro.

Para garantizar la simplicidad, los Estados miembros pueden presentar sus certificados CSCA existentes desde sus sistemas e-DVLM de la OACI o, como recomienda la OMS, crear uno específico para este ámbito sanitario.

8.1. Identificador de clave (kids)

El identificador de clave (kid) se calcula al construir la lista de claves públicas de confianza a partir de los DSC y consiste en una huella dactilar SHA-256 truncada (primeros 8 bytes) del DSC codificada en formato DER (sin procesar).

Los verificadores no necesitan calcular el KID basándose en el certificado DSC y pueden cotejar directamente el identificador de clave en el certificado sanitario emitido con el KID de la lista de confianza.

8.2. Diferencias con el modelo de confianza PKI del e-DVLM de la OACI

Aunque se basa en las mejores prácticas del modelo de confianza PKI del e-DVLM de la OACI, se harán una serie de simplificaciones en aras de la rapidez:

— Un Estado miembro puede presentar varios certificados CSCA.

— Se puede establecer para el período de validez del DSC (uso de la clave) cualquier duración que no exceda la del certificado CSCA, y dicho período puede no indicarse.

— El DSC puede contener identificadores de políticas (uso de claves extendido) que son específicos de la red de sanidad electrónica.

— Los Estados miembros pueden optar por no verificar nunca las revocaciones publicadas, sino, en lugar de ello, basarse exclusivamente en las listas de DSC que reciben diariamente de la Secretaría o que elaboran ellos mismos.

▼M3

9. Solución de revocación

9.1. Disposición de la Lista de Revocación CCD (DLR)

La pasarela proporcionará puntos de conexión y funcionalidad para alojar y gestionar las listas de revocación:

9.2. Modelo de confianza

Todas las conexiones se establecen mediante el modelo de confianza DCCG estándar mediante los certificados NBTLS y NBUP (véase la gobernanza de certificados). Toda la información se empaqueta y se carga mediante mensajes CMS para garantizar la integridad.

9.3. Construcción de lotes

9.3.1. Lote

Cada lista de revocación contendrá una o varias entradas y se empaquetará en lotes que contengan un conjunto de hashes y sus metadatos. Un lote es inmutable y define una fecha de caducidad que indica cuándo puede eliminarse el lote. La fecha de caducidad de todos los elementos del lote debe ser exactamente la misma, es decir, los lotes deben agruparse por fecha de caducidad y por DSC firmante. Cada lote contendrá un máximo de 1 000 entradas. Si la lista de revocación consta de más de 1 000 entradas, se crearán varios lotes. Una entrada determinada solo puede producirse, como máximo, en un lote. El lote se empaquetará en una estructura CMS y se firmará con el certificado NBup del país que lo cargue.

9.3.2. Índice de lotes

Cuando se cree un lote, la pasarela le asignará un identificador único y se añadirá automáticamente al índice. El índice de lotes se ordenará por la fecha modificada, en orden cronológico ascendente.

9.3.3. Comportamiento de la pasarela

La pasarela procesa los lotes de revocación sin introducir cambios: no puede actualizar, eliminar ni añadir información a los lotes. Los lotes se envían a todos los países autorizados (véase el capítulo 9.6).

La pasarela controla activamente las fechas de caducidad de los lotes y elimina los lotes caducados. Después de eliminar el lote, la pasarela muestra la respuesta «HTTP 410 Gone» para la URL del lote eliminado. Así, el lote eliminado aparece como «deleted» en el Índice de lotes.

9.4. Tipos de hash

La lista de revocación contiene hashes que pueden representar diferentes tipos o atributos de revocación. Estos tipos o atributos se indicarán al confeccionarse las listas de revocación. Los tipos actuales son los siguientes:







Tipo Atributo Cálculo del hash SIGNATURE DCC Signature SHA256 of DCC Signature UCI UCI (identificador único de certificado) SHA256 of UCI COUNTRYCODEUCI Código del país emisor + UCI SHA256 of Issuing CountryCode + UCI

Solo los primeros 128 bits de los hashes codificados como cadenas base64 se introducen en los lotes y se utilizan para identificar el CCD revocado ( 12 ).

9.4.1. Tipo de hash: SHA-256(firma CCD)

En este caso, el hash se calcula sobre los bytes de la firma COSE_SIGN1 del CWT. Para las firmas RSA se utilizará la firma completa como entrada. La fórmula de los certificados con firma EC-DSA utiliza el valor r como entrada:

SHA256(r)

[necesario para todas las nuevas implementaciones]

9.4.2. Tipo de hash: SHA-256(UCI)

En este caso, el hash se calcula sobre la cadena UCI codificada en UTF-8 y se convierte en una matriz de bytes (byte array).

[obsoleto ( 13 ), pero adecuado para la retrocompatibilidad]

9.4.3. Tipo de hash: SHA256(Issuing CountryCode+UCI)

En este caso, el CountryCode codificado como una cadena UTF-8 concatenada con la UCI codificada con una cadena UTF-8. Esto se convierte después en una matriz de bytes (byte array) y se utiliza como entrada para la función hash.

[obsoleto2, pero adecuado para la retrocompatibilidad]

9.5. Estructura API

9.5.1. API de suministro de las entradas de revocación

9.5.1.1. Finalidad

El API proporciona las entradas de la lista de revocación en lotes, incluido un índice de lotes.

9.5.1.2. Puntos de conexión

9.5.1.2.1. Punto de conexión para la descarga de listas de lotes.

Los puntos de conexión siguen un diseño sencillo y devuelven una lista de lotes con un pequeño contenedor (wrapper) que facilita los metadatos. Los lotes se clasifican por fecha en orden (cronológico) ascendente:

/revocation-list

Verb: GET

Content-Type: application/json

Response: JSON Array

{

“more”:true|false, “batches”: [{ “batchId”: “{uuid}”, “country”: “XY”, “date”: “2021-11-01T00:00:00Z” “deleted”: true | false }, .. ]

}

Nota: El resultado se limita por defecto a 1 000 . Si la indicación «more» se establece como «true», la respuesta indica que hay más lotes disponibles para descargar. Para descargar más elementos, el cliente debe configurar el encabezado If-Modified-Since en una fecha no anterior a la última entrada recibida.

La respuesta contiene una matriz JSON con la siguiente estructura:







Campo Definición more Indicador booleano que indica que hay más lotes. batches Matriz con los lotes existentes. batchId https://en.wikipedia.org/wiki/Universally_unique_identifier country Código del país ISO 3166 date ISO 8601 Date UTC. Fecha en que se añadió o eliminó el lote. deleted Valor booleano. «True» en caso que se elimine. Cuando se activa la marca «deleted» (eliminado), la entrada puede suprimirse definitivamente de los resultados de la consulta al cabo de 7 días.

9.5.1.2.1.1. Códigos de respuesta







Código Descripción 200 Todo correcto. 204 Sin contenido, si el contenido del encabezado «If-Modified-Since» no tiene ninguna correspondencia.

Encabezado de solicitud







Encabezado Obligatorio Descripción If-Modified-Since Sí Este encabezado contiene la última fecha descargada para obtener únicamente los resultados más recientes. En la llamada inicial, el encabezado debe seguir el formato “2021-06-01T00:00:00Z”

9.5.1.2.2. Punto de conexión para descarga de lotes.

Los lotes contienen una lista de identificadores de certificado:

/revocation-list/{batchId}

Verb: GET

Accepts: application/cms

Response:CMS with Content

{

“country”: “XY”, “expires”: “2022-11-01T00:00:00Z”, “kid”:’23S+33f=’, “hashType”:’SIGNATURE’, “entries”:[{ “hash”:’e2e2e2e2e2e2e2e2’ }, ..]

}

La respuesta contiene un CMS que incluye una firma que debe corresponder al certificado NBUP del país. Todos los elementos de la matriz JSON tienen la siguiente estructura:







Campo Obligatorio Tipo Definición expires Sí Cadena Fecha en que puede suprimirse el elemento. Fecha/hora UTC ISO8601 country Sí Cadena Código del país ISO 3166 hashType Sí Cadena Tipo de hash de las entradas facilitadas (véase “Tipos de hash) entries Sí JSON Object Array Véase el cuadro Entradas kid Sí Cadena KID codificado en Base64 del DSC utilizado para firmar el CCD. Si el KID no es conocido, se puede utilizar la cadena 'UNKNOWN_KID' (sin '). Notas:

— Los lotes se agruparán por fecha de caducidad y DSC: todos los elementos caducarán al mismo tiempo y habrán sido firmados por la misma clave.

— La hora de caducidad es una fecha/hora indicada en UTC, ya que el CCD de la UE es un sistema mundial y debemos utilizar una hora inequívoca.

— La fecha de expiración de un CCD revocado de forma permanente se fijará en la fecha de expiración del DSC correspondiente utilizado para firmar el CCD o en la hora de expiración del CCD revocado (en cuyo caso se considerará que las horas NumericDate/epoch utilizadas se encuentran en la zona horaria del UTC).

— El backend nacional (NB) suprimirá los elementos de su lista de revocación cuando se alcance la fecha de caducidad .

— El Nota: puede suprimir elementos de su lista de revocación en caso de que se revoque el kid utilizado para firmar el CCD.

9.5.1.2.2.1. Entradas







Campo Obligatorio Tipo Definición hash Sí Cadena Primeros 128 bits del hash SHA-256 codificado como cadena de base64

Nota: El objeto de las entradas solo contiene actualmente un hash, pero, para ser compatible con cambios futuro, se eligió un objeto en lugar de una matriz JSON.

9.5.1.2.2.2. Códigos de respuesta







Código Descripción 200 Todo correcto. 410 El lote ha desaparecido. Se puede eliminar el lote en el backend nacional.

9.5.1.2.2.3. Encabezados de respuesta







Encabezado Descripción ETag ID del lote.

9.5.1.2.3. Punto de conexión para carga de lotes.

La carga se realiza sobre el mismo punto de conexión mediante el verbo (verb) POST:

/revocation-list

Verb: POST

Accepts: application/cms

Request: CMS with Content

ContentType: application/cms

Content:

{

“country”: “XY”, “expires”: “2022-11-01T00:00:00Z”, “kid”:’23S+33f=’, “hashType”:’SIGNATURE’, “entries”:[{ “hash”:’e2e2e2e2e2e2e2e2’ }, ..]

}

El lote se firmará mediante el certificado NBUP. La pasarela verificará que la firma se basa en el NBUP para el country (país) en cuestión. Si el control de la firma es negativo, no se producirá la carga.

Nota: Cada lote es inmutable y no puede cambiarse después de cargarlo. Sin embargo, puede eliminarse. Se almacena el ID de cada lote eliminado y se rechaza la carga de un nuevo lote que tenga el mismo ID.

9.5.1.2.4. Punto de conexión para eliminación de lotes.

Un lote se puede eliminar en el mismo punto de conexión mediante el Verb DELETE:

/revocation-list

Verb: DELETE

Accepts: application/cms

ContentType: application/cms

Request: CMS with Content

Content:

{

“batchId”: “...”

}

o, por razones de compatibilidad, al siguiente punto de conexión con el Verb POST:

/revocation-list/delete

Verb: POST

Accepts: application/cms

ContentType: application/cms

Request: CMS with Content

Content:

{

“batchId”: “...”

}

9.6. Protección API/RGPD

En esta sección se especifican las medidas necesarias para que la implementación cumpla con las disposiciones del Reglamento (CE) 2021/953 en lo que respecta al tratamiento de datos personales.

9.6.1. Autenticación existente

La pasarela utiliza actualmente el certificado NBTLS para autenticar a los países que se conectan con la pasarela. Esta autenticación puede utilizarse para determinar la identidad del país conectado a la pasarela. Esta identidad puede utilizarse seguidamente para realizar el control de acceso.

9.6.2. Control de acceso

Para poder tratar legalmente datos personales, la pasarela aplicará un mecanismo de control de acceso.

La pasarela aplica una lista de control de acceso en combinación con una seguridad basada en roles. En dicho sistema se mantendrán dos cuadros: uno en el que se describan qué roles pueden aplicarse a qué operaciones sobre qué recursos, y otro en el que se describen qué roles se asignan a qué usuarios.

Para realizar los controles exigidos en el presente documento, se requieren tres roles, a saber:

RevocationListReader

RevocationUploader

RevocationDeleter

Los siguientes puntos de conexión comprobarán si el usuario tiene el rol RevocationListReader; en caso afirmativo se concederá el acceso; de lo contrario, aparecerá HTTP 403 Forbidden:

GET/revocation-list/

GET/revocation-list/{batchId}

Los siguientes puntos de conexión comprobarán si el usuario tiene el rol RevocationUploader; en caso afirmativo se concederá el acceso; de lo contrario, aparecerá HTTP 403 Forbidden:

POST/revocation-list

Los siguientes puntos de conexión comprobarán si el usuario tiene el rol RevocationDeleter; en caso afirmativo se concederá el acceso; de lo contrario, aparecerá HTTP 403 Forbidden:

DELETE/revocation-list

POST/revocation-list/delete

La pasarela también proporcionará un método fiable mediante el cual los administradores puedan gestionar los roles vinculados a los usuarios de manera que se reduzcan las posibilidades de errores humanos sin que ello suponga una carga para los administradores funcionales.

▼M1









ANEXO II

NORMAS PARA CUMPLIMENTAR EL CERTIFICADO COVID DIGITAL DE LA UE

Las normas generales relativas a los conjuntos de valores establecidas en el presente anexo tienen por objeto garantizar la interoperabilidad en el plano semántico y permitirán implementaciones técnicas uniformes para el certificado COVID digital de la UE. Los elementos contenidos en este anexo pueden utilizarse en los tres diferentes escenarios (vacunación/pruebas/recuperación), tal como se establece en el Reglamento (UE) 2021/953. En este anexo solo se enumeran los elementos que requieren una normalización semántica mediante conjuntos de valores codificados.

La traducción de los elementos codificados a la lengua nacional es responsabilidad de los Estados miembros.

Para todos los campos de datos no mencionados en las siguientes descripciones de conjuntos de valores, la codificación se describe en el anexo V.

Si por alguna razón no se pueden utilizar los sistemas de codificación preferidos que se enumeran a continuación, se pueden utilizar otros sistemas de codificación internacionales y se asesorará sobre cómo asignar los códigos del otro sistema de codificación al sistema de codificación preferido. El texto (nombres visualizados) puede utilizarse en casos excepcionales como mecanismo de reserva cuando no se disponga de un código adecuado en los conjuntos de valores definidos.

Los Estados miembros que utilicen otro tipo de codificación en sus sistemas asignarán dichos códigos a los conjuntos de valores descritos. Los Estados miembros son responsables de estas asignaciones.

Dado que algunos conjuntos de valores basados en los sistemas de codificación previstos en el presente anexo, como los de codificación de vacunas y de pruebas rápidas de antígenos, cambian con frecuencia, la Comisión los publicará y actualizará periódicamente con el apoyo de la red de sanidad electrónica y del Comité de Seguridad Sanitaria. Los conjuntos de valores actualizados se publicarán en el sitio web correspondiente de la Comisión, así como en la página web de la red de sanidad electrónica. Se proporcionará un historial de cambios.

1. Enfermedad o agente para el que se vacuna/Enfermedad o agente del que se ha recuperado el titular: COVID-19 (SARS-CoV-2 o una de sus variantes)

Utilícese en los certificados 1, 2 y 3.

Se utilizará el código siguiente:







Código Visualización Nombre del sistema de codificación URL del sistema de codificación OID del sistema de codificación Versión del sistema de codificación 840539006 COVID-19 SNOMED CT http://snomed.info/sct 2.16.840.1.113883.6.96 2021-01-31

2. Vacuna o profilaxis de la COVID-19

Sistema de codificación preferido: Clasificación SNOMED CT o ATC

Utilícese en el certificado 1.

Algunos de los códigos que se utilizarán de los sistemas de codificación preferidos son, por ejemplo, el código SNOMED CT 1119305005 (vacuna de antígeno del SARS-CoV-2), 1119349007 (vacuna de ARNm del SARS-CoV-2) o J07BX03 (vacunas de la COVID-19).

La Comisión publicará y actualizará periódicamente, con el apoyo de la red de sanidad electrónica, un conjunto de valores que establezca los códigos que deben utilizarse con arreglo a los sistemas de codificación previstos en la presente sección. El conjunto de valores se ampliará cuando se desarrollen y pongan en uso nuevos tipos de vacunas.

3. Vacuna contra la COVID-19

Sistemas de codificación preferidos (por orden de preferencia):

— Registro de la Unión de medicamentos para vacunas con autorización en toda la UE (números de autorización).

— Un registro mundial de vacunas, como el que podría establecer la Organización Mundial de la Salud.

— Nombre de la vacuna en otros casos. Si el nombre incluye espacios en blanco, estos se sustituirán por un guion (-).

Nombre del conjunto de valores: Vacuna.

Utilícese en el certificado 1.

Un ejemplo de código de los sistemas de codificación preferidos que se utilizará es EU/1/20/1528 (Comirnaty). Ejemplo de nombre de vacuna que se utilizará como código: Sputnik-V (siglas de Sputnik V).

La Comisión publicará y actualizará periódicamente, con el apoyo de la red de sanidad electrónica, un conjunto de valores que establezca los códigos que deben utilizarse con arreglo a los sistemas de codificación previstos en la presente sección.

Las vacunas se codificarán utilizando un código existente en el conjunto de valores publicado, aunque sus nombres sean diferentes en los distintos países. La razón es que todavía no existe un registro mundial de vacunas que cubra todas las vacunas en uso en la actualidad. Ejemplo:

— Para la vacuna «COVID-19 Vaccine Moderna Intramuscular Injection», que es el nombre de la vacuna Spikevax en Japón, utilícese el código EU/1/20/1507, ya que es el nombre de esta vacuna en la UE.

Si esto no fuera posible o aconsejable en un caso concreto, se indicará un código separado en el conjunto de valores publicados.

4. Titular de la autorización de comercialización o fabricante de la vacuna contra la COVID-19

Sistema de codificación preferido:

— Código de organización de la EMA (sistema SPOR para ISO IDMP).

— Un registro mundial de titulares de autorizaciones de comercialización o de fabricantes de vacunas, como el que podría establecer la Organización Mundial de la Salud.

— Nombre de la organización en otros casos. Si el nombre incluye espacios en blanco, estos se sustituirán por un guion (-).

Utilícese en el certificado 1.

Un ejemplo de código que se utilizará del sistema de codificación preferido es ORG-100001699 (AstraZeneca AB). Un ejemplo de nombre de organización que se utilizará como código: Sinovac-Biotech (siglas de Sinovac Biotech).

La Comisión publicará y actualizará periódicamente, con el apoyo de la red de sanidad electrónica, un conjunto de valores que establezca los códigos que deben utilizarse con arreglo a los sistemas de codificación previstos en la presente sección.

Las diferentes sucursales de un mismo titular de la autorización de comercialización o de un mismo fabricante utilizarán un código existente en el conjunto de valores publicados.

Como norma general, para el mismo producto de la vacuna, se utilizará el código referente a su titular de autorización de comercialización en la UE, ya que todavía no existe un registro de fabricantes de vacunas o titulares de autorizaciones de comercialización acordado internacionalmente. Ejemplos:

— Para la organización «Pfizer AG», que es un titular de la autorización de comercialización (TAC) de la vacuna «Comirnaty» utilizada en Suiza, utilícese el código ORG-100030215 que hace referencia a BioNTech Manufacturing GmbH, ya que es el TAC de Comirnaty en la UE.

— Para la organización «Zuellig Pharma», que es un TAC de la vacuna Covid-19 Vaccine Moderna (Spikevax) utilizada en Filipinas, utilícese el código ORG-100031184 referido a Moderna Biotech Spain S.L., ya que es el TAC de Spikevax en la UE.

Si esto no fuera posible o aconsejable en un caso concreto, se indicará un código separado en el conjunto de valores publicados.

5. Número en una serie de dosis, así como número total de dosis en la serie

Utilícese en el certificado 1.

Dos campos:

1) Número en una serie de dosis de una vacuna contra la COVID-19 (N);

2) Número total de dosis en la serie de vacunación (C).

5.1. Pauta de primovacunación

Cuando la persona reciba dosis de la pauta de primovacunación, es decir, la pauta de vacunación destinada a proporcionar una protección suficiente en una fase inicial, (C) reflejará el número total de dosis de la pauta estándar de primovacunación (por ejemplo, 1 o 2, dependiendo del tipo de vacuna administrada). Esto incluye la opción de utilizar una pauta más corta (C=1) cuando el protocolo de vacunación aplicado por un Estado miembro prevea la administración de una única dosis de una vacuna de 2 dosis a personas que hayan sido previamente infectadas por el SARS-CoV-2. Una pauta de primovacunación completada se indicará, por tanto, mediante la inscripción: N/C = 1. Así, por ejemplo:

— 1/1 indicaría la finalización de una pauta de primovacunación de una sola dosis, o la finalización de una pauta consistente en una dosis de una vacuna de 2 dosis administrada a una persona recuperada de conformidad con el protocolo de vacunación aplicado por un Estado miembro;

— 2/2 indicaría la finalización de una pauta de primovacunación compuesta de 2 dosis.

Cuando se amplíe la pauta de primovacunación, por ejemplo, en el caso de las personas con sistemas inmunitarios gravemente debilitados o cuando no se haya respetado el intervalo recomendado entre dosis de primovacunación, cualquier dosis de este tipo se codificará como dosis adicionales incluidas en la sección 5.2.

▼M2

5.2. Dosis de refuerzo

Cuando sean administradas tras la pauta de primovacunación, dichas dosis de refuerzo se reflejarán en los certificados correspondientes de la manera siguiente:

— 2/1 indica la administración de una dosis de refuerzo con posterioridad a una pauta de primovacunación de una sola dosis, o la administración de una dosis de refuerzo tras la finalización de una pauta consistente en una dosis de una vacuna de dos dosis administrada a una persona recuperada de conformidad con el protocolo de vacunación aplicado por un Estado miembro. Después de esto, las dosis (X) administradas después de la primera dosis de refuerzo se indicarán mediante (2 + X) / (1) > 1 (3/1, por ejemplo);

— 3/3 indica la administración de una dosis de refuerzo con posterioridad a una pauta de primovacunación de dos dosis. Después de esto, las dosis (X) administradas después de la primera dosis de refuerzo se indicarán mediante (3 + X) / (3 + X) = 1 (4/4, por ejemplo).

Los Estados miembros aplicarán las normas de codificación establecidas en la presente sección a más tardar el 1 de febrero de 2022.

Los Estados miembros, automáticamente o a petición de las personas afectadas, volverán a expedir los certificados en los que la administración de una dosis de refuerzo tras un ciclo de primovacunación de dosis única se codifique de forma que no pueda distinguirse de la finalización de la pauta de primovacunación.

A efectos del presente anexo, debe entenderse que las referencias a las «dosis de refuerzo» abarcan también las dosis adicionales administradas para proteger mejor a las personas que presenten respuestas inmunitarias insuficientes tras la finalización de la pauta de primovacunación normal. Dentro del marco jurídico establecido por el Reglamento (UE) 2021/953, los Estados miembros podrán adoptar medidas para atender a la situación de los grupos vulnerables que pueden recibir dosis adicionales con carácter prioritario. Por ejemplo, si un Estado miembro decide administrar dosis adicionales únicamente a subgrupos específicos de la población, puede optar, de conformidad con el artículo 5, apartado 1, del Reglamento (UE) 2021/953, por expedir certificados de vacunación que indiquen la administración de dichas dosis adicionales solo previa solicitud y no automáticamente. Cuando se adopten tales medidas, los Estados miembros informarán de ello a las personas afectadas, y les comunicarán asimismo que podrán seguir utilizando el certificado recibido una vez completada la pauta estándar de primovacunación.

▼M1

6. Estado miembro o tercer país en el que se administró la vacuna/se realizó la prueba

Sistema de codificación preferido: Códigos de país ISO 3166.

Utilícese en los certificados 1, 2 y 3.

Contenido del conjunto de valores: la lista completa de códigos de 2 letras, disponible como conjunto de valores definidos en FHIR (http://hl7.org/fhir/ValueSet/iso3166-1-2) Si la vacunación o la prueba ha sido realizada por una organización internacional (como el ACNUR o la OMS) y no se dispone de información sobre el país, se utilizará un código para la organización. La Comisión publicará y actualizará periódicamente dichos códigos adicionales con el apoyo de la red de sanidad electrónica.

7. Tipo de prueba

Utilícese en el certificado 2, y en el certificado 3 sólo si, mediante un acto delegado, se introduce la expedición de certificados de recuperación basados en tipos de prueba distintos de la NAAT.

Se utilizarán los códigos siguientes.







Código Visualización Nombre del sistema de codificación URL del sistema de codificación OID del sistema de codificación Versión del sistema de codificación LP6464-4 Amplificación de los ácidos nucleicos con detección por sonda LOINC http://loinc.org 2.16.840.1.113883.6.1 2.69 LP217198-3 Inmunoanálisis rápido LOINC http://loinc.org 2.16.840.1.113883.6.1 2.69

8. Fabricante y nombre comercial de la prueba utilizada (opcional para la prueba NAAT)

Utilícese en el certificado 2.

El contenido del conjunto de valores incluirá la selección de pruebas rápidas de antígenos que figuran en la lista común y actualizada de pruebas rápidas de antígenos de la COVID-19, establecida sobre la base de la Recomendación 2021/C 24/01 del Consejo y acordada por el Comité de Seguridad Sanitaria. El JRC mantiene la lista en la base de datos de dispositivos de diagnóstico in vitro y métodos de prueba de la COVID-19 en: https://covid-19-diagnostics.jrc.ec.europa.eu/devices/hsc-common-recognition-rat

Para este sistema de codificación, se utilizarán los campos pertinentes, como el identificador del dispositivo de la prueba, el nombre de la prueba y el fabricante, siguiendo el formato estructurado del JRC disponible en https://covid-19-diagnostics.jrc.ec.europa.eu/devices

9. Resultado de la prueba

Utilícese en el certificado 2.

Se utilizarán los códigos siguientes:







Código Visualización Nombre del sistema de codificación URL del sistema de codificación OID del sistema de codificación Versión del sistema de codificación 260415000 No detectado SNOMED CT http://snomed.info/sct 2.16.840.1.113883.6.96 2021-01-31 260373001 Detectado SNOMED CT http://snomed.info/sct 2.16.840.1.113883.6.96 2021-01-31

▼B









ANEXO III

ESTRUCTURA COMÚN DEL IDENTIFICADOR ÚNICO DE CERTIFICADO

1. Introducción

Todo certificado COVID digital de la UE (CCD) incluirá un identificador único de certificado (UCI) que contribuya a la interoperabilidad de dichos certificados. El UCI puede utilizarse para verificar el certificado. Los Estados miembros serán responsables de la implementación del UCI. El UCI es un medio para verificar la veracidad del certificado y, en su caso, para enlazar con un sistema de registro (por ejemplo, un sistema de información sobre vacunación). Estos identificadores también permitirán a los Estados miembros afirmar (en papel y digitalmente) que las personas han recibido la vacuna o se han sometido a pruebas.

2. Composición del identificador único de certificado

El UCI seguirá una estructura y un formato comunes que faciliten la interpretación humana o mecánica de la información y podrá referirse a elementos como el Estado miembro de vacunación, la propia vacuna y un identificador específico del Estado miembro. Garantiza la flexibilidad de los Estados miembros para formatearlo, respetando plenamente la legislación sobre protección de datos. El orden de los distintos elementos sigue una jerarquía definida que puede permitir futuras modificaciones de los bloques y mantiene su integridad estructural.

Las posibles soluciones para la composición del UCI forman un espectro en el que la modularidad y la interpretabilidad humana son los dos principales parámetros diversificadores y una característica fundamental:

— Modularidad: el grado en que el código está compuesto por bloques componentes distintos que contienen información semánticamente diferente.

— Interpretabilidad humana: el grado en que el código tiene sentido o puede ser interpretado por el lector humano.

— Único a nivel mundial; el identificador de país o autoridad está bien gestionado; y se espera que cada país (autoridad) gestione bien su segmento del espacio de nombres y no recicle ni vuelva a emitir nunca identificadores. La combinación de todo ello garantiza que cada identificador sea único a nivel mundial.

▼M1

3. Requisitos generales

Se cumplirán los siguientes requisitos generales en relación con el UCI:

1) Juego de caracteres: solo se admiten caracteres alfanuméricos US-ASCII en mayúsculas (de la «A» a la «Z» y del «0» al «9»). con caracteres especiales adicionales para separarse de RFC3986 ( 14 ), a saber {’/’,’#’,’:’};

2) Longitud máxima: los diseñadores intentarán que la longitud sea de veintisiete a treinta caracteres ( 15 ).

3) Prefijo de la versión: se refiere a la versión del esquema del UCI. El prefijo de la versión es «01» para esta versión del documento; el prefijo de la versión se compone de dos dígitos.

4) Prefijo del país: el código de país se especifica mediante la norma ISO 3166-1. Los códigos más largos (de tres caracteres en adelante, por ejemplo, «ACNUR») se reservan para su uso futuro.

5) Sufijo del código / suma de comprobación: 5.1 Los Estados miembros podrán utilizar una suma de comprobación cuando sea probable que se produzcan transmisiones, transcripciones (humanas) u otras corrupciones (es decir, cuando se utilice en formato impreso). 5.2 La suma de comprobación no se utilizará para validar el certificado y no forma parte técnicamente del identificador, sino que se utiliza para verificar la integridad del código. Esta suma de comprobación será el resumen ISO-7812-1 (LUHN-10) ( 16 ) de todo el UCI en formato de transporte digital / por cable. La suma de comprobación se separa del resto del UCI con el carácter «#».

Se garantizará la retrocompatibilidad: los Estados miembros que con el tiempo cambien la estructura de sus identificadores (dentro de la versión principal, actualmente v1) garantizarán que dos identificadores idénticos representen el mismo certificado o afirmación de vacunación. O, en otras palabras, los Estados miembros no pueden reciclar los identificadores.

▼B

4. Opciones de identificadores únicos para los certificados de vacunación

Las directrices de la red de sanidad electrónica para los certificados de vacunación verificables y los elementos básicos de interoperabilidad ( 17 ) prevén diferentes opciones disponibles para los Estados miembros y otras partes que pueden coexistir entre diferentes Estados miembros. Los Estados miembros pueden utilizar estas diferentes opciones en diferentes versiones del esquema UCI.









ANEXO IV

GOBERNANZA DEL CERTIFICADO DE CLAVE PÚBLICA

1. Introducción

El intercambio seguro y fiable de claves de firma para los certificados COVID digitales (CCD) de la UE entre los Estados miembros se realiza a través de la Pasarela del Certificado COVID Digital de la UE (DCCG), que actúa como repositorio central de las claves públicas. Con la DCCG, los Estados miembros están facultados para publicar las claves públicas correspondientes a las claves privadas que utilizan para firmar los certificados COVID digitales. Los Estados miembros que dependen de ella pueden utilizar la DCCG para obtener material de claves públicas actualizado en el momento oportuno. Más adelante, la DCCG puede ampliarse para intercambiar información complementaria de confianza que proporcionen los Estados miembros, como las normas de validación de los CCD. El modelo de confianza del marco de CCD es una infraestructura de clave pública (PKI). Cada Estado miembro mantiene una o varias autoridades nacionales de firma de certificados (CSCA), cuyos certificados tienen una vida relativamente larga. De acuerdo con la decisión del Estado miembro, la CSCA puede ser la misma o diferente de la utilizada para los documentos de viaje de lectura mecánica. La CSCA emite certificados de clave pública para los firmantes de documentos nacionales, de corta duración (es decir, los firmantes de los CCD), que se denominan certificados de firmante de documentos (DSC). La CSCA actúa como anclaje de confianza, de modo que los Estados miembros que confían en ella pueden utilizar el certificado de la CSCA para validar la autenticidad e integridad de los DSC que cambian periódicamente. Una vez validados, los Estados miembros pueden proporcionar estos certificados (o solo las claves públicas que contienen) a sus aplicaciones de validación del CCD. Además de las CSCA y los DSC, la DCCG también utiliza la PKI para autenticar las transacciones y firmar los datos, como base de la autenticación y como medio para garantizar la integridad de los canales de comunicación entre los Estados miembros y la DCCG.

Las firmas digitales pueden utilizarse para lograr la integridad y la autenticidad de los datos. Las infraestructuras de clave pública establecen la confianza vinculando las claves públicas a identidades verificadas (o emisores). Esto es necesario para que otros participantes puedan verificar el origen de los datos y la identidad del interlocutor de la comunicación y decidir sobre la confianza. En la DCCG, se utilizan varios certificados de clave pública en aras de la autenticidad. Este anexo define qué certificados de clave pública se utilizan y cómo deben diseñarse para permitir una amplia interoperabilidad entre los Estados miembros. Proporciona más detalles sobre los certificados de clave pública necesarios y ofrece orientaciones sobre las plantillas de los certificados y los períodos de validez para los Estados miembros que quieran operar su propia CSCA. Dado que los CCD deben ser verificables durante un período de tiempo definido (a partir de la emisión, expiran después de un tiempo determinado), es necesario definir un modelo de verificación para todas las firmas aplicadas en los certificados de clave pública y los CCD.

2. Terminología

La siguiente tabla contiene las abreviaturas y la terminología utilizadas en este anexo.







Término Definición Certificado O certificado de clave pública. Un certificado X.509 v3 que contiene la clave pública de una entidad CSCA Autoridad nacional de firma de certificados CCD Certificado COVID digital de la UE. Un documento digital firmado que contiene información sobre la vacunación, las pruebas o la recuperación DCCG Pasarela del Certificado COVID Digital de la UE. Este sistema se utiliza para intercambiar DSC entre los Estados miembros DCCGTA El certificado de anclaje de veracidad de la DCCG. La clave privada correspondiente se utiliza para firmar la lista de todos los certificados CSCA fuera de línea DCCGTLS El certificado de servidor TLS de la DCCG DSC Certificado de firmante de documentos. El certificado de clave pública de la autoridad de firma de documentos de un Estado miembro (por ejemplo, un sistema que está autorizado a firmar CCD). Este certificado lo expide la CSCA del Estado miembro EC-DSA Algoritmo de firma digital de curva elíptica. Un algoritmo de firma criptográfica basado en curvas elípticas Estado miembro Estado miembro de la Unión Europea mTLS TLS mutua. El protocolo de seguridad de la capa de transporte con autenticación mutua Nota: El backend nacional de un Estado miembro NBCSCA El certificado CSCA de un Estado miembro (puede ser más de uno) NBTLS El certificado de autenticación de cliente TLS de un backend nacional NBUP El certificado que un backend nacional utiliza para firmar los paquetes de datos que se cargan en la DCCG PKI Infraestructura de clave pública. Modelo de confianza basado en certificados de clave pública y autoridades de certificación RSA Algoritmo criptográfico asimétrico basado en la factorización de enteros utilizado para la firma digital o el cifrado asimétrico

3. Flujos de comunicación y servicios de seguridad de la DCCG

Esta sección ofrece una visión general de los flujos de comunicación y los servicios de seguridad en el sistema DCCG. También define qué claves y certificados se utilizan para proteger la comunicación, la información cargada, los CCD y una lista de confianza firmada que contiene todos los certificados CSCA incorporados. La DCCG funciona como un centro de datos que permite el intercambio de paquetes de datos firmados para los Estados miembros.

Los paquetes de datos cargados son proporcionados por la DCCG «tal cual», lo que significa que la DCCG no añade ni elimina DSC de los paquetes que recibe. El backend nacional (NB) de los Estados miembros estará habilitado para verificar la integridad y autenticidad de extremo a extremo de los datos cargados. Además, los backend nacionales y la DCCG utilizarán la autenticación mutua TLS para establecer una conexión segura. Esto se suma a las firmas en los datos intercambiados.

3.1. Autenticación y establecimiento de la conexión

La DCCG utiliza la seguridad de la capa de transporte (TLS) con autenticación mutua para establecer un canal cifrado autenticado entre el backend nacional (NB) del Estado miembro y el entorno de la Pasarela. Por lo tanto, la DCCG posee un certificado de servidor TLS (DCCGTLS) y los backends nacionales poseen un certificado de cliente TLS (NBTLS). Las plantillas de los certificados se proporcionan en la sección 5. Cada backend nacional puede proporcionar su propio certificado TLS. Este certificado se incluirá explícitamente en la lista blanca y, por lo tanto, puede ser emitido por una autoridad certificadora de confianza pública (por ejemplo, una autoridad certificadora que siga los requisitos básicos del CA/Browser Forum), por una autoridad certificadora nacional o puede ser autofirmado. Cada Estado miembro es responsable de sus datos nacionales y de la protección de la clave privada utilizada para establecer la conexión con la DCCG. El enfoque de «traiga su propio certificado» requiere un proceso de registro e identificación bien definido, así como procedimientos de revocación y renovación, como se describe en las secciones 4.1, 4.2y 4.3. La DCCG utiliza una lista blanca en la que se añaden los certificados TLS de los Nota: tras haberse registrado satisfactoriamente. Solo los Nota: que se autentiquen con una clave privada que corresponda a un certificado de la lista blanca pueden establecer una conexión segura con la DCCG. La DCCG también utilizará un certificado TLS que permite a los Nota: verificar que realmente están estableciendo una conexión con la DCCG «real» y no con alguna entidad malintencionada que se hace pasar por ella. El certificado de la DCCG se entregará a los Nota: una vez se haya registrado correctamente. El certificado DCCGTLS será emitido por una autoridad de certificación de confianza pública (incluida en todos los principales navegadores). Es responsabilidad de los Estados miembros verificar que su conexión a la DCCG es segura (por ejemplo, cotejando la huella dactilar del certificado DCCGTLS del servidor al que se conecta con la proporcionada tras el registro).

3.2. Autoridades nacionales de firma de certificados y modelo de validación

Los Estados miembros que participan en el marco de la DCCG deben utilizar una CSCA para emitir los DSC. Los Estados miembros pueden tener más de una CSCA, por ejemplo, en caso de descentralización regional. Cada Estado miembro puede utilizar las autoridades de certificación existentes o crear una autoridad de certificación específica (posiblemente autofirmada) para el sistema del CCD.

Los Estados miembros deben presentar su(s) certificado(s) CSCA al operador de la DCCG durante el procedimiento oficial de incorporación. Tras el registro satisfactorio del Estado miembro (véase la sección 4.1 para más detalles), el operador de la DCCG actualizará una lista de confianza firmada que contiene todos los certificados CSCA que están activos en el marco del CCD. El operador de la DCCG utilizará un par de claves asimétricas específico para firmar la lista de confianza y los certificados en un entorno sin conexión. La clave privada no se almacenará en el sistema DCCG en línea, de manera que, si el sistema en línea se ve comprometido, un atacante no pueda comprometer la lista de confianza. El correspondiente certificado de anclaje de veracidad DCCGTA se proporcionará a los backends nacionales durante el proceso de incorporación.

Los Estados miembros pueden obtener la lista de confianza de la DCCG para sus procedimientos de verificación. La CSCA se define como la autoridad de certificación que emite los DSC, por lo que los Estados miembros que utilizan una jerarquía de autoridades de certificación (AC) de varios niveles (por ejemplo, AC raíz -> CSCA -> DSC) deben proporcionar la autoridad de certificación subordinada que emite los DSC. En este caso, si un Estado miembro utiliza una autoridad de certificación existente, el sistema de CCD ignorará todo lo que esté por encima de la CSCA y pondrá en la lista blanca solo la CSCA como anclaje de veracidad (aunque sea una autoridad de certificación subordinada). Esto se debe a que el modelo de la OACI solo permite exactamente dos niveles: una CSCA «raíz» y un DSC «hoja» firmado solo por esa CSCA.

En caso de que un Estado miembro opere su propia CSCA, el Estado miembro es responsable del funcionamiento seguro y de la gestión de claves de esta autoridad de certificación. La CSCA actúa como anclaje de veracidad para los DSC, por lo que la protección de la clave privada de la CSCA es esencial para la integridad del entorno de los CCD. El modelo de verificación en la PKI del CCD es el modelo «shell», que establece que todos los certificados en la validación de la ruta de certificados deben ser válidos en un momento determinado (es decir, en el momento de validación de la firma). Por lo tanto, se aplican las siguientes restricciones:

— La CSCA no emitirá certificados cuya validez sea mayor que la del propio certificado de la autoridad de certificación.

— El firmante del documento no firmará documentos cuya validez sea mayor que la del propio DSC.

— Los Estados miembros que gestionan su propia CSCA deben definir los períodos de validez de su CSCA y de todos los certificados emitidos y deben ocuparse de la renovación de los certificados.

La sección 4.2 contiene recomendaciones sobre los períodos de validez.

3.3. Integridad y autenticidad de los datos cargados

Los backends nacionales pueden utilizar la DCCG para cargar y descargar paquetes de datos firmados digitalmente tras una autenticación mutua satisfactoria. En un principio, estos paquetes de datos contienen los DSC de los Estados miembros. El par de claves que utiliza el backend nacional para la firma digital de los paquetes de datos cargados en el sistema de la DCCG se denomina «par de claves de firma de carga del backend nacional» y el certificado de clave pública correspondiente se abrevia como «certificado NBUP». Cada Estado miembro aporta su propio certificado NBUP, que puede ser autofirmado o emitido por una autoridad de certificación existente, como una autoridad de certificación pública (es decir, una autoridad que emite certificados de acuerdo con los requisitos básicos del CAB-Forum). El certificado NBUP será diferente de cualquier otro certificado utilizado por el Estado miembro (es decir, CSCA, cliente TLS o DSC).

Los Estados miembros deben proporcionar el certificado de carga al operador de la DCCG durante el procedimiento de registro inicial (véase la sección 4.1 para más detalles). Cada Estado miembro es responsable de sus datos nacionales y debe proteger la clave privada que se utiliza para firmar las cargas.

Otros Estados miembros pueden verificar los paquetes de datos firmados utilizando los certificados de carga que proporciona la DCCG. La DCCG verifica la autenticidad e integridad de los datos cargados con el certificado de carga de Nota: antes de que se faciliten a otros Estados miembros.

3.4. Requisitos de la arquitectura técnica de la DCCG

Los requisitos de la arquitectura técnica de la DCCG son los siguientes:

— La DCCG utiliza la autenticación mutua TLS para establecer una conexión cifrada autenticada con los Nota: Por lo tanto, la DCCG mantiene una lista blanca de certificados de cliente NB TLS registrados.

— La DCCG utiliza dos certificados digitales (DCCG TLS y DCCG TA ) con dos pares de claves distintas. La clave privada del par de claves DCCG TA se mantiene fuera de línea (no en los componentes en línea de la DCCG).

— La DCCG mantiene una lista de confianza de los certificados NB CSCA que está firmada con la clave privada DCCG TA .

— Los cifrados utilizados deben cumplir los requisitos de la sección 5.1 .

4. Gestión del ciclo de vida de los certificados

4.1. Registro de backends nacionales

Los Estados miembros deben registrarse en el operador de la DCCG para participar en su sistema. Esta sección describe el procedimiento técnico y operativo que debe seguirse para registrar un backend nacional.

El operador de la DCCG y el Estado miembro deben intercambiar información sobre las personas de contacto técnico para el proceso de incorporación. Se supone que las personas de contacto técnico están legitimadas por sus Estados miembros y la identificación/autenticación se realiza por otros canales. Por ejemplo, la autenticación puede lograrse cuando el contacto técnico de un Estado miembro proporciona los certificados como archivos cifrados con contraseña por correo electrónico y comparte la contraseña correspondiente con el operador de la DCCG por teléfono. También pueden utilizarse otros canales seguros definidos por el operador de la DCCG.

El Estado miembro debe proporcionar tres certificados digitales durante el proceso de registro e identificación:

— El certificado TLS NB TLS del Estado miembro.

— El certificado de carga NB UP del Estado miembro.

— El certificado o los certificados NB CSCA de la CSCA del Estado miembro.

Todos los certificados proporcionados deben cumplir los requisitos definidos en la sección 5. El operador de la DCCG verificará que el certificado proporcionado se adhiere a los requisitos de la sección 5. Tras la identificación y el registro, el operador de la DCCG:

— añade el certificado o los certificados NB CSCA a la lista de confianza firmados con la clave privada que corresponde a la clave pública DCCG TA ;

— añade el certificado NB TLS a la lista blanca del punto final TLS de la DCCG;

— añade el certificado NB UP al sistema DCCG;

— proporciona el certificado de clave pública DCCG TA y DCCG TLS al Estado miembro.

4.2. Autoridades de certificación, períodos de validez y renovación

En caso de que un Estado miembro quiera operar su propia CSCA, los certificados de la CSCA pueden ser certificados autofirmados. Actúan como anclaje de veracidad del Estado miembro y, por lo tanto, este debe proteger firmemente la clave privada correspondiente a la clave pública del certificado CSCA. Se recomienda que los Estados miembros utilicen un sistema fuera de línea para su CSCA, es decir, un sistema informático que no esté conectado a ninguna red. Se utilizará un control multipersonal para acceder al sistema (por ejemplo, siguiendo el principio de la presencia de dos personas). Tras la firma de los DSC, se aplicarán controles operativos y el sistema que contiene la clave privada de la CSCA se almacenará de forma segura con estrictos controles de acceso. Se pueden utilizar módulos de seguridad de hardware o tarjetas inteligentes para proteger aún más la clave privada de la CSCA. Los certificados digitales contienen un período de validez que obliga a la renovación del certificado. La renovación es necesaria para utilizar claves criptográficas nuevas y para adaptar el tamaño de las claves cuando nuevas mejoras en el cálculo o nuevos ataques amenacen la seguridad del algoritmo criptográfico que se utiliza. Se aplica el modelo «shell» (véase la sección 3.2).

Se recomiendan los siguientes períodos de validez, dado que la validez de los certificados COVID digitales es de un año:

— CSCA: 4 años

— DSC: 2 años

— Carga: 1-2 años

— Autenticación de clientes TLS: 1-2 años

Para una renovación oportuna, se recomiendan los siguientes períodos de uso de las claves privadas:

— CSCA: 1 año

— DSC: 6 meses

Los Estados miembros deben crear nuevos certificados de carga y certificados TLS a tiempo, por ejemplo, un mes antes de la expiración, para permitir un funcionamiento sin problemas. Los certificados CSCA y los DSC deben renovarse al menos un mes antes de que finalice el uso de la clave privada (teniendo en cuenta los procedimientos operativos necesarios). Los Estados miembros deben proporcionar los certificados CSCA y los certificados de carga y TLS actualizados al operador de la DCCG. Los certificados caducados se eliminarán de la lista blanca y de la lista de confianza.

Los Estados miembros y el operador de la DCCG deben llevar un control de la validez de sus propios certificados. No existe una entidad central que mantenga un registro de la validez del certificado e informe a los participantes.

4.3. Revocación de certificados

En general, los certificados digitales pueden ser revocados por su autoridad de certificación emisora mediante listas de revocación de certificados o el respondedor del protocolo de comprobación del estado de un certificado (respondedor OCSP). Las CSCA para el sistema de CCD deben proporcionar listas de revocación de certificados (CRL). Aunque otros Estados miembros no utilicen actualmente estas CRL, deberían integrarse para futuras aplicaciones. En caso de que una CSCA decida no proporcionar CRL, los DSC de esta CSCA deberán renovarse cuando las CRL sean obligatorias. Los verificadores no deben utilizar OCSP para la validación de los DSC y deben utilizar CRL. Se recomienda que el backend nacional realice la validación necesaria de los DSC descargados del Portal de CCD y solo remita un conjunto de DSC de confianza y validados a los validadores de CCD nacionales. Los validadores de CCD no deben realizar ninguna comprobación de revocación de DSC en su proceso de validación. Una de las razones para ello es proteger la privacidad de los titulares de CCD y evitar cualquier posibilidad de que el uso de cualquier DSC particular pueda ser monitorizado por su respondedor OCSP asociado.

Los Estados miembros pueden retirar sus DSC de la DCCG por su cuenta utilizando certificados válidos de carga y TLS. La eliminación de un DSC significa que todos los CCD emitidos con este DSC dejarán de ser válidos cuando los Estados miembros obtengan las listas de DSC actualizadas. La protección del material de clave privada correspondiente a las DSC es crucial. Los Estados miembros deben informar al operador de la DCCG cuando deban revocar los certificados de carga o TLS, por ejemplo, debido a que se haya comprometido el backend nacional. El operador de la DCCG puede entonces eliminar la confianza del certificado afectado, por ejemplo, eliminándolo de la lista blanca de TLS. El operador de la DCCG puede eliminar los certificados de carga de la base de datos de la DCCG. Los paquetes firmados con la clave privada correspondiente a este certificado de carga dejarán de ser válidos cuando los backends nacionales eliminen la confianza del certificado de carga revocado. En caso de que deba revocarse un certificado CSCA, los Estados miembros informarán al operador de la DCCG, así como a otros Estados miembros con los que tengan relaciones de confianza. El operador de la DCCG emitirá una nueva lista de confianza en la que ya no figure el certificado afectado. Todos los DSC emitidos por esta CSCA dejarán de ser válidos cuando los Estados miembros actualicen su almacén nacional de confianza. En caso de que deban revocarse el certificado DCCGTLS o el certificado DCCGTA, el operador de la DCCG y los Estados miembros deberán colaborar para establecer una nueva conexión TLS de confianza y una lista de confianza.

5. Plantillas de certificados

Esta sección establece los requisitos criptográficos y orientaciones, así como los requisitos sobre las plantillas de los certificados. Para los certificados de la DCCG, esta sección define las plantillas de los certificados.

5.1. Requisitos criptográficos

Los algoritmos criptográficos y los conjuntos de cifrado TLS se elegirán sobre la base de la recomendación actual del Servicio federal alemán de Seguridad de la Información (BSI) o SOG-IS. Estas recomendaciones y las de otras instituciones y organizaciones de normalización son similares. Las recomendaciones pueden encontrarse en las directrices técnicas TR 02102-1 y TR 02102-2 ( 18 ) o en los mecanismos criptográficos acordados por SOG-IS ( 19 ).

5.1.1. Requisitos del DSC

Se aplicarán los requisitos previstos en el anexo I de la sección 3.2.2. Por lo tanto, se recomienda encarecidamente que los firmantes de documentos utilicen el algoritmo de firma digital de curva elíptica (ECDSA) con NIST-p-256 (como se define en el apéndice D de FIPS PUB 186-4). No se admiten otras curvas elípticas. Debido a las restricciones de espacio del CCD, los Estados miembros no deben utilizar el RSA-PSS, aunque se permita como algoritmo de reserva. En caso de que los Estados miembros utilicen el RSA-PSS, deberán utilizar un tamaño de módulo de 2048 o, como máximo, de 3072 bits. Se utilizará SHA-2 con una longitud de salida de ≥ 256 bits como función resumen (hash) criptográfica (véase ISO/IEC 10118-3:2004) para la firma DSC.

5.1.2. Requisitos sobre certificados TLS, de carga y CSCA

Para los certificados digitales y las firmas criptográficas en el contexto de la DCCG, los principales requisitos sobre los algoritmos criptográficos y la longitud de las claves se resumen en la siguiente tabla (a partir de 2021):







Algoritmo de firma Tamaño de la clave Función resumen (hash) EC-DSA Mínimo 250 bits SHA-2 con una longitud de salida ≥ 256 bits RSA-PSS (relleno recomendado) RSA-PKCS#1 v1.5 (relleno heredado) Mínimo 3000 bits de módulo RSA (N) con un exponente público e > 2^16 SHA-2 con una longitud de salida ≥ 256 bits DSA Mín. 3000 bits primo p, 250 bits clave q SHA-2 con una longitud de salida ≥ 256 bits

La curva elíptica recomendada para EC-DSA es NIST-p-256 debido a su aplicación generalizada.

5.2. Certificado CSCA (NBCSCA)

El siguiente cuadro ofrece orientación sobre el modelo de certificado NBCSCA si un Estado miembro decide operar su propio CSCA para el sistema de CCD.

Las entradas en negrita son obligatorias (deben incluirse en el certificado), las entradas en cursiva son recomendables (deberían incluirse). Para los campos ausentes, no se definen recomendaciones.







Campo Valor Subject cn=<nombre común único y no vacío>, o=<Proveedor>, c=<Estado miembro que opera la CSCA> Key usage firma de certificados, firma de CRL (como mínimo) Restricciones básicas CA = true, path length constraints = 0

El nombre del asunto no debe estar vacío y debe ser único dentro del Estado miembro especificado. El código de país (c) debe coincidir con el Estado miembro que utilizará este certificado CSCA. El certificado debe contener un identificador de clave del firmante único (SKI) según RFC 5280 ( 20 ).

5.3. Certificado de firmante de documentos (DSC)

El siguiente cuadro proporciona orientación sobre el DSC. Las entradas en negrita son obligatorias (deben incluirse en el certificado), las entradas en cursiva son recomendables (deben incluirse). Para los campos ausentes, no se definen recomendaciones.







Campo Valor Serial Number número de serie único Subject cn=<nombre común único y no vacío>, o=<Proveedor>, c=<Estado miembro que utiliza este DSC> Key Usage digital signature (como mínimo)

El DSC debe estar firmado con la clave privada correspondiente a un certificado CSCA que utilice el Estado miembro.

Se deben utilizar las siguientes extensiones:

— El certificado debe contener un identificador de clave de autoridad (AKI) que coincida con el identificador de clave del firmante (SKI) del certificado CSCA emisor.

— El certificado debe contener un identificador de clave de firmante único (de acuerdo con RFC 5280 ( 21 )).

Además, el certificado debe contener la extensión de punto de distribución CRL que apunta a la lista de revocación de certificados (CRL) que proporciona la CSCA que emitió el DSC.

El DSC puede contener una extensión de uso de claves extendido con cero o más identificadores de políticas de uso de la clave que restringen los tipos de HCERT que este certificado puede verificar. Si hay uno o más, los verificadores comprobarán el uso de la clave con el HCERT almacenado. Para ello se definen los siguientes valores de «extendedKeyUsage»:







Campo Valor extendedKeyUsage 1.3.6.1.4.1.1847.2021.1.1 para emisores de pruebas extendedKeyUsage 1.3.6.1.4.1.1847.2021.1.2 para emisores de vacunas extendedKeyUsage 1.3.6.1.4.1.1847.2021.1.3 para emisores de recuperación

En ausencia de cualquier extensión de uso de claves (es decir, sin extensiones o con cero extensiones), este certificado puede utilizarse para validar cualquier tipo de HCERT. Otros documentos pueden definir los correspondientes identificadores de políticas de uso de claves extendido que se utilizan con la validación de los HCERT.

5.4. Carga de certificados (NBUP)

El siguiente cuadro proporciona una guía para el certificado de carga del backend nacional. Las entradas en negrita son obligatorias (deben incluirse en el certificado), las entradas en cursiva son recomendables (deben incluirse). Para los campos ausentes, no se definen recomendaciones.







Campo Valor Subject cn=<nombre común no vacío y único>, o=<Proveedor>, c=<Estado miembro que utiliza este certificado de carga> Key Usage digital signature (como mínimo)

5.5. Autenticación de clientes TLS del backend nacional (NBTLS)

El siguiente cuadro proporciona orientación para el certificado de autenticación de cliente TLS de backend nacional. Las entradas en negrita son obligatorias (deben incluirse en el certificado), las entradas en cursiva son recomendables (deben incluirse). Para los campos ausentes, no se definen recomendaciones.







Campo Valor Subject cn=<nombre común no vacío y único>, o=<Proveedor>, c=<Estado miembro en el backend nacional> Key Usage digital signature (como mínimo) Extended key usage client authentication (1.3.6.1.5.5.7.3.2)

El certificado también puede contener el server authentication (1.3.6.1.5.5.7.3.1) del uso de claves extendido, pero no es obligatorio.

5.6. Certificado de firma de lista de confianza (DCCGTA)

El siguiente cuadro define el certificado de anclaje de veracidad de la DCCG.







Campo Valor Subject cn = Digital Green Certificate Gateway (1) , o=<Proveedor>, c=<país> Key Usage digital signature (como mínimo) ( 1 ) En este contexto se ha mantenido el término «certificado verde digital» en lugar de «certificado COVID digital de la UE» porque es el término que se codificó y utilizó en el certificado antes de que los colegisladores eligieran un nuevo término.

5.7. Certificados de servidor de TLS de la DCCG (DCCGTLS)

El siguiente cuadro define el certificado TLS de la DCCG.







Campo Valor Subject cn=<FQDN o dirección IP de la DCCG>, o=<Proveedor>, c= <país> SubjectAltName dnsName: <nombre DNS de la DCCG> o su iPAddress: <Dirección IP de la DCCG> Key Usage digital signature (como mínimo) Extended Key usage server authentication (1.3.6.1.5.5.7.3.1)

El certificado también puede contener el client authentication (1.3.6.1.5.5.7.3.2) del uso de claves extendido, pero no es obligatorio.

El certificado TLS de la DCCG deberá ser emitido por una autoridad de certificación de confianza pública (incluida en todos los principales navegadores y sistemas operativos, siguiendo los requisitos básicos del CAB Forum).

▼M1









ANEXO V

SISTEMA DE NOTACIÓN DE OBJETOS EN JAVASCRIPT (JSON)

1. Introducción

El presente anexo establece la estructura técnica de los datos para los certificados COVID digitales de la UE (CCD de la UE), representada como un sistema JSON. El documento contiene instrucciones específicas relativas a cada uno de los campos de datos.

2. Emplazamiento y versiones del sistema JSON

El único sistema acreditado oficial de JSON para el CCD de la UE está disponible en https://github.com/ehn-dcc-development/ehn-dcc-schema. Otros emplazamientos no han sido acreditados, pero pueden utilizarse para preparar las próximas revisiones.

Por defecto, la versión actual, tal como figura en el presente anexo y admitida por todos los países actualmente conectados a la pasarela CCD de la UE / que emiten certificados, figura en la URL indicada.

La próxima versión, que en una fecha determinada deberá ser admitida por todos los países, se muestra en la URL indicada a través de la cadena de caracteres que describen una versión, que se describe más específicamente en el archivo Readme.

▼M3

3. Estructuras comunes y requisitos generales

No se expedirá un certificado COVID digital de la UE si no pueden cumplimentarse correctamente todos los campos de datos de conformidad con esta especificación debido a la falta de información. Esto no se entenderá en el sentido de que afecta a la obligación de los Estados miembros de expedir certificados COVID digitales de la UE.

La información de todos los campos puede facilitarse utilizando el conjunto completo de 13.0 caracteres de UNICODE codificados en UTF-8, a menos que se limite específicamente a conjuntos de valores o conjuntos de caracteres más reducidos.

La estructura común será la siguiente:

«JSON»:{

«ver»:<version information>,

«nam»:{

<person name information>

},

«dob»:<date of birth>,

«v» or «t» or «r»:[

{<vaccination dose or test or recovery information, one entry>}

]

}

En las secciones siguientes se ofrece información detallada sobre los distintos grupos y campos.

Cuando las normas indiquen que debe omitirse un campo, esto significa que su contenido estará vacío y que no se permiten ni el nombre ni el valor del campo en el contenido.

3.1. Versión

Se proporcionará información sobre la versión. La gestión de las versiones se realiza de acuerdo con el Semantic Versioning (semver: https://semver.org). En la producción, será una de las versiones publicadas oficialmente (la actual o una más antigua oficialmente publicada). Véase la sección JSON Schema location para más detalles.







ID del campo Nombre del campo Instructiones ver Versión del sistema Coincidirá con el identificador de la versión del sistema utilizado para elaborar el CCD de la UE. Ejemplo: «ver»:«1.3.0»

3.2. Nombre y fecha de nacimiento

El nombre de la persona es el nombre oficial completo de la persona, que coincide con el nombre indicado en los documentos de viaje. El identificador de la estructura es nam. Se facilitará exactamente 1 (un) nombre de persona.







ID del campo Nombre del campo Instrucciones nam/fn Apellido(s) Apellido(s) del titular Si el titular no tiene apellido(s) pero tiene nombre, se omitirá el campo. En el resto de los casos, se facilitará exactamente 1 (un) campo no vacío, con todos los apellidos incluidos en él. En caso de pluralidad de apellidos, estos estarán separados por un espacio. No obstante, los nombres combinados que incluyan guiones o caracteres similares deberán permanecer iguales. Ejemplos: «fn»:«Musterfrau-Gößinger» «fn»:«Musterfrau-Gößinger Müller» nam/fnt Apellido(s) normalizado(s) Apellido(s) del titular transliterado(s) utilizando la misma convención que la aplicada en los documentos de viaje de lectura mecánica del titular (tales como las normas definidas en el documento 9303 de la OACI, parte 3). Si el titular no tiene apellido(s) pero tiene nombre, se omitirá el campo. Se facilitará exactamente 1 (un) campo no vacío, utilizando solo los caracteres A-Z y <. Longitud máxima: 80 caracteres (según la especificación de la OACI 9303). Ejemplos: «fnt»:«MUSTERFRAU<GOESSINGER» «fnt»:«MUSTERFRAU<GOESSINGER<MUELLER» nam/gn Nombre(s) Nombre(s) del titular. Si el titular no tiene nombre(s) pero tiene apellido(s), se omitirá el campo. En el resto de los casos, se facilitará exactamente 1 (un) campo no vacío, con todos los nombres incluidos en él. En caso de pluralidad de nombres, estos estarán separados por un espacio. Ejemplo: «gn»:«Isolde Erika» nam/gnt Nombre(s) normalizado(s) Nombres(s) del titular transliterado(s) utilizando la misma convención que la aplicada en los documentos de viaje de lectura mecánica del titular (tales como las normas definidas en el documento 9303, parte 3, de la OACI). Si el titular no tiene nombre pero tiene apellido(s), se omitirá el campo. Se facilitará exactamente 1 (un) campo no vacío, utilizando solo los caracteres A-Z y <. Longitud máxima: 80 caracteres Ejemplo: «gnt»:«ISOLDE<ERIKA» dob Fecha de nacimiento Fecha de nacimiento del titular del CCD. Fecha completa o parcial sin indicación de tiempo limitada al intervalo de 1900-01-01 a 2099-12-31. Se facilitará exactamente 1 (un) campo no vacío si se conoce la fecha de nacimiento completa o parcial. Si la fecha de nacimiento no se conoce ni siquiera parcialmente, el campo lo constituirá una cadena vacía ““. Esta información debe coincidir con la facilitada en los documentos de viaje. Se utilizará uno de los siguientes formatos ISO 8601 si se dispone de información sobre la fecha de nacimiento. No se admiten otras opciones. AAAA-MM-DD AAAA-MM AAAA (La aplicación del verificador puede mostrar las partes de la fecha de nacimiento que faltan utilizando la convención XX, como la empleada en documentos de viaje de lectura mecánica, por ejemplo, 1990-XX-XX.) Ejemplos: «dob»:«1979-04-14» «dob»: «1901-08» «dob»:«1939» «dob»:

3.3. Grupos para la información específica sobre el tipo de certificado

El sistema JSON admite tres grupos de entradas que incluyen información específica sobre el tipo de certificado. Cada CCD de la UE contendrá exactamente 1 (un) grupo. No se permiten grupos vacíos.







Identificador del grupo Nombre del grupo Entradas v Grupo de vacunación Si fuera el caso, deberá contener exactamente 1 (una) entrada que indique exactamente 1 (una) dosis de vacunación (una dosis). t Grupo de prueba Si fuera pertinente, deberá contener exactamente 1 (una) entrada que indique exactamente 1 (un) resultado de una prueba. r Grupo de recuperación Si fuera pertinente, deberá contener exactamente 1 (una) entrada que indique 1 (un) certificado de recuperación.

▼M1

4. Información específica sobre el tipo de certificado

4.1. Certificado de vacunación

El grupo de vacunación, si fuera pertinente, deberá contener exactamente 1 (una) entrada que indique exactamente un acto de vacunación (una dosis). Todos los elementos del grupo de vacunación son obligatorios y no se admiten valores vacíos.







ID del campo Nombre del campo Instrucciones v/tg Enfermedad o agente para el que se vacuna: COVID-19 (SARS-CoV-2 o una de sus variantes) Un valor codificado del conjunto de valores disease-agent-targeted.json. Este valor tiene una única entrada 840539006, que es el código de SNOMED CT (GPS) para la COVID-19. Se facilitará exactamente 1 (un) campo no vacío. Ejemplo: "tg":"840539006" v/vp Vacuna o profilaxis de la COVID-19 Tipo de vacuna o profilaxis utilizada. Un valor codificado del conjunto de valores vaccine-prophylaxis.json. El conjunto de valores se distribuye a partir de la pasarela CCD de la UE (EUDCC Gateway). Se facilitará exactamente 1 (un) campo no vacío. Ejemplo: "vp":"1119349007" (una vacuna SARS-CoV-2 mRNA) v/mp Producto de la vacuna contra la COVID-19 Medicamento utilizado para esta dosis específica de vacunación. Un valor codificado del conjunto de valores vaccine-medicinal-product.json. El conjunto de valores se distribuye a partir de la pasarela CCD de la UE (EUDCC Gateway). Se facilitará exactamente 1 (un) campo no vacío. Ejemplo: "mp":"EU/1/20/1528" (Comirnaty) v/ma Titular de la autorización de comercialización o fabricante de la vacuna contra la COVID-19 El titular de la autorización de comercialización o el fabricante a falta del titular de la autorización de comercialización. Un valor codificado del conjunto de valores vaccine-mah-manf.json. El conjunto de valores se distribuye a partir de la pasarela CCD de la UE (EUDCC Gateway). Se facilitará exactamente 1 (un) campo no vacío. Ejemplo: "ma":"ORG-100030215" (Biontech Manufacturing GmbH) v/dn Número en una serie de dosis Número secuencial (entero positivo) de la dosis administrada durante este acto de vacunación. 1 para la primera dosis, 2 para la segunda, y así sucesivamente. En la sección 5 del anexo II se establecen normas más específicas. Se facilitará exactamente 1 (un) campo no vacío. Ejemplos: "dn":"1" (primera dosis) "dn":"2" (segunda dosis) "dn":"3" (tercera dosis) v/sd Número total de dosis en la serie Número total de dosis (entero positivo) en la pauta de vacunación. En la sección 5 del anexo II se establecen normas más específicas. Se facilitará exactamente 1 (un) campo no vacío. Ejemplos: "sd":"1" (en el caso de una pauta de primovacunación de una sola dosis) "sd":"2" (en el caso de una pauta de primovacunación de 2 dosis o de una dosis adicional tras una pauta de primovacunación de una sola dosis) "sd":"3" (por ejemplo, en caso de dosis adicionales tras una pauta de primovacunación de 2 dosis) v/dt Fecha de la vacunación La fecha de recepción de la dosis descrita, en formato AAAA-MM-DD (fecha completa sin hora). No se admiten otros formatos. Se facilitará exactamente 1 (un) campo no vacío. Ejemplo: "dt":"2021-03-28" v/co Estado miembro o tercer país en que se administró la vacuna; País expresado como código ISO 3166 de 2 letras (RECOMENDADO) o una referencia a una organización internacional responsable del acto de vacunación (como ACNUR o OMS). Un valor codificado del conjunto de valores country-2-codes.json. El conjunto de valores se distribuye a partir de la pasarela CCD de la UE (EUDCC Gateway). Se facilitará exactamente 1 (un) campo. Ejemplo: "co":"CZ" "co":"ACNUR" v/is Emisor del certificado Nombre de la organización que expidió el certificado. Los identificadores pueden formar parte del nombre, pero no se recomienda su uso por separado sin el nombre en forma de texto. Máx. 80 caracteres UTF-8 Se facilitará exactamente 1 (un) campo no vacío. Ejemplo: "is":"Ministry of Health of the Czech Republic" "is":"Vaccination Centre South District 3" v/ci Identificador único del certificado. Identificador único del certificado (UVCI), tal como se especifica en https://ec.europa.eu/health/sites/default/files/ehealth/docs/vaccination-proof_interoperability-guidelines_en.pdf La inclusión de la suma de comprobación es opcional. Se podrá añadir el prefijo "URN:UVCI:". Se facilitará exactamente 1 (un) campo no vacío. Ejemplos: "ci":"URN:UVCI:01:NL:187/37512422923" "ci":"URN:UVCI:01:AT:10807843F94AEE0EE5093FBC254BD813#B"

4.2. Certificado de prueba diagnóstica

El grupo de prueba, si fuera pertinente, deberá contener exactamente 1 (una) entrada que indique exactamente 1 (un) resultado de una prueba.







ID del campo Nombre del campo Instrucciones t/tg Enfermedad o agente para el que se vacuna: COVID-19 (SARS-CoV-2 o una de sus variantes) Un valor codificado del conjunto de valores disease-agent-targeted.json. Este valor tiene una única entrada 840539006, que es el código de SNOMED CT (GPS) para la COVID-19. Se facilitará exactamente 1 (un) campo no vacío. Ejemplo: "tg":"840539006" t/tt Tipo de prueba El tipo de prueba utilizada, basado en el material que persigue la prueba. Un valor codificado del conjunto de valores test-type.json (basado en la nomenclatura LOINC) No se permiten valores ajenos al conjunto de valores. Se facilitará exactamente 1 (un) campo no vacío. Ejemplo: "tt":"LP6464-4" (Amplificación de los ácidos nucleicos con detección por sonda) "tt":"LP217198-3" (Inmunoanálisis rápido) t/nm Nombre de la prueba (solo pruebas de amplificación de los ácidos nucleicos) El nombre de la prueba de amplificación de ácidos nucleicos (NAAT) utilizada. El nombre debe incluir el nombre del fabricante de la prueba y la denominación comercial de la prueba, separados por una coma. En cuanto a la NAAT (prueba de amplificación de ácidos nucléicos): el campo es opcional. En cuanto a la RAT (prueba rápida de antígenos): no se utilizará este campo, ya que el nombre de la prueba se suministra indirectamente a través del identificador del dispositivo de la prueba (t/ma). Cuando se facilite, el campo no deberá estar vacío. Ejemplo: "nm":"ELITechGroup, SARS-CoV-2 ELITe MGB® Kit" t/ma Identificador del dispositivo de prueba (solo pruebas rápidas de antígenos) Identificador del dispositivo para pruebas rápidas de antígenos (RAT) de la base de datos del JRC. Conjunto de valores (lista común CSS - Comité de Seguridad Sanitaria): — Todas las pruebas rápidas de antígenos de la lista común del CSS (legible por personas). — https://covid-19-diagnostics.jrc.ec.europa.eu/devices/hsc-common-recognition-rat (legible por máquina, valores del campo id_device incluido en la lista del conjunto de valor