02021D1073 — PT — 15.09.2022 — 004.001

---

Este texto constitui um instrumento de documentação e não tem qualquer efeito jurídico. As Instituições da União não assumem qualquer responsabilidade pelo respetivo conteúdo. As versões dos atos relevantes que fazem fé, incluindo os respetivos preâmbulos, são as publicadas no Jornal Oficial da União Europeia e encontram-se disponíveis no EUR-Lex. É possível aceder diretamente a esses textos oficiais através das ligações incluídas no presente documento

►B

DECISÃO DE EXECUÇÃO (UE) 2021/1073 DA COMISSÃO de 28 de junho de 2021 que estabelece as especificações técnicas e regras para a execução do regime de confiança do Certificado Digital COVID da UE estabelecido pelo Regulamento (UE) 2021/953 do Parlamento Europeu e do Conselho (Texto relevante para efeitos do EEE) (JO L 230 de 30.6.2021, p. 32)

Alterada por:

		Jornal Oficial
		n.°	página	data
►M1	DECISÃO DE EXECUÇÃO (UE) 2021/2014 DA COMISSÃO de 17 de novembro de 2021	L 410	180	18.11.2021
►M2	DECISÃO DE EXECUÇÃO (UE) 2021/2301 DA COMISSÃO de 21 de dezembro de 2021	L 458	536	22.12.2021
►M3	DECISÃO DE EXECUÇÃO (UE) 2022/483 DA COMISSÃO de 21 de março de 2022	L 98	84	25.3.2022
►M4	DECISÃO DE EXECUÇÃO (UE) 2022/1516 DA COMISSÃO de 8 de setembro de 2022	L 235	61	12.9.2022

---

▼B

DECISÃO DE EXECUÇÃO (UE) 2021/1073 DA COMISSÃO

de 28 de junho de 2021

que estabelece as especificações técnicas e regras para a execução do regime de confiança do Certificado Digital COVID da UE estabelecido pelo Regulamento (UE) 2021/953 do Parlamento Europeu e do Conselho

(Texto relevante para efeitos do EEE)

Artigo 1.o

As especificações técnicas do Certificado Digital COVID da UE que estabelecem a estrutura de dados genérica, os mecanismos de codificação e o mecanismo de codificação de transporte num formato de leitura ótica são definidas no anexo I.

Artigo 2.o

As regras de preenchimento dos certificados referidos no artigo 3.o, n.o 1, do Regulamento (UE) 2021/953 são definidas no anexo II da presente decisão.

Artigo 3.o

Os requisitos que estabelecem a estrutura comum do identificador único do certificado são definidos no anexo III.

▼M1

Artigo 4.o

As regras de governação aplicáveis aos certificados de chave pública em relação ao portal do Certificado Digital COVID da UE e que apoiam os aspetos da interoperabilidade do regime de confiança são definidas no anexo IV.

▼M1

Artigo 5.o

O anexo V da presente decisão estabelece uma estrutura de dados comum e coordenada para os dados a incluir nos certificados referidos no artigo 3.o, n.o 1, do Regulamento (UE) 2021/953, utilizando um esquema de notação de objetos JavaScript (JSON).

▼M3

Artigo 5.o-A

Intercâmbio de listas de revogação de certificados

Artigo 5.o-B

Envio de listas de revogação de certificados por países terceiros

Os países terceiros que emitam certificados COVID-19 relativamente aos quais a Comissão tenha adotado um ato de execução ao abrigo do artigo 3.o, n.o 10, ou do artigo 8.o, n.o 2, do Regulamento (UE) 2021/953 podem enviar listas de certificados COVID-19 revogados abrangidos por esse ato de execução, as quais a Comissão tratará em nome dos responsáveis conjuntos pelo tratamento no portal referido no artigo 5.o-A, em conformidade com as especificações técnicas estabelecidas no anexo I.

Artigo 5.o-C

Governação do tratamento de dados pessoais no portal central do Certificado Digital COVID da UE

▼M1

Artigo 6.o

A presente decisão entra em vigor no dia da sua publicação no Jornal Oficial da União Europeia.

▼B

A presente decisão entra em vigor no dia da sua publicação no Jornal Oficial da União Europeia.

---

ANEXO I

FORMATO E GESTÃO DA CONFIANÇA

Estrutura de dados genérica, mecanismos de codificação e mecanismo de codificação de transporte num formato de leitura ótica (a seguir designado por «QR»)

1.    Introdução

As especificações técnicas definidas no presente anexo incluem uma estrutura de dados genérica e mecanismos de codificação para o Certificado Digital COVID da UE («DCC»). Especificam ainda um mecanismo de codificação de transporte num formato de leitura ótica («QR»), que pode ser exibido no ecrã de um dispositivo móvel ou impresso. Os formatos do contentor do certificado sanitário eletrónico destas especificações são genéricos, mas utilizados, neste contexto, para incluir o DCC.

2.    Terminologia

Para efeitos do presente anexo, entende-se por «emitentes» as organizações que utilizam estas especificações para emitir certificados sanitários e por «verificadores» as organizações que aceitam certificados sanitários como prova do estado de saúde. Por «participantes», entende-se os emitentes e os verificadores. Alguns aspetos definidos no presente anexo devem ser coordenados entre os participantes, designadamente, a gestão de um espaço de nomes e a distribuição de chaves criptográficas. Presume-se que uma entidade, a seguir designada por «secretariado», executa estas tarefas.

3.    Formato do contentor do certificado sanitário eletrónico

O formato do contentor do certificado sanitário eletrónico («HCERT») destina-se a disponibilizar um veículo uniforme e normalizado para certificados sanitários dos diferentes emitentes («emitentes»). O objetivo das presentes especificações consiste em harmonizar a forma como esses certificados sanitários são representados, codificados e assinados com vista a facilitar a interoperabilidade.

A capacidade de ler e interpretar um DCC emitido por qualquer emitente exige uma estrutura de dados comum, bem como um acordo quanto ao significado de cada campo de dados da carga útil. A fim de facilitar essa interoperabilidade, é definida uma estrutura de dados comum e coordenada através da utilização de um esquema «JSON», que constitui o enquadramento do DCC.

3.1.    Estrutura da carga útil

A carga útil é estruturada e codificada como CBOR com uma assinatura digital COSE, geralmente conhecida como «CBOR Web Token» (CWT) e definida no RFC 8392 ( 1 ). A carga útil, conforme definida nas secções seguintes, é transportada num atributo («claim») hcert.

A integridade e autenticidade de origem dos dados da carga útil devem ser verificáveis pelo verificador. A fim de disponibilizar este mecanismo, o emitente deve assinar o CWT utilizando um esquema de assinatura eletrónica assimétrico conforme definido na especificação COSE (RFC 8152 ( 2 )).

3.2.    Atributos CWT

3.2.1.    Descrição geral da estrutura CWT

Cabeçalho protegido

Carga útil

Assinatura

3.2.2.    Algoritmo de assinatura

O parâmetro do algoritmo de assinatura (alg) indica o algoritmo utilizado para a criação da assinatura. Deve cumprir ou exceder as diretrizes do SOG-IS em vigor, resumidas nos parágrafos seguintes.

São definidos um algoritmo primário e um secundário. O algoritmo secundário só deve ser utilizado se o algoritmo primário não for aceitável no âmbito das regras e dos regulamentos impostos ao emitente.

A fim de garantir a segurança do sistema, todas as implementações têm de incorporar o algoritmo secundário. Por esta razão, tanto o algoritmo primário como o secundário devem ser implementados.

Os níveis definidos pelo SOG-IS para os algoritmos primário e secundário são os seguintes:

Este corresponde ao parâmetro ES256 do algoritmo COSE.

Este corresponde ao parâmetro PS256 do algoritmo COSE.

3.2.3.    Identificador de chave

O atributo de identificador de chave (kid) indica o certificado de signatário de documento (DSC) que contém a chave pública a utilizar pelo verificador para controlar a exatidão da assinatura digital. A governação dos certificados de chave pública, incluindo os requisitos aplicáveis aos DSC, é descrita no anexo IV.

O atributo de identificador de chave (kid) é utilizado pelos verificadores para selecionar a chave pública correta a partir de uma lista de chaves relativas ao emitente indicadas no atributo de emitente (iss). Um emitente pode utilizar várias chaves em paralelo por razões administrativas e ao efetuar substituições de chaves. O identificador de chave não constitui um campo crítico no plano da segurança. Por esta razão, pode também ser inserido num cabeçalho não protegido, se necessário. Os verificadores devem aceitar ambas as opções. Se ambas as opções estiverem presentes, deve ser utilizado o identificador de chave do cabeçalho protegido.

Devido à redução do identificador (por razões de limite de tamanho), há uma hipótese mínima, mas não nula, de que a lista geral de DSC aceites por um verificador possa conter DSC com kid duplicado. Por esta razão, um verificador deve controlar todos os DSC com esse kid.

3.2.4.    Emitente

O atributo de emitente (iss) é um valor em cadeia que pode conter opcionalmente o código de país ISO 3166-1 alfa-2 da entidade que emite o certificado sanitário. Este atributo pode ser utilizado por um verificador para identificar o conjunto de DSC a utilizar para verificação. É utilizada a chave de atributo 1 para identificar este atributo.

3.2.5.    Prazo de expiração:

O atributo de prazo de expiração (exp) deve conter um selo temporal no formato de número inteiro NumericDate (conforme especificado no RFC 8392 ( 4 ), secção 2) indicando durante quanto tempo esta assinatura concreta da carga útil é considerada válida, após o que um verificador deve considerar que o prazo da carga útil expirou e rejeitá-la. O objetivo do parâmetro de validade é impor um limite ao período de validade do certificado sanitário. É utilizada a chave de atributo 4 para identificar este atributo.

O prazo de expiração da assinatura não deve exceder o período de validade do DSC.

3.2.6.    Emitido em

O atributo «Emitido Em» (iat) deve conter um selo temporal no formato de número inteiro NumericDate (conforme especificado no RFC 8392 ( 5 ), secção 2) indicando a hora a que o certificado sanitário foi criado.

A data do campo «Emitido Em» não deve ser anterior ao período de validade do DSC.

Os verificadores podem aplicar políticas adicionais a fim de limitar a validade do certificado sanitário com base na hora de emissão. É utilizada a chave de atributo 6 para identificar este atributo.

3.2.7.    Atributo de certificado sanitário

O atributo de certificado sanitário (hcert) é um objeto JSON (RFC 7159 ( 6 )) que contém as informações sobre o estado de saúde. Podem existir sob o mesmo atributo vários tipos diferentes de certificados sanitários, um dos quais o DCC.

O JSON é utilizado exclusivamente para efeitos de esquema. O formato de representação é o CBOR, conforme definido no (RFC 7049 ( 7 )). É possível que os programadores de aplicações nunca descodifiquem ou codifiquem realmente de e para o formato JSON, mas utilizem a estrutura na memória.

A chave de atributo a utilizar para identificar este atributo é -260.

As cadeias do objeto JSON devem ser normalizadas de acordo com o Formato de Normalização de Composição Canónica (NFC) definida na norma Unicode. As aplicações de descodificação devem, todavia, ser permissivas e robustas no tocante a estes aspetos e a aceitação de qualquer conversão de tipo razoável é fortemente incentivada. Se forem detetados dados não normalizados durante a descodificação ou em funções subsequentes de comparação, as implementações devem comportar-se como se a entrada de dados fosse normalizada de acordo com o NFC.

4.    Serialização e criação da carga útil do DCC

É aplicado o esquema seguinte como padrão de serialização:

O processo tem início com a extração de dados, por exemplo, de um repositório de dados de saúde (ou de uma fonte de dados externa) estruturando os dados extraídos de acordo com os esquemas de DCC definidos. Neste processo, a conversão para o formato de dados definido e a transformação para efeitos de legibilidade humana podem ocorrer antes de a serialização para CBOR ter início. Os acrónimos dos atributos devem ser identificados em todos os casos para os nomes visíveis antes da serialização e após a desserialização.

Não é permitida a inclusão de conteúdo de dados nacionais opcionais em certificados emitidos em conformidade com o Regulamento (UE) 2021/953 ( 8 ). O conteúdo de dados limita-se aos elementos de dados definidos no conjunto de dados mínimos especificado no anexo do Regulamento 2021/953.

5.    Codificações de transporte

5.1.    Em bruto

Para interfaces de dados arbitrárias, o contentor HCERT e as respetivas cargas úteis podem ser transferidos no estado em que se encontram, utilizando qualquer transporte de dados subjacente, fiável e seguro, de 8 bits. Estas interfaces podem incluir a comunicação de campo próximo, Bluetooth ou transferência através de um protocolo de camada de aplicação, por exemplo, a transferência de um HCERT do emitente para o dispositivo móvel de um titular.

Se a transferência do HCERT do emitente para o titular se basear numa interface apenas de apresentação (por exemplo, SMS, correio eletrónico), obviamente a codificação de transporte em bruto não se aplica.

5.2.    Código de barras

5.2.1.    Compressão da carga útil (CWT)

A fim de reduzir o tamanho e de melhorar a rapidez e a fiabilidade do processo de leitura do HCERT, o CWT deve ser comprimido utilizando o ZLIB (RFC 1950 ( 9 )) e o mecanismo de compressão Deflate no formato definido no RFC 1951 ( 10 ).

5.2.2.    Código de barras QR 2D

A fim de melhor gerir equipamentos preexistentes, concebidos para funcionar com cargas úteis ASCII, o CWT comprimido é codificado como ASCII utilizando Base45 antes de ser codificado num código de barras 2D.

Deve ser utilizado o formato QR definido na norma (ISO/IEC 18004:2015) na geração do código de barras 2D. Recomenda-se uma taxa de correção de erro de «Q» (de cerca de 25 %). Uma vez que se utiliza Base45, o código QR tem de utilizar a codificação alfanumérica (modo 2, indicado pelos símbolos 0010).

Para que os verificadores possam detetar o tipo de dados codificados e selecionar o esquema de descodificação e processamento adequado, os dados codificados com Base45 (de acordo com esta especificação) devem ser precedidos da cadeia de identificadores de contexto «HC1:». As futuras versões desta especificação que tenham impacto na compatibilidade com versões anteriores devem definir um novo identificador de contexto, ao passo que o caráter a seguir a «HC» deve ser retirado do conjunto de carateres [1-9A-Z]. A ordem dos incrementos é definida segundo esta sequência, ou seja, primeiro [1-9] e depois [A-Z].

Recomenda-se que o código ótico seja representado nos meios de apresentação com uma dimensão diagonal entre 35 mm e 60 mm para suportar leitores com ótica fixa, em que os meios de apresentação devem ser colocados sobre a superfície do leitor.

Se o código ótico for impresso em papel utilizando impressoras de baixa resolução (< 300 dpi), deve ter-se cuidado para representar cada símbolo (ponto) do código QR exatamente em quadrado. A escala não proporcional terá como resultado que algumas linhas ou colunas no QR tenham símbolos retangulares, o que, em muitos casos, dificulta a legibilidade.

6.    Formato da lista de confiança (lista de CSCA e DSC)

Cada Estado-Membro é obrigado a fornecer uma lista que inclua uma ou mais autoridades de certificação signatárias nacionais (CSCA) e uma lista de todos os certificados de signatários de documentos (DSC) válidos, bem como a manter estas listas atualizadas.

6.1.    CSCA/DSC simplificados

A partir desta versão das especificações, os Estados-Membros não devem assumir que é utilizada qualquer informação da lista de revogação de certificados (CRL), nem que o período de utilização de chaves privadas é verificado pelos responsáveis pela implementação.

O mecanismo de validade primário será antes a presença do certificado na versão mais recente dessa lista de certificados.

6.2.    Infraestrutura de chave pública (PKI) do documento de viagem eletrónico de leitura ótica (eMRTD) da OACI e centros de confiança

Os Estados-Membros podem utilizar uma CSCA separada, mas também podem apresentar os seus certificados CSCA de eMRTD e/ou DSC existentes, podendo mesmo optar por obtê-los junto de centros de confiança (comerciais) e apresentá-los. No entanto, qualquer DSC deve ser sempre assinado pela CSCA comunicada por esse Estado-Membro.

7.    Considerações em matéria de segurança

Ao conceber um sistema de acordo com esta especificação, os Estados-Membros devem identificar, analisar e monitorizar determinados aspetos de segurança.

Deverão, no mínimo, ser tidos em conta os seguintes aspetos:

7.1.    Período de validade da assinatura do HCERT

O emitente do HCERT deve limitar o período de validade da assinatura especificando um prazo de expiração da assinatura. Tal obriga o titular de um certificado sanitário a renová-lo a intervalos regulares.

O período de validade aceitável pode ser determinado por condicionalismos práticos. Por exemplo, um viajante pode não ter a possibilidade de renovar o certificado sanitário durante uma viagem ao estrangeiro. No entanto, pode também dar-se o caso de um emitente considerar que existe a possibilidade de algum tipo de comprometimento de segurança que o obrigue a retirar um DSC (invalidando todos os certificados sanitários emitidos com essa chave que ainda estejam dentro do respetivo período de validade). As consequências dessa ocorrência podem ser limitadas substituindo regularmente as chaves do emitente e exigindo a renovação de todos os certificados sanitários num intervalo razoável.

7.2.    Gestão de chaves

A presente especificação depende largamente de mecanismos criptográficos fortes para proteger a integridade dos dados e a autenticação da origem dos dados. Por conseguinte, é fundamental manter a confidencialidade das chaves privadas.

A confidencialidade das chaves criptográficas pode ser comprometida de várias formas, nomeadamente:

A fim de atenuar os riscos de o algoritmo de assinatura ser fraco, permitindo que as chaves privadas fiquem comprometidas na sequência de criptoanálise, esta especificação recomenda que todos os participantes implementem um algoritmo de assinatura secundário de recurso baseado em parâmetros diferentes ou num problema matemático diferente do primário.

Quanto aos riscos mencionados relacionados com os ambientes operacionais dos emitentes, devem ser implementadas medidas de atenuação para assegurar um controlo eficaz, nomeadamente para a geração, o armazenamento e a utilização das chaves privadas em módulos de segurança físicos (HSM). Incentiva-se fortemente a utilização de HSM para assinar certificados sanitários.

Independentemente de o emitente decidir ou não utilizar HSM, deverá ser estabelecido um calendário de substituição de chaves em que a frequência das substituições seja proporcional à exposição das chaves a redes externas, a outros sistemas e ao pessoal. Um calendário de substituição devidamente definido também limita os riscos associados a certificados sanitários emitidos erroneamente, permitindo que um emitente revogue esses certificados sanitários por lotes, retirando uma chave, se necessário.

7.3.    Validação de dados de entrada

As presentes especificações podem ser utilizadas de uma forma que implique a receção de dados de fontes não fiáveis em sistemas que podem ser de natureza crítica. Para minimizar os riscos associados a este vetor de ataque, todos os campos de entrada devem ser devidamente validados por tipos, comprimentos e conteúdos de dados. A assinatura do emitente deverá também ser verificada antes de qualquer tratamento do conteúdo do HCERT. No entanto, a validação da assinatura do emitente implica a análise, em primeiro lugar, do cabeçalho protegido do emitente, em que um potencial atacante pode tentar injetar informações cuidadosamente elaboradas para comprometer a segurança do sistema.

8.    Gestão da confiança

A assinatura do HCERT exige uma chave pública para verificação. Os Estados-Membros devem disponibilizar estas chaves públicas. Em última instância, cada verificador tem de dispor de uma lista de todas as chaves públicas em que está disposto a confiar (já que a chave pública não faz parte do HCERT).

O sistema consiste em (apenas) duas camadas; para cada Estado-Membro, um ou mais certificados nacionais que assinam, cada um, um ou mais certificados de signatários de documentos que são utilizados nas operações quotidianas.

Os certificados dos Estados-Membros são designados por certificados das autoridades de certificação signatárias nacionais (CSCA) e são (normalmente) autoassinados. Os Estados-Membros podem ter mais do que um (por exemplo, em caso de descentralização regional). Estes certificados CSCA assinam regularmente os certificados de signatários de documentos (DSC) utilizados para assinar HCERT.

O «secretariado» desempenha um papel funcional. Deve agregar e publicar regularmente os DSC dos Estados-Membros, depois de os ter verificado em relação à lista de certificados CSCA (que foram transmitidos e verificados por outros meios).

A lista de DSC resultante deve então apresentar o conjunto agregado de chaves públicas aceitáveis [e os identificadores de chaves (kid) correspondentes] que os verificadores podem utilizar para validar as assinaturas nos HCERT. Os verificadores devem completar e atualizar esta lista regularmente.

Essas listas específicas dos Estados-Membros podem ser adaptadas no formato adequado ao seu próprio contexto nacional. Deste modo, o formato de ficheiro desta lista de confiança pode variar; pode ser, por exemplo, um JWKS assinado (formato de conjunto de JWK de acordo com o RFC 7517 ( 11 ), secção 5) ou qualquer outro formato específico da tecnologia utilizada nesse Estado-Membro.

Para garantir a simplicidade, os Estados-Membros podem apresentar os seus certificados CSCA existentes a partir dos seus sistemas de eMRTD conformes com as normas da OACI ou, tal como recomendado pela OMS, criar um especificamente para este domínio de saúde.

8.1.    Identificadores de chaves (kid)

O identificador de chave (kid) é calculado ao estabelecer a lista de chaves públicas de confiança a partir dos DSC e consiste numa impressão digital SHA-256 truncada (primeiros 8 bytes) do DSC codificada no formato DER (em bruto).

Os verificadores não precisam de calcular o identificador de chave com base no DSC e podem fazer corresponder diretamente o identificador de chave no certificado sanitário emitido ao identificador de chave na lista de confiança.

8.2.    Diferenças em relação ao modelo de confiança da PKI do eMRTD da OACI

Embora inspirado nas melhores práticas do modelo de confiança da PKI do eMRTD da OACI, deve ser realizado um conjunto de simplificações no interesse da celeridade:

▼M3

9.    Solução de revogação

9.1.    Envio de listas de revogação de Certificados Digitais COVID (DRL — DCC Revocation List)

O portal fornece a funcionalidade e os pontos finais necessários para manter e gerir as listas de revogação:

9.2.    Modelo de confiança

Todas as ligações são estabelecidas conforme o modelo de confiança normalizado do DCCG por intermédio dos certificados NBTLS e NBUP (ver disposições relativas à governação dos certificados). As informações são reunidas em pacotes e carregadas por via de mensagens CMS, de maneira que garanta a sua integridade.

9.3.    Criação de lotes

9.3.1.    Lote

Cada lista de revogação inclui uma ou várias entradas, que são agregadas em lotes (batches) que contêm um conjunto de valores de dispersão (hashes) e respetivos metadados. Um lote é imutável e define uma data de expiração que indica quando pode ser eliminado. A data de expiração tem de ser exatamente a mesma para todos os itens de um lote, pelo que os lotes têm de ser agregados por data de expiração e por assinatura dos DSC. Cada lote pode conter, no máximo, 1 000 entradas. Se uma lista de revogação incluir mais de 1 000 entradas, têm de ser criados vários lotes. Uma entrada individual pode ser incluída, no máximo, num lote. Cada lote é criado com uma estrutura CMS (sistema de gestão de conteúdo) e assinado pelo certificado NBup do país responsável pelo seu carregamento.

9.3.2.    Índice de lotes (batch index)

Quando um lote é criado, o portal atribui-lhe um ID (identificador) único e adiciona-o automaticamente ao índice. O índice de lotes é disposto segundo a ordem cronológica ascendente das datas de modificação.

9.3.3.    Comportamento do portal

O portal trata os lotes de revogação sem introduzir quaisquer alterações nos mesmos: não pode atualizar, suprimir ou acrescentar informações. Os lotes são enviados a todos os países autorizados (ver ponto 9.6).

O portal observa ativamente as datas de expiração dos lotes e remove os lotes expirados. Após a eliminação de um lote, o portal devolve uma resposta «HTTP 410 Gone» para o URL do lote eliminado. Assim, o lote é marcado no índice de lotes como «eliminado».

9.4.    Tipos de valores de dispersão

A lista de revogação contém valores de dispersão que podem representar diferentes tipos/atributos de revogação. Estes tipos ou atributos são indicados aquando do envio das listas de revogação. Os tipos atualmente utilizados são os seguintes:

Apenas os primeiros 128 bits dos valores de dispersão codificados como cadeias (strings) de base64 são incluídos nos lotes e utilizados para identificar o DCC revogado ( 12 ).

9.4.1.    Tipo de valor de dispersão: SHA256(DCC Signature)

Neste caso, o valor de dispersão é calculado com base nos bytes da assinatura COSE_SIGN1 do CWT. As assinaturas RSA são integralmente utilizadas como entrada. A fórmula aplicável aos certificados assinados com EC-DSA utiliza o valor r como entrada:

SHA256(r)

[obrigatório para as novas implementações]

9.4.2.    Tipo de valor de dispersão: SHA256(UCI)

Neste caso, o valor de dispersão é calculado com base na cadeia do UCI codificada em UTF-8 e convertida numa matriz de bytes (byte array).

[obsoleto ( 13 ), mas suportado para garantir compatibilidade com versões anteriores]

9.4.3.    Tipo de valor de dispersão: SHA256(Issuing CountryCode+UCI)

Neste caso, o CountryCode (código de país) codificado como cadeia de UTF-8 é concatenado com o UCI codificado como cadeia de UTF-8. O resultado é convertido numa matriz de bytes e utilizado como entrada para a função de dispersão.

[obsoleto2, mas suportado para garantir compatibilidade com versões anteriores]

9.5.    Estrutura da API

9.5.1.    API para envio de entradas de revogação

9.5.1.1.   Finalidade

A API apresenta as entradas da lista de revogação em lotes, incluindo um índice de lotes.

9.5.1.2.   Pontos finais

9.5.1.2.1.   Ponto final de descarregamento da lista de lotes

Os pontos finais seguem uma conceção simples, devolvendo uma lista de lotes com uma função de encapsulamento (wrapper) reduzida, que fornece metadados. Os lotes são dispostos segundo a ordem (cronológica) ascendente das datas:

/revocation-list

Verb: GET

Content-Type: application/json

Response: JSON Array

Nota: o resultado é limitado, por definição, a 1 000 entradas. Se a variável (flag) «more» devolver o valor «true» (verdadeiro), essa resposta indica que há mais lotes disponíveis para descarregamento. Para descarregar mais itens, o cliente tem de selecionar, no cabeçalho If-Modified-Since, uma data não anterior à da última entrada recebida.

A resposta contém uma matriz JSON com a seguinte estrutura:

9.5.1.2.1.1.   Códigos de resposta

Cabeçalho do pedido

9.5.1.2.2.   Ponto final de descarregamento de lotes

Os lotes contêm uma lista de identificadores de certificados:

/revocation-list/{batchId}

Verb: GET

Accepts: application/cms

Response:CMS with Content

A resposta contém um CMS que inclui uma assinatura, a qual tem de corresponder ao certificado NBUP do país. Todos os itens da matriz JSON contêm a seguinte estrutura:

9.5.1.2.2.1.   Entradas

Nota: atualmente, o objeto das entradas contém apenas um valor de dispersão, mas, para garantir a compatibilidade com futuras alterações, optou-se por um objeto, em vez de uma matriz JSON.

9.5.1.2.2.2.   Códigos de resposta

9.5.1.2.2.3.   Cabeçalhos de resposta

9.5.1.2.3.   Ponto final de carregamento de lotes

O carregamento é efetuado no mesmo ponto final, por via do método (ou verbo) de requisição POST:

/revocation-list

Verb: POST

Accepts: application/cms

Request: CMS with Content

ContentType: application/cms

Content:

O lote é assinado utilizando o certificado NBUP. O portal verifica se o NBUP utilizado na assinatura corresponde ao país em causa. Se a verificação da assinatura falhar, o carregamento falhará igualmente.

Nota: todos os lotes são imutáveis e não podem ser alterados após o carregamento. No entanto, podem ser eliminados. O ID de cada lote eliminado é armazenado, sendo rejeitado o carregamento de um novo lote com o mesmo ID.

9.5.1.2.4.   Ponto final de eliminação de lotes

Um lote pode ser eliminado no mesmo ponto final, por via do método (ou verbo) de requisição DELETE:

/revocation-list

Verb: DELETE

Accepts: application/cms

ContentType: application/cms

Request: CMS with Content

Content:

ou, por questões de compatibilidade, no seguinte ponto final, por via do método (ou verbo) de requisição POST:

/revocation-list/delete

Verb: POST

Accepts: application/cms

ContentType: application/cms

Request: CMS with Content

Content:

9.6.    Proteção da API/RGPD

A presente secção especifica medidas a aplicar para que a implementação cumpra as disposições do Regulamento (UE) 2021/953 no respeitante ao tratamento de dados pessoais.

9.6.1.    Autenticação existente

Atualmente, o portal utiliza o certificado NBTLS para autenticar os países que se ligam ao portal. Esta autenticação pode ser utilizada para determinar a identidade do país ligado ao portal. Essa identidade pode ser subsequentemente utilizada para efeitos de controlo de acesso.

9.6.2.    Controlo de acesso

Para poder tratar legalmente dados pessoais, o portal é obrigado a implantar um mecanismo de controlo de acesso.

O portal recorre a uma lista de controlo de acesso, combinada com uma política de segurança baseada em funções. Neste esquema, são mantidos dois quadros: um descreve as operações autorizadas a cada função e os recursos aos quais aquelas podem ser aplicadas; o outro descreve as funções atribuídas aos diferentes utilizadores.

Para executar os controlos exigidos pelo presente documento, são necessárias três funções, a saber:

Os pontos finais a seguir indicados verificam se o utilizador tem a função de RevocationListReader; em caso afirmativo, o acesso é concedido; caso contrário, é devolvida uma mensagem HTTP 403 Forbidden:

GET/revocation-list/

GET/revocation-list/{batchId}

Os pontos finais a seguir indicados verificam se o utilizador tem a função de RevocationUploader; em caso afirmativo, o acesso é concedido; caso contrário, é devolvida uma mensagem HTTP 403 Forbidden:

POST/revocation-list

Os pontos finais a seguir indicados verificam se o utilizador tem a função de RevocationDeleter; em caso afirmativo, o acesso é concedido; caso contrário, é devolvida uma mensagem HTTP 403 Forbidden:

DELETE/revocation-list

POST/revocation-list/delete

O portal proporciona igualmente um método fiável pelo qual os administradores podem gerir as funções atribuídas aos utilizadores, de modo que reduza a probabilidade de ocorrência de erros humanos, sem com isso sobrecarregar os administradores funcionais.

▼M1

---

ANEXO II

REGRAS PARA EFEITOS DE PREENCHIMENTO DO CERTIFICADO DIGITAL COVID DA UE

As regras gerais relativas aos conjuntos de valores estabelecidas no presente anexo visam assegurar a interoperabilidade a nível semântico e devem permitir implementações técnicas uniformes no que respeita ao Certificado Digital COVID da UE. Os elementos constantes do presente anexo podem ser utilizados nos três contextos distintos (vacinação/teste/recuperação), conforme previsto no Regulamento (UE) 2021/953. Apenas se encontram enumerados no presente anexo os elementos que requerem normalização semântica através de conjuntos de valores codificados.

A tradução dos elementos codificados na língua nacional é da responsabilidade dos Estados-Membros.

Para todos os campos de dados não mencionados nas descrições dos conjuntos de valores seguintes, a codificação está descrita no anexo V.

Se, por alguma razão, os sistemas de codificação preferenciais enumerados abaixo não puderem ser aplicados, podem ser utilizados outros sistemas internacionais de codificação, devendo ser apresentadas recomendações sobre como fazer corresponder os códigos do outro sistema de codificação ao sistema de codificação preferencial. Pode ser utilizado texto (nomes visíveis) em casos excecionais como um mecanismo de recurso quando não estiver disponível um código adequado nos conjuntos de valores definidos.

Os Estados-Membros que utilizarem outra codificação nos seus sistemas devem fazer corresponder esses códigos aos conjuntos de valores descritos. Os Estados-Membros são responsáveis por realizar essas correspondências.

►M4  Uma vez que alguns conjuntos de valores baseados nos sistemas de codificação previstos no presente anexo, tais como para a codificação de vacinas e de testes de antigénios, estão frequentemente a mudar, são publicados e regularmente atualizados pela Comissão com o apoio da rede de saúde em linha e do Comité de Segurança da Saúde. ◄ Os conjuntos de valores atualizados são publicados no sítio Web pertinente da Comissão, assim como na página Web da rede de saúde em linha. Deve ser fornecido um histórico de alterações.

1.    Doença ou agente visado/doença ou agente de que o titular recuperou: COVID-19 (SARS-CoV-2 ou uma das suas variantes)

A utilizar nos certificados 1, 2 e 3.

Deve ser utilizado o seguinte código:

2.    Vacina contra a COVID-19 ou profilaxia

Sistema de codificação preferencial: SNOMED CT ou classificação ATC.

A utilizar no certificado 1.

São exemplos de códigos a utilizar entre os sistemas de codificação preferenciais os códigos SNOMED CT 1119305005 (vacina de antigénio contra o SARS-CoV-2), 1119349007 (vacina de ARN mensageiro contra o SARS-CoV-2) ou J07BX03 (vacinas contra a COVID-19).

A Comissão publica e atualiza regularmente com o apoio da rede de saúde em linha um conjunto de valores que estabeleça os códigos a utilizar em conformidade com os sistemas de codificação estabelecidos na presente secção. O conjunto de valores é alargado quando são desenvolvidos e introduzidos novos tipos de vacinas.

3.    Vacina terapêutica contra a COVID-19

Sistemas de codificação preferenciais (por ordem de preferência):

Nome do conjunto de valores: vacina.

A utilizar no certificado 1.

De entre os sistemas de codificação preferenciais, um exemplo de código a utilizar é o EU/1/20/1528 (Comirnaty). Exemplo de nome de vacina a utilizar como código: Sputnik-V (que corresponde a Sputnik V).

A Comissão publica e atualiza regularmente com o apoio da rede de saúde em linha um conjunto de valores que estabeleça os códigos a utilizar em conformidade com os sistemas de codificação estabelecidos na presente secção.

As vacinas são codificadas utilizando um código existente no conjunto de valores publicado, mesmo que os seus nomes sejam diferentes nos diferentes países. A razão é que não existe ainda um registo mundial de vacinas que abranja todas as vacinas atualmente utilizadas. Exemplo:

Se tal não for possível ou aconselhável num caso específico, será fornecido um código separado no conjunto de valores publicado.

▼M4

Se um país que utiliza o Certificado Digital COVID da UE («EUDCC») decidir emitir certificados de vacinação para os participantes em ensaios clínicos durante ensaios clínicos em curso, a vacina terapêutica deve ser codificada de acordo com o padrão

CT_clinical-trial-identifier

Se o ensaio clínico tiver sido registado no Registo de Ensaios Clínicos da UE (EU-CTR), deve ser utilizado o identificador do ensaio clínico desse registo. Noutros casos, podem ser utilizados identificadores de outros registos (como o clinicaltrials.gov ou o Australian New Zealand Clinical Trials Registry).

O identificador do ensaio clínico deve incluir um prefixo que permita a identificação do registo de ensaios clínicos (por exemplo, EUCTR para o Registo de Ensaios Clínicos da UE, NCT para o clinicaltrials.gov, ACTRN para o Australian New Zealand Clinical Trials Registry).

Se a Comissão tiver recebido orientações do Comité de Segurança da Saúde, do Centro Europeu de Prevenção e Controlo das Doenças (ECDC) ou da Agência Europeia de Medicamentos (EMA) no que diz respeito à aceitação de certificados emitidos para uma vacina contra a COVID-19 sujeita a ensaios clínicos, as orientações devem ser publicadas como parte do documento sobre os conjuntos de valores ou separadamente.

▼M1

4.    Titular da autorização de introdução no mercado ou fabricante da vacina contra a COVID-19

Sistema de codificação preferencial:

A utilizar no certificado 1.

De entre os sistemas de codificação preferenciais, um exemplo de código a utilizar é o ORG-100001699 (AstraZeneca AB). Exemplo de nome de organização a utilizar como código: Sinovac-Biotech (que corresponde a Sinovac Biotech).

A Comissão publica e atualiza regularmente com o apoio da rede de saúde em linha um conjunto de valores que estabeleça os códigos a utilizar em conformidade com os sistemas de codificação estabelecidos na presente secção.

As diferentes sucursais do mesmo titular da autorização de introdução no mercado ou do mesmo fabricante utilizam um código existente no conjunto de valores publicado.

Regra geral, para a mesma vacina, é ser utilizado o código referente ao seu titular da autorização de introdução no mercado na UE, uma vez que ainda não existe um registo dos fabricantes de vacinas ou dos titulares da autorização de introdução no mercado internacionalmente acordado. Exemplos:

Se tal não for possível ou aconselhável num caso específico, será fornecido um código separado no conjunto de valores publicado.

▼M4

Se um país que utiliza o EUDCC decidir emitir certificados de vacinação para os participantes em ensaios clínicos durante os ensaios clínicos em curso, o titular da autorização de introdução no mercado ou o fabricante da vacina é codificado utilizando o valor que lhe foi atribuído no conjunto de valores, se disponível. Noutros casos, o titular da autorização de introdução no mercado ou o fabricante da vacina é codificado utilizando a regra descrita na secção 3 Vacina terapêutica (CT_clinical-trial-identifier).

▼M1

5.    Número numa série de doses, bem como o número total de doses na série

A utilizar no certificado 1.

Dois campos:

5.1.    Série de vacinação primária

Se a pessoa receber doses da série de vacinação primária, ou seja, a série de vacinação destinada a proporcionar proteção suficiente numa fase inicial, (C) reflete o número total de doses da série de vacinação primária normal (por exemplo, uma ou duas, consoante o tipo de vacina administrada). Tal inclui a possibilidade de utilizar uma série mais curta (C = 1), em que o protocolo de vacinação aplicado por um Estado-Membro prevê a administração de uma dose única de uma vacina de duas doses a pessoas que tenham sido previamente infetadas pelo SARS-CoV-2. Uma série de vacinação primária completa é, por conseguinte, indicada por N/C = 1. Por exemplo:

Se a série de vacinação primária for alargada, por exemplo, para pessoas com sistemas imunitários gravemente enfraquecidos ou se o intervalo recomendado entre doses primárias não tiver sido respeitado, essas doses devem ser codificadas como doses adicionais abrangidas pela secção 5.2.

▼M2

5.2.    Doses de reforço

Quando a pessoa recebe doses após a série de vacinação primária, essas doses de reforço são refletidas nos certificados correspondentes do seguinte modo:

Os Estados-Membros devem aplicar as regras de codificação estabelecidas na presente secção até 1 de fevereiro de 2022.

Os Estados-Membros devem, automaticamente ou a pedido das pessoas em causa, reemitir certificados em que a administração de uma dose de reforço após um esquema de vacinação primária de dose única é codificada de modo a não poder ser distinguida da conclusão da série de vacinação primária.

Para efeitos do presente anexo, as referências a «doses de reforço» devem ser entendidas como abrangendo também as doses adicionais administradas para proteger melhor as pessoas que apresentam respostas imunitárias inadequadas após a conclusão da série de vacinação primária normal. No quadro jurídico estabelecido pelo Regulamento (UE) 2021/953, os Estados-Membros podem tomar medidas para resolver a situação dos grupos vulneráveis que podem receber doses adicionais a título prioritário. Por exemplo, se um Estado-Membro decidir administrar doses adicionais apenas a subgrupos específicos da população, pode optar, em conformidade com o artigo 5.o, n.o 1, do Regulamento (UE) 2021/953, por emitir certificados de vacinação que indiquem a administração dessas doses adicionais apenas a pedido e não automaticamente. Sempre que tais medidas forem tomadas, os Estados-Membros devem informar as pessoas em causa desse facto, bem como de que podem continuar a utilizar o certificado recebido após a conclusão da série de vacinação primária normal.

▼M1

6.    Estado-Membro ou país terceiro em que a vacina foi administrada/em que o teste foi realizado

Sistema de codificação preferencial: códigos ISO 3166 do país.

A utilizar nos certificados 1, 2 e 3.

Conteúdo do conjunto de valores: a lista completa de códigos de duas letras, disponível como um conjunto de valores definido em FHIR (http://hl7.org/fhir/ValueSet/iso3166-1-2). Se a vacinação ou o teste tiverem sido realizados por uma organização internacional (como o ACNUR ou a OMS) e não estiverem disponíveis informações sobre o país, deve ser utilizado um código para a organização. Esses códigos adicionais são publicados e atualizados regularmente pela Comissão com o apoio da rede de saúde em linha.

7.    Tipo de teste

A utilizar no certificado 2 e no certificado 3, caso seja introduzido o apoio à emissão de certificados de recuperação baseados em tipos de testes diferentes do TAAN, através de um ato delegado.

São utilizados os seguintes códigos:

▼M4

O código LP217198-3 (Imunoensaio rápido) deve ser utilizado para indicar tanto os testes rápidos de deteção de antigénios como os ensaios antigénicos laboratoriais.

▼M1

8.    Fabricante e designação comercial do teste utilizado (opcional para o teste TAAN)

A utilizar no certificado 2.

▼M4

O conteúdo do conjunto de valores deve incluir a seleção de um teste rápido de antigénio conforme indicado na lista comum e atualizada de testes de antigénio à COVID-19, estabelecida com base na Recomendação do Conselho 2021/C 24/01 e aprovada pelo Comité de Segurança da Saúde. A lista é mantida pelo JRC na base de dados de dispositivos de diagnóstico I e métodos de despistagem, em: https://covid-19-diagnostics.jrc.ec.europa.eu/devices/hsc-common-recognition-rat.

▼M1

Para este sistema de codificação, devem ser utilizados campos relevantes, como o identificador do dispositivo de teste, o nome do teste e do fabricante, de acordo com o formato estruturado do JRC disponível em: https://covid-19-diagnostics.jrc.ec.europa.eu/devices

9.    Resultado do teste

A utilizar no certificado 2.

São utilizados os seguintes códigos:

▼B

---

ANEXO III

ESTRUTURA COMUM DO IDENTIFICADOR ÚNICO DO CERTIFICADO

1.    Introdução

Cada Certificado Digital COVID da UE (DCC) deve incluir um identificador único do certificado (UCI) que suporte a interoperabilidade dos DCC. O UCI pode ser utilizado para verificar o certificado. Os Estados-Membros são responsáveis pela implementação do UCI. O UCI constitui um meio de verificação da veracidade do certificado e, quando aplicável, de estabelecer a ligação a um sistema de registo (por exemplo, um IIS). Estes identificadores devem também permitir declarações (em papel e digitais) dos Estados-Membros em como as pessoas foram vacinadas ou testadas.

2.    Composição do identificador único do certificado

O UCI deve seguir uma estrutura e um formato comuns que facilitem a interpretabilidade humana e/ou automática da informação e pode referir-se a elementos como o Estado-Membro de vacinação, a própria vacina e um identificador específico de um Estado-Membro. Garante flexibilidade aos Estados-Membros para o formatar, no pleno respeito da legislação em matéria de proteção de dados. A ordem dos diferentes elementos segue uma hierarquia definida que pode permitir futuras modificações dos blocos, sem deixar de preservar a sua integridade estrutural.

As soluções possíveis para a composição do UCI formam um espectro em que a modularidade e a interpretabilidade humana são os dois principais parâmetros de diversificação e uma característica fundamental:

▼M1

3.    Requisitos gerais

Devem ser cumpridos os seguintes requisitos gerais em relação ao UCI:

É garantida a compatibilidade com versões anteriores: os Estados-Membros que, ao longo do tempo, alterarem a estrutura dos seus identificadores (na versão principal, atualmente a v1) garantem que dois identificadores idênticos representem o mesmo certificado/declaração de vacinação. Por outras palavras, os Estados-Membros não podem reciclar identificadores.

▼B

4.    Opções para identificadores únicos de certificados de vacinação

As orientações da rede de saúde em linha sobre certificados de vacinação verificáveis e elementos básicos de interoperabilidade (eHealth Network guidelines for verifiable vaccination certificates and basic interoperability elements) ( 17 ) preveem diferentes opções para os Estados-Membros e outras entidades que possam coexistir entre diferentes Estados-Membros. Os Estados-Membros podem implementar essas diferentes opções em diferentes versões do esquema do UCI.

---

ANEXO IV

GOVERNAÇÃO DOS CERTIFICADOS DE CHAVE PÚBLICA

1.    Introdução

A troca segura e fiável de chaves de assinatura para os certificados digitais COVID da UE (DCC) entre os Estados-Membros é realizada através do Portal do Certificado COVID digital da UE (DCCG), que atua como um repositório central das chaves públicas. Com o DCCG, os Estados-Membros têm a possibilidade de publicar as chaves públicas correspondentes às chaves privadas que utilizam para assinar certificados digitais COVID. Os Estados-Membros utilizadores podem recorrer ao DCCG para recolher oportunamente material atualizado sobre chaves públicas. Mais tarde, o DCCG pode ser alargado à troca de informações suplementares fiáveis fornecidas pelos Estados-Membros, como regras de validação para os DCC. O modelo de confiança do regime do DCC é uma infraestrutura de chave pública (PKI). Cada Estado-Membro mantém uma ou mais autoridades de certificação signatárias nacionais (CSCA), cujos certificados têm uma duração relativamente longa. Na sequência da decisão do Estado-Membro, a CSCA pode ser igual ou diferente da CSCA competente para os documentos de viagem de leitura ótica. A CSCA emite certificados de chave pública para os signatários de documentos nacionais de curta duração (ou seja, signatários de DCC), que são designados como certificados de signatários de documentos (DSC). A CSCA atua como uma âncora de confiança, pelo que os Estados-Membros utilizadores podem usar o certificado CSCA para validar a autenticidade e integridade dos DSC que são regularmente alterados. Uma vez efetuada a validação, os Estados-Membros podem facultar esses certificados (ou apenas as chaves públicas neles contidas) às suas aplicações de validação dos DCC. Além das CSCA e dos DSC, o DCCG também conta com a PKI para autenticar transações, assinar dados, como base de autenticação e como meio de garantir a integridade dos canais de comunicação entre os Estados-Membros e o DCCG.

As assinaturas digitais podem ser utilizadas para garantir a integridade e a autenticidade dos dados. As infraestruturas de chave pública estabelecem confiança ao associarem chaves públicas a identidades (ou emitentes) verificados. Tal é necessário para permitir que outros participantes verifiquem a origem dos dados e a identidade do parceiro de comunicação e decidam se podem confiar. No DCCG, são utilizados vários certificados de chave pública para efeitos de autenticidade. O presente anexo define os certificados de chave pública utilizados e a forma como devem ser concebidos, a fim de permitir uma ampla interoperabilidade entre os Estados-Membros. Apresenta mais informações sobre os certificados de chave pública necessários e fornece orientações sobre modelos de certificados e períodos de validade aos Estados-Membros que pretendam ter a sua própria CSCA. Uma vez que os DCC devem ser verificáveis durante um determinado período (que tem início com a emissão e expira após algum tempo), é necessário definir um modelo de verificação para todas as assinaturas aplicadas nos certificados de chave pública e nos DCC.

2.    Terminologia

O quadro seguinte contém as abreviaturas e a terminologia utilizadas no presente anexo.

3.    Fluxos de comunicação e serviços de segurança do DCCG

Esta secção apresenta uma visão geral dos fluxos de comunicação e dos serviços de segurança no sistema DCCG. Define igualmente as chaves e os certificados que são utilizados para proteger a comunicação, as informações carregadas, os DCC e uma lista de confiança assinada que contém todos os certificados CSCA integrados. O DCCG funciona como uma plataforma de dados que permite o intercâmbio de pacotes de dados assinados para os Estados-Membros.

Os pacotes de dados carregados são fornecidos pelo DCCG «no estado em que se encontram», o que significa que o DCCG não adiciona nem exclui DSC dos pacotes que recebe. O sistema nacional de retaguarda (NB) dos Estados-Membros deve poder verificar a integridade e autenticidade de ponta a ponta dos dados carregados. Além disso, os sistemas nacionais de retaguarda e o DCCG utilizarão a autenticação TLS mútua para estabelecer uma ligação segura. Trata-se de um complemento às assinaturas nos dados trocados.

3.1.    Autenticação e estabelecimento da ligação

O DCCG utiliza o protocolo de Segurança da Camada de Transporte (TLS) com autenticação mútua para estabelecer um canal cifrado autenticado entre o sistema nacional de retaguarda do Estado-Membro (NB) e o ambiente do portal. Por conseguinte, o DCCG detém um certificado de servidor TLS (DCCGTLS) e os sistemas nacionais de retaguarda detêm um certificado de cliente TLS, (NBTLS). São disponibilizados modelos de certificados na secção 5. Cada sistema nacional de retaguarda pode disponibilizar o seu próprio certificado TLS. Este certificado será explicitamente incluído numa lista branca e, como tal, pode ser emitido por uma autoridade de certificação de confiança pública (por exemplo, uma autoridade de certificação que cumpra os requisitos básicos do CA/Browser Forum), por uma autoridade de certificação nacional ou pode ser autoassinado. Cada Estado-Membro é responsável pelos seus dados nacionais e pela proteção da chave privada utilizada para estabelecer a ligação ao DCCG. A abordagem «traga o seu próprio certificado» requer um processo de registo e identificação bem definido, bem como procedimentos de revogação e renovação, conforme descrito nas secções 4.1, 4.2 e 4.3. O DCCG utiliza uma lista branca a que os certificados TLS dos N.B.: são adicionados uma vez registados com sucesso. Somente os N.B.: que se autenticam com uma chave privada correspondente a um certificado da lista branca podem estabelecer uma ligação segura ao DCCG. O DCCG também utilizará um certificado TLS que permite aos N.B.: verificar se estão efetivamente a estabelecer uma ligação ao DCCG «real» e não a alguma entidade mal-intencionada que se faz passar pelo DCCG. O certificado do DCCG será disponibilizado aos N.B.: uma vez registados com sucesso. O certificado DCCGTLS será emitido por uma AC de confiança pública (incluída em todos os navegadores principais). Os Estados-Membros são responsáveis por verificar se a sua ligação ao DCCG é segura (por exemplo, comparando a impressão digital do certificado DCCGTLS do servidor ligado com aquela que foi fornecida após o registo).

3.2.    Autoridades de certificação signatárias nacionais e modelo de validação

Os Estados-Membros que participam no regime do DCCG devem recorrer a uma CSCA para emitir os DSC. Os Estados-Membros podem ter mais do que uma CSCA, por exemplo, em caso de descentralização regional. Cada Estado-Membro pode recorrer a autoridades de certificação existentes ou criar uma autoridade de certificação (possivelmente autoassinada) específica para o sistema DCC.

Os Estados-Membros devem apresentar o(s) seu(s) certificado(s) CSCA ao operador do DCCG durante o procedimento oficial de integração. Após a conclusão do registo do Estado-Membro (consultar a secção 4.1 para mais informações), o operador do DCCG atualizará uma lista de confiança assinada que contém todos os certificados CSCA que estão ativos no regime do DCC. O operador do DCCG utilizará um par de chaves assimétricas específico para assinar a lista de confiança e os certificados num ambiente fora de linha. A chave privada não será guardada no sistema DCCG em linha, de forma a evitar que um comprometimento do sistema em linha permita a um atacante comprometer a lista de confiança. O certificado âncora de confiança correspondente, DCCGTA, será disponibilizado aos sistemas nacionais de retaguarda durante o processo de integração.

Os Estados-Membros podem obter a lista de confiança junto do DCCG para os seus procedimentos de verificação. A CSCA é definida como a autoridade de certificação que emite DSC; por conseguinte, os Estados-Membros que aplicam uma hierarquia de AC de vários níveis (por exemplo, AC raiz -> CSCA -> DSC) devem indicar a autoridade de certificação subordinada que emite os DSC. Neste caso, se um Estado-Membro recorrer a uma autoridade de certificação existente, o sistema DCC ignorará tudo o que esteja acima da CSCA e coloca na lista branca apenas a CSCA na qualidade de âncora de confiança (mesmo que seja uma AC subordinada). Este modelo, à semelhança do modelo da OACI, só permite exatamente 2 níveis – uma CSCA de «raiz» e um DSC de «folha» assinado apenas por essa CSCA.

Na eventualidade de um Estado-Membro explorar a sua própria CSCA, é responsável pelo funcionamento seguro e pela gestão das chaves desta AC. A CSCA atua como âncora de confiança para os DSC e, portanto, a proteção da chave privada da CSCA é essencial para a integridade do ambiente do DCC. O modelo de verificação na PKI do DCC é o modelo shell, segundo o qual todos os certificados na validação da cadeia de certificação devem ser válidos num determinado momento (ou seja, no momento da validação da assinatura). Por conseguinte, aplicam-se as seguintes restrições:

A secção 4.2 inclui recomendações sobre os períodos de validade.

3.3.    Integridade e autenticidade dos dados carregados

Os sistemas nacionais de retaguarda podem utilizar o DCCG para carregar e descarregar pacotes de dados assinados digitalmente após a conclusão da respetiva autenticação mútua. No início, estes pacotes de dados contêm os DSC dos Estados-Membros. O par de chaves utilizado pelo sistema nacional de retaguarda para a assinatura digital de pacotes de dados carregados no sistema DCCG denomina-se par de chaves de assinatura de carregamento do sistema de retaguarda nacional e o certificado de chave pública correspondente é abreviado como certificado NBUP. Cada Estado-Membro traz o seu próprio certificado NBUP, que pode ser autoassinado ou emitido por uma autoridade de certificação existente, como uma autoridade de certificação pública (ou seja, uma autoridade de certificação que emite o certificado de acordo com os requisitos básicos do CAB-Forum). O certificado NBUP deve ser diferente de quaisquer outros certificados utilizados pelo Estado-Membro (ou seja, CSCA, cliente TLS ou DSC).

Os Estados-Membros devem fornecer o certificado de carregamento ao operador do DCCG durante o procedimento de registo inicial (consultar a secção 4.1 para mais informações). Cada Estado-Membro é responsável pelos seus dados nacionais e deve proteger a chave privada utilizada para assinar os carregamentos.

Outros Estados-Membros podem verificar os pacotes de dados assinados utilizando os certificados de carregamento fornecidos pelo DCCG. O DCCG verifica a autenticidade e a integridade dos dados carregados com o certificado de carregamento do N.B.: antes de serem fornecidos a outros Estados-Membros.

3.4.    Requisitos da arquitetura técnica do DCCG

Os requisitos da arquitetura técnica do DCCG são os seguintes:

4.    Gestão do ciclo de vida dos certificados

4.1.    Registo dos sistemas nacionais de retaguarda

Os Estados-Membros devem registar-se junto do operador do DCCG para participarem no sistema DCCG. Esta secção descreve o procedimento técnico e operacional que deve ser seguido para registar um sistema nacional de retaguarda.

O operador do DCCG e o Estado-Membro devem trocar informações sobre as pessoas de contacto para questões técnicas relativas ao processo de integração. Presume-se que as pessoas de contacto para questões técnicas estejam habilitadas pelos respetivos Estados-Membros e a identificação/autenticação é efetuada através de outros canais. Por exemplo, a autenticação pode ser realizada quando o contacto técnico de um Estado-Membro fornece os certificados sob a forma de ficheiros cifrados por palavra-passe via correio eletrónico e partilha a palavra-passe correspondente com o operador do DCCG por telefone. Também podem ser utilizados outros canais seguros definidos pelo operador do DCCG.

O Estado-Membro deve fornecer três certificados digitais durante o processo de registo e identificação:

Todos os certificados fornecidos devem cumprir os requisitos definidos na secção 5. O operador do DCCG verificará se o certificado fornecido cumpre os requisitos da secção 5. Após a identificação e o registo, o operador do DCCG:

4.2.    Autoridades de certificação, períodos de validade e renovação de certificados

Caso um Estado-Membro pretenda explorar a sua própria CSCA, os certificados CSCA podem ser certificados autoassinados. Estes funcionam como âncora de confiança do Estado-Membro e, por conseguinte, o Estado-Membro deve adotar medidas sólidas para proteger a chave privada que corresponde à chave pública do certificado CSCA. Recomenda-se que os Estados-Membros utilizem um sistema fora de linha para a sua CSCA, ou seja, um sistema informático que não esteja ligado a qualquer rede. Para aceder ao sistema, deve utilizar-se um controlo por múltiplas pessoas (por exemplo, seguindo o princípio dos quatro olhos). Após a assinatura dos DSC, aplicam-se os controlos operacionais e o sistema que contém a chave privada da CSCA deve ser guardado em segurança com fortes controlos de acesso. Para proteger a chave privada da CSCA, também podem ser utilizados módulos de segurança físicos ou cartões inteligentes. Os certificados digitais têm um período de validade que obriga à renovação do certificado. A renovação é necessária para que se utilizem chaves criptográficas novas e se adaptem os tamanhos das chaves sempre que se verifiquem novos avanços informáticos ou ocorram novos ataques que ameacem a segurança do algoritmo criptográfico utilizado. Aplica-se o modelo shell (ver a secção 3.2).

Recomenda-se a aplicação dos períodos de validade seguintes, atendendo à validade de um ano dos certificados digitais COVID:

Para uma renovação em tempo útil, recomendam-se os seguintes prazos de utilização para as chaves privadas:

Os Estados-Membros devem criar novos certificados de carregamento e novos certificados TLS em tempo útil, por exemplo, um mês, antes de os referidos certificados expirarem para que tudo funcione sem incidentes. Os certificados CSCA e os DSC devem ser renovados pelo menos um mês antes de terminar a utilização das chaves privadas (considerando os procedimentos operacionais necessários). Os Estados-Membros devem fornecer certificados CSCA, certificados de carregamento e certificados TLS atualizados ao operador do DCCG. Os certificados expirados devem ser retirados da lista branca e da lista de confiança.

Os Estados-Membros e o operador do DCCG devem monitorizar a validade dos seus próprios certificados. Não existe uma entidade central que mantenha um registo da validade dos certificados e informe os participantes.

4.3.    Revogação de certificados

Em geral, os certificados digitais podem ser revogados pela AC que os emitiu utilizando listas de revogação de certificados ou o respondedor do protocolo sobre o estado do certificado em linha (OCSP). As CSCA para o sistema DCC devem fornecer listas de revogação de certificados (CRL). Mesmo que ainda não estejam a ser utilizados por outros Estados-Membros, estas CRL devem ser integradas para aplicações futuras. Caso uma CSCA decida não fornecer as CRL, os DSC dessa CSCA devem ser renovados quando as CRL passarem a ser obrigatórias. Os verificadores não devem utilizar o OCSP para validação dos DSC, mas sim as CRL. Recomenda-se que o sistema nacional de retaguarda execute a validação necessária dos DSC descarregados do Portal do DCC e que apenas remeta para os validadores nacionais dos DCC um conjunto de DSC de confiança e validados. Os validadores dos DCC não devem executar qualquer controlo da revogação dos DSC no âmbito do seu processo de validação. Uma das razões para tal prende-se com a proteção da privacidade dos titulares dos DCC evitando qualquer possibilidade de que a utilização de um DSC possa ser monitorizada pelo respondedor OCSP associado.

Os Estados-Membros podem remover os seus DSC do DCCG por sua própria iniciativa utilizando certificados de carregamento e TLS válidos. Remover um DSC significa que todos os DCC emitidos com esse DSC ficarão inválidos quando os Estados-Membros obtiverem as listas de DSC atualizadas. É fundamental proteger o material da chave privada correspondente ao DSC. Os Estados-Membros devem informar o operador do DCCG quando tiverem de revogar certificados de carregamento ou TLS, nomeadamente pelo facto de o sistema nacional de retaguarda estar comprometido. O operador do DCCG pode assim retirar a confiança depositada no certificado afetado, por exemplo, removendo-o da lista branca TLS. O operador do DCCG pode remover os certificados de carregamento da base de dados do DCCG. Os pacotes assinados com chave privada que correspondam a este certificado de carregamento ficarão inválidos quando os sistemas nacionais de retaguarda retirarem a confiança ao certificado de carregamento revogado. Caso um certificado CSCA deva ser revogado, os Estados-Membros informam o operador do DCCG, bem como os outros Estados-Membros com quem mantêm relações de confiança. O operador do DCCG emitirá uma nova lista de confiança quando o certificado afetado deixar de constar. Todos os DSC emitidos por esta CSCA ficarão inválidos quando os Estados-Membros atualizarem a loja de confiança do seu sistema nacional de retaguarda. Caso o certificado DCCGTLS ou o certificado DCCGTA deva ser revogado, o operador do DCCG e os Estados-Membros devem colaborar para criar uma nova ligação TLS de confiança e uma nova lista de confiança.

5.    Modelos de certificados

Esta secção estabelece os requisitos e as orientações no que respeita à criptografia, bem como os requisitos relativos aos modelos dos certificados. Para os certificados DCCG, a presente secção define os modelos dos certificados.

5.1.    Requisitos de criptografia

Os algoritmos criptográficos e as sequências de cifras TLS devem ser escolhidos com base na atual recomendação do Serviço Federal Alemão para a Segurança da Informação (BSI) ou do SOG-IS. Estas recomendações e as recomendações de outras instituições e organizações de normalização são semelhantes. É possível encontrar estas recomendações nas orientações técnicas TR 02102-1 e TR 02102-2 ( 18 ) ou nos Mecanismos Criptográficos Acordados (Agreed Cryptographic Mechanisms) do SOG-IS ( 19 ).

5.1.1.    Requisitos aplicáveis ao DSC

Aplicam-se os requisitos previstos no anexo I, secção 3.2.2. Como tal, recomenda-se veementemente que os signatários dos documentos utilizem o algoritmo de assinatura digital de curva elíptica (ECDSA) com NIST-p-256 (tal como definido no apêndice D da FIPS PUB 186-4). Não são suportadas outras curvas elípticas. Devido às restrições de espaço do DCC, os Estados-Membros não devem utilizar RSA-PSS, mesmo que seja autorizado como algoritmo de recurso. Caso utilizem RSA-PSS, os Estados-Membros devem utilizar um módulo com 2048 ou no máximo 3072 bits de tamanho. É utilizada SHA-2 com um comprimento de saída ≥ 256 bits como função criptográfica de dispersão (ver ISO/IEC 10118-3:2004) para a assinatura do DSC.

5.1.2.    Requisitos aplicáveis aos certificados TLS, de carregamento e CSCA

No caso dos certificados digitais e das assinaturas criptográficas no contexto do DCCG, os principais requisitos aplicáveis aos algoritmos criptográficos e ao comprimento das chaves encontram-se resumidos no quadro seguinte (a partir de 2021):

A curva elíptica recomendada para o EC-DSA é NIST-p-256 devido à sua aplicação generalizada.

5.2.    Certificado CSCA (NBCSCA)

O quadro seguinte fornece orientações sobre o modelo de certificado NBCSCA, caso um Estado-Membro decida explorar a sua própria CSCA para o sistema DCC.

As entradas a negrito são obrigatórias (e devem ser incluídas no certificado), as entradas em itálico são recomendadas (convém serem incluídas). Não foram definidas quaisquer recomendações para os campos em falta.

O nome da entidade não pode estar vazio e deve ser único dentro do Estado-Membro especificado. O código do país (c) deve corresponder ao Estado-Membro que utilizará este certificado CSCA. O certificado deve conter um identificador de chave único da entidade (SKI) de acordo com o RFC 5280 ( 20 ).

5.3.    Certificado de signatário de documento (DSC)

O quadro seguinte fornece orientações sobre o DSC. As entradas a negrito são obrigatórias (e devem ser incluídas no certificado), as entradas em itálico são recomendadas (convém serem incluídas). Não foram definidas quaisquer recomendações para os campos em falta.

O DSC deve ser assinado com a chave privada correspondente a um certificado CSCA que seja utilizado pelo Estado-Membro.

Deverão ser utilizadas as extensões seguintes:

Além disso, o certificado deve conter a extensão do ponto de distribuição da lista de revogação de certificados (CRL) que indica a CRL fornecida pela CSCA que emitiu o DSC.

O DSC pode conter uma extensão de utilização alargada da chave com zero ou mais identificadores de políticas de utilização de chaves que condicionam os tipos de HCERT cuja verificação este certificado permite. Se estiverem presentes um ou mais tipos, os verificadores devem verificar a utilização da chave em relação ao HCERT guardado. Para o efeito, são definidos os seguintes valores de utilização alargada da chave (extendedKeyUsage):

Na ausência de uma extensão de utilização da chave (ou seja, sem extensões ou zero extensões), este certificado pode ser utilizado para validar qualquer tipo de HCERT. Outros documentos podem definir identificadores pertinentes adicionais da política de utilização alargada da chave utilizados com a validação de HCERT.

5.4.    Certificados de carregamento (NBUP)

O quadro seguinte fornece orientações sobre o certificado de carregamento do sistema nacional de retaguarda. As entradas a negrito são obrigatórias (e devem ser incluídas no certificado), as entradas em itálico são recomendadas (convém serem incluídas). Não foram definidas quaisquer recomendações para os campos em falta.

5.5.    Autenticação de cliente TLS do sistema nacional de retaguarda (NBTLS)

O quadro seguinte fornece orientações relativas ao certificado de autenticação de cliente TLS do sistema nacional de retaguarda. As entradas a negrito são obrigatórias (e devem ser incluídas no certificado), as entradas em itálico são recomendadas (convém serem incluídas). Não foram definidas quaisquer recomendações para os campos em falta.

O certificado também pode conter a autenticação do servidor (1.3.6.1.5.5.7.3.1) com utilização alargada da chave, mas não é obrigatório.

5.6.    Certificado de assinatura da lista de confiança (DCCGTA)

O quadro seguinte define o certificado âncora de confiança do DCCG.

5.7.    Certificados do servidor TLS do DCCG (DCCGTLS)

O quadro seguinte define o certificado TLS do DCCG.

O certificado também pode conter a autenticação de cliente (1.3.6.1.5.5.7.3.2) com utilização alargada da chave, mas não é obrigatório.

O certificado TLS do DCCG é emitido por uma autoridade de certificação de confiança pública (incluída em todos os navegadores e sistemas operativos principais, segundo os requisitos básicos do CA/Browser Forum).

▼M1

---

ANEXO IV

ESQUEMA DE NOTAÇÃO DE OBJETOS JAVASCRIPT (JSON)

1.    Introdução

O presente anexo estabelece a estrutura técnica dos dados para os Certificados Digitais COVID da UE (EUDCC), representados como um esquema JSON. O documento contém instruções específicas relativas aos campos de dados individuais.

2.    Localização e versões do esquema JSON

O esquema JSON oficial e autêntico para o EUDCC está disponível em https://github.com/ehn-dcc-development/ehn-dcc-schema. Outros endereços não são autênticos, mas podem ser utilizados para preparar futuras revisões.

Por defeito, a versão atual constante do presente anexo e suportada por todos os países atualmente em produção é apresentada no URL indicado.

A próxima versão que, numa data determinada, deverá ser suportada por todos os países, é apresentada no URL indicado através da etiquetagem das versões (version tagging), descrita mais especificamente no ficheiro Readme.

▼M3

3.    Estruturas comuns e requisitos gerais

Não é emitido um Certificado Digital COVID da UE se, devido à falta de informações, não for possível preencher corretamente todos os campos de dados em conformidade com a presente especificação. Tal não deve ser entendido como afetando a obrigação de os Estados-Membros emitirem Certificados Digitais COVID da UE.

As informações de todos os campos podem ser fornecidas utilizando o conjunto completo de carateres UNICODE 13.0 codificados em UTF-8, salvo se especificamente restringidos a conjuntos de valores ou a conjuntos de carateres mais reduzidos.

A estrutura comum é a seguinte:

«JSON»:{

«ver»:<informação sobre a versão>,

«nam»:{

<informação sobre o nome da pessoa>

},

«dob»:<data de nascimento>,

«v» ou «t» ou «r»:[

{<informação sobre a dose de vacinação ou o teste ou a recuperação, uma entrada>}

]

}

Nas secções seguintes são fornecidas informações pormenorizadas sobre os diferentes grupos e campos.

Sempre que as regras indicarem que um campo deve ser ignorado, tal significa que o conteúdo deste deve permanecer vazio e que não é permitido inserir o nome ou o valor do campo.

3.1.    Versão

Devem ser fornecidas informações sobre a versão. A gestão das versões é efetuada segundo o Semantic Versioning (semver: https://semver.org). Em produção, deve ser uma das versões oficialmente publicadas (atuais ou oficialmente publicadas anteriormente). Para mais informações, ver o ponto relativo à localização do esquema (Schema) JSON.

3.2.    Nome e data de nascimento da pessoa

O nome da pessoa é o nome oficial completo da pessoa, correspondente ao nome indicado nos documentos de viagem. O identificador da estrutura é nam. Deve ser fornecido exatamente 1 (um) nome de pessoa.

3.3.    Grupos para as informações específicas do tipo de certificado

O esquema (Schema) JSON apoia três grupos de entradas que abrangem informações específicas do tipo de certificado. Cada EUDCC deve conter exatamente 1 (um) grupo. Não são permitidos grupos vazios.

▼M1

4.    Informações específicas do tipo de certificado

4.1.    Certificado de vacinação

O grupo de vacinação, se presente, deve conter exatamente 1 (uma) entrada que descreva exatamente um evento de vacinação (uma dose). Todos os elementos do grupo de vacinação são obrigatórios e não são aceites valores vazios.

4.2.    Certificado de teste

O grupo teste, se presente, deve conter exatamente 1 (uma) entrada que descreva exatamente um resultado de teste.

4.3.    Certificado de recuperação

O grupo de teste, se presente, deve conter exatamente 1 (uma) entrada que descreva exatamente uma declaração de recuperação. Todos os elementos do grupo de recuperação são obrigatórios e não são aceites valores vazios.

▼M3

---

ANEXO VI

RESPONSABILIDADES DOS ESTADOS-MEMBROS ENQUANTO RESPONSÁVEIS CONJUNTOS PELO TRATAMENTO NO ÂMBITO DO PORTAL DO CERTIFICADO DIGITAL COVID DA UE NO QUE RESPEITA AO INTERCÂMBIO DE LISTAS DE REVOGAÇÃO DE EUDCC

PONTO 1

Subponto 1

Repartição de responsabilidades

Subponto 2

Responsabilidades e funções para tramitação de pedidos e informação dos titulares dos dados

PONTO 2

Gestão de incidentes de segurança, incluindo violações de dados pessoais

PONTO 3

Avaliação de impacto sobre a proteção de dados

---

ANEXO VII

RESPONSABILIDADES DA COMISSÃO ENQUANTO SUBCONTRATANTE NO ÂMBITO DO PORTAL DO CERTIFICADO DIGITAL COVID DA UE NO QUE RESPEITA AO APOIO AO INTERCÂMBIO DE LISTAS DE REVOGAÇÃO DE EUDCC

A Comissão:

---

( 1 ) rfc8392 (ietf.org).

( 2 ) rfc8152 (ietf.org).

( 3 ) rfc8230 (ietf.org).

( 4 ) rfc8392 (ietf.org).

( 5 ) rfc8392 (ietf.org).

( 6 ) rfc7159 (ietf.org).

( 7 ) rfc7049 (ietf.org).

( 8 ) Regulamento (UE) 2021/953 do Parlamento Europeu e do Conselho de 14 de junho de 2021 relativo a um regime para a emissão, verificação e aceitação de certificados interoperáveis de vacinação, teste e recuperação da COVID-19 (Certificado Digital COVID da UE), a fim de facilitar a livre circulação durante a pandemia de COVID-19, JO L 211 de 15.6.2021, p. 1.

( 9 ) rfc1950 (ietf.org).

( 10 ) rfc1951 (ietf.org).

( 11 ) rfc7517 (ietf.org).

( 12 ) Para descrições pormenorizadas da API, consultar igualmente o ponto 9.5.1.2.

( 13 ) A indicação «obsoleto» significa que esta funcionalidade não deve ser considerada para novas implementações, mas deve ser suportada para implementações existentes durante um período bem definido.

( 14 ) rfc3986 (ietf.org)

( 15 ) Para a implementação com códigos QR, os Estados-Membros podem considerar a possibilidade de utilizar um conjunto extra de carateres com um comprimento total máximo de 72 carateres (incluindo os 27-30 do próprio identificador) a fim de transmitir outras informações. Compete aos Estados-Membros definir a especificação desta informação.

( 16 ) O algoritmo Luhn mod N é uma extensão do algoritmo Luhn (também conhecido como algoritmo mod 10) que funciona para códigos numéricos e é usado, por exemplo, para calcular a soma de controlo dos cartões de crédito. A extensão permite que o algoritmo funcione com sequências de valores em qualquer base (neste caso, carateres alfa).

( 17 ) https://ec.europa.eu/health/sites/default/files/ehealth/docs/vaccination-proof_interoperability-guidelines_en.pdf.

( 18 ) BSI – Orientações técnicas TR-02102 (bund.de).

( 19 ) SOG-IS – Documentos de apoio (sogis.eu).

( 20 ) rfc5280 (ietf.org).

( 21 ) rfc5280 (ietf.org).