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 NBTLS registrados.

— La DCCG utiliza dos certificados digitales (DCCGTLS y DCCGTA) con dos pares de claves distintas. La clave privada del par de claves DCCGTA 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 NBCSCA que está firmada con la clave privada DCCGTA.

— 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 NBTLS del Estado miembro.

— El certificado de carga NBUP del Estado miembro.

— El certificado o los certificados NBCSCA 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 NBCSCA a la lista de confianza firmados con la clave privada que corresponde a la clave pública DCCGTA;

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

— añade el certificado NBUP al sistema DCCG;

— proporciona el certificado de clave pública DCCGTA y DCCGTLS 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 (1) o en los mecanismos criptográficos acordados por SOG-IS (2).

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 (3).

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 (4)).

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 (5) , o=<Proveedor>, c=<país> Key Usage digital signature (como mínimo)

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).

(1) BSI - Directrices técnicas TR-02102 (bund.de).

(2) SOG-IS - Documentos de apoyo (sogis.eu).

(3) rfc5280 (ietf.org).

(4) rfc5280 (ietf.org).

(5) 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.