ANEXO. Regulamento Delegado da Comissão

Transcrição

1 COMISSÃO EUROPEIA Bruxelas, C(2019) 1789 final ANNEX 3 ANEXO do Regulamento Delegado da Comissão que complementa a Diretiva 2010/40/UE do Parlamento Europeu e do Conselho no que diz respeito à implantação e à utilização de sistemas cooperativos de transporte inteligentes {SEC(2019) 100 final} - {SWD(2019) 95 final} - {SWD(2019) 96 final} PT PT

2 ÍNDICE 1. Introdução Visão geral e âmbito de aplicação da presente política Definições e siglas Participantes da PKI Introdução Autoridade da política de certificação de STI-C Gestor da lista aprovada Auditor acreditado da PKI Ponto de contacto para STI-C (CPOC) Funções operacionais Utilização de certificados Domínios de utilização aplicáveis Limites de responsabilidade Administração da política de certificação Atualização dos CPS de CA enumerados no ECTL Procedimentos de aprovação da CPS Responsabilidades de publicação e criação de repositórios Métodos para a publicação de informações de certificados Altura ou frequência de publicação Repositórios Controlos de acesso a repositórios Publicação de informações de certificados Publicação de informações de certificados pelo TLM Publicação de informações de certificados pelas CA Identificação e autenticação Nomenclatura Tipos de nomes Nomes para TLM, CA de raiz, EA e AA Nomes para as entidades finais Identificação de certificados Necessidade de os nomes serem significativos Anonimato e pseudonímia das entidades finais Regras de interpretação das diversas formas de nomes Exclusividade dos nomes PT 1 PT

3 3.2. Validação inicial de identidade Método para demonstrar posse de chave privada Autenticação de identidade de uma organização Autenticação da identidade de uma organização de CA Autenticação da identidade de uma organização do TLM Autenticação da identidade de uma organização de CA subordinadas Autenticação da organização do subscritor da entidade final Autenticação de entidade individual Autenticação de entidade individual de TLM/CA Autenticação de identidade de subscritores de estações de STI-C Autenticação de identidade de estações de STI-C Informações de subscritor não verificadas Validação de autoridade Validação de TLM, CA de raiz, EA, AA Validação de subscritores de estações de STI-C Validação de estações de STI-C Critérios de interoperação Identificação e autenticação para pedidos de reemissão de chave Identificação e autenticação para pedidos de reemissão de chave de rotina Certificados de TLM Certificados de CA de raiz Renovação ou reemissão de chave de certificados de EA/AA Credenciais de inscrição de entidades finais Bilhetes de autorização das entidades finais Identificação e autenticação para pedidos de reemissão de chave após revogação Certificados de CA Credenciais de inscrição de entidades finais Pedidos de autorização de entidades finais Identificação e autenticação para pedidos de revogação Certificados de CA de raiz/ea/aa Credenciais de inscrição de estações de STI-C Certificados de autorização de estações de STI-C Requisitos operacionais do ciclo de vida dos certificados Pedido de certificado Quem pode submeter um pedido de certificado PT 2 PT

4 CA de raiz TLM EA e AA Estação de STI-C Processo de inscrição e responsabilidades CA de raiz TLM EA e AA Estação de STI-C Processamento de pedidos de certificado Realização de funções de identificação e autenticação Identificação e autenticação de CA de raiz Identificação e autenticação de TLM Identificação e autenticação de EA e AA Identificação e autenticação de subscritores de EE Certificados de autorização Aprovação ou rejeição de pedidos de certificado Aprovação ou rejeição de certificados de CA de raiz Aprovação ou rejeição de certificados de TLM Aprovação ou rejeição de certificados de EA e AA Aprovação ou rejeição de EC Aprovação ou rejeição de CA Tempo de processamento do pedido de certificado Pedido de certificado da CA de raiz Pedido de certificado do TLM Pedido de certificado da EA e AA Pedido de EC Pedido de CA Emissão do certificado Ações da CA durante a emissão de certificados Emissão de certificados de CA de raiz Emissão de certificados de TLM Emissão de certificados de EA e AA Emissão de EC Emissão de CA PT 3 PT

5 Notificação da CA aos subscritores da emissão de certificados Aceitação de certificados Realização da aceitação de certificados CA de raiz TLM EA e AA Estação de STI-C Publicação do certificado Notificação de emissão de certificado Par de chaves e utilização do certificado Chave privada e utilização do certificado Chave privada e utilização de certificados para TLM Chave privada e utilização de certificados para CA de raiz Chave privada e utilização de certificados para EA e AA Chave privada e utilização de certificados para a entidade final Chave pública e utilização de certificados da parte utilizadora Renovação de certificado Reemissão de chave de certificado Circunstâncias para a reemissão de chave de certificado Quem pode solicitar a reemissão de chave CA de raiz TLM EA e AA Estação de STI-C Processo de reemissão de chave Certificado do TLM Certificado da CA de raiz Certificados de EA e AA Certificados da estação de STI-C Alteração de certificado Revogação e suspensão de certificado Serviços de estado de certificado Características operacionais Disponibilidade do serviço Características facultativas PT 4 PT

6 4.11. Fim da subscrição Retenção e recuperação de chaves Subscritor Que par de chaves pode ser retido Quem pode submeter um pedido de recuperação Processo de recuperação e responsabilidades Identificação e autenticação Aprovação ou rejeição de pedidos de recuperação Ações da autoridade de retenção de chaves e da autoridade de recuperação de chaves durante a recuperação do par de chaves Disponibilidade da autoridade de retenção de chaves e da autoridade de recuperação de chaves Política e práticas de encapsulação e recuperação de chaves de sessão Instalações, gestão e controlos operacionais Controlos físicos Localização física e construção CA de raiz, CPOC e TLM EA/AA Acesso físico CA de raiz, CPOC e TLM EA/AA Energia e ar condicionado Exposição à água Prevenção e proteção contra incêndios Gestão de suportes Eliminação de resíduos Salvaguarda fora do local CA de raiz, CPOC e TLM EA/AA Procedimentos de controlo Funções de confiança Número de pessoas necessário por tarefa Identificação e autenticação para cada função Funções que requerem a separação de tarefas Controlos de pessoal Requisitos relativos a qualificações, experiência e credenciação PT 5 PT

7 Procedimentos de verificação de antecedentes Requisitos de formação Frequência e requisitos de ações de reciclagem Frequência e sequência da rotação de funções Sanções para ações não autorizadas Requisitos aplicáveis aos contratantes independentes Documentação fornecida ao pessoal Procedimentos de registo de auditorias Tipos de eventos a serem registados e comunicados por cada CA Frequência do registo de processamento Período de conservação de registos de auditoria Proteção de registos de auditoria Procedimentos de salvaguarda de registos de auditoria Sistema de recolha de auditorias (interno ou externo) Notificação ao sujeito causador de evento Avaliação de vulnerabilidades Arquivo de registos Tipos de registos arquivados Período de conservação de arquivos Proteção de arquivos Arquivo e armazenamento do sistema Requisitos de validação cronológica de registos Sistema de recolha de arquivos (interno ou externo) Procedimentos para obter e verificar informações do arquivo Transferência da chave para elementos do modelo de confiança de STI-C TLM CA de raiz Certificado da EA/AA Auditor Recuperação em caso de comprometimento e catástrofe Tratamento de incidentes e comprometimentos Corrupção de recursos informáticos, aplicações informáticas e/ou dados Procedimentos em caso de comprometimento de chaves privadas de entidades Capacidade de continuidade das atividades em caso de catástrofe Cessação e transferência PT 6 PT

8 TLM CA de raiz EA/AA Controlos de segurança técnica Geração e instalação de pares de chaves TLM, CA de raiz, EA, AA EE estação móvel de STI-C EE estação fixa de STI-C Requisitos de criptografia Comprimento de algoritmos e chaves algoritmos de assinatura Comprimento de algoritmos e chaves algoritmos de encriptação para inscrição e autorização Criptoagilidade Armazenamento seguro de chaves privadas Nível de CA de raiz, CA subordinada e TLM Entidade final Salvaguarda de chaves privadas Destruição de chaves privadas Dados de ativação Controlos de segurança informática Controlos técnicos do ciclo de vida Controlos de segurança de rede Perfis de certificados, CRL e CTL Perfil do certificado Validade do certificado Certificados de pseudónimos Bilhetes de autorização para estações de STI-C fixas Revogação de certificados Revogação de certificados de CA, EA e AA Revogação de credenciais de inscrição Revogação de bilhetes de autorização Lista de revogação de certificados Lista aprovada de certificados europeus Auditoria de conformidade e outras avaliações Aspetos abrangidos pela auditoria e base da auditoria Frequência das auditorias PT 7 PT

9 8.3. Identidade/qualificações do auditor Relação do auditor com a entidade auditada Medidas tomadas face a deficiência Comunicação dos resultados Outras disposições Taxas Responsabilidade financeira Confidencialidade das informações comerciais Plano de privacidade Referências PT 8 PT

10 ANEXO III 1. INTRODUÇÃO 1.1. Visão geral e âmbito de aplicação da presente política A presente política de certificação define o modelo europeu de confiança de STI-C baseado numa infraestrutura de chave pública (PKI) no âmbito do sistema geral de gestão de credenciais de segurança dos STI-C da UE (EU CCMS). Define requisitos para a gestão de certificados de chave pública para aplicações STI-C por entidades emissoras e a sua utilização por entidades finais na Europa. No seu nível mais elevado, a PKI é composta de um conjunto de CA de raiz «ativadas» devido ao facto de o gestor da lista aprovada (TLM) inserir os seus certificados numa lista aprovada de certificados europeus (ECTL), que é emitida e publicada pela entidade central do TLM (ver secções 1.2 e 1.3). A presente política é vinculativa para todas as entidades que participam no sistema STI-C na Europa. Funciona como auxílio na avaliação do nível de confiança que pode ser estabelecido em relação às informações recebidas por qualquer recetor de uma mensagem autenticada por um certificado de entidade final da PKI. Para permitir a avaliação da confiança nos certificados fornecidos pelo EU CCMS, estabelece um conjunto obrigatório de requisitos para a operação da entidade central do TLM e a compilação e gestão da ECTL. Por conseguinte, o presente documento rege os seguintes aspetos relacionados com a ECTL: identificação e autenticação de diretores que obtêm funções de PKI para o TLM, incluindo declarações dos privilégios atribuídos a cada função; requisitos mínimos para práticas de segurança locais para o TLM, incluindo controlos físicos, de pessoal e processuais; requisitos mínimos para práticas de segurança técnica para o TLM, nomeadamente segurança informática, segurança de rede e controlos de engenharia de módulos criptográficos; requisitos mínimos para práticas operacionais para o TLM, incluindo o registo de novos certificados de CA de raiz, o cancelamento temporário ou permanente de CA de raiz existentes e incluídas e a publicação e distribuição de atualizações da ECTL; um perfil da ECTL, incluindo todos os campos de dados obrigatórios e facultativos na ECTL, algoritmos criptográficos a utilizar, o formato exato da ECTL e recomendações para o processamento da ECTL; gestão do ciclo de vida de certificados da ECTL, incluindo a distribuição de certificados da ECTL, a ativação, a expiração e a revogação; gestão da revogação da confiança das CA de raiz quando necessário. Uma vez que a confiabilidade da ECTL não depende somente da própria ECTL, mas em grande parte também das CA de raiz que compõem a PKI e respetivas CA subordinadas, a presente política também estabelece requisitos mínimos, que são obrigatórios para todas as CA participantes (CA de raiz e CA subordinadas). As áreas sujeitas a requisitos são: identificação e autenticação de diretores que obtêm funções de PKI (por exemplo, agentes de segurança, responsáveis pelas questões de privacidade, PT 9 PT

11 administradores de segurança, administradores de diretório e utilizadores finais), incluindo uma declaração de deveres, obrigações, responsabilidades e privilégios associados a cada função; gestão de chaves, incluindo algoritmos aceitáveis e obrigatórios de assinatura de certificados e de assinatura de dados e períodos de validade de certificados; requisitos mínimos para práticas de segurança locais, incluindo controlos físicos, de pessoal e processuais; requisitos mínimos para práticas de segurança técnica, como segurança informática, segurança de rede e controlos de engenharia de módulos criptográficos; requisitos mínimos para as práticas operacionais da CA, EA AA e entidades finais, nomeadamente, aspetos do registo, do cancelamento de registos (retirada da lista), da revogação, do comprometimento de chaves, da demissão por justa causa, da atualização de certificados, das práticas de auditoria e da não divulgação de informações relacionadas com a privacidade; certificado e perfil da CRL, incluindo formatos, algoritmos aceites, campos de dados obrigatórios e opcionais e respetivos intervalos de valores válidos, e a forma como os verificadores devem processar os certificados; deveres de monitorização regular, elaboração de relatórios, emissão de alertas e restauração das entidades do modelo de confiança de STI-C, a fim de estabelecer uma operação segura, inclusive em casos de comportamento indevido. Além dos referidos requisitos mínimos, as entidades que gerem as CA de raiz e CA subordinadas podem decidir os seus próprios requisitos adicionais e defini-los nas declarações de práticas de certificação (CPS) pertinentes, desde que não contradigam os requisitos definidos na política de certificação. Para mais informações sobre o modo como as CPS são auditadas e publicadas, ver secção 1.5. A CP também estabelece as finalidades para as quais as CA de raiz e CA subordinadas, bem como os respetivos certificados emitidos, podem ser utilizados. Estabelece as responsabilidades assumidas: pelo TLM; por cada CA de raiz cujos certificados constem na ECTL; pelas CA subordinadas da CA de raiz (EA e AA); por cada membro ou organização responsável por, ou que opere, uma das entidades do modelo de confiança de STI-C. A CP define igualmente as obrigações obrigatórias aplicáveis: ao TLM; a cada CA de raiz cujos certificados constem na ECTL; a cada CA subordinada certificada por uma CA de raiz; a todas as entidades finais; a cada membro da organização responsável por, ou que opere, uma das entidades do modelo de confiança de STI-C. PT 10 PT

12 Por último, a CP estabelece requisitos no que diz respeito à documentação das limitações de responsabilidades e obrigações na CPS de cada CA de raiz cujos certificados constem na ECTL. A presente CP está em linha com a política de certificação e o quadro de práticas de certificação adotado pela Internet Engineering Task Force (IETF)[3] Definições e siglas Aplicam-se as definições de [2], [3] e [4]. AA autoridade de autorização CA certificado de autorização CA autoridade de certificação CP CPA CPOC CPS CRL EA EC ECIES EE ECTL EU CCMS GDPR HSM PKI RA política de certificação autoridade da política de certificação de STI-C ponto de contacto para STI-C declaração de práticas de certificação lista de revogação de certificados autoridade de inscrição credencial de inscrição esquema integrado de curva de criptografia elítica entidade final (ou seja, estação de STI-C) Lista aprovada de certificados europeus sistema de gestão de credenciais de segurança dos STI-C da UE Regulamento Geral sobre a Proteção de Dados: módulo de segurança do equipamento infraestrutura de chave pública autoridade de registo CA subordinada EA e AA TLM gestor da lista aprovada PT 11 PT

13 PT 12 PT

14 Glossário requerente A pessoa singular ou entidade jurídica que solicita (ou pretende renovar) um certificado. Uma vez criado o certificado inicial (inicialização), o requerente é referido como o subscritor. Para certificados emitidos para entidades finais, o subscritor (requerente do certificado) é a entidade que controla ou opera/mantém a entidade final para a qual o certificado é emitido, mesmo se a entidade final enviar o pedido de certificado real. autoridade autorização de No presente documento, o termo «autoridade de autorização» (AA) refere-se não apenas à função específica da AA, mas também à entidade jurídica e/ou operacional que o gere. autoridade certificação de A autoridade de certificação de raiz, a autoridade de inscrição e a autoridade de autorização são cumulativamente referidas como a autoridade de certificação (CA). Modelo confiança STI-C de de O modelo de confiança de STI-C é responsável por estabelecer uma relação de confiança entre as estações de STI-C. É implementada através da utilização de uma PKI composta de CA de raiz, o CPOC, o TLM, as EA e AA e uma rede segura. Criptoagilidade módulo criptográfico A capacidade das entidades do modelo de confiança de STI-C de adaptar a CP a ambientes em mudança ou a novos requisitos futuros, por exemplo, através da mudança de algoritmos criptográficos e de comprimento da chave ao longo do tempo Um elemento seguro baseado em equipamento informático no qual as chaves são geradas e/ou armazenadas, são gerados números aleatórios e os dados são assinados ou encriptados. autoridade inscrição de No presente documento, o termo «autoridade de inscrição» (EA) refere-se não apenas à função específica da EA, mas também à entidade jurídica e/ou operacional que o gere. Participantes da PKI Entidades do modelo de confiança de STI-C, a saber, o TLM, as CA de raiz, as EA, as AA e as estações de STI-C. reemissão chave repositório autoridade certificação raiz sujeito de de de Este subcomponente é utilizado para descrever certos elementos relacionados com um subscritor ou outro participante que gera um novo par de chaves e solicita a emissão de um novo certificado que certifica a nova chave pública, tal como descrita em [3]. O repositório utilizado para armazenar os certificados e informações sobre certificados fornecidos pelas entidades do modelo de confiança de STI-C, conforme definido na secção 2.3. No presente documento, o termo «autoridade de certificação de raiz» (CA) refere-se não apenas à função específica da CA, mas também à entidade jurídica e/ou operacional que o gere. A pessoa singular, dispositivo, sistema, unidade ou entidade jurídica identificada num certificado como o sujeito, ou seja, o subscritor ou um dispositivo sob o controlo e a operação do subscritor. subscritor contrato subscritor de Pessoa singular ou entidade jurídica à qual é emitido um certificado e que está juridicamente vinculada por um contrato de subscritor ou termos de utilização. Um acordo entre a CA e o requerente/subscritor que especifica os direitos e as responsabilidades das partes. PT 13 PT

15 1.3. Participantes da PKI Introdução Os participantes da PKI desempenham uma função na PKI definida pela presente política. A menos que seja explicitamente proibido, um participante pode assumir várias funções em simultâneo. Pode estar proibido de assumir funções específicas em simultâneo, a fim de evitar conflitos de interesses ou garantir a separação de tarefas. Os participantes também podem delegar partes da sua função a outras entidades no âmbito de um contrato de serviços. Por exemplo, quando as informações de estado de revogação são fornecidas utilizando CRL, a CA também é o emissor da CRL, mas pode delegar a responsabilidade de emitir CRL numa entidade diferente. As funções da PKI consistem em: funções de autoridade, ou seja, cada função é instanciada de forma única; funções operacionais, ou seja, funções que podem ser instanciadas em uma ou mais entidades. Por exemplo, uma CA de raiz pode ser implementada por uma entidade comercial, um grupo de interesse comum, uma organização nacional e/ou uma organização europeia. A Figure 1 mostra a arquitetura do modelo de confiança STI-C baseada na [2]. A arquitetura é aqui brevemente descrita, mas os principais elementos são descritos em maior detalhe nas secções a A CPA nomeia o TLM, que é, por conseguinte, uma entidade de confiança para todos os participantes da PKI. A CPA aprova a operação da CA de raiz e confirma que o TLM pode confiar na(s) CA de raiz. O TLM emite a ECTL que garante a confiança das CA de raiz aprovadas a todos os participantes da PKI. A CA de raiz emite certificados para a EA e a AA, garantindo assim confiança na sua operação. A EA emite certificados de inscrição para as estações STI-C de envio e retransmissão (como entidades finais), garantindo assim confiança na sua operação. A AA emite CA para as estações de STI-C com base na confiança na EA. A estação de STI-C de receção e retransmissão (como parte retransmissora) pode confiar noutras estações de STI-C, uma vez que os CA são emitidos por uma AA de confiança aprovada por uma CA de raiz, que é aprovada pelo TLM e pela CPA. Observe-se que a Figure 1descreve apenas o nível da CA de raiz do modelo de confiança do STI-C. Os detalhes das camadas inferiores são apresentados nas secções subsequentes da presente CP ou na CPS das CA de raiz específicas. A Figure 2 fornece uma visão geral dos fluxos de informação entre os participantes da PKI. Os pontos verdes indicam fluxos que exigem comunicações máquina a máquina. Os fluxos de informação a vermelho definiram requisitos de segurança. O modelo de confiança de STI-C baseia-se numa arquitetura de CA de raiz múltipla, em que os certificados da CA raiz são transmitidos periodicamente (conforme estabelecido abaixo) para o ponto central de contacto (CPOC) por meio de um protocolo seguro (por exemplo, certificados de ligação) definido pelo CPOC. Uma CA de raiz pode ser operada por uma organização governamental ou privada. A arquitetura do modelo de confiança de STI-C contém pelo menos uma CA de raiz (a CA de raiz da UE com o mesmo nível que as outras CA de raiz). A CA de raiz da UE PT 14 PT

16 (18) resposta (29) resposta (19) resposta (30) resposta é delegada por todas as entidades que participam no modelo de confiança de STI-C que não pretendem configurar sua própria CA de raiz. O CPOC transmite os certificados da CA de raiz recebidos ao TLM, que é responsável por recolher e assinar a lista de certificados da CA de raiz e os enviar de volta ao CPOC, o que os torna publicamente disponíveis para todos (ver abaixo). As relações de confiança entre as entidades no modelo de confiança de STI-C são descritas nas figuras, nos quadros e nas secções a seguir. TLM Autoridade da política de certificação de STI-C Legenda: TLM gestor da lista aprovada CPOC ponto de contacto para STI-C CA autoridade de certificação EA autoridade de inscrição AA autoridade de autorização relação de confiança elementos europeus comuns CPOC CA de raiz da UE CA de raiz 1 CA de raiz 2... CA de raiz N EA AA EA EA AA AA EA EA AA AA EA EA AA AA EA EA AA AA CA de raiz adicionais administradas na Europa, p. ex. por autoridades ou organizações privadas dos Estados-Membros que fornecem certificados a utilizadores específicos. Figura 1: Arquitetura do modelo de confiança de STI-C (37) pedidos alteração CP (todos) (5) alteração da ECTL autoridade da política de certificação de STI-C (38) formulário de pedido (39) aprovação (40) relatório rejeição de auditoria TLM (1) aprovação/ (2) revogação de CA de raiz (3) atualizações CP (4) aprovação / rejeição repositório CPOC cert. TLM ECTL auditor de PKI acreditado repositório da CA de raiz certificado (EA)/AA CRL (33) registo (34) desativação (7) ECTL (13) solicitação (36) relatório (21) pedido cert. EA (6) cert. TLM CPOC (8) informações de certificado da AC de raiz (9) revogação de CA de raiz (11) informações de certificado da CA de raiz (12) revogação de certificado da CA de raiz (31) rg. inscrição (27) envio de pedido EA (22) resposta CA de raiz (25) pedido de autorização (23) resposta de autorização (24) pedido cert. AA (28) envio de pedido AA (14) formulário de pedido (15) alterações CPS + (16) relatório de auditoria (17) relatórios (incidentes) (32) reg. aut. (26) resposta fabricante / operador estação STI-C Figura 2: Fluxos de informação do modelo de confiança de STI-C PT 15 PT

17 ID do fluxo De Para Conteúdo Referência (1). CPA TLM aprovação do pedido da CA de raiz 8 (2). CPA TLM informações sobre revogação da CA de raiz 8.5 (3). CPA CA de raiz atualizações da CP 1.5 (4). CPA CA de raiz aprovação/rejeição do formulário de pedido da CA de raiz ou das alterações do pedido da CPS ou do processo de auditoria. 8.5, 8.6 (5). TLM CPA notificação de alteração da ECTL 4, (6). TLM CPOC Certificado do TLM (7). TLM CPOC ECTL (8). CPOC TLM informações de certificado da CA de raiz (9). CPOC TLM revogação de certificado da CA de raiz 7.3 (10). CPOC todas as entidades finais certificado do TLM (11). CA de raiz CPOC informações de certificado da CA de raiz (12). CA de raiz CPOC revogação de certificado da CA de raiz 7.3 (13). CA de raiz auditor pedido de auditoria 8 (14). CA de raiz CPA formulário de pedido da CA de raiz pedido inicial (15). CA de raiz CPA formulário de pedido da CA de raiz alterações da CPS (16). CA de raiz CPA formulário de pedido da CA de raiz relatório de auditoria (17). CA de raiz CPA relatórios de incidentes da CA de raiz, nomeadamente a revogação de uma CA subordinada (EA, AA) Anexo III, (18). CA de raiz EA resposta do certificado da EA (19). CA de raiz AA resposta de certificado da AA (20). CA de raiz Todos certificado da EA/AA, CRL (21). EA CA de raiz pedido de certificado da EA (22). EA Estação de STI-C resposta de credencial de inscrição (23). EA AA resposta de autorização (24). AA CA de raiz pedido de certificado da AA (25). AA EA pedido de autorização (26). AA Estação de STI-C resposta de bilhete de autorização PT 16 PT

18 (27). EA CA de raiz submissão de pedido (28). AA CA de raiz submissão de pedido (29). CA de raiz EA resposta 4.12 e (30). CA de raiz AA resposta 4.12 e (31). Estação de STI-C (32). Estação de STI-C (33). fabricante/ope rador (34). fabricante/ope rador EA pedido de credencial de inscrição AA pedido de certificado de autorização EA registo EA desativação 7.3 (35). EA fabricante/ operador resposta (36). auditor CA de raiz relatório 8.1 (37). todos CPA pedido de alteração da CP 1.5 (38). TLM CPA formulário de pedido (39). CPA TLM aprovação/rejeição (40). TLM CPA Relatório de auditoria Quadro 1: Descrição detalhada dos fluxos de informação no modelo de confiança de STI-C Autoridade da política de certificação de STI-C (1) A autoridade da política de certificação (CPA) de STI-C é composta pelos representantes dos intervenientes públicos e privados (por exemplo, Estados- Membros, fabricantes de veículos, etc.) que participam no modelo de confiança de STI-C. É responsável por duas subfunções: (1) gestão da política de certificação, nomeadamente: aprovação da presente CP e futuros pedidos de alteração da CP; decisão sobre a análise de pedidos de alteração da CP e recomendações enviadas por outros participantes ou entidades da PKI; decisão sobre o lançamento de novas versões da CP; (2) gestão das autorizações da PKI, nomeadamente: definir, decidir e publicar a aprovação da CPS e os procedimentos de auditoria da CA (coletivamente designados «procedimentos de aprovação da CA»); autorizar o CPOC a operar e apresentar relatórios periodicamente; autorizar o TLM a operar e apresentar relatórios periodicamente; aprovação da CPS da CA de raiz, se estiver de acordo com a CP comum e válida; PT 17 PT

19 escrutínio dos relatórios de auditoria do auditor acreditado da PKI para todas as CA de raiz; notificar o TLM sobre a lista das CA de raiz aprovadas ou não aprovadas e respetivos certificados com base nos relatórios de aprovação recebidos das CA de raiz e nos relatórios de operações regulares. (2) O representante autorizado da CPA é responsável por autenticar o representante autorizado do TLM e aprovar o formulário de pedido do processo de inscrição do TLM. A CPA é responsável por autorizar que o TLM opere conforme estabelecido na presente secção Gestor da lista aprovada (3) O TLM é uma entidade única designada pela CPA. (4) O TLM é responsável: pela operação da ECTL de acordo com a CP comum válida e a apresentação regular de relatórios de atividades à CPA para a operação geral segura do modelo de confiança de STI-C; por receber certificados de CA do CPOC; por incluir/excluir certificados de CA de raiz na ECTL após notificação pela CPA; por assinar a ECTL; Auditor acreditado da PKI pela comunicação regular e atempada da ECTL ao CPOC. (5) O auditor da PKI acreditado é responsável por: executar ou organizar auditorias de CA de raiz, TLM e CA subordinada; distribuir o relatório de auditoria (de uma auditoria inicial ou periódica) à CPA, de acordo com os requisitos da secção 8 abaixo. O relatório de auditoria deve incluir recomendações do auditor da PKI acreditado; notificar a entidade que gere a CA de raiz do sucesso ou insucesso da realização de uma auditoria inicial ou periódica das CA subordinadas; avaliar a conformidade da CPS com a presente CP Ponto de contacto para STI-C (CPOC) (6) O CPOC é uma entidade única designada pela CPA. O representante autorizado da CPA é responsável por autenticar o representante autorizado do CPOC e aprovar o formulário de registo do processo de inscrição do CPOC. A CPA é responsável por autorizar que o CPOC opere conforme estabelecido na presente secção. (7) O CPOC é responsável por: estabelecer e contribuir para o intercâmbio seguro de comunicações entre todas as entidades do modelo de confiança de STI-C de forma eficiente e rápida; PT 18 PT

20 analisar pedidos e recomendações de alteração de procedimentos enviados por outros participantes do modelo de confiança (por exemplo, CA de raiz); transmitir certificados da CA de raiz ao TLM; publicar a âncora de confiança comum (chave pública atual e certificado de ligação do TLM); publicar a ECTL. A secção 7 contém todos os detalhes relativos à ECTL Funções operacionais (8) As seguintes entidades definidas na norma [2] desempenham uma função operacional, conforme definido no RFC 3647: Elemento funcional Função da PKI ([3] e [4]) Função detalhada ([2]) autoridade de certificação de raiz autoridade de inscrição autoridade de autorização estação de STI-C remetente estação de STI-C de retransmissão (encaminhamento) CA/RA (autoridade de registo) subscritor da CA de raiz/sujeito do certificado da EA CA/RA subscritor da CA de raiz/sujeito do certificado da AA CA/RA sujeito do certificado (EE) da entidade final (EE) parte retransmissora / sujeito do certificado de EE Comprova à EA e AA que pode emitir EC e CA Autentica uma estação de STI-C e concede-lhe acesso a comunicações STI Comprova irrefutavelmente à estação de STI-C que pode utilizar serviços de STI específicos Adquire os direitos da EA para aceder a comunicações STI Negoceia os direitos de AA de invocar serviços STI Envia mensagens de difusão de salto único e retransmitidas Recebe a mensagem de difusão da estação de STI-C remetente e encaminha-a para a estação de STI-C recetora, se necessário estação de STI-C recetora parte retransmissora Recebe mensagens de difusão da estação de STI-C remetente ou retransmissora fabricante subscritor da EA Instala informações necessárias para a gestão de segurança na estação de STI-C na produção operador subscritor da EA/AA Instala e atualiza informações necessárias para a gestão de segurança na estação de STI-C durante a operação Quadro 2: Funções operacionais Nota: de acordo com a norma [4], a presente CP utiliza termos diferentes para o «subscritor» que contrata a CA para a emissão de certificados e o «sujeito» ao qual o certificado se aplica. São subscritores todas as entidades que possuem uma relação contratual com uma CA. Os sujeitos são as entidades às quais o certificado se aplica. As EA/AA agem na qualidade de subscritores e sujeitos da CA de raiz e podem solicitar certificados EA/AA. As estações de STI-C são sujeitos e podem solicitar certificados de entidade final. PT 19 PT

21 (9) Autoridades de registo: A EA deve desempenhar a função de uma autoridade de registo para entidades finais. Apenas os subscritores autenticados e autorizados podem registar novas entidades finais (estações de STI-C) numa EA. As CA de raiz pertinentes devem desempenhar a função de autoridades de registo para EA e AA Utilização de certificados Domínios de utilização aplicáveis (10) Os certificados emitidos ao abrigo da presente CP destinam-se a ser utilizados para validar assinaturas digitais no contexto de comunicações de STI cooperativos de acordo com a arquitetura de referência da norma [2]. (11) Os perfis de certificado da norma [5] determinam utilizações de certificados para o TLM, a CA de raiz, as EA, as AA e as entidades finais Limites de responsabilidade (12) Os certificados não se destinam a ser utilizados, nem podem sê-lo, em: circunstâncias que infrinjam, violem ou se oponham a qualquer lei, regulamento (por exemplo, o GDPR), decreto ou decisão aplicável do governo; circunstâncias que violem ou infrinjam os direitos de terceiros; violem a presente CP ou o contrato de subscritor pertinente; quaisquer circunstâncias em que a respetiva utilização possa levar diretamente à morte, a lesões corporais ou danos ambientais graves (por exemplo, por falha na operação de instalações nucleares, na navegação ou comunicação de aeronaves ou em sistemas de controlo de armas); circunstâncias que contrariem os objetivos gerais de uma maior segurança rodoviária e de transportes rodoviários mais eficientes na Europa Administração da política de certificação Atualização de CPS das CA incluídas na ECTL (13) Cada CA de raiz incluída na ECTL deve publicar a sua própria CPS, que deve estar em conformidade com a presente política. Uma CA de raiz pode acrescentar requisitos adicionais, mas deve garantir o cumprimento permanente de todos os requisitos da presente CP. (14) Cada CA de raiz incluída na ECTL deve implementar um processo de alteração apropriado para o seu documento CPS. As principais propriedades do processo de alteração devem ser documentadas na parte pública da CPS. (15) O processo de alteração deve assegurar que todas as alterações à presente CP são cuidadosamente analisadas e, se necessário para o cumprimento da CP de acordo com as alterações, que a CPS é atualizada dentro do prazo estabelecido na etapa de implementação do processo de alteração para a CP. Em especial, o processo de alteração deve envolver procedimentos de alteração de emergência que garantam a implementação atempada de alterações à CP que sejam relevantes no que respeita à segurança. PT 20 PT

22 (16) O processo de alteração deve incluir medidas apropriadas para verificar a conformidade da CP para todas as alterações à CPS. Qualquer alteração à CPS deve ser claramente documentada. Antes que uma nova versão de uma CPS seja implementada, a sua conformidade com a CP deve ser confirmada por um auditor de PKI acreditado. (17) A CA de raiz deve notificar a CPA de qualquer alteração feita à CPS com pelo menos as seguintes informações: uma descrição exata da alteração; os motivos que justificam a alteração; um relatório do auditor acreditado da PKI confirmando o cumprimento da CP; o contacto da pessoa responsável pela CPS; o calendário previsto para a implementação Procedimentos de aprovação da CPS (18) Antes de iniciar as suas operações, uma futura CA de raiz deve apresentar a sua CPS a um auditor de PKI acreditado no âmbito de um pedido de auditoria para verificar a conformidade (fluxo 13) e à CPA para que esta dê a sua aprovação (fluxo 15). (19) Uma CA de raiz deve apresentar as alterações da sua CPS a um auditor de PKI acreditado no âmbito de um pedido de auditoria para verificar a conformidade (fluxo 13) e à CPA para que esta dê a sua aprovação (fluxo 15) antes de as alterações se tornarem efetivas. (20) A EA/AA deve apresentar a sua CPS, ou alterações à sua CPS, à CA de raiz. A CA de raiz pode solicitar um certificado de conformidade do organismo nacional ou entidade privada responsável pela aprovação da EA/AA, conforme definido nas secções e 8. (21) O auditor de PKI acreditado deve avaliar a CPS de acordo com a secção 8. (22) O auditor da PKI acreditado deve comunicar os resultados da avaliação da CPS no âmbito do relatório de auditoria, conforme estabelecido na secção 8.1. A CPS deve ser aceite ou rejeitada no âmbito da aceitação do relatório de auditoria referido nas secções 8.5 e RESPONSABILIDADES DE PUBLICAÇÃO E CRIAÇÃO DE REPOSITÓRIOS 2.1. Métodos para a publicação de informações de certificados (23) As informações do certificado podem ser publicadas de acordo com a secção 2.5: de forma regular ou periódica; ou em resposta a um pedido de uma das entidades participantes. Em cada caso, aplicam-se graus de urgência de publicação diferentes e, por conseguinte, calendários diferentes, mas as entidades devem estar preparadas para ambas as situações. PT 21 PT

23 (24) A publicação regular das informações do certificado permite determinar um prazo máximo até ao qual as informações dos certificados são atualizadas para todos os nós da rede de STI-C. A frequência da publicação de todas as informações do certificado é definida na secção 2.2. (25) A pedido de entidades participantes da rede de STI-C, qualquer participante pode começar a publicar as informações do certificado a qualquer momento e, dependendo do seu estado, solicitar um conjunto atual de informações do certificado para se tornar um nó de total confiança da rede de STI-C. O principal objetivo dessa publicação é atualizar as entidades quanto ao estado geral atual das informações de certificado na rede e permitir que estas comuniquem com confiança até à próxima publicação regular das informações. (26) Uma CA de raiz individual também pode iniciar a publicação de informações de certificado a qualquer momento enviando um conjunto atualizado de certificados a todos os «membros inscritos» da rede de STI-C que são recetores regulares dessas informações. Essa situação apoia a operação das CA e permite que estes se dirijam aos membros entre as datas regulares e agendadas para publicar os certificados. (27) A secção 2.5 define o mecanismo e todos os procedimentos para publicar certificados de CA de raiz e a ECTL. (28) O CPOC deve publicar os certificados da CA de raiz (conforme incluídos na ECTL e destinados ao consumo público), o certificado do TLM e a ECTL que emite. (29) As CA de raiz devem publicar os seus certificados EA/AA e CRL e ser capazes de suportar os três mecanismos aqui referidos para os publicar aos seus membros inscritos e partes utilizadoras, tomando todas as medidas necessárias para garantir a transmissão segura, conforme referido na secção Altura ou frequência de publicação (30) Os requisitos aplicáveis ao agendamento da publicação de certificados e CRL devem ser determinados à luz dos vários fatores limitantes dos nós do STI-C individuais, com o objetivo geral de operar uma «rede de confiança» e publicar as atualizações o mais rapidamente possível para todas as estações de STI-C envolvidas. Para a publicação regular de informações atualizadas do certificado (por exemplo, alterações na composição da ECTL ou da CRL), é necessário um período máximo de três meses para a operação segura da rede de STI- C. As CA de raiz devem publicar os seus certificados de CA e CRL logo que possível após a emissão. Para a publicação da CRL, deve ser utilizado o repositório da CA de raiz. Além disso, o CPS para cada CA deve especificar o período de tempo dentro do qual um certificado será publicado após a CA emitir o certificado. Esta secção especifica apenas o tempo ou a frequência da publicação regular. Os meios de conectividade para atualizar as estações de STI-C com a ECTL e as CRL no espaço de uma semana após a sua publicação (sob condições normais de operação, por exemplo, com cobertura celular, veículo em operação PT 22 PT

24 2.3. Repositórios real, etc.) devem ser implementados em conformidade com os requisitos do presente documento. (31) Os requisitos relativos à estrutura do repositório para armazenar os certificados e às informações que são fornecidas pelas entidades da rede de STI-C são os seguintes para as entidades únicas: em geral, cada CA de raiz deve utilizar um repositório das suas próprias informações de certificado EA/AA e CRL atualmente ativas para publicar certificados para os outros participantes na PKI (por exemplo, um serviço de diretório baseado em LDAP). O repositório de cada CA de raiz deve suportar todos os controlos de acesso necessários (secção 2.4) e tempos de transmissão (secção 2.2) para cada modalidade de distribuição de informações relacionadas com STI-C; o repositório do TLM (que armazena a ECTL e os certificados do TLM publicados pelo CPOC, por exemplo) deve basear-se num mecanismo de publicação capaz de garantir os tempos de transmissão definidos na secção 2.2 para cada modalidade de distribuição. Os requisitos das AA não estão definidos, mas devem suportar os mesmos níveis de segurança que as outras entidades e devem ser declarados na sua CPS Controlos de acesso a repositórios (32) Os requisitos de controlo de acesso a repositórios de informações de certificado devem, no mínimo, estar em conformidade com os padrões gerais de tratamento seguro de informações descritos na norma ISO/IEC e com os requisitos da secção 4. Adicionalmente, devem refletir as necessidades de segurança do processo a serem estabelecidas para as etapas do processo único na publicação das informações do certificado. Tal inclui a implementação do repositório para certificados TLM e a ECTL no TLM/CPOC. Cada CA ou operador de repositório deve implementar controlos de acesso em relação a todas as entidades do STI- C e partes externas a pelo menos três níveis diferentes (por exemplo, público, restrito a entidades de STI-C, nível da CA de raiz), para evitar que entidades não autorizadas adicionem, alterem ou excluam entradas do repositório. Os mecanismos exatos de controlo de acesso da entidade única devem fazer parte da respetiva CPS. Para cada CA de raiz, os repositórios da EA e da AA devem cumprir os mesmos requisitos para os procedimentos de controlo de acesso, independentemente do local ou do vínculo contratual com o prestador de serviços que opera o repositório. Como ponto de partida para os níveis de controlo de acesso, cada CA de raiz ou operador de repositório deve fornecer pelo menos três níveis diferentes (por exemplo, público, restrito a entidades de STI-C, nível da CA de raiz). PT 23 PT

25 2.5. Publicação de informações de certificados Publicação de informações de certificados pelo TLM (33) O TLM no domínio de confiança comum europeu de STI-C deve publicar as seguintes informações através do CPOC: todos os certificados de TLM atualmente válidos para o próximo período de operação (certificado atual e de ligação, se disponíveis); informações de ponto de acesso para o repositório do CPOC para fornecer a lista assinada da CA de raiz (ECTL); ponto de informação geral para a implantação da ECTL e do STI-C Publicação de informações de certificados pelas CA (34) As CA de raiz no domínio de confiança comum europeu de STI-C devem publicar as seguintes informações: certificados de CA de raiz emitidos (válidos à data) (certificados atuais e com correta reemissão de chave, incluindo um certificado de ligação) no repositório referido na secção 2.3; todas as entidades de EA, AA válidas, com a respetiva identificação de operador e período planeado de operação; certificados da CA emitidos nos repositórios referidos na secção 2.3; as CRL de todos os certificados de CA revogados que cobrem as respetivas EA e AA subordinadas; informações relativas ao ponto de acesso da CA de raiz às informações da CRL e da CA. Todas as informações do certificado devem ser categorizadas de acordo com três níveis de confidencialidade e os documentos para o público em geral devem estar publicamente disponíveis sem restrições. 3. IDENTIFICAÇÃO E AUTENTICAÇÃO 3.1. Nomenclatura Tipos de nomes Nomes para TLM, CA de raiz, EA e AA (35) O nome no certificado TLM deve consistir num único atributo nome_sujeito com o valor reservado EU_TLM». (36) O nome das CA de raiz deve consistir num único atributo nome_sujeito com um valor atribuído pela CPA. A exclusividade dos nomes é da inteira responsabilidade da CPA e o TLM deve manter o registo dos nomes da CA de raiz mediante notificação pela CPA (aprovação, revogação/retirada de uma CA de raiz). Os nomes de sujeitos nos certificados têm um limite de 32 bytes. Cada CA de raiz propõe o seu nome à CPA no formulário do pedido (fluxo 14). A CPA é responsável por verificar a exclusividade do nome. Se o nome não for exclusivo, o formulário de pedido será rejeitado (fluxo 4). PT 24 PT

26 (37) O nome em cada certificado de EA/AA pode consistir num único atributo nome_sujeito com um valor gerado pelo emissor do certificado. A exclusividade dos nomes é da inteira responsabilidade da CA de raiz emissora. (38) Os certificados de EA e AA não devem utilizar um nome que exceda 32 bytes, porque o nome_sujeito em certificados tem um limite de 32 bytes. (39) Os CA não devem conter um nome Nomes para as entidades finais (40) Cada estação de STI-C deve receber dois tipos de identificador único: Identificação de certificados uma identificação canónica que é armazenada no registo inicial da estação de STI-C sob a responsabilidade do fabricante. Deve conter uma subsequência que identifique o fabricante ou operador, para que este identificador possa ser único; um sujeito_nome, que pode fazer parte da EC da estação de STI-C, sob a responsabilidade da EA. (41) Os certificados que seguem o formato da norma [5] devem ser identificados através do cálculo de um valor de HashedId8 conforme definido na norma [5] Necessidade de os nomes serem significativos Não estipulado Anonimato e pseudonímia das entidades finais (42) A AA deve assegurar que a pseudonímia de uma estação de STI-C é estabelecida fornecendo à estação de STI-C certificados de autorização que não contenham nomes ou informações que possam vincular o sujeito à sua identidade real Regras de interpretação das diversas formas de nomes Não estipulado Exclusividade dos nomes (43) Os nomes para o TLM, as CA de raiz, as EA, as AA e as identificações canónicas para estações de STI-C devem ser únicos. (44) O TLM deve garantir, no processo de registo de uma determinada CA de raiz na ECTL, que o seu identificador de certificado (HashedId8) é único. A CA de raiz deve garantir, no processo de emissão, que o identificador de certificado (HashedId8) de cada CA subordinada é único. (45) O HashedId8 de uma EC deve ser único dentro da CA emissora. O HashedId8 de um CA não necessita de ser único Validação inicial de identidade Método para demonstrar posse de chave privada (46) A CA de raiz deve comprovar que detém legitimamente a chave privada correspondente à chave pública no certificado autoassinado. O CPOC deve verificar esse elemento de prova. PT 25 PT