Artigo 1.o

O artigo 58.o do Regulamento (UE) 2016/1628 é alterado do seguinte modo:

1)

No n.o 5, é aditado o seguinte parágrafo: «No caso dos motores de todas as subcategorias para os quais a data fixada no anexo III para a colocação no mercado de motores da fase V seja 1 de janeiro de 2020, excetuando os motores referidos no segundo e no terceiro parágrafos, o período de transição e o período de 18 meses a que se refere o primeiro parágrafo são prorrogados por seis meses.»;

2)	No n.o 7, é aditada a seguinte alínea: «e) 33 meses a contar da data aplicável para a colocação no mercado dos motores fixada no anexo III, no caso a que se refere o n.o 5, sexto parágrafo.».

Artigo 2.o

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

Artigo 1.o

Alteração do Regulamento (UE) 2020/1579

O Regulamento (UE) 2020/1579 é alterado nos termos da parte A do anexo do presente regulamento.

Artigo 2.o

Alteração do Regulamento (UE) 2021/92

O Regulamento (UE) 2021/92 é alterado nos termos das partes B e C do anexo do presente regulamento.

Artigo 3.o

Entrada em vigor e aplicação

O presente regulamento entra em vigor no dia seguinte ao da sua publicação no Jornal Oficial da União Europeia.

O artigo 1.o é aplicável desde 1 de janeiro de 2021.

O artigo 2.o é aplicável a partir de 1 de julho de 2021.

ANEXO

PARTE A

No anexo do Regulamento (UE) 2020/1579, o quadro das possibilidades de pesca de arenque nas águas da União das subdivisões CIEM 30-31 é substituído pelo seguinte quadro:

PARTE B

O anexo I-A do Regulamento (UE) 2021/92 é alterado do seguinte modo:

1)

O quadro das possibilidades de pesca de espadilha e capturas acessórias associadas nas águas da União da divisão CIEM 3a é substituído pelo seguinte quadro: «Espécie: Espadilha e capturas acessórias associadas Sprattus sprattus Zona: 3a (SPR/03A) Dinamarca 13 086  (1)  (2) TAC analítico Alemanha 27  (1)  (2) Suécia 4 951  (1)  (2) União 18 064  (1)  (2)   TAC 19 529  (2)

2)

O quadro das possibilidades de pesca de espadilha e capturas acessórias associadas nas águas do Reino Unido e da União da subzona CIEM 4 e nas águas do Reino Unido da divisão CIEM 2a é substituído pelo seguinte quadro: «Espécie: Espadilha e capturas acessórias associadas Sprattus sprattus Zona: Águas do Reino Unido e águas da União da subzona 4; Águas do Reino Unido da divisão 2a (SPR/2AC4-C) Bélgica 993  (3)  (4) TAC analítico Dinamarca 78 553  (3)  (4) Alemanha 993  (3)  (4) França 993  (3)  (4) Países Baixos 993  (3)  (4) Suécia 1 330  (3)  (4)  (5) União 83 855  (3)  (4) Noruega 0  (3) Ilhas Faroé 0  (3)  (6) Reino Unido 3 331  (3)   TAC 87 186  (3)

3)

O quadro das possibilidades de pesca do biqueirão nas subzonas CIEM 9 e 10 e nas águas da União da divisão CECAF 34.1.1 é substituído pelo seguinte quadro: «Espécie: Biqueirão Engraulis encrasicolus Zona: 9, 10; águas da União da zona CECAF 34.1.1 (ANE/9/3411) Espanha 2 747  (7) TAC de precaução Portugal 2 997  (7) União 5 744  (7)   TAC 5 744  (7)

PARTE C

No anexo VI do Regulamento (UE) 2021/92, o ponto 6 passa a ter a seguinte redação:

«6.

Capacidade máxima de cultura e de engorda de atum-rabilho para cada Estado-Membro e quantidade máxima de atum-rabilho selvagem capturado que cada Estado-Membro pode atribuir às suas explorações no Atlântico leste e no Mediterrâneo. Quadro A Capacidade máxima de cultura e de engorda do atum-rabilho   Número de explorações Capacidade (em toneladas) Espanha 10 11 852 Itália 13 9 564 Grécia 2 2 100 Chipre 3 3 000 Croácia 7 7 880 Malta 6 14 511 Quadro B (8) Quantidade máxima de atum-rabilho selvagem capturado (em toneladas) Espanha 6 850 Itália 1 739,5 Grécia 785 Chipre 2 195 Croácia 2 947 Malta 10 260,5 Portugal 350

---

(1)  Até 5 % da quota pode ser constituída por capturas acessórias de badejo e arinca (OTH/*03A.). As capturas acessórias de badejo e arinca imputadas à quota ao abrigo da presente disposição e as capturas acessórias de espécies imputadas à quota nos termos do artigo 15.o, n.o 8, do Regulamento (UE) n.o 1380/2013 não podem exceder, no total, 9 % da quota.

(2)  Esta quota só pode ser pescada de 1 de julho de 2021 a 30 de junho de 2022. Podem ser efetuadas transferências desta quota para as águas do Reino Unido e da União das zonas 2a e 4. Todavia, essas transferências devem ser previamente notificadas à Comissão e ao Reino Unido.»;

(3)  A quota só pode ser pescada de 1 de julho de 2021 a 30 de junho de 2022.

(4)  Até 2 % da quota pode ser constituída por capturas acessórias de badejo (OTH/*2AC4C). As capturas acessórias de badejo imputadas à quota ao abrigo da presente disposição e as capturas acessórias de espécies imputadas à quota nos termos do artigo 15.o, n.o 8, do Regulamento (UE) n.o 1380/2013 não podem exceder, no total, 9 % da quota.

(5)  Incluindo galeota.

(6)  Pode conter até 4 % de capturas acessórias de arenque.»;

(7)  A quota só pode ser pescada de 1 de julho de 2021 a 30 de setembro de 2021.».

(8)  A capacidade de cultura de Portugal de 500 toneladas encontra-se abrangida pela capacidade não utilizada da União estabelecida no quadro A.».

Artigo 1.o

Objeto e âmbito

O presente regulamento estabelece medidas especiais de controlo de doenças contra a infeção pelo vírus da dermatose nodular contagiosa (VDNC), a aplicar durante um período limitado pelos Estados-Membros em áreas do seu território em que:

a)	Tenha sido confirmado um foco dessa doença;

b)	Não tenha sido confirmado um foco dessa doença, mas em que decidam efetuar a vacinação contra essa doença em conformidade com as regras estabelecidas no presente regulamento.

As medidas especiais de controlo de doenças estabelecidas no presente regulamento aplicam-se aos bovinos e aos subprodutos e produtos germinais obtidos desses bovinos e complementam as medidas de controlo de doenças aplicáveis às zonas de proteção, vigilância e outras zonas submetidas a restrições estabelecidas pela autoridade competente de um Estado-Membro na sequência de um foco de infeção pelo VDNC, em conformidade com o artigo 21.o, n.o 1, do Regulamento Delegado (UE) 2020/687.

Artigo 2.o

Definições

Para efeitos do presente regulamento são aplicáveis as definições constantes do Regulamento Delegado (UE) 2020/687.

Aplicam-se igualmente as seguintes definições:

1)	«Bovino», um animal das espécies de ungulados pertencentes aos géneros Bison, Bos (incluindo os subgéneros Bos, Bibos, Novibos, Poephagus) e Bubalus (incluindo o subgénero Anoa) e os animais resultantes de cruzamentos dessas espécies.

2)

«Zona submetida a restrições I», uma parte do território de um Estado-Membro com uma delimitação geográfica precisa: a) Situada fora de uma área onde tenha sido confirmado um foco de infeção pelo VDNC; b) Em que a vacinação contra a infeção pelo VDNC seja efetuada em conformidade com o artigo 3.o, n.o 2; c) Que conste ou não do anexo I, parte I; d) Sujeita às regras especiais de controlo de doenças previstas nos artigos 3.o a 6.o.

3)

«Zona submetida a restrições II», uma parte do território de um Estado-Membro com uma delimitação geográfica precisa: a) Que abranja uma área onde tenha sido confirmado um foco de infeção pelo VDNC; b) Em que a vacinação contra a infeção pelo VDNC seja efetuada em conformidade com o artigo 3.o, n.o 1; c) Que conste ou não do anexo I, parte II; d) Sujeita às regras especiais de controlo de doenças previstas nos artigos 3.o a 6.o.

Artigo 3.o

Estabelecimento de zonas submetidas a restrições I e II

Artigo 4.o

Proibições de circulação nas zonas submetidas a restrições I e II

Artigo 5.o

Inclusão de zonas submetidas a restrições II no anexo I, parte II

Se, por razões epidemiológicas, uma área de um Estado-Membro abrangida total ou parcialmente por uma zona submetida a restrições II, estabelecida em conformidade com o artigo 3.o, n.o 1, for incluída no anexo I, parte II, a autoridade competente deve imediatamente:

a)	Adaptar os limites da zona inicial submetida a restrições inicial II, a fim de assegurar que corresponde à zona submetida a restrições II descrita nesse anexo;

b)	Alargar a vacinação prevista no artigo 3.o, n.o 1, alínea b), e as proibições previstas no artigo 4.o, n.o 1, à zona submetida a restrições II descrita nesse anexo.

Artigo 6.o

Inclusão de zonas submetidas a restrições I no anexo I, parte I

Artigo 7.o

Derrogações à proibição de circulação de remessas de bovinos a partir da zona submetida a restrições I

Em derrogação da proibição prevista no artigo 4.o, n.o 2, alínea a), a autoridade competente pode autorizar a circulação de remessas de bovinos a partir de estabelecimentos situados na zona submetida a restrições I para:

a)

Uma zona submetida a restrições I ou II do mesmo ou de outro Estado-Membro, desde que estejam preenchidas todas as seguintes condições: i) os bovinos da remessa têm de ter sido vacinados contra a infeção pelo VDNC pelo menos 28 dias antes da data de expedição e permanecer, à data de expedição, dentro do período de imunidade em conformidade com as instruções do fabricante da vacina, ii) todos os outros bovinos mantidos no mesmo estabelecimento de origem que os bovinos da remessa têm de ter sido vacinados contra a infeção pelo VDNC pelo menos 28 dias antes da data de expedição e permanecer, à data de expedição, dentro do período de imunidade em conformidade com as instruções do fabricante da vacina ou permanecer, à data de expedição, dentro do período de imunidade induzido por uma vacinação anterior ou por imunidade materna, iii) os bovinos da remessa devem ter sido mantidos no seu estabelecimento de origem desde o seu nascimento ou durante um período contínuo de pelo menos 28 dias antes da data de expedição, e iv) a autoridade competente deve realizar: — um exame clínico, com resultados favoráveis, de todos os bovinos mantidos no estabelecimento de origem dessas remessas, incluindo os bovinos dessas remessas, — se necessário, um exame laboratorial, com resultados favoráveis, dos bovinos mantidos no estabelecimento de origem dessas remessas, incluindo os bovinos dessas remessas;

b)

Qualquer destino — incluindo áreas fora das zonas submetidas a restrições, outras zonas submetidas a restrições I ou zonas submetidas a restrições II — no mesmo Estado-Membro ou noutros Estados-Membros, se, para além das condições estabelecidas na alínea a), subalíneas ii), iii) e iv), do presente artigo, estiverem preenchidas todas as seguintes condições: i) os bovinos da remessa têm de ter sido vacinados contra a infeção pelo VDNC pelo menos 60 dias antes da data de expedição e permanecer, à data de expedição, dentro do período de imunidade em conformidade com as instruções do fabricante da vacina, ii) num raio de, pelo menos, 20 km em redor do estabelecimento de origem dessas remessas, não se registaram focos de infeção pelo VDNC durante um período de pelo menos três meses anterior à data de expedição, e iii) todos os bovinos mantidos num raio de 50 km em redor do estabelecimento de origem da remessa têm de ter sido vacinados ou revacinados contra a infeção pelo VDNC pelo menos 60 dias antes da data de expedição e permanecer, à data de expedição, dentro do período de imunidade em conformidade com as instruções do fabricante da vacina ou dentro do período da sua imunidade materna;

c)

Qualquer destino — incluindo áreas fora das zonas submetidas a restrições, outras zonas submetidas a restrições I ou zonas submetidas a restrições II — noutros Estados-Membros ou territórios em países terceiros, se, para além das condições estabelecidas na alínea a) do presente artigo, estiverem preenchidas as seguintes condições: i) os animais têm de respeitar todas as garantias de saúde animal, com base no resultado favorável de uma avaliação dos riscos das medidas contra a propagação da infeção pelo VDNC, exigidas pela autoridade competente do Estado-Membro de origem e aprovadas pelas autoridades competentes dos Estados-Membros de destino e de passagem, antes da data de expedição, ii) não podem ter ocorrido focos confirmados de infeção pelo VDNC num raio de, pelo menos, 20 km em redor do estabelecimento de origem dessas remessas durante um período de pelo menos três meses anterior à data de expedição, e iii) todos os bovinos mantidos num raio de 50 km em redor do estabelecimento de origem da remessa têm de ter sido vacinados ou revacinados contra a infeção pelo VDNC pelo menos 60 dias antes da data de expedição e permanecer, à data de expedição, dentro do período de imunidade em conformidade com as instruções do fabricante da vacina ou dentro do período da sua imunidade materna.

Artigo 8.o

Derrogações às proibições de circulação de remessas de bovinos a partir da zona submetida a restrições II

Em derrogação da proibição prevista no artigo 4.o, n.o 1, alínea a), a autoridade competente pode autorizar a circulação de remessas de bovinos a partir de estabelecimentos situados numa zona submetida a restrições II para:

a)

Qualquer destino, incluindo áreas fora das zonas submetidas a restrições, outras zonas submetidas a restrições I ou zonas submetidas a restrições II no mesmo Estado-Membro e noutros Estados-Membros, desde que estejam preenchidas todas as seguintes condições: i) os bovinos da remessa têm de cumprir todas as garantias de sanidade animal, com base no resultado favorável de uma avaliação dos riscos das medidas contra a propagação da infeção pelo VDNC, exigidas pela autoridade competente do Estado-Membro de origem e acordadas com a autoridade competente dos Estado-Membros de destino ou de passagem, antes da data de expedição, ii) os bovinos da remessa têm de ter sido vacinados contra a infeção pelo VDNC pelo menos 28 dias antes da data de expedição e permanecer, à data de expedição, dentro do período de imunidade em conformidade com as instruções do fabricante da vacina, iii) todos os outros bovinos mantidos no mesmo estabelecimento de origem que os bovinos da remessa têm de ter sido vacinados contra a infeção pelo VDNC pelo menos 28 dias antes da data de expedição e permanecer, à data de expedição, dentro do período de imunidade em conformidade com as instruções do fabricante da vacina ou permanecer, à data de expedição, dentro do período de imunidade induzido por uma vacinação anterior ou por imunidade materna, iv) a autoridade competente deve realizar: — um exame clínico, com resultados favoráveis, de todos os bovinos mantidos no estabelecimento de origem dessas remessas, incluindo os bovinos dessas remessas, — se necessário, um exame laboratorial, com resultados favoráveis, dos bovinos mantidos no estabelecimento de origem dessas remessas, incluindo os bovinos dessas remessas, v) os bovinos têm de ter permanecido desde o seu nascimento ou, pelo menos, nos 28 dias anteriores à data de expedição, num estabelecimento no qual, num raio de pelo menos 20 km, não foi confirmado qualquer foco de infeção pelo VDNC nos três meses anteriores à data de expedição, vi) todos os bovinos num raio de 50 km em redor do estabelecimento de origem da remessa têm de ter sido vacinados ou revacinados contra a infeção pelo VDNC, em conformidade com as regras dos planos de vacinação estabelecidas no anexo II, pelo menos 60 dias antes da data de expedição e permanecer, à data de expedição, dentro do período de imunidade em conformidade com as instruções do fabricante da vacina ou dentro da sua imunidade materna;

b)

Qualquer destino situado noutra zona submetida a restrições II do mesmo Estado-Membro, desde que estejam preenchidas todas as seguintes condições: i) todos os outros bovinos mantidos no estabelecimento de origem dessas remessas têm de ter sido vacinados contra a infeção pelo VDNC pelo menos 28 dias antes da data de expedição e permanecer, à data de expedição, dentro do período de imunidade em conformidade com as instruções do fabricante da vacina ou permanecer dentro do período de imunidade induzido por uma vacinação anterior ou por imunidade materna, e ii) os bovinos têm de ter sido vacinados contra a infeção pelo VDNC pelo menos 28 dias antes da data de expedição e permanecer, à data de expedição, dentro do período de imunidade em conformidade com as instruções do fabricante da vacina ou ser crias não vacinadas, com idade inferior a quatro meses, de fêmeas vacinadas pelo menos 28 dias antes do parto que, à data do parto, permaneciam dentro período de imunidade de acordo com o fabricante da vacina, e podem circular para outro estabelecimento.

Artigo 9.o

Condições específicas para autorizar a circulação de remessas de bovinos a partir de zonas submetidas a restrições I e II para um matadouro fora dessas zonas, situado no território do mesmo Estado-Membro, para efeitos de abate imediato

Em derrogação das proibições previstas no artigo 4.o, n.o 2, alínea a), e no artigo 4.o, n.o 1, alínea a), do presente regulamento, a autoridade competente do Estado-Membro pode autorizar a circulação de remessas de bovinos a partir de zonas submetidas a restrições I e II para um matadouro fora dessas zonas, situado no território do mesmo Estado-Membro, desde que os bovinos circulem para efeitos de abate imediato em conformidade com as condições gerais estabelecidas no artigo 28.o, n.os 2 a 5, e no artigo 28.o, n.o 7, do Regulamento Delegado (UE) 2020/687.

Artigo 10.o

Derrogações à proibição de circulação de remessas de sémen, óvulos e embriões de bovinos a partir de zonas submetidas a restrições I e II

Artigo 11.o

Derrogações à proibição de circulação de subprodutos animais não processados de bovinos a partir de zonas submetidas a restrições I

Em derrogação da proibição prevista no artigo 4.o, n.o 2, alínea c), a autoridade competente de um Estado-Membro pode autorizar a circulação de remessas subprodutos animais não processados de bovinos a partir de estabelecimentos situados na zona submetida a restrições I para:

a)	Qualquer destino situado no mesmo Estado-Membro ou qualquer destino situado em zonas submetidas a restrições I ou II noutro Estado-Membro;

b)

No caso de remessas de couros e peles, qualquer destino situado numa área do mesmo ou de outro Estado-Membro ou de um país terceiro, desde que estejam preenchidas as seguintes condições: i) os couros e peles tratados foram submetidos a um dos tratamentos referidos no anexo I, ponto 28, alíneas b) a e), do Regulamento (UE) n.o 142/2011 da Comissão (10), ou ii) os couros e peles tratados foram submetidos a um dos tratamentos previstos no anexo III, secção XIV, capítulo I, ponto 4), alínea b), subalínea ii), do Regulamento (CE) n.o 853/2004 do Parlamento Europeu e do Conselho (11) e foram objeto de todas as precauções necessárias para evitar a recontaminação por agentes patogénicos após o tratamento.

Artigo 12.o

Derrogação à proibição de circulação de remessas de subprodutos animais não processados de bovinos a partir de zonas submetidas a restrições II

Em derrogação da proibição prevista no artigo 4.o, n.o 1, alínea c), a autoridade competente de um Estado-Membro pode autorizar a circulação de remessas de subprodutos animais não processados de bovinos a partir de estabelecimentos situados numa zona submetida a restrições II para:

a)

No caso de subprodutos animais não processados, com exceção dos couros e peles, qualquer destino situado no mesmo Estado-Membro ou qualquer destino situado nas zonas submetidas a restrições I ou II de outro Estado-Membro, desde que os subprodutos animais não processados sejam expedidos sob supervisão oficial das autoridades competentes para processamento ou eliminação numa unidade aprovada em conformidade com o artigo 24.o do Regulamento (CE) n.o 1069/2009 do Parlamento Europeu e do Conselho (12);

b)

No caso de couros e peles de bovinos: i) qualquer destino situado na zona submetida a restrições II do mesmo ou de outro Estado-Membro, desde que sejam couros e peles em bruto não tratados destinados ao consumo humano ou couros e peles não tratados expedidos sob a supervisão oficial das autoridades competentes para processamento ou eliminação numa instalação aprovada, ii) qualquer destino situado no mesmo ou noutro Estado-Membro, desde que estejam preenchidas as condições estabelecidas no artigo 11.o, alínea b);

c)	No caso de colostro, leite e produtos lácteos, qualquer destino situado numa área do mesmo ou de outro Estado-Membro, desde que tenham sido submetidos a um tratamento de mitigação dos riscos para a infeção pelo VDNC, tal como estabelecido no anexo VII do Regulamento Delegado (UE) 2020/687.

Artigo 13.o

Obrigações dos operadores no que diz respeito aos certificados sanitários para a circulação de remessas de bovinos a partir de zonas submetidas a restrições I e II para fora dessas zonas

Os operadores só podem transportar remessas de bovinos a partir de zonas submetidas a restrições I e II para fora dessas zonas no mesmo Estado-Membro ou para outro Estado-Membro nos casos abrangidos pelos artigos 7.o, 8.o e 9.o do presente regulamento se os animais a transportar forem acompanhados do certificado sanitário previsto no artigo 73.o do Regulamento Delegado (UE) 2020/688 da Comissão (13), que contenha pelo menos um dos seguintes atestados de conformidade com os requisitos previstos no presente regulamento:

a)	«Bovinos provenientes da zona submetida a restrições I em conformidade com as medidas especiais de controlo contra a infeção pelo VDNC estabelecidas no artigo 7.o do Regulamento de Execução (UE) 2021/1070 da Comissão.»;

b)	«Bovinos provenientes da zona submetida a restrições II em conformidade com as medidas especiais de controlo contra a infeção pelo VDNC estabelecidas no artigo 8.o do Regulamento de Execução (UE) 2021/1070 da Comissão.»;

c)	«Bovinos provenientes de zonas submetidas a restrições I ou II em conformidade com as medidas especiais de controlo contra a infeção pelo VDNC estabelecidas no artigo 9.o do Regulamento de Execução (UE) 2021/1070 da Comissão.».

No entanto, no caso da circulação das remessas referidas no primeiro parágrafo do presente artigo no interior do mesmo Estado-Membro, a autoridade competente pode decidir que não é necessário emitir um certificado sanitário, tal como referido no artigo 143.o, n.o 2, segundo parágrafo, do Regulamento (UE) 2016/429.

Artigo 14.o

Obrigações dos operadores no que diz respeito aos certificados sanitários para a circulação de remessas de produtos germinais obtidos de bovinos a partir de estabelecimentos situados nas zonas submetidas a restrições I e II para fora dessas zonas

Os operadores só podem transportar remessas de produtos germinais obtidos de bovinos a partir de zonas submetidas a restrições I e II para fora dessas zonas no mesmo Estado-Membro ou para outro Estado-Membro, em conformidade com o artigo 10.o do presente regulamento, se essas remessas forem acompanhadas de um certificado sanitário, tal como previsto no artigo 161.o, n.o 4, do Regulamento (UE) 2016/429, que contenha pelo menos um dos seguintes atestados de conformidade com os requisitos previstos no presente regulamento:

a)

«Produtos germinais … (sémen, óvulos e/ou embriões, indicar conforme adequado) obtidos de bovinos mantidos na zona submetida a restrições I em conformidade com medidas especiais de controlo contra a infeção pelo VDNC, tal como estabelecido no artigo 10.o do Regulamento de Execução (UE) 2021/1070 da Comissão.»;

b)

«Produtos germinais … (sémen, óvulos e/ou embriões, indicar conforme adequado) obtidos de bovinos mantidos na zona submetida a restrições II em conformidade com medidas especiais de controlo contra a infeção pelo VDNC, tal como estabelecido no artigo 10.o do Regulamento de Execução (UE) 2021/1070 da Comissão.».

No entanto, no caso da circulação das remessas referidas no primeiro parágrafo do presente artigo no interior do mesmo Estado-Membro, a autoridade competente pode decidir que não é necessário emitir um certificado sanitário, tal como referido no artigo 161.o, n.o 2, segundo parágrafo, do Regulamento (UE) 2016/429.

Artigo 15.o

Obrigações dos operadores no que diz respeito aos certificados sanitários para a circulação de remessas de subprodutos animais não processados de bovinos a partir de zonas submetidas a restrições I e II para fora dessas zonas

Os operadores só podem transportar remessas de subprodutos animais não processados de bovinos a partir de zonas submetidas a restrições I e II para fora dessas zonas no mesmo Estado-Membro ou para outro Estado-Membro nos casos abrangidos pelo artigo 12.o se essas remessas forem acompanhadas:

a)	De um documento comercial referido no anexo VIII, capítulo III, do Regulamento (UE) n.o 142/2011; e

b)	De um certificado sanitário referido no artigo 22.o, n.o 5, do Regulamento Delegado (UE) 2020/687.

No entanto, no caso da circulação das remessas referidas no primeiro parágrafo do presente artigo no interior do mesmo Estado-Membro, a autoridade competente pode decidir que não é necessário emitir um certificado sanitário, tal como referido no artigo 22.o, n.o 6, do Regulamento Delegado (UE) 2020/687.

Artigo 16.o

Condições gerais adicionais relativas aos meios de transporte utilizados para a circulação de remessas de bovinos e subprodutos animais não processados a partir de zonas submetidas a restrições I e II para fora dessas zonas

A autoridade competente do Estado-Membro só pode autorizar a circulação de remessas de bovinos e subprodutos animais não processados a partir de zonas submetidas a restrições I e II para fora dessas zonas se os meios de transporte utilizados para a circulação dessas remessas preencherem as seguintes condições:

a)

No caso do transporte de bovinos, os meios de transporte: i) cumprem os requisitos estabelecidos no artigo 24.o, n.o 1, do Regulamento Delegado (UE) 2020/687, e ii) foram limpos e desinfetados em conformidade com o artigo 24.o, n.o 2, do Regulamento Delegado (UE) 2020/687 sob o controlo ou a supervisão da autoridade competente do Estado-Membro;

b)	Só incluem animais ou subprodutos animais não processados ou couros e peles não tratados com o mesmo estatuto sanitário.

Artigo 17.o

Obrigações da autoridade competente do estabelecimento de origem no que diz respeito aos procedimentos de encaminhamento

Artigo 18.o

Obrigações da autoridade competente do local de destino no que diz respeito aos procedimentos de encaminhamento

Na sequência de um procedimento de encaminhamento, a autoridade competente do local de destino deve:

a)	Confirmar todas as chegadas à autoridade competente do local de origem;

b)	Garantir que os bovinos permanecem no estabelecimento de destino durante, pelo menos, o período de monitorização da infeção pelo VDNC estabelecido no anexo II do Regulamento Delegado (UE) 2020/687, exceto quando o estabelecimento de destino for um matadouro;

c)

Assegurar que, após a descarga dos bovinos ou dos subprodutos animais não processados, o meio de transporte e qualquer outro equipamento que tenha sido usado no transporte dos bovinos ou dos subprodutos animais não processados são integralmente limpos, desinfetados e tratados com inseticidas autorizados eficazes contra os vetores conhecidos da infeção pelo VDNC no interior de uma área fechada no local de destino, sob supervisão de um veterinário oficial.

Artigo 19.o

Obrigações do Estado-Membro do local de origem das remessas de bovinos, produtos germinais ou subprodutos animais não processados no que diz respeito à informação a facultar à Comissão e aos Estados-Membros sobre as derrogações concedidas com base em avaliações dos riscos

Sempre que a autoridade competente autorizar a circulação de remessas de bovinos ou produtos germinais com base no resultado favorável de uma avaliação dos riscos das medidas contra a propagação da infeção pelo VDNC, tal como referido nos artigos 7.o, 8.o ou 10.o, o Estado-Membro do local de origem deve informar imediatamente a Comissão e os outros Estados-Membros sobre as garantias de saúde animal e a aprovação pelas autoridades competentes do local do estabelecimento de destino.

Artigo 20.o

Entrada em vigor e data de aplicação

O presente regulamento entra em vigor no dia seguinte ao da sua publicação no Jornal Oficial da União Europeia.

O presente regulamento é aplicável até 21 de abril de 2023.

ANEXO I

ZONAS SUBMETIDAS A RESTRIÇÕES I e II

(conforme previstas no artigo 3.o)

PARTE I

Zona submetida a restrições I

1.   Bulgária:

A totalidade do território da Bulgária.

2.   Grécia:

A.

As seguintes regiões da Grécia: — Região da Ática — Região da Grécia Central — Região da Macedónia Central — Região de Creta — Região da Macedónia Oriental-Trácia — Região de Epiro — Região das Ilhas Jónicas, com exceção da unidade regional de Kerkyra — Região do Egeu do Norte, com exceção da unidade regional de Limnos — Região do Peloponeso — Região do Egeu do Sul — Região de Tessália — Região da Grécia Ocidental — Região da Macedónia Ocidental

B.	As seguintes unidades regionais na Grécia: — Unidade regional de Limnos — Unidade regional de Kerkyra

PARTE II

Zona submetida a restrições II

Nenhuma

ANEXO II

REGRAS APLICÁVEIS AOS PLANOS DE VACINAÇÃO NO QUE DIZ RESPEITO À INFEÇÃO PELO VÍRUS DA DERMATOSE NODULAR CONTAGIOSA

(conforme previstas no artigo 3.o)

PARTE I

Informações a incluir no plano de vacinação conforme previstas no artigo 3.o

Sempre que um Estado-Membro efetuar a vacinação contra a infeção pelo VDNC, essa vacinação deve ser efetuada de acordo com um plano de vacinação que contenha, pelo menos, as seguintes informações:

a)	A descrição e os resultados da avaliação realizada em conformidade com os critérios estabelecidos no artigo 46.o, n.o 2, do Regulamento (UE) 2016/429, incluindo a situação epidemiológica e outras informações pertinentes utilizadas como base para a avaliação;

b)	Os principais objetivos e metas de acordo com a estratégia de vacinação escolhida e o plano de vacinação;

c)	A descrição geográfica pormenorizada da zona de vacinação em que a vacinação deve ser efetuada e a localização dos estabelecimentos que mantêm bovinos que devem ser vacinados, incluindo mapas;

d)	A autoridade responsável pela administração da vacina aos bovinos;

e)	O sistema de supervisão da administração da vacina;

f)	O número de estabelecimentos que mantêm bovinos situados na zona submetida a restrições e o número de estabelecimentos que devem ser alvo de vacinação, se diferentes;

g)	O número estimado de bovinos, as suas categorias e a idade dos animais que devem ser vacinados;

h)	A duração prevista da vacinação, desde o início da vacinação até ao fim da vigilância efetuada após a vacinação;

i)	O resumo das características da vacina, incluindo o nome do medicamento e o nome do fabricante, e as vias de administração;

j)	A indicação de a vacina ser ou não utilizada em conformidade com o artigo 110.o, n.os 2 e 3, do Regulamento (UE) 2019/6 do Parlamento Europeu e do Conselho (1);

k)	Os métodos de avaliação da eficácia da vacinação;

l)	As regras de higiene e bioproteção a aplicar;

m)	O sistema de manutenção de registos sobre a vacinação;

n)	Outros aspetos relevantes para a situação específica.

PARTE II

Requisitos mínimos para os planos de vacinação contra a infeção pelo VDNC conforme previstos no artigo 3.o

Os planos de vacinação contra a infeção pelo VDNC devem cumprir os seguintes requisitos técnicos:

a)	A vacinação de todos os bovinos, independentemente do sexo, idade e estádio de gestação ou produção nas zonas submetidas a restrições I e II onde a vacinação tem de ser aplicada;

b)	A vacinação das crias de bovinos vacinados com idade superior a quatro meses, de acordo com as instruções do fabricante da vacina utilizada;

c)	A revacinação de todos os bovinos de acordo com as instruções do fabricante;

d)	O registo dos pormenores relativos a cada bovino vacinado, efetuado pela autoridade competente, na base de dados em linha destinada a esse efeito e ligada à base de dados central criada em conformidade com o artigo 42.o do Regulamento (UE) 2019/2035 do Parlamento Europeu e do Conselho (2);

e)	O estabelecimento de uma zona de vigilância aumentada de pelo menos 20 km em redor das zonas submetidas a restrições I e II em que a vacinação é efetuada, onde deve ser exercida uma vigilância reforçada e a circulação de bovinos deve ser sujeita a controlos da autoridade competente;

f)	A cobertura vacinal de, pelo menos, 95% dos efetivos que representem, pelo menos, 75% da população bovina.

PARTE III

Informações preliminares a facultar à Comissão e aos outros Estados-Membros antes do início da vacinação conforme previstas no artigo 3.o, n.o 3

Antes de iniciarem a vacinação, os Estados-Membros que efetuam a vacinação contra a dermatose nodular contagiosa devem facultar as seguintes informações à Comissão e aos outros Estados-Membros:

a)	Uma breve justificação para o início da vacinação;

b)	As espécies de bovinos a vacinar;

c)	O número estimado de bovinos a vacinar;

d)	A duração estimada da vacinação;

e)	O tipo e a designação comercial da vacina aplicada, indicando se a vacina é utilizada em conformidade com o artigo 110.o, n.os 2 e 3, do Regulamento (UE) 2019/6;

f)	Uma descrição da zona de vacinação prevista.

---

(1)  Regulamento (UE) 2019/6 do Parlamento Europeu e do Conselho, de 11 de dezembro de 2018, relativo aos medicamentos veterinários e que revoga a Diretiva 2001/82/CE (JO L 4 de 7.1.2019, p. 43).

(2)  Regulamento Delegado (UE) 2019/2035 da Comissão, de 28 de junho de 2019, que complementa o Regulamento (UE) 2016/429 do Parlamento Europeu e do Conselho no que se refere às regras aplicáveis aos estabelecimentos que detêm animais terrestres e aos centros de incubação, e à rastreabilidade de determinados animais terrestres detidos e ovos para incubação (JO L 314 de 5.12.2019, p. 115).

Artigo 1.o

No artigo 4.o do Regulamento de Execução (UE) 2021/442, o segundo parágrafo passa a ter a seguinte redação:

Artigo 2.o

No artigo 3.o do Regulamento de Execução (UE) 2021/521, o segundo parágrafo passa a ter a seguinte redação:

Artigo 3.o

O presente regulamento entra em vigor em 1 de julho de 2021.

Artigo 1.o

Em derrogação dos artigos 2.o, 3.o e 4.o da Decisão 2013/471/UE, se as medidas restritivas relacionadas com a COVID-19 comprometerem a possibilidade de organizar ou participar fisicamente numa reunião, os beneficiários que participem na reunião à distância, por meios eletrónicos, só têm direito a ajudas de custo diárias fixadas em 145 euros.

Artigo 2.o

O Comité adota as disposições de execução pormenorizadas do artigo 1.o até 2 de setembro de 2021.

Artigo 3.o

O Comité apresenta ao Conselho, até 2 de janeiro de 2022 e, posteriormente, de seis em seis meses, um relatório de avaliação sobre a aplicação da presente decisão e, em especial, sobre o seu impacto orçamental, bem como sobre a persistência das dificuldades de deslocação relacionadas com a COVID-19 ou de medidas restritivas conexas que comprometam a possibilidade de organizar ou participar fisicamente em reuniões.

Artigo 4.o

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

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.

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.

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.

---

(1)  rfc8392 (ietf.org).

(2)  rfc8152 (ietf.org).

(3)  rfc8230 (ietf.org).

(4)  rfc8392 (ietf.org).

(5)  rfc8392 (ietf.org).

(6)  rfc7159 (ietf.org).

(7)  rfc7049 (ietf.org).

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

(9)  rfc1950 (ietf.org).

(10)  rfc1951 (ietf.org).

(11)  rfc7517 (ietf.org).

ANEXO II

REGRAS PARA EFEITOS DE PREENCHIMENTO DO CERTIFICADO DIGITAL COVID DA UE

As regras gerais relativas aos conjuntos de valores estabelecidos no presente anexo visam assegurar a interoperabilidade a nível semântico e devem permitir implementações técnicas uniformes no que respeita ao DCC. 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, recomenda-se a codificação em UTF-8 (nome, centro de teste, emitente do certificado). Recomenda-se que os campos de dados que contêm datas de calendário (data de nascimento, data de vacinação, data da recolha de amostras para teste, data do primeiro resultado de teste positivo, datas de validade do certificado) sejam codificados de acordo com a norma ISO 8601.

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.

Os conjuntos de valores devem ser 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 devem ser 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)

Sistema de codificação preferencial: SNOMED CT.

A utilizar nos certificados 1, 2 e 3.

Os códigos selecionados referem-se à COVID-19 ou, se forem necessárias informações mais pormenorizadas sobre a variante genética do SARS-CoV-2, a estas variantes, caso essas informações pormenorizadas sejam indispensáveis por razões epidemiológicas.

Um exemplo de código a utilizar é o código SNOMED CT 840539006 (COVID-19).

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). O conjunto de valores deve ser 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 devem ser 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).

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

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 de doses administradas num ciclo

(2)	Número de doses previstas para um ciclo completo (específico para uma pessoa no momento da administração)

Por exemplo, 1/1, 2/2 indicará ciclo completo, incluindo a opção 1/1 no caso de vacinas que compreendam duas doses, mas em relação às quais o protocolo aplicado pelo Estado-Membro consista em administrar apenas uma dose a cidadãos que tenham sido diagnosticados com COVID-19 antes da vacinação. O número total de doses na série deve ser indicado de acordo com a informação disponível no momento em que a dose é administrada. Por exemplo, se uma vacina específica requerer uma terceira dose (reforço) à data da última injeção administrada, o segundo número de campo deve refletir esta situação (por exemplo, 2/3, 3/3, etc.).

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 2 letras, disponível como um conjunto de valores definido em FHIR (http://hl7.org/fhir/ValueSet/iso3166-1-2).

7.   Tipo de teste

Sistema de codificação preferencial: LOINC.

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.

Os códigos neste conjunto de valores devem referir-se ao método do teste e devem ser selecionados, pelo menos, para distinguir os testes TAAN dos testes TRDA, conforme expresso no Regulamento (UE) 2021/953.

De entre os sistemas de codificação preferenciais, um exemplo de código a utilizar é o LP217198-3 (imunoensaio rápido).

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

Sistema de codificação preferencial: lista do CSS de testes rápidos de antigénio, mantida pelo JRC (base de dados de dispositivos de diagnóstico in vitro e métodos de despistagem da COVID-19).

A utilizar no certificado 2.

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 rápidos 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 in vitro e métodos de despistagem, em: https://covid-19-diagnostics.jrc.ec.europa.eu/devices/hsc-common-recognition-rat.

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

Sistema de codificação preferencial: SNOMED CT.

A utilizar no certificado 2.

Os códigos selecionados devem permitir a distinção entre resultados de teste positivos e negativos (detetado ou não detetado). Podem ser adicionados mais valores (como indeterminado) se os casos de utilização o exigirem.

São exemplos de códigos a utilizar, de entre os sistemas de codificação preferenciais, o 260415000 (não detetado) e o 260373001 (detetado).

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

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 (1) (2), designadamente {«/»,«#»,«:»};

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

(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, 3 carateres ou mais (por exemplo, «ACNUR»)] para utilização futura;

(5)

Sufixo do código/soma de controlo: 5.1. Os Estados-Membros deverão 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 deverá corresponder ao resumo da norma ISO-7812-1 (LUHN-10) (4) de todo o UCI em formato de transporte digital/por cabo. A soma de controlo é separada do resto do UCI por um caráter «#».

Deve ser 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) devem garantir 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.

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

---

(1)  rfc3986 (ietf.org).

(2)  Os campos correspondentes ao sexo, ao número do lote, ao centro de administração, à identificação do profissional de saúde ou à data da próxima vacinação podem não ser necessários para outros fins que não a utilização médica.

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

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

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

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 NBTLS registados,

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

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

—	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 NBTLS do Estado-Membro

—	o certificado de carregamento NBUP do Estado-Membro

—	o(s) certificado(s) CSCA NBCSCA 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) NBCSCA à lista de confiança assinada com a chave privada que corresponde à chave pública DCCGTA,

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

—	adiciona o certificado NBUP ao sistema DCCG,

—	fornece o certificado de chave pública DCCGTA e DCCGTLS 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 (1) ou nos Mecanismos Criptográficos Acordados (Agreed Cryptographic Mechanisms) do SOG-IS (2).

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

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

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  (5) , o=<Fornecedor>, c=<país>
Utilização de chave	assinatura digital (no mínimo)

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

---

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

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

(3)  rfc5280 (ietf.org).

(4)  rfc5280 (ietf.org).

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