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:









▼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

1. O regime de confiança do Certificado Digital COVID da UE permite o intercâmbio de listas de revogação de certificados por intermédio do portal central do Certificado Digital COVID da UE (a seguir designado por «portal»), em conformidade com as especificações técnicas constantes do anexo I.

2. Sempre que os Estados-Membros revoguem Certificados Digitais COVID da UE, podem enviar listas de revogação de certificados para o portal.

3. Se os Estados-Membros enviarem listas de revogação de certificados, as autoridades emitentes devem manter uma lista dos certificados revogados.

4. Sempre que sejam trocados dados pessoais por intermédio do portal, o tratamento dos mesmos limita-se à finalidade de apoiar o intercâmbio de informações sobre a revogação. Esses dados pessoais só podem ser utilizados para efeitos de verificação do estado de revogação de Certificados Digitais COVID da UE emitidos no âmbito do Regulamento (UE) 2021/953.

5. As informações enviadas para o portal devem incluir os seguintes dados, em conformidade com as especificações técnicas constantes do anexo I: a) os identificadores únicos dos certificados revogados, pseudonimizados; b) a data de expiração da lista de revogação de certificados enviada;

6. Se uma autoridade emitente revogar Certificados Digitais COVID da UE por si emitidos nos termos do Regulamento (UE) 2021/953 ou do Regulamento (UE) 2021/954 e pretender trocar informações pertinentes por intermédio do portal, deve transmitir as informações referidas no n. o 5 sob a forma de listas de revogação de certificados enviadas para o portal num formato seguro, em conformidade com as especificações técnicas constantes do anexo I.

7. As autoridades emitentes devem, na medida do possível, encontrar uma solução que permita informar os titulares de certificados revogados do estado de revogação desses certificados, bem como dos motivos da revogação no momento da mesma.

8. O portal colige as listas de revogação de certificados recebidas e fornece ferramentas para as distribuir aos Estados-Membros. As listas são apagadas automaticamente, em conformidade com as datas de expiração indicadas para cada lista enviada pelas autoridades pertinentes.

9. As autoridades nacionais ou os organismos oficiais designados pelos Estados-Membros que tratam dados pessoais no portal são responsáveis conjuntos pelo tratamento desses dados. As responsabilidades respetivas dos responsáveis conjuntos pelo tratamento são atribuídas em conformidade com o anexo VI.

10. A Comissão é o subcontratante de dados pessoais tratados no portal. Na sua qualidade de subcontratante em nome dos Estados-Membros, a Comissão assegura a segurança da transmissão e do alojamento de dados pessoais no portal e cumpre as obrigações do subcontratante estabelecidas no anexo VII.

11. A Comissão e os responsáveis conjuntos pelo tratamento testam, analisam e avaliam periodicamente a eficácia das medidas técnicas e organizativas adotadas para garantir a segurança do tratamento de dados pessoais no portal.

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

1. O processo de tomada de decisões dos responsáveis conjuntos pelo tratamento é conduzido por um grupo de trabalho criado no âmbito do comité referido no artigo 14. o do Regulamento (UE) 2021/953.

2. As autoridades nacionais ou os organismos oficiais designados pelos Estados-Membros que tratam dados pessoais no portal na qualidade de responsáveis conjuntos pelo tratamento devem designar representantes para esse grupo.

▼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

— algoritmo de assinatura (alg, etiqueta 1)

— identificador de chave (kid, etiqueta 4)

Carga útil

— emitente (iss, chave de atributo 1, opcional, ISO 3166-1 alfa-2 do emitente)

— emitido em (iat, chave de atributo 6)

— prazo de expiração (exp, chave de atributo 4)

— certificado sanitário (hcert, chave de atributo -260)

— certificado Digital COVID da UE v1 (eu_DCC_v1, chave de atributo 1)

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:

— Algoritmo primário: o algoritmo primário é o algoritmo de assinatura digital de curva elíptica (ECDSA), conforme definido na norma (ISO/IEC 14888–3:2006), secção 2.3, utilizando os parâmetros P–256, definidos no apêndice D (D.1.2.3) da norma (FIPS PUB 186–4) em combinação com o algoritmo de dispersão SHA–256, definido na função 4 da norma (ISO/IEC 10118–3:2004).

Este corresponde ao parâmetro ES256 do algoritmo COSE.

— Algoritmo secundário: o algoritmo secundário é RSASSA-PSS conforme definido no (RFC 8230 ( 3 )), com um módulo de 2048 bits em combinação com o algoritmo de dispersão SHA–256, definido na função 4 da norma (ISO/IEC 10118–3:2004).

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:

— o processo de geração de chaves pode ser deficiente, resultando em chaves fracas,

— as chaves podem ser reveladas devido a erro humano,

— as chaves podem ser roubadas por criminosos externos ou internos,

— as chaves podem ser calculadas através de criptoanálise,

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:

— um Estado-Membro pode apresentar vários certificados CSCA,

— o período de validade do DSC (utilização da chave) pode ser definido com qualquer duração que não exceda a do certificado CSCA e pode estar ausente,

— o DSC pode conter identificadores de políticas (utilização alargada da chave) específicos dos certificados sanitários,

— os Estados-Membros podem optar por nunca efetuar qualquer verificação das revogações publicadas, fazendo simplesmente fé nas listas de DSC que recebem diariamente do secretariado ou que coligem.

▼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:







Tipo Atributo Cálculo do valor de dispersão SIGNATURE DCC Signature SHA256 de DCC Signature UCI UCI (Unique Certificate Identifier) SHA256 de UCI COUNTRYCODEUCI Issuing Country Code + UCI SHA256 de Issuing CountryCode + UCI

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

{

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

}

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:







Campo Definição more Variável booliana que indica se existem mais lotes. batches Matriz com os lotes existentes. batchId https://en.wikipedia.org/wiki/Universally_unique_identifier country Código ISO 3166 do país. date Data UTC (tempo universal coordenado) no formato ISO 8601. Data em que o lote foi adicionado ou eliminado. deleted Boolean [variável booliana]. «True» (verdadeiro) se o lote tiver sido eliminado. A entrada pode ser removida definitivamente dos resultados da consulta passados sete dias de esta variável assumir o valor de verdadeiro.

9.5.1.2.1.1. Códigos de resposta







Código Descrição 200 Conteúdo apresentado normalmente. 204 Nenhum conteúdo apresentado, caso não haja correspondências com o conteúdo do cabeçalho «If-Modified-Since».

Cabeçalho do pedido







Cabeçalho Obrigatório Descrição If-Modified-Since Sim Este cabeçalho contém a última data descarregada, para que sejam apresentados apenas resultados mais recentes. Numa primeira chamada à API, o cabeçalho deve estar definido do seguinte modo: «2021-06-01T00:00:00Z».

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

{

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

}

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:







Campo Obrigatório Tipo Definição expires Sim String Data em que o item pode ser removido. Data/hora UTC no formato ISO 8601. country Sim String Código ISO 3166 do país. hashType Sim String Tipo do valor de dispersão das entradas apresentadas (ver Tipos de valores de dispersão) entries Sim JSON Object Array Ver quadro Entradas kid Sim String KID (identificador da chave) codificado em base64 do DSC utilizado para assinar o DCC. Se o KID for desconhecido, pode utilizar-se a cadeia «UNKNOWN_KID» (excluindo as aspas). Notas:

— Os lotes são agregados por data de expiração e por DSC, ou seja, todos os itens expiram em simultâneo e foram assinados usando a mesma chave;

— O prazo de expiração é uma data/hora no UTC, uma vez que o EU-DCC é um sistema global e é necessário utilizar uma hora inequívoca;

— A data de expiração de um DCC definitivamente revogado é fixada como a data de expiração do DSC correspondente utilizado para assinar o DCC ou como o prazo de expiração do DCC revogado (sendo que, neste caso, os prazos no formato NumericDate/epoch utilizados são tratados como estando no fuso horário UTC);

— Cabe aos sistemas nacionais de retaguarda (NB) remover itens das respetivas listas de revogação, uma vez atingida a data de expiração ;

— Os N.B. podem remover itens das listas de revogação caso o KID utilizado para assinar o DCC seja revogado.

9.5.1.2.2.1. Entradas







Campo Obrigatório Tipo Definição hash Sim String Primeiros 128 bits do valor de dispersão SHA256 codificado como cadeia de base64

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







Código Descrição 200 Conteúdo apresentado normalmente. 410 O lote foi removido. O sistema nacional de retaguarda pode eliminar o lote.

9.5.1.2.2.3. Cabeçalhos de resposta







Cabeçalho Descrição ETag ID do lote.

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:

{

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

}

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:

{

“batchId”: “...”

}

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:

{

“batchId”: “...”

}

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:

RevocationListReader

RevocationUploader

RevocationDeleter

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:







Código Visualização Nome do sistema de codificação URL do sistema de codificação OID do sistema de codificação Versão do sistema de codificação 840539006 COVID-19 SNOMED CT http://snomed.info/sct 2.16.840.1.113883.6.96 2021-01-31

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

— Registo de Medicamentos da União para vacinas com autorização a nível da UE (números de autorização);

— um registo de vacinas mundial que possa ser estabelecido pela Organização Mundial da Saúde;

— nome da vacina terapêutica noutros casos. Se o nome incluir espaços em branco, estes são substituídos por um hífen (-).

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:

— Para a vacina «COVID-19 Vaccine Moderna Intramuscular Injection», que é o nome da vacina Spikevax no Japão, utilizar o código EU/1/20/1507, uma vez que é o nome desta vacina na UE.

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:

— código da organização da EMA (sistema SPOR para ISO IDMP)

— um registo mundial de titulares da autorização de introdução no mercado ou fabricantes da vacina que possa, nomeadamente, ser estabelecido pela Organização Mundial da Saúde;

— nome da organização noutros casos. Se o nome incluir espaços em branco, estes são substituídos por um hífen (-).

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:

— para a organização «Pfizer AG», que é um titular da AIM para a vacina «Comirnaty» utilizada na Suíça, utilizar o código ORG-100030215 referente à BioNTech Manufacturing GmbH, uma vez que é o titular da AIM da Comirnaty na UE.

— para a organização «Zuellig Pharma», que é um titular da AIM para a vacina Covid-19 Vaccine Moderna (Spikevax) utilizada nas Filipinas, utilizar o código ORG-100031184 referente à Moderna Biotech Spain S.L., uma vez que é o titular da AIM da Spikevax na UE.

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:

1) Número numa série de doses de vacina de uma vacina contra a COVID-19 (N);

2) Número total de doses na série de vacinação (C).

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:

— 1/1 indicaria a conclusão de um esquema de vacinação primária de dose única, ou a conclusão de um esquema primário constituído por uma dose de uma vacina de duas doses administrada a uma pessoa recuperada, em conformidade com o protocolo de vacinação aplicado por um Estado-Membro;

— 2/2 indicaria a conclusão de uma série de vacinação primária de duas doses.

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:

— 2/1 indica a administração de uma dose de reforço após um esquema de vacinação primária de dose única, ou a administração de uma dose de reforço após a conclusão de um esquema primário constituído por uma dose de uma vacina de duas doses administrada a uma pessoa recuperada, em conformidade com o protocolo de vacinação aplicado por um Estado-Membro. Subsequentemente, as doses (X) administradas após a primeira dose de reforço devem ser indicadas por (2 + X)/(1) > 1 (por exemplo, 3/1);

— 3/3 indica a administração de uma dose de reforço após uma série de vacinação primária de duas doses. Subsequentemente, as doses (X) administradas após a primeira dose de reforço devem ser indicadas por (3 + X)/(3 + X) = 1 (por exemplo, 4/4).

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:







Código Visualização Nome do sistema de codificação URL do sistema de codificação OID do sistema de codificação Versão do sistema de codificação LP6464-4 Amplificação de ácidos nucleicos com deteção por sonda LOINC http://loinc.org 2.16.840.1.113883.6.1 2.69 LP217198-3 Imunoensaio rápido LOINC http://loinc.org 2.16.840.1.113883.6.1 2.69

▼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:







Código Visualização Nome do sistema de codificação URL do sistema de codificação OID do sistema de codificação Versão do sistema de codificação 260415000 Não detetado SNOMED CT http://snomed.info/sct 2.16.840.1.113883.6.96 2021-01-31 260373001 Detetado SNOMED CT http://snomed.info/sct 2.16.840.1.113883.6.96 2021-01-31

▼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:

— modularidade: o grau em que o código é composto de elementos constituintes distintos que contêm informações semanticamente diferentes

— interpretabilidade humana: o grau em que o código é significativo ou pode ser interpretado pelo leitor humano

— globalmente único; o identificador do país ou da autoridade é corretamente gerido; e cada país (autoridade) deve gerir corretamente o seu segmento do espaço de nomes, nunca reciclando ou reemitindo identificadores. A combinação destes fatores garante que cada identificador seja globalmente único

▼M1

3. Requisitos gerais

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

1) Conjunto de carateres: só são permitidos carateres alfanuméricos US-ASCII maiúsculos («A» a «Z», «0» a «9»); com carateres especiais adicionais para separação do RFC3986 ( 14 ), designadamente {'/','#',':'};

2) Comprimento máximo: os criadores devem ter como objetivo um comprimento de 27 a 30 carateres ( 15 );

3) Prefixo da versão: refere-se à versão do esquema do UCI. O prefixo da versão é «01» para a presente versão do documento; o prefixo da versão é composto por dois dígitos;

4) Prefixo do país: o código do país é especificado pela norma ISO 3166-1. São reservados códigos mais longos [por exemplo, três carateres ou mais (por exemplo, «ACNUR»)] para utilização futura;

5) Sufixo do código/soma de controlo: 5.1 Os Estados-Membros podem utilizar uma soma de controlo quando for provável a ocorrência de transmissão, transcrição (humana) ou outras corrupções (ou seja, em caso de utilização de um formato impresso). 5.2 A soma de controlo não deve ser considerada para validar o certificado e não faz tecnicamente parte do identificador, mas é utilizada para verificar a integridade do código. Esta soma de controlo deve corresponder ao resumo da norma ISO-7812-1 (LUHN-10) ( 16 ) de todo o UCI em formato de transporte digital/por cabo. A soma de controlo é separada do resto do UCI por um caráter «#».

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







Termo Definição Certificado Ou certificado de chave pública. Um certificado X.509 v3 que contém a chave pública de uma entidade CSCA Autoridade de certificação signatária nacional DCC Certificado Digital COVID da UE. Um documento digital assinado que contém informações sobre a vacinação, os testes ou a recuperação DCCG Portal do Certificado Digital COVID da UE. Sistema utilizado para trocar DSC entre os Estados-Membros DCCGTA O certificado âncora de confiança do DCCG. A chave privada correspondente é utilizada para assinar a lista de todos os certificados CSCA fora de linha DCCGTLS O certificado do servidor TLS do DCCG DSC Certificado de signatário de documento. O certificado de chave pública da autoridade signatária do documento de um Estado-Membro (por exemplo, um sistema autorizado a assinar DCC). Este certificado é emitido pela CSCA do Estado-Membro EC-DSA Algoritmo de assinatura digital de curva elíptica. Um algoritmo de assinatura criptográfica baseado em curvas elípticas Estado-Membro Estado-Membro da União Europeia mTLS TLS mútua. O protocolo de Segurança da Camada de Transporte com autenticação mútua N.B.: Sistema nacional de retaguarda (backend) de um Estado-Membro NBCSCA O certificado CSCA de um Estado-Membro (pode ser mais do que um) NBTLS O certificado de autenticação de cliente TLS de um sistema nacional de retaguarda NBUP O certificado que um sistema nacional de retaguarda utiliza para assinar pacotes de dados carregados no DCCG PKI Infraestrutura de chave pública. Modelo de confiança baseado em certificados de chave pública e autoridades de certificação RSA Algoritmo criptográfico assimétrico baseado na fatorização de inteiros utilizado nas assinaturas digitais ou na cifragem assimétrica

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 CSCA não deve emitir certificados que tenham validade superior à do próprio certificado da AC,

— o signatário do documento não deve assinar documentos que tenham validade superior à do próprio DSC,

— os Estados-Membros que exploram a sua própria CSCA devem definir períodos de validade para a sua CSCA e para todos os certificados emitidos e devem tratar da renovação dos certificados.

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:

— o DCCG utiliza autenticação TLS mútua para estabelecer uma ligação cifrada autenticada aos N.B.: Deste modo, o DCCG mantém uma lista branca de certificados de cliente NB TLS registados,

— o DCCG utiliza dois certificados digitais (DCCG TLS e DCCG TA ) com dois pares de chaves distintos. A chave privada do par de chaves DCCG TA é mantida fora de linha (e não nos componentes em linha do DCCG),

— o DCCG mantém uma lista de confiança dos certificados NB CSCA , que é assinada com a chave privada DCCG TA ,

— as cifras utilizadas devem cumprir os requisitos da secção 5.1 .

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:

— o certificado TLS NB TLS do Estado-Membro

— o certificado de carregamento NB UP do Estado-Membro

— o(s) certificado(s) CSCA NB CSCA do Estado-Membro

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:

— adiciona o(s) certificado(s) NB CSCA à lista de confiança assinada com a chave privada que corresponde à chave pública DCCG TA ,

— adiciona o certificado NB TLS à lista branca do ponto final TLS do DCCG,

— adiciona o certificado NB UP ao sistema DCCG,

— fornece o certificado de chave pública DCCG TA e DCCG TLS ao Estado-Membro.

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:

— CSCA: 4 anos

— DSC: 2 anos

— Carregamento: 1-2 anos

— Autenticação de cliente TLS: 1-2 anos

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

— CSCA: 1 ano

— DSC: 6 meses

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







Algoritmo de assinatura Tamanho da chave Função de dispersão EC-DSA Mín. 250 bits SHA-2 com um comprimento de saída ≥ 256 bits RSA-PSS (zona de preenchimento recomendada) RSA-PKCS#1 v1.5 (zona de preenchimento pré-existente) Mín. 3000 bits Módulo RSA (N) com um expoente público e > 2^16 SHA-2 com um comprimento de saída ≥ 256 bits DSA Mín. 3000 bits primo p, 250 bits chave q SHA-2 com um comprimento de saída ≥ 256 bits

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.







Campo Valor Entidade cn=<nome comum não vazio e único>, o=<Fornecedor>, c=<Estado-Membro que explora a CSCA> Utilização de chave assinatura do certificado, assinatura da CRL (no mínimo) Restrições de base AC = verdadeiro, restrições ao comprimento da cadeia = 0

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.







Campo Valor Número de série número de série único Entidade cn=<nome comum não vazio e único>, o=<Fornecedor>, c=<Estado-Membro que utiliza este DSC> Utilização de chave assinatura digital (no mínimo)

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:

— o certificado deve conter um identificador de chave da autoridade (AKI) que corresponda ao identificador de chave da entidade (SKI) do certificado da CSCA emitente

— o certificado deve conter um identificador de chave único da entidade (de acordo com o RFC 5280 ( 21 ))

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







Campo Valor extendedKeyUsage 1.3.6.1.4.1.1847.2021.1.1 para os emitentes «testes» extendedKeyUsage 1.3.6.1.4.1.1847.2021.1.2 para os emitentes «vacinação» extendedKeyUsage 1.3.6.1.4.1.1847.2021.1.3 para os emitentes «recuperação»

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.







Campo Valor Entidade cn=<nome comum não vazio e único>, o=<Fornecedor>, c=<Estado-Membro que utiliza este certificado de carregamento> Utilização de chave assinatura digital (no mínimo)

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.







Campo Valor Entidade cn=<nome comum não vazio e único>, o=<Fornecedor>, c=<Estado-Membro do NB> Utilização de chave assinatura digital (no mínimo) Utilização alargada da chave autenticação de cliente (1.3.6.1.5.5.7.3.2)

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.







Campo Valor Entidade cn = Portal do Certificado Verde Digital (1) , o=<Fornecedor>, c=<país> Utilização de chave assinatura digital (no mínimo) ( 1 ) A expressão «Certificado Verde Digital» em vez de «Certificado Digital COVID da UE» foi mantida neste contexto por ser a terminologia que foi consagrada e implementada no certificado antes de os colegisladores decidirem utilizar uma nova terminologia.

5.7. Certificados do servidor TLS do DCCG (DCCGTLS)

O quadro seguinte define o certificado TLS do DCCG.







Campo Valor Entidade cn=<FQDN ou endereço IP do DCCG>, o=<Fornecedor>, c=<país> NomeAltEntidade NomedNS: <nome DNS do DCCG> ou Endereço IP: <endereço IP do DCCG> Utilização de chave assinatura digital (no mínimo) Utilização alargada da chave autenticação do servidor (1.3.6.1.5.5.7.3.1)

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.







ID do campo Nome do campo Instruções ver Versão do esquema Deve corresponder ao identificador da versão do esquema utilizada para produzir o EUDCC. Exemplo: «ver»: «1.3.0»

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.







ID do campo Nome do campo Instruções nam/fn Apelido(s) Apelido(s) do titular Se o titular não tiver apelidos e tiver um nome próprio, o campo deve ser ignorado. Nos restantes casos, deve ser fornecido exatamente 1 (um) campo não vazio, com todos os apelidos nele incluídos. Em caso de apelidos múltiplos, estes devem ser separados por um espaço. Os nomes combinados que incluam hífenes ou carateres semelhantes devem, no entanto, permanecer iguais. Exemplos: «fn»:«Musterfrau-Gößinger» «fn»:«Musterfrau-Gößinger Müller» nam/fnt Apelido(s) normalizado(s) Apelido(s) do titular transliterado(s) segundo a mesma convenção utilizada nos documentos de viagem de leitura automática do titular (por exemplo, as regras definidas na parte 3 do documento ICAO Doc 9303). Se o titular não tiver apelidos e tiver um nome próprio, o campo deve ser ignorado. Nos restantes casos, deve ser fornecido exatamente 1 (um) campo não vazio, incluindo apenas os carateres A-Z e <. Comprimento máximo: 80 carateres (de acordo com as especificações ICAO 9303). Exemplos: «fnt»:«MUSTERFRAU<GOESSINGER» «fnt»:«MUSTERFRAU<GOESSINGER<MUELLER» nam/gn Nome(s) próprio(s) Nome(s) próprio(s) do titular. Se o titular não tiver nomes próprios e tiver um apelido, o campo deve ser ignorado. Nos restantes casos, deve ser fornecido exatamente 1 (um) campo não vazio, com todos os nomes próprios nele incluídos. Em caso de nomes próprios múltiplos, estes devem ser separados por um espaço. Exemplo: «gn»:«Isolde Erika» nam/gnt Nome(s) próprio(s) normalizado(s) Nome(s) próprio(s) do titular transliterado(s) segundo a mesma convenção utilizada nos documentos de viagem de leitura automática do titular (por exemplo, as regras definidas na parte 3 do documento ICAO Doc 9303). Se o titular não tiver nomes próprios e tiver um apelido, o campo deve ser ignorado. Nos restantes casos, deve ser fornecido exatamente 1 (um) campo não vazio, incluindo apenas os carateres A-Z e <. Comprimento máximo: 80 carateres. Exemplo: «gnt»:«ISOLDE<ERIKA» dob Data de nascimento Data de nascimento do titular do DCC. Data completa ou parcial sem hora, limitada ao intervalo compreendido entre 1900-01-01 e 2099-12-31. Deve ser fornecido exatamente 1 (um) campo não vazio se a data de nascimento completa ou parcial for conhecida. Se a data de nascimento não for conhecida, mesmo parcialmente, o campo deve ser uma cadeia vazia: «». Estas informações devem corresponder às que constam dos documentos de viagem. Se estiverem disponíveis informações sobre a data de nascimento, deve ser utilizado um dos seguintes formatos ISO 8601. Não são aceites outras opções. YYYY-MM-DD YYYY-MM YYYY (A aplicação de verificação pode mostrar as partes em faltam da data de nascimento utilizando a convenção XX como a utilizada nos documentos de viagem de leitura automática, por exemplo, 1990-XX-XX.) Exemplos: «dob»:«1979-04-14» «dob»:«1901-08» «dob»:«1939» «dob»:””

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.







Identificador do grupo Nome do grupo Entradas v Grupo de vacinação Se presente, deve conter exatamente 1 (uma) entrada que descreva exatamente 1 (uma) dose de vacinação (uma dose). t Grupo de teste Se presente, deve conter exatamente 1 (uma) entrada que descreva exatamente 1 (um) resultado de teste. r Grupo de recuperação Se presente, deve conter exatamente 1 (uma) entrada que descreva 1 (uma) declaração de recuperação.

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







ID do campo Nome do campo Instruções v/tg Doença ou agente visado: COVID-19 (SARS-CoV ou uma das suas variantes) Um valor codificado do conjunto de valores disease-agent-targeted.json. Este conjunto de valores tem uma única entrada 840539006, que é o código SNOMED CT (GPS) para a COVID-19. Deve ser fornecido exatamente 1 (um) campo não vazio. Exemplo: "tg":"840539006" v/vp Vacina contra a COVID-19 ou profilaxia Tipo de vacina ou profilaxia utilizada. Um valor codificado do conjunto de valores vaccine-prophylaxis.json. O conjunto de valores é distribuído a partir do portal EUDCC (EUDCC Gateway). Deve ser fornecido exatamente 1 (um) campo não vazio. Exemplo: "vp":"1119349007" (Uma vacina de ARN mensageiro contra o SARS-CoV-2) v/mp Vacina contra a COVID-19 Medicamento utilizado para esta dose específica de vacinação. ►M4

Um valor codificado do conjunto de valores

vaccine-medicinal-product.json.

Ou um valor codificado referente a um ensaio clínico e de acordo com a regra definida no anexo II, secção 3. ◄

O conjunto de valores é distribuído a partir do portal EUDCC (EUDCC Gateway).

Deve ser fornecido exatamente 1 (um) campo não vazio. Exemplo:

"mp":"EU/1/20/1528" (Comirnaty) v/ma Titular da autorização de introdução no mercado ou fabricante da vacina contra a COVID-19 Titular da autorização de introdução no mercado ou fabricante, na ausência de titular da autorização de introdução no mercado. ►M4

Um valor codificado do conjunto de valores

vaccine-mah-manf.json.

Ou um valor codificado referente a um ensaio clínico e de acordo com a regra definida no anexo II, secção 4. ◄

O conjunto de valores é distribuído a partir do portal EUDCC (EUDCC Gateway).

Deve ser fornecido exatamente 1 (um) campo não vazio. Exemplo:

"ma":"ORG-100030215" (Biontech Manufacturing GmbH) v/dn Número numa série de doses Número sequencial (número inteiro positivo) da dose administrada durante este evento de vacinação. 1 para a primeira dose, 2 para a segunda dose, etc. São estabelecidas regras mais específicas na secção 5 do anexo II. Deve ser fornecido exatamente 1 (um) campo não vazio. Exemplos: "dn":"1" (primeira dose) "dn":"2" (segunda dose) "dn":"3" (terceira dose) v/sd Número total de doses na série Número total de doses (número inteiro positivo) na série de vacinação. São estabelecidas regras mais específicas na secção 5 do anexo II. Deve ser fornecido exatamente 1 (um) campo não vazio. Exemplos: "sd":"1" (no caso de um esquema de vacinação primária de uma dose) "sd":"2" (no caso de uma série de vacinação primária de duas doses ou de uma dose adicional após um esquema de vacinação primária de 1 dose) "sd":"3" (por exemplo, no caso de doses adicionais após uma série de vacinação primária de duas doses) v/dt Data de vacinação A data de receção da dose descrita, no formato YYYY-MM-DD (data completa sem hora). Não são aceites outros formatos. Deve ser fornecido exatamente 1 (um) campo não vazio. Exemplo: "dt":"2021-03-28" v/co Estado-Membro ou país terceiro em que a vacina foi administrada País expresso como código ISO3166 de 2 letras (RECOMENDADO) ou referência a uma organização internacional responsável pelo evento de vacinação (como o ACNUR ou a OMS). Um valor codificado do conjunto de valores country-2-codes.json. O conjunto de valores é distribuído a partir do portal EUDCC (EUDCC Gateway). Deve ser fornecido exatamente 1 (um) campo. Exemplo: "co":"CZ" "co":"UNHCR" v/is Emitente do certificado Nome da organização que emitiu o certificado. Os identificadores são permitidos como parte do nome, mas não se recomenda que sejam utilizados individualmente sem o nome como texto. Máximo: 80 carateres em UTF-8. Deve ser fornecido exatamente 1 (um) campo não vazio. Exemplo: "is":"Ministry of Health of the Czech Republic" "is":"Vaccination Centre South District 3" v/ci Identificador único do certificado Identificador único do certificado (UVCI), tal como especificado em https://ec.europa.eu/health/sites/default/files/ehealth/docs/vaccination-proof_interoperability-guidelines_en.pdf A inclusão da soma de controlo é facultativa. O prefixo "URN:UVCI:" pode ser adicionado. Deve ser fornecido exatamente 1 (um) campo não vazio. Exemplos: "ci":"URN:UVCI:01:NL:187/37512422923" "ci":"URN:UVCI:01:AT:10807843F94AEE0EE5093FBC254BD813#B"

4.2. Certificado de teste

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







ID do campo Nome do campo Instruções t/tg Doença ou agente visado: COVID-19 (SARS-CoV ou uma das suas variantes) Um valor codificado do conjunto de valores disease-agent-targeted.json. Este conjunto de valores tem uma única entrada 840539006, que é o código SNOMED CT (GPS) para a COVID-19. Deve ser fornecido exatamente 1 (um) campo não vazio. Exemplo: "tg":"840539006" t/tt Tipo de teste O tipo de teste utilizado, com base no material visado pelo teste. Um valor codificado do conjunto de valores test-type.json (com base no sistema de codificação LOINC). Não são permitidos valores fora do conjunto de valores. Deve ser fornecido exatamente 1 (um) campo não vazio. Exemplo: "tt":"LP6464-4" (Amplificação de ácidos nucleicos com deteção por sonda) "tt":"LP217198-3" (Imunoensaio rápido) t/nm Nome do teste (apenas testes de