2.1

Referências normativas

—

[i.11] Nulo e sem efeito.

—

EUCC: Sistema europeu de certificação da cibersegurança baseado nos Critérios Comuns.

—

NOTA 10 Ver ETSI EN 319 102-1 [3] para obter orientações e ETSI TS 119 172-4 [8] para obter orientações adicionais para o caso da assinatura ou do selo qualificado da UE.

—

OVR-6.1-02 A declaração de práticas do SVS deve estar estruturada de acordo com o anexo A.

—

OVR-6.1-03 A declaração de práticas do SVS deve enumerar ou fazer referência às políticas do SVS apoiadas [por exemplo, através de identificadores de objeto (OID)] e descrevê-las sucintamente.

—

OVR-6.3-02 A política de segurança deve documentar os controlos de segurança e privacidade aplicados para proteger os dados pessoais.

—

OVR-7.2-02 O pessoal do prestador do serviço de validação de assinaturas (SVSP) com funções de confiança e, se aplicável, os seus subcontratantes com funções de confiança devem ser capazes de cumprir o requisito de dispor de conhecimentos especializados, experiência e qualificações adquiridos por meio de formação formal e credenciais, de experiência ou de uma combinação de ambas.

—

OVR-7.2-03 A conformidade com o OVR-7.2-02 deve incluir atualizações regulares (pelo menos a cada 12 meses) sobre as novas ameaças e as atuais práticas de segurança.

—

OVR-7.5-02 [CONDICIONAL] Quando são assinados relatórios de validação, o certificado público de assinatura do SVSP correspondente à chave de assinatura privada do SVSP deve ser emitido por uma autoridade de certificação (CA) de confiança, em conformidade com a política de certificação NCP+, como especificado na norma ETSI EN 319 411-1 [12]. Deve ser emitido em conformidade com uma política de certificação adequada especificada na norma ETSI EN 319 411-2 [i.17].

—

OVR-7.5-03 [CONDICIONAL] Quando são assinados relatórios de validação, a chave de assinatura privada do SVSP deve ser conservada e utilizada num dispositivo criptográfico seguro que seja um sistema fiável certificado em conformidade com:

—

OVR-7.5-04 nulo e sem efeito.

—

OVR-7.5-06 A chave de assinatura privada de um SVSP só deve ser exportada e importada para um dispositivo criptográfico seguro diferente se essa exportação e importação forem implementadas de forma segura e em conformidade com a certificação desses dispositivos.

—

OVR-7.7-02 Para garantir que os sistemas em que a aplicação é desenvolvida aplicam medidas de segurança adequadas e se adaptam a ambientes de aplicação específicos, a aplicação de validação de assinaturas (SVA) deve utilizar um ambiente de aplicação mantido com correções de segurança atualizadas.

—

OVR-7.7-03 Aplicam-se à SVA os seguintes requisitos especificados na norma ETSI TS 119 101 [1], cláusula 5.2: GSM 1.3.

—

OVR-7.8-02 Se for permitido o acesso remoto a sistemas de armazenamento ou tratamento de dados confidenciais, deve ser adotada e descrita uma política formal como parte dos elementos exigidos pelo OVR-6.3-02.

—

OVR-7.8-04 A análise das vulnerabilidades solicitada pelo REQ-7.8-13 da norma ETSI EN 319 401 [1] deve ser efetuada pelo menos uma vez por trimestre.

—

OVR-7.8-05 O teste de penetração solicitado pelo REQ-7.8-17X da norma ETSI EN 319 401 [1] deve ser efetuado pelo menos uma vez por ano.

—

OVR-7.8-06 As barreiras de segurança devem ser configuradas de modo a impedir todos os protocolos e acessos não necessários para a operação do SVSP.

—

OVR-7.12-02 O plano de cessação do TSP deve cumprir os requisitos estabelecidos nos atos de execução adotados nos termos do artigo 24.o, n.o 5, do Regulamento (UE) n.o 910/2014 [i.1].

—

OVR-7.14-01 Aplicam-se os requisitos especificados na norma ETSI EN 319 401 [2], cláusula 7.14.

—

VPR-8.1-07 A SVA deve cumprir os requisitos da norma ETSI TS 119 101 [1], cláusula 7.4., SIA 1 a SIA 4.

—

VPR-8.1-11 [CONDICIONAL] Quando o SVS pretender validar assinaturas eletrónicas qualificadas ou selos eletrónicos qualificados em conformidade com o artigo 32.o, n.o 1, (ou o artigo 40.o, respetivamente) do Regulamento (UE) n.o 910/2014 [i.1], o processo de validação deve seguir os requisitos da norma ETSI TS 119 172-4 [8].

—

SVP-8.2-03 A resposta da validação da assinatura contém o OID da política do SVS.

—

SVR-8.4-02 O relatório de validação deve estar em conformidade com a norma ETSI TS 119 102-2 [9].

—

SVR-8.4-07 [CONDICIONAL] Quando uma política de validação de assinaturas não é totalmente tratada pelo SVS, para além de indicar as restrições validadas, o relatório deve indicar as restrições que tenham sido ignoradas ou anuladas.

—

SVR-8.4-15 O relatório de validação deve indicar claramente a origem de cada prova de existência (PoE) (a partir da assinatura, do cliente, do servidor).

—

SVR-8.4-16 O relatório de validação deve conter uma assinatura do relatório de validação, que é a assinatura digital do SVSP.

—

SVR-8.4-17 [CONDICIONAL] Quando os relatórios de validação são assinados, o formato e o objetivo da assinatura devem estar em conformidade com a norma ETSI TS 119 102-2 [9].

—

OVR-9-05 [CONDICIONAL] Aquando da elaboração de uma política de SVS com base numa política de serviços de confiança definida no presente documento, deve ser realizada uma avaliação dos riscos para avaliar os requisitos operacionais e determinar os requisitos de segurança a incluir na política para a comunidade e a aplicabilidade declaradas.

—

OVR-9-06 [CONDICIONAL] Aquando da elaboração de uma política de SVS com base numa política de serviços de confiança definida no presente documento, a política deve ser aprovada e alterada em conformidade com um processo de revisão definido, incluindo as responsabilidades pela manutenção da política.

—

OVR-9-07 [CONDICIONAL] Aquando da elaboração de uma política de SVS com base numa política de serviços de confiança definida no presente documento, deve existir um processo de revisão definido para assegurar que a política é apoiada pelas declarações de práticas.

—

OVR-9-08 [CONDICIONAL] Aquando da elaboração de uma política de SVS com base numa política de serviços de confiança definida no presente documento, o TSP deve disponibilizar as políticas por si apoiadas à sua comunidade de utentes.

—

OVR-9-09 [CONDICIONAL] Aquando da elaboração de uma política de SVS com base numa política de serviços de confiança definida no presente documento, devem ser disponibilizadas aos assinantes as revisões das políticas apoiadas pelo TSP.

—

VPR-B-02 [CONDICIONAL] Se o SVSP for um prestador qualificado de serviços de validação de assinaturas (QSVSP), a implementação deve estar em conformidade com a norma ETSI TS 119 172-4 [8].

—

NOTA 2 nula e sem efeito.

—

OVR-B-04 [CONDICIONAL] Se o SVSP for um QSVSP, os ensaios previstos no OVR-B-03 devem verificar diferentes casos de utilização, positivos e negativos.

—

VPR-B-11 [CONDICIONAL] Se o SVSP for um QSVSP, deve controlar o cálculo de dispersão (executar o cálculo do lado do servidor ou controlar o cliente se tal for permitido do lado do cliente).

—

NOTA 5 nula e sem efeito.

—

NOTA 6 nula e sem efeito.

—

VPR-B-15 [CONDICIONAL] Se o SVSP for um QSVSP, o relatório de validação deve estar em conformidade com a norma ETSI TS 119 102-2 [9] para que os requisitos VPR-B-13 e VPR-B-14 sejam cumpridos.

—

VPR-B-16 [CONDICIONAL] Se o SVSP for um QSVSP, a implementação deve estar em conformidade com os mecanismos criptográficos acordados, aprovados pelo Grupo Europeu para a Certificação da Cibersegurança e publicados pela ENISA [10], para a utilização das técnicas criptográficas adequadas durante a prestação de serviços qualificados de validação de QES.

—

para assegurar a verificação de todas as condições exigidas pelo artigo 32.o, n.o 1, e pelo artigo 40.o do Regulamento (UE) n.o 910/2014 [i.1], é necessário um algoritmo de validação correto. Este fornece o mesmo resultado determinístico para uma assinatura ou selo submetido a validação. A política de validação de assinaturas é crucial para este efeito. A norma ETSI TS 119 172-4 [8], baseada no algoritmo de validação especificado na norma ETSI EN 319 102-1 [3], foi emitida nesta perspetiva.

—

[1] ETSI EN 319 102-1 V1.4.1 (2024-06) «Electronic Signatures and Trust Infrastructures (ESI); Procedures for Creation and Validation of AdES Digital Signatures; Part 1: Creation and Validation» [Assinaturas eletrónicas e infraestruturas de confiança (ESI); procedimentos de criação e validação de assinaturas digitais AdES; parte 1: criação e validação].

—

Qualquer referência à «ETSI TS 119 102-1 [1]» deve ser entendida como uma referência à «ETSI EN 319 102-1 [1]».

—

[2] ETSI TS 119 612 V2.3.1 (2024-11) «Electronic Signatures and Trust Infrastructures (ESI); Trusted Lists» [Assinaturas eletrónicas e infraestruturas de confiança (ESI); listas de confiança].

—

[13] ETSI TS 119 101 V1.1.1 (2016-03) «Electronic Signatures and Infrastructures (ESI); Policy and security requirements for applications for signature creation and signature validation» [Assinaturas eletrónicas e infraestruturas (ESI); requisitos de política e de segurança para aplicações de criação e validação de assinaturas].

—

i) se um certificado de entidade final representar uma âncora de confiança, não se pode utilizar «RevocationCheckingConstraints»,

—

ii) se um certificado de entidade final não representar uma âncora de confiança, deve definir-se «RevocationCheckingConstraints» como «eitherCheck» , conforme especificado na norma ETSI TS 119 172-1 [3], cláusula A.4.2.1, quadro A.2, linhas m)2.1,

—

iii) se um certificado de entidade final representar uma âncora de confiança, as restrições «RevocationFreshnessConstraints» definidas na norma ETSI TS 119 172-1 [3], cláusula A.4.2.1, quadro A.2, linhas m)2.2, não podem ser utilizadas,

—

iv) se um certificado de entidade final não representar uma âncora de confiança, as restrições «RevocationFreshnessConstraints» definidas na norma ETSI TS 119 172-1 [3], cláusula A.4.2.1, quadro A.2, linhas m)2.2, devem ser utilizadas com um valor máximo de 24 horas para o certificado de assinatura. Não é fixado qualquer valor para «RevocationFreshnessConstraints» para certificados que não o certificado de assinatura, incluindo os certificados comprovativos dos selos temporais.

—

REQ-4.4.2-03 Se alguma das verificações especificada no REQ-4.4.2-01 falhar: