Source: http://docplayer.com.br/2893880-Politica-de-certificados-da-scee.html
Timestamp: 2016-10-26 09:32:18+00:00
Document Index: 44044797

Matched Legal Cases: ['artigo 7', 'Artigo 1', 'Artigo 5', 'Artigo 2', 'Artigo 6', 'ARTIGO 29', 'ARTIGO 29']

⭐POLÍTICA DE CERTIFICADOS DA SCEE
Download "POLÍTICA DE CERTIFICADOS DA SCEE"
Rosângela Custódio de Barros
1 POLÍTICA DE CERTIFICADOS DA SCEE e Requisitos mínimos de Segurança Versão 1.0, de 14 de Julho de 2006 OID:2 ÍNDICE 1. INTRODUÇÃO Enquadramento Âmbito Estrutura do documento Hierarquia de OiD da SCEE Identificação do documento Participantes na Infra-estrutura de Chaves Públicas Entidades Certificadoras (EC) Entidades de Registo (ER) Titulares de Certificados Partes confiantes Outros participantes Utilização do certificado Utilização adequada Utilização não autorizada Gestão das políticas Entidade responsável pela Gestão do documento Contacto Entidade que determina a conformidade da Declaração de Práticas de Certificação (DPC) para a Política Procedimentos para aprovação da DPC Definições e acrónimos RESPONSABILIDADE DE PUBLICAÇÃO E REPOSITÓRIO Repositórios Publicação de informação de certificação Periodicidade de publicação Controlo de acesso aos repositórios IDENTIFICAÇÃO E AUTENTICAÇÃO Atribuição de nomes Tipo de nomes Necessidade de nomes significativos Anonimato ou pseudónimo de titulares Interpretação de formato de nomes Unicidade de nomes Reconhecimento, autenticação e funções das marcas registadas...253 3.2. Validação de identidade no registo inicial Método de comprovação da posse de chave privada Autenticação da identidade de uma pessoa colectiva Autenticação da identidade de uma pessoa singular Informação de subscritor/titular não verificada Critérios para interoperabilidade Identificação e autenticação para pedidos de renovação de chaves Identificação e autenticação para renovação de chaves, de rotina Identificação e autenticação para renovação de chaves, após revogação Identificação e autenticação para pedido de revogação REQUISITOS OPERACIONAIS DO CICLO DE VIDA DO CERTIFICADO Pedido de certificado Quem pode subscrever um pedido de certificado Processo de registo e responsabilidades Processamento do pedido de certificado Processos para a identificação e funções de autenticação Aprovação ou recusa de pedidos de certificado Prazo para processar o pedido de certificado Emissão de certificado Procedimentos para a emissão de certificado Notificação da emissão do certificado ao titular Aceitação do certificado Procedimentos para a aceitação de certificado Publicação do certificado Notificação da emissão de certificado a outras entidades Uso do certificado e par de chaves Uso do certificado e da chave privada pelo titular Uso do certificado e da chave pública pelas partes confiantes Renovação de certificados Motivos para renovação de certificado Quem pode submeter o pedido de renovação de certificado Processamento do pedido de renovação de certificado Notificação de emissão de novo certificado ao titular Procedimentos para aceitação de certificado Publicação de certificado após renovação Notificação da emissão do certificado a outras entidades Renovação de certificado com geração de novo par de chaves...35 Página 3 de 1204 Motivos para a renovação de certificado com geração de novo par de chaves Quem pode submeter o pedido de certificação de uma nova chave pública Processamento do pedido de renovação de certificado com geração de novo par de chaves Notificação da emissão de novo certificado ao titular Procedimentos para aceitação de um certificado renovado com geração de novo par de chaves Publicação de novo certificado renovado com geração de novo par de chaves Notificação da emissão de novo certificado a outras entidades Modificação de certificados Motivos para alteração de certificado Quem pode submeter o pedido de alteração de certificado Processamento do pedido de alteração de certificado Notificação da emissão de certificado alterado ao titular Procedimentos para aceitação de certificado alterado Publicação do certificado alterado Notificação da emissão de certificado alterado a outras entidades Suspensão e revogação de certificado Motivos para a revogação Quem pode submeter o pedido de revogação Procedimento para o pedido de revogação Produção de efeitos da revogação Prazo para processar o pedido de revogação Requisitos de verificação da revogação pelas parte confiantes Periodicidade da emissão da Lista de Certificados Revogados (LCR) Período máximo entre a emissão e a publicação da CRL Disponibilidade de verificação on-line do estado / revogação de certificado Requisitos de verificação on-line de revogação Outras formas disponíveis para divulgação de revogação Requisitos especiais em caso de comprometimento de chave privada Motivos para suspensão Quem pode submeter o pedido de suspensão Procedimentos para pedido de suspensão Limite do período de suspensão Serviços sobre o estado do certificado Características operacionais...40 Página 4 de 1205 Disponibilidade de serviço Características opcionais Fim de subscrição Retenção e recuperação de chaves (key escrow) Políticas e práticas de recuperação de chaves Políticas e práticas de encapsulamento e recuperação de chaves de sessão MEDIDAS DE SEGURANÇA FÍSICA, DE GESTÃO E OPERACIONAIS Medidas de segurança física Localização física e tipo de construção Acesso físico ao local Energia e ar condicionado Exposição à água Prevenção e protecção contra incêndio Salvaguarda de suportes de armazenamento Eliminação de resíduos Instalações externas (alternativa) para recuperação de segurança Medidas de segurança dos processos Funções de confiança Número de pessoas exigidas por tarefa Identificação e autenticação para cada função Funções que requerem separação de responsabilidades Medidas de segurança de pessoal Requisitos relativos às qualificações, experiência, antecedentes e credenciação Procedimentos de verificação de antecedentes Requisitos de formação e treino Frequência e requisitos para acções de reciclagem Frequência e sequência da rotação de funções Sanções para acções não autorizadas Contratação de pessoal Documentação fornecida ao pessoal Procedimentos de auditoria de segurança Tipo de eventos registados Frequência da auditoria de registos Período de retenção dos registos de auditoria Protecção dos registos de auditoria Procedimentos para a cópia de segurança dos registos Sistema de recolha de dados de auditoria (interno/externo)...50 Página 5 de 1206 Notificação de agentes causadores de eventos Avaliação de vulnerabilidades Arquivo de registos Tipo de dados arquivados Período de retenção em arquivo Protecção dos arquivos Procedimentos para as cópias de segurança do arquivo Requisitos para validação cronológica dos registos Sistema de recolha de dados de arquivo (interno/externo) Procedimentos de recuperação e verificação de informação arquivada Renovação de chaves Recuperação em caso de desastre ou comprometimento Procedimentos em caso de incidente ou comprometimento Corrupção dos recursos informáticos, do software e/ou dos dados Procedimentos em caso de comprometimento da chave privada da entidade Capacidade de continuidade da actividade em caso de desastre Procedimentos em caso de extinção de EC ou ER MEDIDAS DE SEGURANÇA TÉCNICAS Geração e instalação do par de chaves Geração do par de chaves Entrega da chave privada ao titular Entrega da chave pública ao emissor do certificado Entrega da chave pública da EC às partes confiantes Dimensão das chaves Geração dos parâmetros da chave pública e verificação da qualidade Fins a que se destinam as chaves (campo key usage X.509v3) Outra utilização para as chaves Protecção da chave privada e características do módulo criptográfico Normas e medidas de segurança do módulo criptográfico Controlo multi-pessoal (N de M) para a chave privada Retenção da chave privada (key escrow) Cópia de segurança da chave privada Arquivo da chave privada Transferência da chave privada para/do módulo criptográfico Armazenamento da chave privada no módulo criptográfico Processo para activação da chave privada Processo para desactivação da chave privada...60 Página 6 de 1207 Processo para destruição da chave privada Avaliação/nível do módulo criptográfico Outros aspectos da gestão do par de chaves Arquivo da chave pública Períodos de validade do certificado e das chaves Dados de activação Geração e instalação dos dados de activação Protecção dos dados de activação Outros aspectos dos dados de activação Medidas de segurança informática Requisitos técnicos específicos Avaliação/nível de segurança Ciclo de vida das medidas técnicas de segurança Medidas de desenvolvimento do sistema Medidas para a gestão da segurança Ciclo de vida das medidas de segurança Medidas de segurança da rede Validação cronológica (Time-stamping) PERFIS DE CERTIFICADO, CRL E OCSP Perfil do certificado Número(s) de versão Extensões do certificado Identificadores de algoritmo Formatos de nome Restrições de nome Objecto identificador da política de certificado Utilização da extensão de restrição de políticas Sintaxe e semântica dos qualificadores de políticas Semântica de processamento da extensão de política de certificados críticos Perfil da LCR Número(s) da versão Extensões da CRL e das suas entradas Perfil do OCSP Número(s) da versão Extensões do OCSP AUDITORIA E AVALIAÇÕES DE CONFORMIDADE Frequência ou motivo da auditoria...73 Página 7 de 1208 8.2. Identidade e qualificações do auditor Relação entre o auditor e a entidade certificadora Âmbito da auditoria Procedimentos após uma auditoria com resultado deficiente Comunicação de resultados OUTRAS SITUAÇÕES E ASSUNTOS LEGAIS Taxas Taxas por emissão ou renovação de certificados Taxas para acesso a certificado Taxas para acesso a informação do estado certificado ou de revogação Taxas para outros serviços Política de reembolso Responsabilidade financeira Seguro de cobertura Outros recursos Seguro ou garantia de cobertura para utilizadores Confidencialidade da informação processada Âmbito da confidencialidade da informação Informação fora do âmbito da confidencialidade da informação Responsabilidade de protecção da confidencialidade da informação Privacidade dos dados pessoais Medidas para garantia da privacidade Informação privada Informação não protegida pela privacidade Responsabilidade de protecção da informação privada Notificação e consentimento para utilização de informação privada Divulgação resultante de processo judicial ou administrativo Outras circunstâncias para revelação de informação Direitos de propriedade intelectual Representações e garantias Representação e garantias das Entidades Certificadoras Representação e garantias das Entidades de Registo Representação e garantias dos titulares Representação e garantias das partes confiantes Representação e garantias de outros participantes Renuncia de garantias Limitações às obrigações...83 Página 8 de 1209 9.9. Indemnizações Termo e cessação da actividade Termo Substituição e revogação da PC Consequências da cessação da actividade Notificação individual e comunicação aos participantes Alterações Procedimento para alterações Prazo e mecanismo de notificação Motivos para mudar de OID Disposições para resolução de conflitos Legislação aplicável Conformidade com a legislação em vigor Providências várias Acordo completo Independência Severidade Execuções (taxas de advogados e desistência de direitos) Força maior Outras providências...87 A. Anexo - PERFIL DOS CERTIFICADOS...88 A.1. Perfil de Certificado de ECRaizEstado...88 A.2. Perfil de Certificado de ECEstado...90 A.3. Perfil de Certificado de Assinatura Digital...92 A.4. Perfil de Certificado de Autenticação...94 A.5. Perfil de Certificado de Confidencialidade...96 B. Anexo PERFIL DAS LCR...98 C. Anexo NORMALIZAÇÃO TÉCNICA...99 D. Anexo DEFINIÇÕES E ACRÓNIMOS D.1. Acrónimos D.2. Definições E. Anexo Hierarquia de OID da SCEE Página 9 de 12010 ÍNDICE DE TABELAS Tabela 1 - Hierarquia superior de OID...12 Tabela 2 Dados relativos à Politica de certificados da SCEE...13 Tabela 3 - Dados dos certificados da ECRaizEstado...14 Tabela 4 Perfis de certificados suportados pela SCEE...18 Tabela 5 Dados para contacto...20 Tabela 6 Prazos mínimos para renovação da informação pelas diversas entidades...22 Tabela 7 Regras para o preenchimento do DN...24 Tabela 8 Incompatibilidade entre funções...46 Tabela 9 Credenciação de segurança...47 Tabela 10 Procedimentos em caso de comprometimento de chaves...53 Tabela 11 Definição dos campos Keyusage dos Certificados SCEE...57 Tabela 12 Definição dos Períodos de Validade dos Certificados...62 Tabela 13 Campos básicos do certificado...67 Tabela 14 Identificadores OiD de Algoritmos...68 Tabela 15 Campos básicos do certificado...70 Tabela 16 Prazos de comunicação dos resultados de Auditoria...7511 1. INTRODUÇÃO 1.1. ENQUADRAMENTO ÂMBITO Decorrente da implementação em curso de vários programas públicos para a promoção das tecnologias de informação e comunicação e a introdução de novos processos de relacionamento em sociedade, entre cidadãos, empresas, organizações não governamentais e o Estado, com vista ao fortalecimento da sociedade de informação e do governo electrónico (egovernment), foi aprovado através da Resolução do Conselho de Ministros n.º 171/2005, publicada em D.R. em 3 de Novembro de 2005, a criação da Sistema de Certificação Electrónica do Estado (SCEE) Infra-estrutura de Chaves Públicas. Esses programas envolvem, para certos fins específicos, mecanismos de autenticação digital forte de identidades e assinaturas electrónicas que podem ser concretizados mediante a utilização das denominadas infra-estruturas de chaves públicas. São exemplos de projectos programados ou em curso no âmbito da sociedade da informação e do governo electrónico os relativos ao cartão do cidadão, ao passaporte electrónico português, à certificação electrónica do Governo e à disponibilização de serviços da Administração Pública pela Internet que requeiram autenticação digital forte de identidades e assinaturas electrónicas e à desmaterialização dos processos intra e interorganismos do Estado que requeiram esse tipo de autenticação. A arquitectura do SCEE constituirá assim uma hierarquia de confiança, que promoverá a segurança electrónica do Estado. Para o efeito a SCEE compreenderá um Conselho Gestor que dá parecer sobre a aprovação e integração de entidades certificadoras no SCEE pronunciando-se igualmente sobre práticas e políticas de certificação, uma Entidade Certificadora Electrónica Raiz, que constitui o primeiro nível da cadeia hierárquica de certificação, e as várias Entidades Certificadoras do Estado a esta subordinadas. Esta entidade deve funcionar independentemente de outras infra-estruturas de chaves públicas de natureza privada ou estrangeira, mas deve permitir a interoperabilidade com as infra-estruturas que satisfaçam os requisitos necessários de rigor de autenticação, através dos mecanismos técnicos adequados, e da compatibilidade em termos de políticas de certificação, nomeadamente no âmbito dos países da União Europeia (UE). Assim, é criada a Sistema de Certificação Electrónica do Estado Português Infra-Estrutura de Chaves Públicas, adiante designada como SCEE, que opera para os organismos e funcionários da Administração Pública bem como para as pessoas singulares e colectivas no seu relacionamento com o Estado. A SCEE estabelece uma estrutura de confiança electrónica, de forma a que os serviços disponibilizados pelas entidades certificadoras que a compõem, proporcionem nomeadamente a realização de transacções electrónicas seguras, a autenticação forte, um meio de assinar electronicamente transacções ou informações e documentos electrónicos, assegurando a sua autoria, integridade e não repúdio, e assegurando a confidencialidade das transacções ou informação ESTRUTURA DO DOCUMENTO Assume-se que o leitor é conhecedor dos conceitos de criptografia, infra-estruturas de chave pública e assinatura electrónica. Caso esta situação não se verifique recomenda-se o12 aprofundar de conceitos e conhecimento nos tópicos anteriormente focado antes de proceder com a leitura do documento. Este documento segue a estrutura definida e proposta pelo grupo de trabalho PKIX do IETF, no documento RFC De forma a facilitar a leitura e consequente análise deste documentos com as práticas difundidas e recomendadas internacionalmente, optou-se por incluir todas a secções estabelecidas no índice do documento supracitado, pelo que se não houver nada designado sobre o assunto, será incluída a expressão nada a assinalar. Ainda de acordo com este pressuposto foi tido em consideração as especificações e recomendações definidas nos vários documentos emanados pelo PKIX Working Group, União Europeia e pela legislação nacional aplicável HIERARQUIA DE OID DA SCEE Os OID são identificadores utilizados para referenciar objectos de forma inequívoca num determinado contexto, neste caso, a SCEE, funcionando por hierarquias. Neste particular a união ISO-ITU-T é a responsável pela atribuição de OID para os países. A SCEE tem referenciado, mas não atribuído oficialmente, o OID = , com base na seguinte referência superior: 1 Estado Português 620 Portugal 16 Country assignments 2 ISO/ITU-T jointly assigned OIDs Tabela 1 - Hierarquia superior de OID Distribuição da arvore {id-scee} No âmbito da infra-estrutura de chave pública da SCEE, a distribuição dos OID, tendo em consideração a necessidade de atribuição de identificadores aos objectos digitais de toda a infra-estrutura (documentos, extensões e perfis de certificados, e outras extensões do protocolo PKIX), será feita tendo em conta a hierarquia global definida no Anexo X IDENTIFICAÇÃO DO DOCUMENTO Em virtude dos vários projectos em curso e tendo conta a diversidade e especificidade de cada um dos mesmos, as várias politicas de certificados são identificadas por um OiD, que Página 12 de 12013 traduz a sua aplicabilidade na atribuição de certificados digitais por cada uma das Entidade Certificadoras do Estado. Os diversos OiD, estão de acordo com as especificações definidas na Estrutura de OID da SCEE, descrita anteriormente Este documento de Politica de Certificação é identificado pelos dados constantes na seguinte tabela: INFORMAÇÃO DO DOCUMENTO Versão do Documento Versão 0.1 Estado do Documento Em aprovação OID Data de Emissão 21 de Abril de 2006 Válidade Não aplicável Localização Tabela 2 Dados relativos à Politica de certificados da SCEE 1.3. PARTICIPANTES NA INFRA-ESTRUTURA DE CHAVES PÚBLICAS ENTIDADES CERTIFICADORAS (EC) São entidades que, após devida autorização da Entidade de Certificação Electrónica do Estado (ECEE), estão habilitadas para criar, assinar, atribuir e gerir certificados. Na prática uma EC é composta pelo conjunto de equipamentos, aplicações, pessoal e procedimentos que são indispensáveis para implementar os diversos serviços de certificação disponibilizados e garantir a adequada gestão do ciclo de vida dos certificados descritos neste documento. A hierarquia de confiança do SCEE compreende a Entidade Certificadora Raiz do Estado (ECRaizEstado), as Entidades Certificadoras do Estado (ECEstado) e Entidades Certificadoras Subordinadas (subecestado). As Entidades Certificadoras que compõem a SCEE são: A Entidade Certificadora Raiz do Estado A Entidade Certificadora Raiz do Estado (ECEE) é a entidade certificadora de topo da cadeia de certificação da SCEE, executora das políticas de certificados e directrizes aprovadas pelo Conselho Gestor do SCEE. Compete a esta prestar os serviços de certificação às Entidades Certificadoras do Estado no nível hierárquico imediatamente inferior ao seu na cadeia de certificação em conformidade com as normas aplicáveis às entidades certificadoras estabelecidas em Portugal na emissão de certificados digitais qualificados. Página 13 de 12014 Os serviços de certificação digital disponibilizados pela Entidade de Certificação Raiz do Estado englobam exclusivamente: o processo de registo das entidades certificadoras, geração de certificados e gestão do seu ciclo de vida, disseminação dos certificados, das politicas e das praticas de certificação, a gestão de revogações e disponibilização do estado/situação das mesmas. A definição do detalhe, composição e funcionamento estão definidos em documentação e legislação própria. O quadro seguinte apresenta os dados mais relevantes relativos aos certificados da ECRaizEstado, sendo de destacar a adopção emissão de dois certificados (pkcs1- sha1withrsaencryption 1 e Certificado pkcs1-sha256withrsaencryption) para o mesmo par de chaves. DN CN= ECRAIZESTADO; O=SCEE; C=PT Certificado pkcs1-sha1withrsaencryption Número de série Período de validade Impressão digital Certificado pkcs1-sha256withrsaencryption Número de série Período de validade Impressão digital Tabela 3 - Dados dos certificados da ECRaizEstado A ECRaizEstado, é a Entidade Certificadora de primeiro nível. A sua função é estabelecer a raiz da cadeia de confiança da infra-estrutura de chaves públicas (PKI). Esta EC não emite certificados para utilizadores finais, emitindo apenas certificados para assinar as Entidades Certificadoras do Estado. A ECRaizEstado assina-se a si própria Entidades Certificadoras do Estado (ECEstado) As ECEstado, são entidades que se encontram no nível imediatamente abaixo da ECRaizEstado, sendo a sua função principal providenciar a gestão de serviços de certificação: emissão, operação, suspensão, revogação para os seus subscritores. O seu certificado é assinado pela ECRaizEstado. 1 O certificado pkcs1-sha1withrsaencryption é apenas publicado para efeitos de garantia de interoperabilidade, de modo a permitir que os sistemas e aplicações que não suportem o algoritmo pkcs1-sha256withrsaencryption, estejam habilitados para construir o caminho de certificação para validação de certificados e assinatura. Página 14 de 12015 Entidades Certificadoras Subordinadas (subecestado) As subecestado, são entidades que se encontram no nível imediatamente abaixo das EC, tendo como função a prestação de serviços de certificação para o utilizador final. O seu certificado é assinado pela respectiva ECEstado ENTIDADES DE REGISTO (ER) São entidades que por via do estabelecimento de um acordo com uma Entidade Certificadora do Estado, estas delegam a prestação de serviços de identificação e registo de utilizadores, bem como a gestão de pedidos de revogação de certificados. As Entidades de Registo desenvolvem a sua actividade de acordo com o estabelecido na DPC da respectiva EC e pelo Conselho Gestor do SCEE TITULARES DE CERTIFICADOS Titulares No contexto deste documento o termo subscritor/titular aplica-se a todos os utilizadores finais a quem tenham sido atribuídos certificados por uma ECEstado ou subecestado. No âmbito do SCEE são considerados como titulares, aqueles em que o nome está inscrito no campo Subject do certificado e utilizam o certificado e respectiva chave privada de acordo com o estabelecido nas diversas politicas de certificado descritas neste documento, sendo consideradas as seguintes categorias titulares: a) Pessoa singular; b) Pessoa colectiva; c) Equipamentos tecnológicos. Não são considerados titulares, no âmbito deste documento, as seguintes categorias: a) Entidade Certificadoras, independentemente do nível a que se encontram; b) Entidades de Registo; c) O pessoal das Entidades Certificadoras e Entidades de Registo cujos certificados tem como uso exclusivo a operação dos respectivos sistemas Patrocinador A emissão de certificados para equipamentos tecnológicos (p.e: computadores, firewall, routers, servidores, etc.) deve ser efectuada sempre sob responsabilidade humana, sendo esta entidade designada por patrocinador. O patrocinador aceita o certificado e é responsável pela sua correcta utilização, bem como pela protecção e salvaguarda da sua chave privada. Página 15 de 12016 PARTES CONFIANTES As partes confiantes ou destinatários são pessoas singulares, entidades ou equipamentos que confiam na validade dos mecanismos e procedimentos utilizados no processo de associação do nome do titular com a sua chave pública, ou seja que o certificado corresponde na realidade a quem diz pertencer. Na prática, considera-se uma parte confiante, aquela que confia no teor, validade e aplicabilidade do certificado, podendo ser titular de certificados da comunidade SCEE ou não OUTROS PARTICIPANTES O Conselho Gestor do Sistema de Certificação Electrónico do Estado O Conselho Gestor do SCEE é a entidade a quem cabe pronunciar-se sobre as políticas e práticas de certificação das entidades certificadoras que integram a SCEE. Compete especialmente ao Conselho Gestor do SCEE: a) Definir, de acordo com a lei e tendo em conta as normas ou especificações internacionalmente reconhecidas, a política de certificação e as práticas de certificação a observar pelas entidades certificadoras que integram o SCEE; b) Garantir que as declarações de práticas de certificação das várias entidades certificadoras do Estado, bem como da entidade certificadora raiz do Estado, estão em conformidade com a política de certificação do SCEE; c) Propor os critérios para aprovação das entidades certificadoras que pretendam integrar o SCEE; d) Aferir a conformidade dos procedimentos seguidos pelas entidades certificadoras do Estado com as políticas e práticas aprovadas, sem prejuízo das competências legalmente cometidas à autoridade credenciadora; e) Pronunciar-se pela exclusão do SCEE das entidades certificadoras do Estado em caso de não conformidade com as políticas e práticas aprovadas, comunicando tal facto à autoridade credenciadora; f) Pronunciar-se sobre as melhores práticas internacionais no exercício das actividades de certificação electrónica e propor a sua aplicação; g) Representar institucionalmente o SCEE; Compete, ainda, ao Conselho Gestor do SCEE a promoção das actividades necessárias para o estabelecimento de acordos de interoperabilidade, com base em certificação Página 16 de 12017 cruzada, com outras infra-estruturas de chaves públicas, de natureza privada ou pública, nacionais ou internacionais, nomeadamente: a) Dar indicações à entidade certificadora raiz do Estado para a atribuição e a revogação de certificados emitidos com base em certificação cruzada; b) Definir os termos e condições para o início, a suspensão ou a finalização dos procedimentos de interoperabilidade com outras infra-estruturas de chaves públicas A definição do detalhe, composição e funcionamento estão definidos em documentação e legislação própria Autoridade Credenciadora De uma forma geral o papel da Autoridade Credenciadora, no domínio da SCEE, está relacionado com a disponibilização de serviços de auditoria/inspecção de conformidade, no sentido de aferir se os processos utilizados pelas EC nas suas actividades de certificação, estão conformes, de acordo com os requisitos mínimos estabelecidos neste documento e com o estabelecido na DPC da respectiva entidade. Assim, consideram-se como principais atribuições as seguintes: a) a condução de auditorias; b) a gestão do controlo de qualidade de todo o processo de certificação; c) a fixação da procedimentos e documentação relativa às auditorias; d) Gestão dos relatórios de auditoria, nomeadamente, na elaboração e recepção (quando efectuados por pessoal externo); e) a fixação de planos de medidas correctivas aplicáveis às entidades certificadoras da SCEE; f) a fixação e acompanhamento de metas para indicadores de qualidade que deverá propor para aprovação do Conselho Gestor do SCEE no contexto de objectivos estratégicos previamente fixados pelo Conselho Gestor do SCEE; g) a gestão da bolsa de auditores; h) a apresentação à ECEE de proposta de registo e de rescisão de registo de entidades certificadoras na SCEE; i) a promoção da competência técnica dos auditores Autoridades de Validação As Autoridades de Validação (AV), tem como função comprovar o estado dos certificados emitidos, através da utilização do protocolo Online Certificate Status Protocol (OCSP), de Página 17 de 12018 forma a determinar o estado actual do certificado a pedido de uma entidade sem necessidade de recorrer à verificação do estado através da consulta das LCR UTILIZAÇÃO DO CERTIFICADO Os certificados emitidos no domínio do SCEE são utilizados, pelos diversos os sistemas, aplicações, mecanismos e protocolos, com o objectivo de garantir os seguintes serviços de segurança: a) Controlo de acessos; b) Confidencialidade; c) Integridade; d) Autenticação; e e) não-repúdio. Estes serviços são obtidos com recurso à utilização de criptografia de chave pública, através da sua utilização na estrutura de confiança que a SCEE proporciona. Assim, os serviços de identificação e autenticação, integridade e não-repúdio são obtidos mediante a utilização de assinaturas digitais. A confidencialidade é garantida através dos recursos a algoritmos de cifra, quando conjugados com mecanismos de estabelecimento e distribuição de chaves. Esta política engloba tipos e perfis de certificados, descritos sumariamente no quadro seguinte: TIPO DE UTILIZAÇÃO IDENTIFICADOR OID DESCRIÇÃO Assinatura de Certificados e LCR anypolicy Assinatura electrónica scee-assinatura Autenticação scee-autenticacao ver Anexo A Confidencialidade scee-confidencialidade Tabela 4 Perfis de certificados suportados pela SCEE UTILIZAÇÃO ADEQUADA Os requisitos e regras definidos neste documento, aplicam-se a todos os certificados emitidos pelas ECEstado e subecestado que forem constituídas como parte integrante do domínio da SCEE. Os certificados atribuídos a pessoas, singulares e colectivas, têm como objectivo a sua utilização em qualquer aplicação para efeitos de Assinatura digital, autenticação de cliente e encriptação. Os certificados emitidos para equipamentos tecnológicos, têm como objectivo a sua utilização em serviços de autenticação e no estabelecimento de canais cifrados. Página 18 de 12019 Os certificados emitidos para efeitos de utilização por serviços de confidencialidade, emitidos com base nas regras aqui definidas, podem ser utilizados para processar informação classificada até o grau de RESERVADO quando utilizados sobre redes públicas (p.e. Internet). Na sua utilização em redes proprietárias, o grau de classificação da informação deverá ser definido pelo organismo nacional com responsabilidades no âmbito do tratamento da informação/matéria classificada. Os certificados emitidos pela SCEE devem ser utilizados de acordo com a função e finalidade estabelecida nas Declaração de Práticas de Certificação e nas correspondentes Políticas de Certificados e de acordo com a lei em vigor UTILIZAÇÃO NÃO AUTORIZADA Os certificados emitidos para os titulares não podem ser utilizados para desempenhar actividades como certificados de EC nem ER, consequentemente, não podem ser utilizados para assinar certificados nem LCR. Os serviços de certificação que oferecidos pela SCEE, não foram desenhados nem estão autorizados a ser utilizados em actividades de alto risco ou que requeiram um actividade isenta de falhas, como as relacionadas com o funcionamento de instalações hospitalares, nucleares, controlo de tráfego aéreo, controlo de tráfego ferroviário, ou qualquer outra actividade onde uma falha possa levar à morte, lesões pessoais ou danos graves para o meio ambiente GESTÃO DAS POLÍTICAS ENTIDADE RESPONSÁVEL PELA GESTÃO DO DOCUMENTO A gestão desta política de certificados é da responsabilidade do Conselho Gestor CONTACTO Nas DPC, devem ser incluídos, no mínimo, o nome, o endereço, o número de telefone, o número de fax e o endereço de correio electrónico. A informação de contacto para este documento é a seguinte: NOME CONSELHO GESTOR DO SCEE Morada: Rua Professor Gomes Teixeira Lisboa Correio electrónico: Página Internet: Página 19 de 12020 Telefone Fax: Tabela 5 Dados para contacto ENTIDADE QUE DETERMINA A CONFORMIDADE DA DECLARAÇÃO DE PRÁTICAS DE CERTIFICAÇÃO (DPC) PARA A POLÍTICA O Conselho Gestor do SCEE é o órgão competente para determinar a adequação das DPC das diversas entidades, com a Política de Certificados definida neste documento PROCEDIMENTOS PARA APROVAÇÃO DA DPC O Conselho Gestor do SCEE é a entidade responsável pela aprovação da presente PC e das PC e DPC associadas, bem como por garantir que as declarações de práticas de certificação das várias entidades certificadoras do Estado, bem como da entidade certificadora raiz do Estado, estão em conformidade com a política de certificação do SCEE DEFINIÇÕES E ACRÓNIMOS Ver Anexo D. Página 20 de 12021 2. RESPONSABILIDADE DE PUBLICAÇÃO E REPOSITÓRIO 2.1. REPOSITÓRIOS Um repositório é o conjunto de equipamentos (hardware e software), pessoas e procedimentos, construído com o objectivo de publicar, entre outras, informação relativa às práticas adoptadas e o estado dos certificados. Neste ponto as entidades responsáveis pelas diversas DPC devem descriminar, no mínimo: a) Níveis de disponibilidade; b) os protocolos de acesso; c) mecanismos de segurança implementados PUBLICAÇÃO DE INFORMAÇÃO DE CERTIFICAÇÃO Todos os repositórios no domínio da SCEE, deverão disponibilizar, no mínimo, a seguinte informação: a) Uma cópia electrónica deste documento (PCert), assinado electronicamente, por indivíduo devidamente autorizado e com certificado digital atribuído para o efeito; b) Uma cópia electrónica da sua DPC, assinada electronicamente, por individuo devidamente autorizado e com certificado digital atribuído para o efeito; c) Listas de Certificados Revogados (LCR) d) Lista de Certificados de Entidades Certificadoras Revogadas (LER), quando aplicável; e) Documentação de suporte (exemplo: formulários para pedido de certificado, pedido de revogação, etc.), num formato amplamente acessível; f) As LCR; g) Qualquer outra informação relevante deverá ser de igual modo publicada. As entidades integradas no domínio do SCEE deverão conservar todas as versões anteriores das suas PC (caso exista) e DPC, disponibilizando-as a quem o solicite (desde que justificado), ficando, no entanto fora do repositório público de acesso livre. Os certificados para efeitos de confidencialidade serão os únicos certificados disponibilizados com acesso livre, no entanto, apenas e quando assim esteja estabelecido na respectiva DPC. Quando se trate dos repositórios das EC, e caso tenham sido criadas EC subordinadas ou ER, à informação referida anteriormente deve ser adicionada a mesma informação relacionada com as suas subordinadas. Este documento pode ser consultado em: Página 21 de 12022 2.3. PERIODICIDADE DE PUBLICAÇÃO A informação incluída nos repositórios deverá ser disponibilizada logo que haja informação actualizada. No que concerne às LCR, a sua publicação não deverá em caso algum exceder 24 horas desde a data da sua aprovação/criação até a sua publicação em repositório. Independentemente, de haver ou não informação actualizada, devem ser considerados como prazos mínimos para actualização da informação os seguintes: DOCUMENTO PRAZOS Politicas de certificados da SCEE DPC Anualmente Documentação de suporte Listas de certificados revogados ECRaizEstado ECEstado subecestado 2 meses 1 mês 1 semana Tabela 6 Prazos mínimos para renovação da informação pelas diversas entidades 2.4. CONTROLO DE ACESSO AOS REPOSITÓRIOS No acesso à informação contida nos repositórios deverá ser garantido que esta apenas é disponibilizada, apenas e só, em modo de leitura. Devem ser implementados mecanismos de segurança de forma a garantir que apenas pessoas autorizadas possam escrever ou modificar a informação contida nos repositórios. A actual política não estabelece nenhum tipo de restrição de acesso para consulta das CRL, e ultimas versões das DPC e Política de Certificados. Página 22 de 12023 3. IDENTIFICAÇÃO E AUTENTICAÇÃO 3.1. ATRIBUIÇÃO DE NOMES No domínio SCEE é permitida a atribuição e utilização de nomes Reais, Pseudónimos e equipamentos TIPO DE NOMES Todos os titulares de certificados requerem um nome único (DN - Distinguished Name) de acordo com o standard X.500. Os certificados atribuídos a cada entidade deverão conter no campo Subject, um DN, para utilização como identificador único de cada entidade, de acordo com o preconizado no RFC 3280, pelo que: a) Para os certificados emitidos a pessoas, o atributo descreve a organização a que o titular do certificado pertence; b) Nos certificados atribuídos a equipamentos, é inscrito o nome da organização responsável pela sua operação (patrocinador); c) O DN deverá ser sempre preenchido. O campo Subject deverá ser construído seguindo o descrito na tabela seguinte, sendo obrigatória a utilização dos seguintes atributos: ATRIBUTO CÓDIGO REGRAS PARA PREENCHIMENTO CountryName C OrganizationName O OrganizationUnitName OU CommonName CN Incluir o código PT. Este campo corresponde, regra geral, ao Ministério (ou equivalente) do titular do certificado. Neste campo deverá constar informação relativa ao organismo (ou equivalente) a que o titular do certificado pertence. É proibida a utilização de nicknames. Os equipamentos deverão ser identificados através do modelo e número de série. Se os equipamentos forem servidores, estes serão designados pelo FQDN (CN = FQDN.), sendo proibida a sua designação através do endereço IP. Nos certificados emitidos para pessoa colectiva, deverá ser incluído o nome da pessoa singular responsável pela sua utilização. Quando se trate de nomes reais, deverá corresponder Página 23 de 12024 com o nome que aparece identificado no documento de Identificação. Quando se trate de pseudónimos, o nome deverá ser antecedido da expressão Pseudo:. Tabela 7 Regras para o preenchimento do DN NECESSIDADE DE NOMES SIGNIFICATIVOS Os nomes utilizados dentro da cadeia de confiança do SCEE devem identificar de forma concreta e lógica a pessoa ou objecto a quem é atribuído um certificado digital. As EC e ER, devem garantir que a relação entre o titular e a organização a que pertencem é a mesma que consta no certificado e é facilmente perceptível e identificável pelos Humanos ANONIMATO OU PSEUDÓNIMO DE TITULARES Os titulares de certificados apenas podem optar pela utilização de pseudónimos. Neste caso o atributo CommonName do campo subject deverá começar pela identificação pela palavra pseudo:, seguida do pseudónimo do titular (CN = pseudo: qualquer cadeia de caracteres ). As entidades responsáveis pelo processo de registo podem recusar a aceitação de pseudónimos considerados ostensivos. Não é permitida a utilização de titulares com base no conceito de anonimato INTERPRETAÇÃO DE FORMATO DE NOMES As regras utilizadas pela SCEE para interpretar o formato dos nomes dos certificados que emite são as contidas na norma ISO Seguir o estabelecido no RFC 3280, para certificados emitidos a partir de 31 de Dezembro de 2003, todos os atributos DirectoryString dos campos issuer e subject do certificado, devem ser codificados numa UTF8String, com excepção dos atributos country e serialnumber, que devem estar codificados numa PrintableString UNICIDADE DE NOMES Os identificadores do tipo DN deverão ser únicos para cada titular de certificado, dentro de cada EC e não podem induzir a ambiguidades. Poderão ser utilizados caracteres adicionais ao nome original de cada entidade de forma a assegurar a unicidade do campo. As DPC deverão descrever de forma clara os critérios que utilizam para garantir a unicidade dos nomes. Página 24 de 12025 RECONHECIMENTO, AUTENTICAÇÃO E FUNÇÕES DAS MARCAS REGISTADAS As entidades requisitantes de certificados, devem demonstrar que têm direito à utilização do nome requisitado. Nas DPC devem estar explícitos os procedimentos utilizados para verificação do estipulado neste ponto VALIDAÇÃO DE IDENTIDADE NO REGISTO INICIAL Para os certificados emitidos no domínio da SCEE, é obrigatório que o registo inicial seja efectuado presencialmente, ou seja, a validação inicial da identidade do requerente é feita pelo método de cara-a-cara. Nas DPC deve ser descrito todos os passos necessários, desde o início do pedido de certificado até à atribuição do certificado digital ao futuro titular MÉTODO DE COMPROVAÇÃO DA POSSE DE CHAVE PRIVADA É considerado um mecanismo aceitável como método de comprovação da posse de chave privada a utilização do Certificate Management Protocol (CMP) definido no RFC Pode ser permitida a utilização de outros métodos desde que o Conselho Gestor do SCEE verifique que o método proposto é no mínimo tão seguro como o descrito anteriormente. Nas DPC deve estar descrito de forma clara o método utilizado para garantir a comprovação da posse de chave privada AUTENTICAÇÃO DA IDENTIDADE DE UMA PESSOA COLECTIVA O processo de autenticação da identidade de uma pessoa colectiva, deve obrigatoriamente garantir que a pessoa colectiva para quem vai ser emitido o certificado é quem na realidade diz ser e que a criação de assinatura, através de dispositivo de criação de assinatura, exige a intervenção de pessoas singulares que, estatutariamente, representam essa pessoa colectiva. Assim, as EC (ou as ER) devem guardar toda a documentação utilizada para verificação da identidade, garantindo a verificação da identidade dos seus representantes legais, por meio legalmente reconhecido, garantindo, no caso de o pedido ser subscrito para outrem, os poderes bastantes do requerente para a referida subscrição. Entre outras, considera-se como documentação mínima exigível, a documentação onde conste todos os dados necessários para a criação e emissão do certificado digital. Assim, quando requerido pela pessoa colectiva a constar como titular do certificado, é subscrito pelos seus representantes legais e contém, entre outros, os seguintes elementos: a) Denominação legal; b) Número de pessoa colectiva, sede, objecto social, nome dos titulares dos corpos sociais e de outras pessoas com poderes para a obrigarem e número de matrícula na Página 25 de 12026 conservatória do registo comercial; c) Nome completo, número do bilhete de identidade ou qualquer outro elemento que permita a identificação inequívoca das pessoas singulares que estatutária ou legalmente a representam; d) Endereço e outras formas de contacto; e) Indicação quanto ao uso do certificado ser ou não restrito a determinados tipos de utilização, bem como eventuais limites do valor das transacções para as quais o certificado é válido; f) Eventual referência a uma qualidade específica, em função da utilização a que o certificado estiver destinado; g) Outras informações relativas a poderes de representação, à qualificação profissional ou a outros atributos. Quando requerido por outrem que não o titular do certificado, o mesmo, para além dos elementos referidos no número anterior, contém, consoante seja requerido por pessoa singular ou colectiva, os seguintes elementos referentes ao requerente: a) Nome ou denominação legal; b) Número do bilhete de identidade, data e entidade emitente, ou qualquer outro elemento que permita a identificação inequívoca, ou número de pessoa colectiva; c) Residência ou sede; d) Objecto social, nome dos titulares dos corpos sociais e de outras pessoas com poderes para a obrigarem e número de matrícula na conservatória do registo comercial; e) Endereço e outras formas de contacto; f) Declaração da pessoa singular a constar como titular do certificado de que se obriga ao cumprimento das obrigações enquanto titular. Nas DPC deve constar um exemplar do documento que serve de base ao registo do requerente AUTENTICAÇÃO DA IDENTIDADE DE UMA PESSOA SINGULAR O processo de autenticação da identidade de uma pessoa singular, deve obrigatoriamente garantir que a pessoa singular para quem vai ser emitido o certificado é quem na realidade diz ser: Assim, as EC (ou as ER) devem guardar toda a documentação utilizada para verificação da identidade, garantindo a verificação da identidade dos seus representantes legais, por meio legalmente reconhecido, garantindo, no caso de o pedido ser subscrito para outrem, os poderes bastantes do requerente para a referida subscrição. Entre outras, considera-se como documentação mínima exigível, a documentação onde conste todos os dados necessários para a criação e emissão do certificado digital, destacando-se, os seguintes elementos: a) Nome completo; Página 26 de 12027 b) Indicação de eventual pseudónimo a constar como titular; c) Número do bilhete de identidade, data e entidade emitente ou qualquer outro elemento que permita a identificação inequívoca; d) Endereço e outras formas de contacto; e) Eventual indicação de uma qualidade específica em função da utilização a que este se destinar; f) Indicação quanto ao uso do certificado ser ou não restrito a determinados tipos de utilização, bem como eventuais limites do valor das transacções para as quais o certificado é válido; g) Outras informações relativas a poderes de representação, à qualificação profissional ou a outros atributos. No caso de o pedido de emissão ser requerido por outrem que não a pessoa singular a constar como titular do certificado, o mesmo, para além dos elementos referidos no número anterior, contém, consoante seja requerido por pessoa singular ou colectiva, os seguintes elementos referentes ao requerente: a) Nome ou denominação legal; b) Número do bilhete de identidade, data e entidade emitente, ou qualquer outro elemento que permita a identificação inequívoca, ou número de pessoa colectiva; c) Residência ou sede; d) Objecto social, nome dos titulares dos corpos sociais e de outras pessoas com poderes para a obrigarem e número de matrícula na conservatória do registo comercial; e) Endereço e outras formas de contacto. f) Declaração da pessoa singular a constar como titular do certificado de que se obriga ao cumprimento das obrigações enquanto titular. Nas DPC deve constar um exemplar do documento que serve de base ao registo do requerente INFORMAÇÃO DE SUBSCRITOR/TITULAR NÃO VERIFICADA Toda a informação descrita nos pontos e 3.2.4, deve ser obrigatoriamente verificada. As Entidades Certificadoras e as Entidades de Registo podem autorizar entidades privadas a tomar acções em nome de outras entidades, no entanto, tais autorizações estão geralmente associadas com regras particulares das instituições. A autenticação das autorizações é uma parte formal do pedido de registo de certificado para entidades com personalidade jurídica. Um certificado emitido é uma confirmação de que uma entidade legal é intitulada para utilizar uma chave privada em nome de outra entidade legal. Página 27 de 12028 CRITÉRIOS PARA INTEROPERABILIDADE Nos processos relativos a acordos de interoperabilidade, tendo por base certificação cruzada com Infra-estruturas de Chaves Públicas externas, será analisada, no mínimo, a seguinte documentação: a) A Política de Certificados; b) O ultimo relatório de auditoria, demonstrando a total conformidade com o estabelecido na PC e na DPC; c) Os parâmetros respeitantes a validação técnica da certificação cruzada; O Conselho Gestor agirá em conformidade com o estabelecido no documento SCEE - Regulamento para a interoperabilidade, nos casos em que seja solicitado um pedido para acordo de interoperabilidade, com base em certificação cruzada IDENTIFICAÇÃO E AUTENTICAÇÃO PARA PEDIDOS DE RENOVAÇÃO DE CHAVES IDENTIFICAÇÃO E AUTENTICAÇÃO PARA RENOVAÇÃO DE CHAVES, DE ROTINA A identificação e autenticação para a renovação de certificados pode realizar-se utilizado os procedimentos para a autenticação e identificação inicial, ou utilizando pedidos assinados digitalmente, mediante o certificado original que se pretende renovar, sempre que este tenha expirado e não exista pedido para a sua revogação IDENTIFICAÇÃO E AUTENTICAÇÃO PARA RENOVAÇÃO DE CHAVES, APÓS REVOGAÇÃO A política de identificação e autenticação para a renovação de um certificado, depois deste ser revogado deve seguir as mesmas regras constantes no e A renovação não deve ser concedida se: a) A revogação ocorreu porque o certificado foi emitido para uma pessoa que não a que está no Subject do certificado; b) O certificado foi emitido sem autorização da pessoa que está indicada no Subject; c) A entidade que aprovou o titular descobre que tem razões para acreditar que a informação dada para o certificado é falsa. As DPC devem descrever de forma clara as regras utilizadas IDENTIFICAÇÃO E AUTENTICAÇÃO PARA PEDIDO DE REVOGAÇÃO As regras de identificação para os pedidos de revogação poderão ser as mesmas que para o registo inicial. Página 28 de 12029 Qualquer entidade integrada no domínio da SCEE, pode solicitar a revogação de um determinado certificado, havendo conhecimento ou suspeita de compromisso da chave privada do titular ou qualquer outro acto que recomende esta acção. As DPC devem descrever de forma clara as regras utilizadas. Página 29 de 12030 4. REQUISITOS OPERACIONAIS DO CICLO DE VIDA DO CERTIFICADO 4.1. PEDIDO DE CERTIFICADO QUEM PODE SUBSCREVER UM PEDIDO DE CERTIFICADO As DPC devem descrever de forma clara qual a comunidade que se aceita para subscrever um pedido de certificado PROCESSO DE REGISTO E RESPONSABILIDADES O processo de registo para pedido de um certificado, deverá ser baseado pelo menos nas seguintes etapas: a) Estabelecimento do registo inicial do requisitante, tal como definido no ponto 3.2 Validação de identidade no registo inicial ; b) Obtenção por parte do requisitante, do respectivo par de chaves, por cada certificado requisitado/solicitado; c) Assinatura por parte do requisitante de um documento onde esteja especificado os termos e condições aplicáveis à utilização do certificado. As DPC devem descrever detalhadamente o processo de registo utilizado, nomeadamente, a documentação necessária, bem como a identificação das funções e responsabilidades dos diversos participantes no referido processo PROCESSAMENTO DO PEDIDO DE CERTIFICADO Os pedidos de certificado, depois de recebidos pela entidade competente (EC ou ER), são considerados válidos se os seguintes requisitos forem cumpridos: a) Recepção e verificação de toda a documentação e autorizações exigidas; b) verificação da identidade do requisitante; c) verificação da exactidão e integridade do pedido de certificado; d) criação e assinatura o certificado; e) disponibilização do certificado ao titular. As DPC devem descrever detalhadamente todo o processo PROCESSOS PARA A IDENTIFICAÇÃO E FUNÇÕES DE AUTENTICAÇÃO De acordo com o estipulado na secção 3.2 deste documento. A DPC deve indicar como e quem efectua as tarefas de identificação e autenticação, bem como os mecanismos que dispõe.31 APROVAÇÃO OU RECUSA DE PEDIDOS DE CERTIFICADO A aprovação do certificado passa pelo cumprimento dos requisitos mínimos exigidos no ponto 4.2. Quando tal não se verifique, a entidade competente (EC ou ER) pode recusar a emissão do certificado. Estes procedimentos, aceitação ou recusa, serão processados de acordo com os requisitos estipulados na respectiva DPC da entidade. As DPC devem descrever detalhadamente todo o processo PRAZO PARA PROCESSAR O PEDIDO DE CERTIFICADO Os pedidos de certificados serão processados sem atrasos, a partir do momento em que toda a documentação exigida, esteja na posse da entidade responsável pela emissão do certificado. A DPC estabelece o prazo máximo necessário para o processamento dos pedidos de certificados EMISSÃO DE CERTIFICADO PROCEDIMENTOS PARA A EMISSÃO DE CERTIFICADO A emissão do certificado por parte de uma EC da SCEE, indica que todos os procedimentos até à emissão foram concluídos sucesso. Os procedimentos estabelecidos nesta secção, são também aplicados aos casos de renovação de certificados, uma vez que implica a emissão de novos certificados. Os procedimentos adoptados devem garantir que para a emissão de certificados a EC: a) Utiliza procedimentos de geração de certificados que vincula de forma segura, o certificado com a respectiva informação de registo (incluindo a chave publica certificada); b) depois de emitido o certificado, as notificações são efectuadas de acordo com estabelecido na secção do presente capítulo; c) todos os certificados iniciam a sua vigência no momento da sua emissão, com excepção dos casos em que se indique nos próprios uma data e hora para a entrada em vigor diferente (que nunca poderá ser posterior ao dia natural da sua emissão); d) o período de validade do certificado está sujeito à extinção antecipada, temporal ou definitiva, quando se verificarem situações para a revogação ou suspensão. As DPC devem descrever detalhadamente todo o processo, bem como a forma utilizada para entrega do certificado ao seu titular. Página 31 de 12032 NOTIFICAÇÃO DA EMISSÃO DO CERTIFICADO AO TITULAR No âmbito desta política, consideram-se como formas aceitáveis de notificação da emissão do certificado ao titular por parte da respectiva EC, as que se baseiam nas seguintes formas: a) Envio do certificado directamente à ER requisitante (quando aplicável); b) envio da informação necessária para que o titular possa descarregar o certificado de um sítio Web ou repositório; c) Envio da informação necessária para que a ER respectiva possa descarregar o certificado de um sítio Web ou repositório (quando aplicável); d) De forma presencial. Em caso algum o futuro titular pode obter previamente o certificado sem o prévio procedimento de aceitação do mesmo. Podem ser utilizadas outras formas de notificação para além das descritas anteriormente, desde que devidamente aprovadas pelo Conselho Gestor do SCEE e descritas na respectiva DPC. A DPC deve descrever o método utilizado para a notificação da emissão do certificado ao titular ACEITAÇÃO DO CERTIFICADO PROCEDIMENTOS PARA A ACEITAÇÃO DE CERTIFICADO Antes de ser disponibilizado o certificado ao titular, e consequentemente lhe serem disponibilizadas todas as funcionalidades na utilização da chave privada e certificado, deverá ser garantido que: a) O titular toma conhecimento dos seus direitos e responsabilidades; b) o titular toma conhecimento das funcionalidades e conteúdo do certificado; c) o titular aceita formalmente sobre a aceitação do certificado e das suas condições de utilização assinando para o efeito, de forma manuscrita ou electronicamente, o Termo de Responsabilidade do Titular; No termo de responsabilidade do titular, devem constar, pelo menos, os procedimentos necessários em caso de expiração, revogação e renovação do certificado, bem como os termos, condições e âmbito de utilização do mesmo. A DPC deve estabelecer os mecanismos para verificar a aceitação do certificado por parte de titular PUBLICAÇÃO DO CERTIFICADO As entidades certificadoras, na publicação/distribuição dos certificados, deve utilizar sistemas seguros que permitam a sua conservação e disponibilização para efeitos de verificação, assegurando que: Página 32 de 12033 a) Regra geral, a EC não publica o certificado do titular; b) o certificado é disponibilizado, integralmente, ao titular para quem foi emitido, com os constrangimentos definidos no ponto 4.4.1; c) O certificado só é publicamente disponibilizado com o consentimento do titular; As DPC devem descrever detalhadamente todo o processo NOTIFICAÇÃO DA EMISSÃO DE CERTIFICADO A OUTRAS ENTIDADES A Notificação da emissão de certificado pela EC respectiva é obrigatória apenas para o requisitante/titular do certificado. Se o pedido de certificado tiver como origem com recurso aos serviços de uma ER, esta entidade também deverá ser notificada USO DO CERTIFICADO E PAR DE CHAVES Dentro da comunidade da SCEE, a utilização dos certificados e respectiva chave privada, pelos diversos participantes, segue os seguintes constrangimentos: a) A ECRaizEstado apenas emite certificados à ECEstado e EC externas e ao pessoal próprio para efeitos de operação dos seus sistemas; b) As ECEstado emitem certificados ao pessoal próprio para efeitos de operação dos seus sistemas e dependendo da forma como estão organizadas, emitem certificados para o utilizador final (titulares) ou para subecestado; As EC devem assegurar que a utilização da sua chave privada apenas é utilizada para assinar certificados e CRL. É ainda responsabilidade das EC, garantir que as chaves privadas atribuídas ao seu pessoal para efeitos de operação do sistema, são utilizadas apenas e exclusivamente para esse fim USO DO CERTIFICADO E DA CHAVE PRIVADA PELO TITULAR Os titulares de certificados utilizarão a sua chave privada apenas e só para o fim a que estas se destinam (conforme estabelecido no campo do certificado keyusage ) e sempre com propósitos legais. A sua utilização apenas é permitida: a) a quem estiver designado no campo Subject do certificado; b) depois de aceitar as condições definidas nos pontos e 1.4.2; e c) enquanto este se mantiver válido. As DPC devem descrever o tipo de certificados emitidos e sua utilização, podendo estabelecer limitações adicionais. Página 33 de 12034 USO DO CERTIFICADO E DA CHAVE PÚBLICA PELAS PARTES CONFIANTES Na utilização do certificado e da chave pública, as partes confiantes apenas podem confiar nos certificados, tendo em conta apenas o que é estabelecido nesta política e na respectiva DPC, para isso devem, entre outras, garantir o cumprimento das seguintes condições: a) Ter conhecimento e perceber a utilização e funcionalidades proporcionadas pela criptografia de chave publica e certificados. b) ser responsável pela sua correcta utilização; c) ler e entender os termos e condições descritos nas Politicas e práticas de certificação; d) verificar os certificados (validação de cadeias de confiança) e CRL, tendo especial atenção às suas extensões marcadas como críticas e propósito das chaves; e) confiar nos certificados, utilizando-os sempre que estes estejam válidos; 4.6. RENOVAÇÃO DE CERTIFICADOS A renovação de um certificado é o processo em que a emissão de um novo certificado, no qual é inscrito uma nova validade. Este processo utiliza os dados anteriores do certificado, não havendo alteração das chaves ou qualquer outra informação, com excepção do período de validade do certificado. Este processo levanta algumas reticências uma vez que a sua utilização é caracterizada pela perda de entropia das chaves, uma vez que não são gerados novos parâmetros, mas sim utilizados os já existentes. Esta prática não é suportada na SCEE MOTIVOS PARA RENOVAÇÃO DE CERTIFICADO Não aplicável QUEM PODE SUBMETER O PEDIDO DE RENOVAÇÃO DE CERTIFICADO Não aplicável PROCESSAMENTO DO PEDIDO DE RENOVAÇÃO DE CERTIFICADO Não aplicável NOTIFICAÇÃO DE EMISSÃO DE NOVO CERTIFICADO AO TITULAR Não aplicável. Página 34 de 12035 PROCEDIMENTOS PARA ACEITAÇÃO DE CERTIFICADO Não aplicável PUBLICAÇÃO DE CERTIFICADO APÓS RENOVAÇÃO Não aplicável NOTIFICAÇÃO DA EMISSÃO DO CERTIFICADO A OUTRAS ENTIDADES Não aplicável RENOVAÇÃO DE CERTIFICADO COM GERAÇÃO DE NOVO PAR DE CHAVES A renovação de chaves do certificado (certificate re-key) é o processo em que um titular (ou outro participante) gera um novo par de chaves e submete o pedido para emissão de novo certificado que certifica a nova chave pública. Este processo, no âmbito da SCEE, é designado por renovação de certificado com geração de novo par de chaves. A emissão do certificado é feita de acordo com o estabelecido na secção MOTIVOS PARA A RENOVAÇÃO DE CERTIFICADO COM GERAÇÃO DE NOVO PAR DE CHAVES De forma geral, são considerados motivos válidos para a renovação de certificado com geração de novo par de chaves, sempre e quando que se verifique que: a) O certificado esteja a expirar; b) o suporte do certificado esteja expirar; c) a informação do certificado sofra alterações. As DPC devem descrever quais os motivos para a renovação de certificado com geração de novo par de chaves QUEM PODE SUBMETER O PEDIDO DE CERTIFICAÇÃO DE UMA NOVA CHAVE PÚBLICA A submissão do pedido de certificação, é válida para titulares com certificados em vigor PROCESSAMENTO DO PEDIDO DE RENOVAÇÃO DE CERTIFICADO COM GERAÇÃO DE NOVO PAR DE CHAVES As DPC devem descrever os processos para os pedidos de renovação, identificando os diferentes cenários e os respectivos requisitos. Página 35 de 12036 NOTIFICAÇÃO DA EMISSÃO DE NOVO CERTIFICADO AO TITULAR De acordo com os critérios especificados para a emissão inicial de certificados PROCEDIMENTOS PARA ACEITAÇÃO DE UM CERTIFICADO RENOVADO COM GERAÇÃO DE NOVO PAR DE CHAVES A recepção do certificado renovado, por si só, serve como confirmação da aceitação do mesmo. As DPC devem descrever de forma clara os procedimentos adoptados, no entanto, podem ser estabelecidos requisitos mais restritivos PUBLICAÇÃO DE NOVO CERTIFICADO RENOVADO COM GERAÇÃO DE NOVO PAR DE CHAVES De acordo com os critérios especificados para a emissão inicial de certificados NOTIFICAÇÃO DA EMISSÃO DE NOVO CERTIFICADO A OUTRAS ENTIDADES De acordo com os critérios especificados para a emissão inicial de certificados MODIFICAÇÃO DE CERTIFICADOS A alteração de certificados é o processo em que é emitido um certificado para um titular (ou outro participante), mantendo as respectivas chaves, havendo apenas alterações na informação do certificado. Esta prática é suportada pela SCEE com restrições, nomeadamente, na informação sujeita a alterações não está contemplada a alteração da validade inicial do certificado. Os procedimentos descritos nos seguintes parágrafos, relativos à alteração de certificados, estão sujeitas às mesmas regras definidas para os pedidos de certificado em conformidade com o disposto no ponto MOTIVOS PARA ALTERAÇÃO DE CERTIFICADO Descrito na secção QUEM PODE SUBMETER O PEDIDO DE ALTERAÇÃO DE CERTIFICADO Descrito na secção PROCESSAMENTO DO PEDIDO DE ALTERAÇÃO DE CERTIFICADO Descrito na secção 4.8. Página 36 de 12037 NOTIFICAÇÃO DA EMISSÃO DE CERTIFICADO ALTERADO AO TITULAR Descrito na secção PROCEDIMENTOS PARA ACEITAÇÃO DE CERTIFICADO ALTERADO Descrito na secção PUBLICAÇÃO DO CERTIFICADO ALTERADO Descrito na secção NOTIFICAÇÃO DA EMISSÃO DE CERTIFICADO ALTERADO A OUTRAS ENTIDADES Descrito na secção SUSPENSÃO E REVOGAÇÃO DE CERTIFICADO A revogação e suspensão de certificados, são mecanismos a utilizar quando por algum motivo os certificados deixam de ser fiáveis, antes do período de finalização originalmente previsto. Na prática, a revogação e suspensão de certificados é uma acção através da qual o certificado deixa de estar válido antes do fim do seu período de validade, perdendo a sua operacionalidade. Os certificados depois de revogados não podem voltar a ser válidos, enquanto que os certificados suspensos podem recuperar a sua validade MOTIVOS PARA A REVOGAÇÃO Os certificados devem ser revogados, sempre que se verifiquem as seguintes situações: a) Roubo, extravio, destruição ou deterioração do dispositivo de suporte dos certificados (exemplo: Smartcard) b) Incapacidade ou falecimento do titular; c) Inexactidões graves nos dados fornecidos; d) o certificado estar suspenso por um período alargado; e) comprometimento ou suspeita de comprometimento das chaves privada do titular; f) comprometimento ou suspeita de comprometimento da senha (exemplo: PIN); g) comprometimento ou suspeita de comprometimento das chaves privada da EC; h) incumprimento por parte da EC ou titular das responsabilidades prevista na DPC; Página 37 de 12038 i) sempre que haja razões credíveis que induzam que o serviços de certificação possam ter sido comprometidos, de tal forma que coloquem em causa a fiabilidade dos certificados; j) por resolução judicial ou administrativa; k) por vontade do próprio. As DPC devem estabelecer de forma detalhada as causas passíveis para revogação do certificado QUEM PODE SUBMETER O PEDIDO DE REVOGAÇÃO Está legitimado para submeter o pedido de revogação, sempre que se verifiquem alguma das condições descritas no ponto 4.9.1, os seguintes: a) O titular do certificado; b) O responsável por um certificado emitido para produtos de tecnologia de informação; c) uma parte confiante, sempre que demonstre que o certificado foi utilizado com fins diferente dos previstos; d) a EC ou ER; e) a Entidade de Certificação Electrónica do Estado; f) o Conselho Gestor do SCEE; g) a Autoridade Credenciadora. As DPC devem descrever as entidades a quem é permitido submeter o pedido de revogação PROCEDIMENTO PARA O PEDIDO DE REVOGAÇÃO De modo geral os procedimentos mínimos a ter em conta para um pedido de revogação serão os seguintes: a) Qualquer pedido de revogação deve ser sempre autenticado e autorizado; b) Todos os pedidos de revogação devem ser endereçados para a EC ou ER respectiva; c) Os pedidos podem ser efectuados por escrito ou por um processo on-line (CMP); d) Qualquer pedido, desde que autenticado, deve ficar registado e arquivado; e) Sempre que um certificado for revogado, deve ficar documentado juntamente com uma descrição exaustiva do motivo da revogação, nomeadamente: i. data do pedido de revogação; ii. nome do titular do certificado (o assinante); iii. exposição pormenorizada dos motivos para o pedido de revogação; iv. nome e funções da pessoa que solicita a revogação; Página 38 de 12039 v. informação de contacto da pessoa que solicita a revogação; vi. assinatura da pessoa que solicita a revogação. f) sempre que for revogado um certificado de um titular, a revogação deve ser publicada na respectiva LCR. As DPC devem estabelecer de forma detalhada os procedimentos utilizados para o pedido de revogação de certificados PRODUÇÃO DE EFEITOS DA REVOGAÇÃO A revogação será feita de forma imediata. Após terem sido efectuados todos os procedimentos e seja verificado que o pedido é válido, o pedido não pode ser anulado PRAZO PARA PROCESSAR O PEDIDO DE REVOGAÇÃO O pedido de revogação deve ser tratado de forma imediata, pelo que em caso algum poderá ser superior a 24 horas REQUISITOS DE VERIFICAÇÃO DA REVOGAÇÃO PELAS PARTE CONFIANTES Antes de utilizarem um certificado, as partes confiantes tem como responsabilidade verificar o estado de todo os certificados, através das LCR ou num servidor de verificação do estado on-line (via OCSP) PERIODICIDADE DA EMISSÃO DA LISTA DE CERTIFICADOS REVOGADOS (LCR) As EC deverão publicar uma nova LCR no repositório, sempre que haja uma revogação. Quando não haja alterações ao estado de validade dos certificados, ou seja, se nenhuma revogação se tiver produzido as várias entidades deverão disponibilizar nova informação de revogação com os seguintes limites máximos: a) para as EC que emitam certificados de utilizador final, as LCR serão disponibilizadas a cada 24 Horas; b) para as EC que não emitam certificados de utilizador final, as LCR serão disponibilizadas a cada 3 meses; As DPC devem estabelecer de forma detalhada a periodicidade utilizada para emissão das LCR PERÍODO MÁXIMO ENTRE A EMISSÃO E A PUBLICAÇÃO DA CRL De acordo com o ponto Página 39 de 12040 DISPONIBILIDADE DE VERIFICAÇÃO ON-LINE DO ESTADO / REVOGAÇÃO DE CERTIFICADO As DPC deverão estabelecer se dispõem e em que condições, serviços de validação do estado dos certificados de forma on-line REQUISITOS DE VERIFICAÇÃO ON-LINE DE REVOGAÇÃO No caso de serem utilizadas as AV, as partes confiantes deverão dispor de software capaz de operar o protocolo OCSP, de forma a obter a informação sobre o estado do certificado OUTRAS FORMAS DISPONÍVEIS PARA DIVULGAÇÃO DE REVOGAÇÃO Não estabelecido REQUISITOS ESPECIAIS EM CASO DE COMPROMETIMENTO DE CHAVE PRIVADA Apenas quando se trate do comprometimento da chave privada de uma EC. Neste caso deverão ser adoptados os procedimentos descritos na secção MOTIVOS PARA SUSPENSÃO As DPC deverão os motivos e identificar as causas em que se aplica a suspensão do certificado em detrimento da revogação QUEM PODE SUBMETER O PEDIDO DE SUSPENSÃO A estabelecer na DPC PROCEDIMENTOS PARA PEDIDO DE SUSPENSÃO A estabelecer na DPC LIMITE DO PERÍODO DE SUSPENSÃO A estabelecer na DPC SERVIÇOS SOBRE O ESTADO DO CERTIFICADO CARACTERÍSTICAS OPERACIONAIS Página 40 de 12041 Caso haja algum serviço para além das LCR, será um serviço de validação on-line, com implementação do protocolo OCSP, de acordo com o estipulado no RFC DISPONIBILIDADE DE SERVIÇO Salvo causa justificada, a disponibilidade do serviço será contínua (24 horas, todos os dias do ano CARACTERÍSTICAS OPCIONAIS Para usufruir do serviço de validação on-line, as partes confiantes deverão dispor de um cliente OCSP que cumpra o RFC FIM DE SUBSCRIÇÃO O fim da operacionalidade de um certificado acontece quando se verificarem uma das seguintes situações: a) Revogação do certificado; b) por ter caducado o prazo de validade do certificado RETENÇÃO E RECUPERAÇÃO DE CHAVES (KEY ESCROW) POLÍTICAS E PRÁTICAS DE RECUPERAÇÃO DE CHAVES Apenas é autorizada a retenção de chaves para os seguintes casos: a) Chaves privadas das EC; b) Chaves para efeitos de confidencialidade. Em ambos os casos apenas é permitido a realização desta operação, no mínimo por duas pessoas. As políticas e práticas de recuperação fazem parte integral da DPC da entidade POLÍTICAS E PRÁTICAS DE ENCAPSULAMENTO E RECUPERAÇÃO DE CHAVES DE SESSÃO. Não estipulado. Página 41 de 12042 5. MEDIDAS DE SEGURANÇA FÍSICA, DE GESTÃO E OPERACIONAIS 5.1. MEDIDAS DE SEGURANÇA FÍSICA Todos os aspectos relacionados com as medidas de segurança física exigidas às instalações onde operam as EC da SCEE, estão definidos no documento Localização e Instalação das EC do SCEE Medidas de Segurança Física. Nesta secção apenas são descritos os aspectos mais relevantes LOCALIZAÇÃO FÍSICA E TIPO DE CONSTRUÇÃO As instalações das EC devem ser desenhadas de forma a proporcionar um ambiente capaz de controlar e auditar o acesso aos sistemas de certificação, devendo estar fisicamente protegidas do acesso não autorizado, dano, ou interferência. Esta protecção deve ser proporcional aos riscos identificados. A arquitectura deverá ser formada aplicando o conceito de defesa em profundidade, ou seja, por níveis de segurança. O acesso a um nível de segurança mais elevado só é possível quando previamente se tenha alcançado o nível imediatamente anterior, nunca sendo possível, em qualquer local das instalações, aceder ao nível de segurança (n) a partir de outro que não seja o nível (n-1). Neste contexto torna-se fundamental a existência e integração de um conjunto de subsistemas, que em conjunto formam um sistema complementar de segurança electrónico, de funcionamento ininterrupto, proporcionando um ambiente altamente seguro. O local onde se desenvolve a actividade da EC, a Zona de Alta Segurança (ZAS), é uma área deverá obedecer ao descrito para as áreas de Classe 1 2. Esta área deverá ter as seguintes características: a) Paredes em alvenaria, betão ou tijolo; b) Tecto e pavimento com construção similar à das paredes; c) Inexistência de janelas; d) Porta de segurança, com chapa em aço em aço, com as dobradiças fixas e ombreira igualmente em aço, com de fechadura de segurança accionável electronicamente, características corta fogo e funcionalidade anti-pânico ACESSO FÍSICO AO LOCAL O acesso à ZÁS, deverá ser composto por diversos perímetros com diferentes requisitos de segurança e autorizações. Entre os equipamentos que protegem os perímetros de segurança deverão incluir-se sistemas electrónicos de controlo de acessos, sistemas de vídeo vigilância e de gravação em circuito fechado de TV e sistemas de detecção de intrusões. Os vários sistemas devem estar integrados, funcionando de forma ininterrupta 24 horas, todos os dias do ano. As ZÁS não podem ser contíguas às zonas de acesso comum do edifício. O acesso às mesmas, para actividades como emissão de certificados, deverá ser registado e gravado automaticamente sendo que o acesso deve ser feito através de pelo menos a conjugação 2 Resolução do Conselho de Ministros n.º 50/88.43 de dois sistemas, em que um deles é obrigatoriamente com recurso a tecnologia baseada em biometria. Nas ZÁS, deve existir um livro para registo manual dos acessos e de todas as actividades e cerimónias que ocorram no seu interior ENERGIA E AR CONDICIONADO As instalações devem dispor de sistemas de alimentação ininterrupta com a potência suficiente para manter autonomamente a rede eléctrica durante períodos de falta de corrente e para proteger os equipamentos face a flutuações eléctricas que os possam danificar. O sistema de acondicionamento ambiental deverá ser composto por vários equipamentos independentes com capacidade para manter níveis de temperatura e humidade de acordo com recomendações para operação dos sistemas EXPOSIÇÃO À ÁGUA As ZAS devem dispor de detectores de inundação e sistemas de alarme apropriados para o efeito PREVENÇÃO E PROTECÇÃO CONTRA INCÊNDIO Os funcionários e os equipamentos devem ter todas as condições de segurança no que se concerne a incêndios. As ZAS devem dispor de sistemas automáticos de detecção e extinção de incêndios. Os materiais da sala e portas utilizadas devem ser de material não combustível e que sejam resistentes ao fogo, sendo que no caso das portas estas devem ter uma resistência de pelo menos 2 horas SALVAGUARDA DE SUPORTES DE ARMAZENAMENTO Os suportes de informação sensível, deverão ser armazenados de forma segura em cofres de acordo com o tipo de suporte e classificação da informação. O acesso a estas zonas, deve ser restrito a pessoas devidamente autorizadas ELIMINAÇÃO DE RESÍDUOS A eliminação de suportes magnéticos, ópticos e informação em papel, deve ser realizada de forma segura, seguindo os procedimentos estabelecidos para este fim, recorrendo a processos de desmagnetização, de esterilização e de destruição ou triturando em função do tipo de suporte a tratar. Periféricos criptográficos devem ser destruídos de acordo com as recomendações dos respectivos fabricantes. Página 43 de 12044 INSTALAÇÕES EXTERNAS (ALTERNATIVA) PARA RECUPERAÇÃO DE SEGURANÇA Todas as cópias de segurança (e.g., base de dados, programas, file system,) devem ser colocadas em site remoto que será geograficamente separado do sítio primário. As condições de segurança do site remoto deverão ser idênticas ou superiores ao estipulado para o local primário. O acesso é restrito apenas ao pessoal autorizado MEDIDAS DE SEGURANÇA DOS PROCESSOS Os sistemas de informação e os serviços disponibilizados pelas várias EC que integram a SCEE, devem ser operados de forma controlada FUNÇÕES DE CONFIANÇA As funções de confiança a estabelecer deverão estar em conformidade com os requisitos estabelecidos no ponto do documento CWA parte 1, de Junho de 2003, para certificados qualificados. Nas funções de confiança está incluído todo o pessoal com acesso aos sistemas de certificação das EC e que na prática podem materialmente afectar: a) Manipulação de informações de subscritor e validação de informação de emissão de Certificado; b) Funções do ciclo de vida dos certificados; c) Configuração e manutenção dos sistemas de certificação. No âmbito da sua estrutura organizativa são consideradas funções de confiança as descritas a seguir, estando divididas e diferenciadas pela natureza da sua actividade, quer se trate das software para certificação digital, quer se trate das funções relacionadas com o dispositivo seguro para criação de assinaturas. A cada uma delas são cometidas as seguintes responsabilidades consoante o âmbito Software para certificação digital a) Administrador de Segurança (AdmSeg), responsáveis segurança global dos sistemas, nomeadamente, pela gestão e implementação das regras e práticas de segurança; b) Administrador de registo (AdmReg), responsáveis pela aprovação da emissão, suspensão e revogação de certificados de titulares; c) Administrador de Sistemas (AdmSist), responsáveis pela instalação, configuração e manutenção dos sistemas, no entanto, com acesso controlado às configurações relacionadas com a segurança; d) Operador de Sistemas (OpSist), responsáveis pela operação de rotina dos sistemas, estando autorizados a realizar as cópias de segurança e sua recuperação; e) Auditor de Sistemas (AuditorS), responsáveis pela análise da actividade do sistema, estão autorizados a ver e monitorizar os arquivos de actividade dos sistemas. Página 44 de 12045 As DPC devem descrever em detalhe as responsabilidades inerentes a cada função Dispositivo seguro para criação de assinaturas a) Administradores do HSM (AdmHSM), responsáveis pela segurança das chaves; b) Operadores do HSM (OpHSM), autorizados a utilizarem a chaves. As DPC devem descrever em detalhe as responsabilidades inerentes a cada função NÚMERO DE PESSOAS EXIGIDAS POR TAREFA As seguintes tarefas/acções/actividade, requerem o mínimo a presença 2 pessoas em simultâneo: a) Qualquer acesso à ZÁS; b) Geração das chaves da EC; c) configuração dos perfis para o desempenho das funções de confiança d) manutenção e actualização dos sistemas dos sistemas; e) recuperação de chaves para efeitos de confidencialidade; e f) recuperação das chaves da EC. As DPC devem descrever em detalhe a metodologia e o número de pessoas por tarefa adoptada IDENTIFICAÇÃO E AUTENTICAÇÃO PARA CADA FUNÇÃO Todos os utilizadores autorizados, devem identificar-se preferencialmente através de certificados digitais emitidos pela própria EC. No caso dos HSM são empregues as técnicas de segredo partilhado. As DPC devem descrever em detalhe os mecanismos adoptados. Página 45 de 12046 FUNÇÕES QUE REQUEREM SEPARAÇÃO DE RESPONSABILIDADES De acordo com o descrito no quadro seguinte: AdmSeg AdmReg AdmSist OpSist AuditorS AdmHSM * ophsm * AdmSeg AdmReg AdmSist OpSist AuditorS AdmHSM * OpHSM. * NOTAS - As funções assinaladas são incompatíveis; *- Estas funções não são obrigatoriamente requeridas pela legislação, nem necessárias a todas as entidades certificadoras, podendo no entanto ser necessárias em casos específicos. Tabela 8 Incompatibilidade entre funções 5.3. MEDIDAS DE SEGURANÇA DE PESSOAL As DPC devem descrever em detalhe os requisitos adoptados nas diversas secções, no entanto, a EC deve garantir que o pessoal com funções de confiança cumpre os seguintes requisitos mínimos: a) Nomeado formalmente para a função; b) ter recebido formação e treino adequado para o desempenho da respectiva função; c) garantir que o funcionário (p.e: contrato, estatuto próprio, etc.), não revela informação sensível sobre a EC ou dados de identificação dos titulares; d) garantir que o funcionário, (p.e: contrato, estatuto próprio, etc.), conhece os termos e condições para o desempenho da respectiva função; e e) garantir que o funcionário não desempenha funções que possam causar conflito com as suas responsabilidades nas actividades da EC Página 46 de 12047 REQUISITOS RELATIVOS ÀS QUALIFICAÇÕES, EXPERIÊNCIA, ANTECEDENTES E CREDENCIAÇÃO O pessoal que desempenha funções nas EC deve possuir suficientes qualificações para o desempenho da função PROCEDIMENTOS DE VERIFICAÇÃO DE ANTECEDENTES A verificação de antecedentes decorre do processo de credenciação dos indivíduos nomeados para exercer cargos em qualquer uma das funções de confiança. A credenciação varia tendo em conta a função de confiança e o tipo de EC onde se desenvolvem as actividades. O grau de credenciação de segurança 3 exigido está descrito no quadro seguinte: ECRAIZESTADO ECESTADO SUBECESTADO ERESTADO AdmSeg Secreto Confidencial Confidencial Confidencial AdmReg Secreto Confidencial Confidencial Confidencial AdmSist Secreto Confidencial Confidencial Confidencial OpSist Secreto Confidencial Confidencial Confidencial AuditorS Secreto Confidencial Confidencial Confidencial AdmHSM Secreto Confidencial Confidencial Confidencial OpHSM. Secreto Confidencial Confidencial Confidencial Tabela 9 Credenciação de segurança REQUISITOS DE FORMAÇÃO E TREINO Os elementos com cargos que desempenhem actividades nas várias EC, deverão estar sujeitos a um plano de formação e treino, englobando os seguintes tópicos: a) Certificação digital e Infra-estruturas de Chave Publica; b) Conceitos gerais sobre segurança da informação c) Formação especifica para o seu posto d) Funcionamento do software e/ou hardware usado pela EC e) Politica de Certificados e Declaração de Práticas de Certificação; f) Recuperação face a desastres; g) Procedimentos para a continuidade da actividade; h) Aspectos legais básicos relativos à prestação de serviços de certificação. 3 Resolução do Conselho de Ministros n.º 50/88 (SEGNAC 1), Capitulo 4 Página 47 de 12048 FREQUÊNCIA E REQUISITOS PARA ACÇÕES DE RECICLAGEM Sempre que existe qualquer alteração tecnológica, introdução de novas ferramentas ou modificação de procedimentos, dever levar-se a cabo a adequada formação para todo o pessoal afecto às EC. Sempre que sejam levadas a cabo alterações nas Politicas de Certificação ou Declaração de Práticas de Certificação devem ser realizadas sessões formativas aos elementos das EC FREQUÊNCIA E SEQUÊNCIA DA ROTAÇÃO DE FUNÇÕES Não é definido nenhum plano de rotação na atribuição de tarefas ao pessoal das EC, contudo sempre que alguma EC o faça deve materializar de forma clara a forma como esta rotação é realizada SANÇÕES PARA ACÇÕES NÃO AUTORIZADAS No caso da realização de acções não autorizadas respeitantes às EC, devem ser tomadas as medidas disciplinares adequadas. Consideram-se acções não autorizadas todas as acções que desrespeitem a Declaração de Práticas de Certificação e as Políticas de Certificação, quer sejam realizadas de forma deliberada ou sejam ocasionadas por negligência. Se for realizada alguma infracção, a EC suspenderá o acesso a todos os sistemas de EC de forma imediata às pessoas envolvidas com o conhecimento destes Adicionalmente em função da gravidade da infracção cometida, devem aplicar-se as sanções previstas na lei geral da função pública, das organizações ou entidades CONTRATAÇÃO DE PESSOAL O pessoal contratado para exercer cargos relacionados com funções de confiança de qualquer parte da EC ou ER está sujeito aos mesmos critérios que um funcionário dos quadros da própria organização e é credenciado de acordo com o especificado na secção DOCUMENTAÇÃO FORNECIDA AO PESSOAL Ao pessoal com cargos nas várias EC deve ser disponibilizado, no mínimo, os seguintes documentos: a) Política de Certificados b) Declaração de Práticas de Certificação c) Documento com a descrição das responsabilidades, obrigações e tarefas para a respectiva função; d) Documentação técnica sobre o software e hardware da EC. Página 48 de 12049 5.4. PROCEDIMENTOS DE AUDITORIA DE SEGURANÇA TIPO DE EVENTOS REGISTADOS As EC devem registar entre outros, os eventos especificado no documento CWA , sendo obrigatório o registo dos seguintes: a) Ligar e desligar os servidores; b) Tentativas com sucesso ou fracassadas de alteração dos parâmetros de segurança do sistema operativo; c) Tentativas com sucesso ou fracassadas de criar, modificar, apagar contas do sistema d) Ligar e desligar as aplicações e sistemas utilizados para a actividade de certificação; e) Tentativas com sucesso ou fracassadas de inicio e fim de sessão; f) Tentativas com sucesso ou fracassadas das operações relativas ao pedido, emissão, renovação, modificação e revogação chaves e certificados; g) Tentativas com sucesso ou fracassadas de gerar ou emitir LCR; h) Tentativas com sucesso ou fracassadas de criar, modificarmos ou apagar informação dos titulares dos certificados; i) Tentativas com sucesso ou fracassadas de acesso às ZÁS da EC; j) Copias de segurança, recuperação ou arquivo dos dados; k) Alterações ou actualizações de software e hardware; l) Manutenção do sistema; m) Mudança de pessoal; O registo dos eventos, efectuado com recurso a meios automáticos e/ou manuais, devem conter, pelo menos, a data e hora do evento, bem como a identificação da entidade causadora do evento. Os eventos registados devem ser especificados na respectiva DPC FREQUÊNCIA DA AUDITORIA DE REGISTOS A auditoria dos registos deve ser realizadas com uma frequência mínima semanal e todos os eventos significativos devem ficar registados num relatório sumário de análise de eventos. Cada EC deve declarar na sua DPC a frequência com que auditoria de registos é implementada e quais os tipos de eventos considerados como significativos e que justificam a sua inclusão no Relatório Sumário de Análise de Eventos (RSAE) PERÍODO DE RETENÇÃO DOS REGISTOS DE AUDITORIA Página 49 de 12050 As EC deverão guardar os registos de auditoria nos sistemas por um período mínimo de 3 meses. Depois de arquivados, os registos de auditoria devem ser conservados por um período mínimo de 20 anos. Nas DPC deve ser especificado quais os períodos adoptados para a retenção dos registos de auditoria PROTECÇÃO DOS REGISTOS DE AUDITORIA Os registos de auditoria devem estar protegidos contra acesos não autorizados, alteração e destruição. Por regra, os registos electrónicos devem estar protegidos com recurso a técnicas criptográficas, para que ninguém, com excepção das próprias aplicações de visualização de registos, com o controlo de acessos adequado, possam aceder aos mesmos. Os registos manuais devem ser armazenados em local, que cumpra os requisitos definidos anteriormente, dentro das instalações seguras das EC. A destruição de um arquivo de auditoria só pode ser levado a cabo com a autorização do Administrador de Sistema, Administrador de Segurança e Auditor de Registo. Esta destruição só pode proceder-se por recomendação escrita de qualquer dos três elementos. Os registos de auditoria são considerados informação sensível como especificado na secção PROCEDIMENTOS PARA A CÓPIA DE SEGURANÇA DOS REGISTOS Devem ser realizadas cópias de segurança dos registos de auditoria bem como dos RSAE. As DPC devem descrever a os mecanismos adoptados para efectuar as cópias de segurança dos registos e RSAE SISTEMA DE RECOLHA DE DADOS DE AUDITORIA (INTERNO/EXTERNO) O sistema de recolha dos dados de auditoria deve ser uma combinação de processos automáticos e manuais executados pelos sistemas operativos, pelas aplicações das EC e pelo pessoal que as opera. As DPC devem descrever de forma clara o procedimento para este sistema NOTIFICAÇÃO DE AGENTES CAUSADORES DE EVENTOS Não esta contemplada qualquer notificação. As DPC, caso implementem notificações, devem descrever o método e as pessoas/sistemas alvo de notificação AVALIAÇÃO DE VULNERABILIDADES Não havendo alterações significativas no ambiente global da EC, deve ser efectuada pelo menos uma vez por ano uma avaliação das vulnerabilidades. Página 50 de 12051 O resultado da análise deve ser reportado ao responsável da EC para rever e aprovar, caso se justifique, um plano de implementação e correcção das vulnerabilidades detectadas ARQUIVO DE REGISTOS TIPO DE DADOS ARQUIVADOS As EC devem arquivar, pelo menos os seguintes tipos de dados: a) Os registos de auditoria especificados no ponto 5.4 deste documento; b) As cópias de segurança dos sistemas que compõem a infra-estrutura da EC; c) Documentação relativa ao ciclo de vida dos certificados. d) Chaves para efeitos de confidencialidade (quando aplicável); e) Contratos estabelecidos entre a EC e outras entidades. Nas DPC deve estar especificados o tipo de dados sujeitos a arquivos PERÍODO DE RETENÇÃO EM ARQUIVO Os dados sujeitos a arquivo são retidos por um período mínimo de 20 anos PROTECÇÃO DOS ARQUIVOS De acordo com o disposto na secção PROCEDIMENTOS PARA AS CÓPIAS DE SEGURANÇA DO ARQUIVO De acordo com o disposto na secção REQUISITOS PARA VALIDAÇÃO CRONOLÓGICA DOS REGISTOS Os registos arquivados são certificados por assinatura electrónica qualificada com validação cronológica que liga criptograficamente os dados com os valores de tempo. Assim, os sistemas de informação utilizados pelas EC devem garantir o registo da data e hora do momento, tendo por base uma fonte de tempo segura. Os sistemas da EC devem estar sincronizados entre si e as fontes de tempo utilizadas, devem-se calibrar automaticamente, devendo ser utilizada com referência a fonte de tempo do Observatório Astronómico de Lisboa (http://www.oal.ul.pt) SISTEMA DE RECOLHA DE DADOS DE ARQUIVO (INTERNO/EXTERNO) De acordo com o disposto na secção Página 51 de 12052 PROCEDIMENTOS DE RECUPERAÇÃO E VERIFICAÇÃO DE INFORMAÇÃO ARQUIVADA Só o pessoal devidamente autorizado deve ter acesso aos arquivos. As EC devem verificar a integridade da informação arquivada a cada 9 meses, de forma a garantir que os mesmos se encontram em bom estado e que podem ser recuperados. As EC devem garantir a capacidade para realizar verificações de integridade dos arquivos electrónicos na altura da sua criação. No caso de erros ou comportamentos imprevistos, deve ser criado um evento de segurança e ser criado novo arquivo. As DPC devem descrever de forma clara os mecanismos utilizados RENOVAÇÃO DE CHAVES Apenas os titulares de certificados válidos podem requerer a renovação do respectivo par de chaves. As DPC devem descrever de forma clara os processos utilizados para a renovação de certificado com geração de novo par de chaves (re-key), bem como os prazos mínimos exigidos para iniciar o processo de renovação RECUPERAÇÃO EM CASO DE DESASTRE OU COMPROMETIMENTO As DPC de cada EC deverão indicar, no caso de indisponibilidade das instalações da Entidade Certificadora qual o tempo máximo para esta indisponibilidade antes de ser activado o Plano de Continuidade de Serviço da respectiva EC. O Plano de Continuidade deverá garantir que os serviços indicados como críticos pela sua necessidade de disponibilidade estão disponíveis no Local Alternativo, devendo a DPC indicar o tempo máximo para activação dos serviços PROCEDIMENTOS EM CASO DE INCIDENTE OU COMPROMETIMENTO As EC devem estabelecer procedimentos de contingência para as EC e ER subordinadas, estabelecendo as etapas necessárias, de modo a dar continuidade à sua actividade em caso de incidentes, nomeadamente, corrupção ou perda dos dados, software e equipamentos. Se as EC subcontratarem alguns serviços, as EC garantem que os requisitos anteriores são acautelados e estabelece, obrigatoriamente, um contrato escrito com as provisões necessárias. As DPC devem descrever os procedimentos adoptados CORRUPÇÃO DOS RECURSOS INFORMÁTICOS, DO SOFTWARE E/OU DOS DADOS Página 52 de 12053 Se os recursos de hardware, software e/ou dados estão alterados ou há suspeita de terem sido alterados as EC devem suspender os serviços até ao restabelecimento das condições seguras com a inclusão de novos componentes de eficácia credível. A ECEE deve ser notificada. As DPC devem descrever de forma clara os procedimentos adoptados PROCEDIMENTOS EM CASO DE COMPROMETIMENTO DA CHAVE PRIVADA DA ENTIDADE No caso de comprometimento da chave privada de uma entidade, deverá proceder-se à sua revogação imediata e informar deste facto todo o resto das entidades que compõem a SCEE dependentes ou não da Entidade afectada. Os certificados assinados por entidades dependentes da comprometida, no período compreendido entre o compromisso da chave e a revogação do certificado, deverão por sua vez ser revogados. No caso de comprometimento da chave de uma EC, o seu certificado é revogado e deve ser gerada nova chave. Dependendo do tipo de EC em causa deverão ser adoptados, no mínimo, os requisitos definidos no quadro seguinte: ECRAIZESTADO - revoga o seu certificado; - emite nova LER; - gera nova chave; - dissemina novo certificado. NOTIFICA: - Tutela Politica da ECEE - Conselho Gestor; - Outras EC com quem tenha certificação cruzada; - EC subordinadas. ECESTADO OU SUBECESTADO - gera um pedido de revogação (CMP); - gera nova chave; - efectua pedido de certificado (PKCS#10); - recebe o novo certificado; - dissemina novo certificado. NOTIFICA: - ECEE - Conselho Gestor; - EC subordinadas e ER; - Todos os titulares. Tabela 10 Procedimentos em caso de comprometimento de chaves As DPC devem descrever de forma clara os procedimentos adoptados. Página 53 de 12054 CAPACIDADE DE CONTINUIDADE DA ACTIVIDADE EM CASO DE DESASTRE As EC devem obrigatoriamente dispor de um plano de continuidade da actividade, onde estão descritos todos os procedimentos a accionar em caso de desastre onde haja perda ou corrupção de dados, software e equipamentos. O Plano de Continuidade deverá garantir que os serviços indicados como críticos pela sua necessidade de disponibilidade estão disponíveis no Local Alternativo, devendo a DPC indicar o tempo máximo para activação dos serviços. Nas DPC deverá ser indicado, em caso de indisponibilidade das instalações da EC, o tempo máximo de inactividade antes de ser activado o respectivo Plano de Continuidade da Actividade PROCEDIMENTOS EM CASO DE EXTINÇÃO DE EC OU ER Em caso de cessação de actividade como prestador de serviços de Certificação, a EC deverá, atempadamente, com uma antecedência mínima de três meses, proceder às seguintes acções: a) Informar o Conselho Gestor do SCEE b) Informar a Entidade de Certificação Electrónica do Estado; c) informar todos os titulares de certificados; d) informar as EC com quem tenha efectuado acordos de certificação cruzada (caso existam); e) revogar todos os certificados e de certificados cruzados (caso existam); f) Efectuar uma notificação final aos titulares 2 (dois) dias antes da cessação formal da actividade; g) garantir a transferência (para retenção por outra organização) de toda a informação relativa à actividade da EC, nomeadamente, chave da EC, certificados, documentação em arquivos (interno ou externo), repositórios e arquivos de registo de eventos. Os arquivos devem ficar sob retenção de acordo com o estipulado no ponto Em caso de alterações do organismo/estrutura responsável de gestão da actividade da EC, esta deve informar de tal facto às entidades listadas nas alíneas anteriores. As DPC devem descrever de forma clara os procedimentos adoptados. Página 54 de 12055 6. MEDIDAS DE SEGURANÇA TÉCNICAS 6.1. GERAÇÃO E INSTALAÇÃO DO PAR DE CHAVES A geração dos pares de chaves dos vários participantes nesta Infra-estrutura de chaves públicas são processados de acordo com os requisitos e algoritmos definidos nesta politica GERAÇÃO DO PAR DE CHAVES A hierarquia do SCEE prevê a existência de participantes em três níveis. No primeiro nível, encontra-se a ECRaizEstado, que funciona obrigatoriamente em modo off-line, em que o respectivo par de chaves é gerado num módulo criptográfico, de acordo com requisitos definidos na secção e o certificado desta entidade é auto-assinado. No segundo nível, encontra-se as ECEstado, em que o seu funcionamento pode ser efectuado em modo off-line ou em modo on-line (devendo nestes casos obedecer aos requisitos descrito adiante no ponto 6.7). O respectivo par de chaves é gerado, obrigatoriamente, num módulo criptográfico com o nível de protecção adequada, que corresponde aos requisitos definidos no ponto O certificado desta entidade é assinado pela ECRaizEstado. Às entidade de terceiro nível aplicam-se os mesmos requisitos que às entidade de segundo nível. A geração do par de chaves para o titular é efectuada de acordo com as seguintes condições: Chaves para efeitos de Assinatura Digital e Autenticação O processo de geração das chaves é, obrigatoriamente, efectuado directamente num módulo criptográfico em hardware (p.e. smartcard), sob o único controlo do titular, não podendo ser feita qualquer cópia da mesma. O módulo criptográfico, tem obrigatoriamente, um nível de protecção de acordo com o especificado na secção Estes certificados são assinados pela EC respectiva. As DPC devem descrever de forma clara e em pormenor os procedimentos adoptados Chaves para efeitos de Confidencialidade O processo de geração das chaves é, obrigatoriamente, efectuado directamente num módulo criptográfico em hardware (p.e. smartcard). O módulo criptográfico, tem obrigatoriamente, um nível de protecção de acordo com o especificado na secção Estes certificados são assinados pela EC respectiva. As DPC devem descrever de forma clara e em pormenor os procedimentos adoptados, em particular se são efectuadas cópias de segurança, como é feita a sua retenção e a sua recuperação, caso seja necessário.56 ENTREGA DA CHAVE PRIVADA AO TITULAR Chaves para efeitos de Assinatura Digital e Autenticação A forma de entrega do módulo criptográfico, que contem as chaves, deve ser descrita nas respectivas DPC. No entanto, é obrigatório que a forma de entrega do módulo criptográfico e a forma de entrega do PIN de acesso a este não seja entrega em simultâneo Chaves para efeitos de Confidencialidade As DPC devem descrever de forma clara e em pormenor os procedimentos adoptados para entrega da chave privada e certificado ao seu titular ENTREGA DA CHAVE PÚBLICA AO EMISSOR DO CERTIFICADO Nos casos em que a entidade emissora do certificado não gera directamente o par de chaves, a sua entrega à EC emissora do certificado deve ser efectuada através de um pedido de certificado (PKCS#10), através de uma transacção on-line (de acordo com o especificado no RFC 2510) ou por outro método igualmente seguro desde que aprovado pelo Conselho Gestor do SCEE. Os métodos utilizados devem estar descritos nas respectivas DPC ENTREGA DA CHAVE PÚBLICA DA EC ÀS PARTES CONFIANTES A entrega da chave pública da EC, é efectuada pela disponibilização do seu certificado (p.e. no sítio Web ). Os formatos a disponibilizar podem ser em codificação DER (binário ou base64) ou no formato PKCS#7 (binário ou base64), com ou sem cadeia de certificação, dependendo dos requisitos estabelecidos na respectiva DPC. Outros formatos, para além dos descritos anteriormente, requerem autorização do Conselho Gestor do SCEE. As DPC devem descrever os métodos utilizados na entrega da chave da EC, bem como os formatos disponibilizados DIMENSÃO DAS CHAVES O que concerne, à dimensão das chaves, os vários participantes devem obedecer aos comprimentos mínimos de chaves: a) ECRaizEstado: RSA 4096 bit; b) ECEstado: RSA 2048 bit; c) subecestado: RSA 2048 bit; Página 56 de 12057 d) Titulares: RSA 1024 bit GERAÇÃO DOS PARÂMETROS DA CHAVE PÚBLICA E VERIFICAÇÃO DA QUALIDADE A geração dos parâmetros da chave pública e verificação da qualidade deverá ter sempre por base a norma que define o algoritmo. Em termos exemplificativos, para o caso do algoritmo RSA, deverá ser feita de acordo com o estipulado no PKCS#1 e RFC As chaves das EC devem ser geradas com base na utilização de processos aleatórios ou pseudo-aleatórios descritos, respectivamente, na ISO e ISO FINS A QUE SE DESTINAM AS CHAVES (CAMPO KEY USAGE X.509V3) O campo keyusage dos certificados deve ser utilizados de acordo com o recomendado no RFC CAMPO KEYUSAGE DO CERTIFICADO BIT ACTIVO digitalsignature 0 nonrepudiation (contentcommitment) 1 keyencipherment 2 dataencipherment 3 keyagreement 4 keycertsign 5 crlsign 6 encipheronly 7 decipheronly 8 Tabela 11 Definição dos campos Keyusage dos Certificados SCEE Chaves para efeitos de Assinatura Digital Este tipo de chaves é utilizado, primordialmente, para efeitos de autenticação, integridade e não-repudio da informação, devendo ser tido em consideração os seguintes aspectos: a) Quando utilizadas por EC, apenas é permitido que sejam utilizadas para assinar de certificados e CRL (keycertsign e crlsign) b) quando utilizadas pelos titulares, apenas são activadas para não-repudio (nonrepudiation - contentcommitment), de acordo com as recomendações dos Página 57 de 12058 RFC3280 e ETSI Não é permitida a presença de outros atributos nos certificados emitidos com este fim Chaves para efeitos de Autenticação Este tipo de chaves é utilizado, primordialmente, para a assinatura digital de , autenticação em sistemas, etc. Na prática, estas chaves irão dar suporte às actividades que requerem o uso estendido das chaves. Deve ser activado o bit digitalsignature, da extensão KeyUsage do certificado Chaves para efeitos de Confidencialidade Este tipo de chaves é utilizado, primordialmente, para a troca e estabelecimento de chaves de sessão e processamento da informação cifrada, devendo ser tido em consideração os seguintes aspectos: Neste tipo de chaves pelo menos um dos seguintes atributos deverá estar presente nos certificados: keyencipherment e/ou keyagreement. Não é permitida a presença de outros atributos nos certificados emitidos com este fim OUTRA UTILIZAÇÃO PARA AS CHAVES Podem ser atribuídas, adicionalmente, outro tipo de utilização das chaves, para alem da utilização base descrita anteriormente. A utilização alargada das chaves apenas é permitida para certificados de titulares (pessoas, organizações ou equipamentos). A extensão extkeyusage pode incluir, os seguintes tipos de utilização: a) Server Authentication; b) Client Authentication; c) CodeSigning; d) Protection ; e) TimeStamping; f) OCSPSigning g) Smart Card Logon; 6.2. PROTECÇÃO DA CHAVE PRIVADA E CARACTERÍSTICAS DO MÓDULO CRIPTOGRÁFICO Página 58 de 12059 Quando for requerida a utilização de módulos criptográficos para protecção das chaves privadas, os participantes desta infra-estrutura deverão empregar dispositivos devidamente avaliados e certificados por organismo e esquema de avaliação adequado para o efeito. O nível de avaliação de segurança requerido para os dispositivos varia em função do nível de protecção requerido e do nível hierárquico que o participante ocupa dentro da infraestrutura NORMAS E MEDIDAS DE SEGURANÇA DO MÓDULO CRIPTOGRÁFICO Aos módulos criptográficos utilizados pela ECRaizEstado, ECEstado ou subecestado, nomeadamente para as operações que dizem respeito à geração, armazenamento e assinatura, é requerida a conformidade e respectiva certificação em pelo menos uma das seguintes normas (ou critérios reconhecidos como equivalentes): a) FIPS PUB com nível 3 ou superior; b) CWA ; c) ISO/IEC em EAL 4 ou superior. Quando está em causa uma EREstado, os requisitos expressos anteriormente, referem-se às chaves do sistema /administrador da mesma. Aos titulares de certificados é requerida a utilização de módulos criptográficos certificados segundo o padrão ISO/IEC EAL4+ com suporte às normas PKCS#11 e CSP CONTROLO MULTI-PESSOAL (N DE M) PARA A CHAVE PRIVADA O controlo multi-pessoal apenas é utilizado para as chaves de EC, pois a chave privada dos certificados está sob exclusivo controlo do seu titular. Todas as operações deverão ser efectuadas com um mínimo de 2 pessoas (com funções qualificadas dentro da entidade) por tarefa, sendo empregues nas diversas funções, pelo menos 2 pessoas (N=2), entre o conjunto total de pessoas com funções atribuídas dentro da entidade (M=staff). As DPC deverão descrever de forma precisa o número de pessoal empregue por tarefa RETENÇÃO DA CHAVE PRIVADA (KEY ESCROW) Não é autorizada a retenção de chaves privadas para efeitos de assinatura digital. Esta autorizado a retenção de chaves privadas para efeitos de confidencialidade. Nos procedimentos para recuperação deste tipo de chaves, é requerido controlo multi-pessoal. As DPC deverão descrever de forma precisa os mecanismos utilizados CÓPIA DE SEGURANÇA DA CHAVE PRIVADA As chaves privadas dos titulares, para efeitos de assinatura digital, não são alvo de qualquer cópia de segurança. Página 59 de 12060 As chaves privadas das Entidades Certificadoras do SCEE deverão ser alvo, obrigatoriamente, de pelo menos uma cópia de segurança, a realizar pela própria entidade. As cópias de segurança deverão ter o mesmo nível de segurança que a chave original ARQUIVO DA CHAVE PRIVADA Todas as chaves que tenham sido alvo de cópias de segurança, deverão ser arquivadas de acordo com o estabelecido na secção TRANSFERÊNCIA DA CHAVE PRIVADA PARA/DO MÓDULO CRIPTOGRÁFICO No caso das chaves com utilização para efeitos de assinatura digital a transferência de e para o modulo criptográfico não se aplica, uma vez que são geradas dentro deste. Assim esta situação não é aplicável para as chaves das EC, nem para as chaves de titulares, quando utilizadas para efeitos de assinatura digital. No caso das chaves com utilização para efeitos de confidencialidade, se estas não forem geradas dentro do módulo criptográfico, a forma de a transferir deverá ser efectuada de acordo com o descrito no RFC ARMAZENAMENTO DA CHAVE PRIVADA NO MÓDULO CRIPTOGRÁFICO As chaves das EC são geradas e guardadas em módulo criptográfico de acordo com o especificado na secção PROCESSO PARA ACTIVAÇÃO DA CHAVE PRIVADA A chave privada deverá ser activada quando o sistema quando o sistema/aplicação da EC é ligado ( startup process ). Esta activação só deverá ser efectivada quando previamente tiver sido feita a autenticação no módulo criptográfico pelos indivíduos indicados para o efeito. O mecanismo de autenticação mínimo exigido é a autenticação por PIN/ palavra-chave. O número máximo de tentativas de autenticação permitidas não deve ser superior a 5 tentativas. As DPC deverão descrever o procedimento utilizado para activação da chave privada, bem como a identificação e interacção das pessoas com o sistema/aplicação/módulo criptográfico durante o processo PROCESSO PARA DESACTIVAÇÃO DA CHAVE PRIVADA A chave privada deverá ser desactivada quando o sistema quando o sistema/aplicação da EC é desligado ( shutdown process ). Esta desactivação só deverá ser efectivada quando previamente tiver sido encerrada a sessão com o módulo criptográfico. Página 60 de 12061 Neste processo, antes de finalizado, deve ser garantido que todas as chaves são eliminadas da memória do módulo criptográfico. Qualquer espaço em disco, onde a chave tenha sido eventualmente armazenada, deve ser reescrito As DPC deverão descrever o procedimento utilizado para desactivação da chave privada, bem como a identificação e interacção das pessoas com o sistema/aplicação/módulo criptográfico durante o processo PROCESSO PARA DESTRUIÇÃO DA CHAVE PRIVADA As várias chaves privadas devem ser destruídas sempre que deixarem de ser necessárias,. De forma geral, esta actividade deve ser precedida sempre pela revogação do certificado, no caso de estar em vigor. Para além do descrito no ponto anterior (6.2.9), as respectivas cópias de segurança devem também ser alvo de destruição. A destruição das chaves privadas podem passar por processos diversos, consoante se enquadrem nos casos descritos a seguir: a) sem formatação do modulo criptográfico: Nas situações renovação de chaves (de rotina), a destruição da chave privada antiga é efectuada reescrevendo a nova chave privada do titular. b) com formatação do modulo criptográfico: Nas situações em a chave privada deixou de poder ser utilizada, nomeadamente, após expiração ou revogação do certificado. c) destruição física: Sempre que existam modulo criptográficos personalizados, nomeadamente smartcards com fotografia. Antes da sua destruição física, devem ser previamente formatados. Todos os procedimentos relativos à destruição das chaves privadas, bem como a gestão do ciclo de vida dos módulos criptográficos personalizados devem estar descritos nas respectivas DPC AVALIAÇÃO/NÍVEL DO MÓDULO CRIPTOGRÁFICO Descrito no ponto OUTROS ASPECTOS DA GESTÃO DO PAR DE CHAVES ARQUIVO DA CHAVE PÚBLICA As EC devem efectuar o arquivo das suas chaves e das chaves por si emitidas (para efeitos de assinatura digital), permanecendo armazenadas após a expiração dos certificados correspondentes, de acordo com os requisitos definidos no ponto 5.5, para verificação de assinaturas geradas durante seu prazo de validade. Página 61 de 12062 PERÍODOS DE VALIDADE DO CERTIFICADO E DAS CHAVES O período de utilização das chaves é determinado pelo período de validade do certificado, pelo que após expiração do certificado as chaves deixam de poder ser utilizadas, dando origem à cessação permanente da sua operacionalidade e da utilização que lhes foi destinada. Neste sentido a tabela seguinte apresenta a validade dos diversos tipos de certificados e período em que os mesmos devem ser renovados. Os valores estão expressos em anos. [VALIDADE DOS CERTIFICADOS] [PERÍODO DE RENOVAÇÃO] ECRaizEstado ECEstado subecestado Outras Entidades PKI Hardware Titulares Software [24] [12] [12] [6] [6] [3] [3] [3] [3] [3] [1] [1] Outras Entidades PKI: EREstado, Serviços de Validação Cronológica e Serviços de Validação On-line do Estado de Certificados Tabela 12 Definição dos Períodos de Validade dos Certificados 6.4. DADOS DE ACTIVAÇÃO GERAÇÃO E INSTALAÇÃO DOS DADOS DE ACTIVAÇÃO Os dados de activação devem ser gerados de forma a serem únicos e imprevisíveis. Os dados de activação conjugados com outro tipo de controlo de acessos, deve ter um adequado nível de robustez para as chaves e dados a proteger. A entrada de uma EC no domínio da SCEE, requer a existência de dispositivos/mecanismos criptográficos (p.e. smartcards) para suporte às actividades das EC, nomeadamente no seu funcionamento e na sua recuperação. A actividade das EC é efectuada com base em funções diferenciadas, cada uma com o correspondente dispositivo onde se encontram os respectivos dados de activação PROTECÇÃO DOS DADOS DE ACTIVAÇÃO Apenas o pessoal autorizado tem em posse os dispositivos (p.e. Smartcard, PED, etc.) e respectivo segrego (p.e. PIN) dos dados de activação das EC. No caso de chaves associadas a certificados de titulares, apenas o próprio conhece o respectivo segredo para activação, sendo este o único e exclusivo responsável pela protecção e guarda dos dados de activação das suas chaves. Página 62 de 12063 OUTROS ASPECTOS DOS DADOS DE ACTIVAÇÃO Não estipulado MEDIDAS DE SEGURANÇA INFORMÁTICA Os dados relativos a esta secção são considerados sensíveis, sendo apenas disponibilizados a quem tiver necessidade de conhecer. No domínio da SCEE, apenas são fornecidos à Entidade de Certificação Electrónica do Estado, ao Conselho Gestor do SCEE e a Autoridade Credenciadora. Cada EC deve implementar o conjunto de medidas de segurança consideradas adequadas, em resultado da arquitectura escolhida e dos riscos avaliados. As DPC devem conter uma descrição das medidas de segurança implementadas, sem colocar em causa a segurança dos sistemas por eventual excesso de divulgação de informação REQUISITOS TÉCNICOS ESPECÍFICOS De forma geral os sistemas que compõe a EC devem proporcionar, desde que aplicável, no mínimo, as seguintes capacidades/funcionalidades: a) As descritas no ponto 5, do documento CWA ; b) mecanismos para recuperação dos sistemas e chaves de EC; c) dispositivos de protecção de fronteira, nomeadamente, firewall, IDS/IPS. Os requisitos definidos anteriormente, devem ser alcançados pela conjunção dos diversos sistemas que compõem os sistemas seguro da EC (p.e. sistema operativo, software, HSM, medidas de segurança física, etc.). Outros tipos de software (p.e. antivírus,), só deve ser instalado se for verificados que: a) não interfere com as configurações previamente definidas pelos fabricantes/organismos de avaliação; e b) se demonstrar que proporciona um acréscimo no nível de segurança. De modo general as EC devem seguir as boas práticas estabelecidas na norma ISO 17799: AVALIAÇÃO/NÍVEL DE SEGURANÇA Os vários sistemas e produtos empregues pelas EC, no domínio da SCEE, são fiáveis e protegidos contra modificações. Os produtos e sistemas referidos, são avaliados, estando em conformidade com os requisitos definidos na especificação técnica CWA e/ou com a norma ISO ou perfil equivalente. Página 63 de 12064 6.6. CICLO DE VIDA DAS MEDIDAS TÉCNICAS DE SEGURANÇA Os dados relativos a esta secção são considerados sensíveis, sendo apenas disponibilizados a quem tiver necessidade de conhecer. No domínio da SCEE, apenas são fornecidos à ECEE, ao Conselho Gestor do SCEE e a Autoridade Credenciadora. Cada EC deve implementar o conjunto de medidas de segurança consideradas adequadas, em resultado da arquitectura escolhida e dos riscos avaliados. As DPC devem conter uma descrição das medidas de segurança implementadas, sem colocar em causa a segurança dos sistemas por eventual excesso de divulgação de informação MEDIDAS DE DESENVOLVIMENTO DO SISTEMA São exigidos requisitos de segurança desde o início, na aquisição dos sistemas informáticos como no instalação e implementação dos mesmos, visto que podem ter algum impacto dobre a segurança da SCEE. Serão realizadas análises dos requisitos de segurança durante as fases de desenho e especificação de requisitos de qualquer componente utilizado nas aplicações que constituem cada um dos sistemas da SCEE, para garantir que os sistemas são seguros. Utilizam-se procedimentos de verificação de alteração de versões, actualizações e instalação de patches ou fixes dos ditos componentes. A infra-estrutura das ECs deve estar dotadas de ambientes de desenvolvimento e préprodução segregados dos ambientes de produção MEDIDAS PARA A GESTÃO DA SEGURANÇA A EC deve manter actualizado um inventário com todos os activos (equipamento, dados e pessoal), sendo classificados de acordo com a sua importância e necessidades de protecção, tendo em conta o normal funcionamento da actividade da EC. Esta classificação deve estar coerente com a análise de riscos inicial. De modo geral as EC devem regular a sua actividade pela adopção dos seguintes princípios: a) Os produtos e sistemas da EC devem única e exclusivamente ser utilizados para as actividades de certificação; b) A configuração dos produtos e sistemas da EC, tal como a sua manutenção devem ser sempre documentadas; c) Nos sistemas das EC apenas deve ser instalado aplicações e componentes indispensáveis para o seu funcionamento; d) Devem estar previstos mecanismo para detecção de eventuais modificações na sua configuração; e) Devem ser adoptadas medidas adequadas para a prevenção de software malicioso Página 64 de 12065 carregado através dos equipamentos das ER; f) Depois de instalado, os sistemas e produtos da EC devem efectuar verificações da sua integridade, de forma periódica, nunca ultrapassando, o período de 30 dias entre verificações. A DPC deve descrever a medidas adoptadas, com um detalhe que não coloque em causa a segurança do sistema CICLO DE VIDA DAS MEDIDAS DE SEGURANÇA As operações de actualização e manutenção dos produtos e sistemas das EC, devem seguir o mesmo controlo que o equipamento original e deve ser instalado pelo pessoal com funções de confiança, com adequada formação para o efeito, seguindo os procedimentos definidos para o efeito. Nas DPC devem estar descritos os procedimentos a seguir para a actualização e manutenção dos produtos e sistemas que compõe o sistema da EC MEDIDAS DE SEGURANÇA DA REDE Os sistemas da EC que se encontrem a funcionar em modo on-line devem estar protegidos de eventuais ataques em virtude de estarem interligados, directa ou indirectamente, a redes externas. Esta protecção deve ser garantida com o recurso a equipamentos de protecção de fronteira, nomeadamente, um Firewall, configurado de forma a permitir apenas a utilização de protocolos e comandos necessários para o correcto funcionamento do sistema da EC responsável pela emissão dos certificados. A DPC deve descrever a medidas de segurança de rede adoptadas, com um detalhe que não coloque em causa a segurança do sistema VALIDAÇÃO CRONOLÓGICA (TIME-STAMPING) As EC integradas na infra-estrutura de chave pública da SCEE, asseguram que a data e a hora incluída em todas as fases do ciclo de vida do certificado, são determinadas através de uma fonte de tempo segura, nomeadamente, a do Observatório Astronómico de Lisboa. Os dados relacionados com a geração e a gestão das chaves utilizadas na validação cronológica, incluindo os dados associados à certificação da hora por um instituto nacional de medida, são registados e arquivados por um período mínimo de 20 anos. Neste contexto, os serviços de validação cronológica, associam com recurso a mecanismos e protocolos baseados em criptografia de chave pública os dados e o tempo, garantindo em todo o momento que: a) A origem e a validade de cada pedido de validação cronológica são conhecidas; b) O pedido utiliza um algoritmo criptográfico aprovado pelo Conselho Gestor do SCEE; c) É utilizada a hora UTC, certificada pelo OAL, com incerteza inferior a 100 milissegundos; Página 65 de 12066 d) Os dados incluídos no pedido são devolvidos garantindo a sua integridade, sem alteração ou modificação; e) A chave privada utilizada na assinatura da prova de validação cronológica: f) Apenas é utilizada para esse fim; g) Utiliza um algoritmo criptográfico aprovado pelo Conselho Gestor do SCEE; h) É gerada e armazenada num módulo criptográfico, de acordo com as especificações definidas no ponto 6.2.1; i) Em cada prova de validação cronológica são incluídos: j) O valor tempo certificado; k) Um identificador único; l) Um indicador único da política de certificação cronológica adoptada; m) O grau de exactidão do valor tempo utilizado sempre que aquele seja superior ao indicado na política adoptada; n) A prova de validação cronológica é assinada criptograficamente antes da devolução da resposta ao pedido; o) Não está incluída, na prova de validação cronológica, a identificação da entidade que a solicitou. Página 66 de 12067 7. PERFIS DE CERTIFICADO, CRL E OCSP 7.1. PERFIL DO CERTIFICADO A emissão de certificados é feita segundo o perfil de Certificados ITU-T X.509 versão 3, de acordo, com as recomendações definidas no RFC 3280, RFC 3739, ETSI TS e ETSI Os certificados emitidos pelas EC, no domínio da SCEE, devem incluir,: CAMPO DESCRIÇÃO serialnumber numero inteiro que indica o número de série do certificado; signature OID do algoritmo utilizado pela EC para assinar o certificado; issuer um X.500 DN da EC que emite o certificado o período de tempo em que o certificado é considerado válido. validity nos certificados até 2049: representado num UTC Time (YYMMDDHHMMSSZ). nos certificados após 2049: representado num generalized time (YYYYMMDDHHMMSSZ). subject um X.500 DN a quem é atribuído o certificado subjectpublickeyinfo OID do algoritmo e uma cópia da chave publica do certificado Tabela 13 Campos básicos do certificado NÚMERO(S) DE VERSÃO Neste campo os certificados deverão conter o valor 2 (dois), de forma a identificar a utilização de certificados ITU-T X.509 versão EXTENSÕES DO CERTIFICADO Todos os sistemas das várias entidades deverão processar correctamente todas as extensões identificadas no RFC authoritykeyidentifier Extensão obrigatória e não critica. Esta extensão é utilizada para verificar a assinatura do certificado, possibilitando que as várias chaves utilizadas pelas EC na assinatura dos certificados, sejam facilmente diferenciadas. O valor do keyidentifier deve derivar da chave pública da EC (normalmente um hash da chave pública que consta no campo subjectpublickeyinfo do certificado da EC que o emitiu). Nos certificados auto-assinados não é utilizado.68 subjectkeyidentifier Extensão obrigatória e não critica. Esta extensão é utilizada para identificar de forma inequívoca a chave pública do certificado. Possibilita que várias chaves sejam utilizadas pelo mesmo subject e que sejam facilmente diferenciadas. O valor utilizado é normalmente um hash da chave pública que consta no campo do certificado subjectpublickeyinfo KeyUsage Extensão obrigatória e critica. Especificado na secção deste documento certificatepolicies Extensão obrigatória e não critica. Esta extensão lista as Politicas de Certificados que dão suporte e regem o ambiente em que se processou a emissão do certificado. Deve ser incluído o OiD da Politica de Certificado e o URL da DPC BasicConstraints: É uma extensão obrigatória e crítica para Certificados de EC, é opcional para certificados de titular. Se o certificado é um certificado de EC, o valor ca, deverá estar activo (ca=true). Em termos práticos, se num certificado o campo keyusage estiver presente o valor keycertsign, então no BasicConstraints, o valor do campo ca, deverá ser estar activo, ou o processo de verificação do certificado falha Authority Information Access A extensão Authority Information Access, é introduzida nos vários perfis de certificados definidos no âmbito da SCEE, de forma a permitir futuras implementações para verificação via OSCP, sem que para isso haja necessidade de futuras alterações nesta infra-estrutura de chaves públicas IDENTIFICADORES DE ALGORITMO ALGORITMO OID Sha1WithRSAEncryption Sha256withRSAEncryption rsaencryption Tabela 14 Identificadores OiD de Algoritmos Página 68 de 12069 FORMATOS DE NOME Os Certificados emitidos para cada entidade do SCEE são referenciados através de um DN, a aplicar nos campos issuer e subject do certificado. Os DN deverão ser representados através de uma X.501 UTF8String RESTRIÇÕES DE NOME Os nomes incluídos nos certificados estão restritos à utilização de DN, únicos e sem ambiguidades. O atributo C (countryname) é codificado de acordo com a ISO alpha-2 code elements, numa PrintableString OBJECTO IDENTIFICADOR DA POLÍTICA DE CERTIFICADO Todos os certificados emitidos pelas Entidades Certificadoras do SCEE devem garantir a inclusão do OID da Politica de certificado UTILIZAÇÃO DA EXTENSÃO DE RESTRIÇÃO DE POLÍTICAS Nada a assinalar SINTAXE E SEMÂNTICA DOS QUALIFICADORES DE POLÍTICAS Nos certificados emitidos, as Entidades Certificadoras devem incluir no campo policyqualifiers da extensão CertificatePolicies o URL da sua DPC. Nas DPC poderão ser estabelecidos a utilização do Policy Qualifier, o campo Notice Reference. O Notice Reference, é uma nota de texto que aparece no monitor, quando se procede a verificação do certificado SEMÂNTICA DE PROCESSAMENTO DA EXTENSÃO DE POLÍTICA DE CERTIFICADOS CRÍTICOS Tendo em consideração as recomendações introduzidas pelo RFC 3280, quanto à utilização desta extensão, os certificados das EC do SCEE devem incluir no OiD o valor Esta opção tem como objectivo não limitar, em termos futuros, o conjunto de políticas a emitir sob o domínio de certificação da SCEE. Nos certificados para titulares serão incluídos os OiD respectivo, tendo em conta a sua aplicação. Esta extensão é marcada como não critica para evitar problemas de interoperabilidade. Página 69 de 12070 7.2. PERFIL DA LCR Cada EC da SCEE, na emissão de uma LCR, deve obrigatoriamente incluir: CAMPO signature issuer DESCRIÇÃO OID do algoritmo utilizado pela EC para assinar o certificado; o algoritmo e respectivo OID um X.500 DN da EC que emite o certificado o X.500 DN da EC que gerou a LCR; thisupdate a indicação de quando a LCR foi gerada nextupdate a indicação de quando será gerada nova LCR revokedcertificates deverá ser introduzida a sequencia de dados correspondentes aos campos usercertificate, revocationdate e crlentryextensions, de forma a fornecer informação do estado dos certificados no que diz respeito, respectivamente, ao numero de série do certificado revogado, a data em que foi revogado e o motivo da sua revogação Tabela 15 Campos básicos do certificado Adicionalmente, as diversas aplicações e sistemas utilizados pelos participantes que integram a SCEE, devem garantir, entre outras que: a) A verificação da assinatura constante na LCR, através da chave pública constante no certificado da EC que emite a LCR; b) Verificar a cadeia de certificação do certificado da EC; c) Verificar que é utilizada a versão 2; d) No momento da verificação a data está enquadrada de acordo com os valores indicados nos campos da LCR thisupdate e nextupdate ; e) A LCR que está a ser verificada, no seu campo CRLNumber, o valor indicado é superior ao valor constante no mesmo campo da LCR já existente; f) Que a entidade que emite a LCR é a mesma que emitiu o certificado; NÚMERO(S) DA VERSÃO As CRL emitidas pelas EC, devem implementar versão 2 padrão ITU X.509, de acordo com o RFC 3280 Página 70 de 12071 EXTENSÕES DA CRL E DAS SUAS ENTRADAS A SCEE define como extensões de CRL obrigatórias, não criticas, as seguintes: g) CRLNumber, implementado de acordo com as recomendações do RFC 3280; h) AuthorityKeyIdentifier: contem um identificador da chave pública da EC que assinou a LCR; 7.3. PERFIL DO OCSP Se o serviço de OCSP for implementado, os certificados de OCSPResponder, devem estar em concordância com as seguintes normas: a) RFC 3280; b) ITU-T X.509 (2005); c) RFC E tendo em conta os seguintes constrangimentos: a) O período de validade não deve ser superior a 6 meses. b) No certificado de OCSP será incluída a extensão id-pkix-ocsp-nocheck. No entanto, de futuro não deve ser excluída a possibilidade de inclusão da extensão AIA, fornecendo informação sobre os mecanismos adicionais para comprovação da validade dos certificados NÚMERO(S) DA VERSÃO Os certificados de OCSP Responder utilizam a norma X.509 versão 3 (X.509 v3) EXTENSÕES DO OCSP Os certificados de OCSP Responder emitidos por uma EC no domínio do SCEE incluirão o DN da entidade emissora e do titular, nos campos issuer name e subject name, respectivamente. Os campos e extensões utilizadas nos certificados de OCSP Responder são: a) Version; b) serialnumber; c) subject; d) issuer; e) signingalgorithms; f) validityperiod; g) extkeyusage; h) subjectkeyidentifier; Página 71 de 12072 i) authoritykeyidentifier issuerandserialpresent; j) KeyUsage, marcada como crítica; k) BasicConstraint, marcada como crítica; l) CertificatePolicies; m) OCSPNocheck; n) AIA; Página 72 de 12073 8. AUDITORIA E AVALIAÇÕES DE CONFORMIDADE Todas as EC integradas na hierarquia da SCEE, devem obrigatoriamente, construir as suas DPC em conformidade com os requisitos mínimos definidos neste documento. São alvo de auditoria todas as entidades que directa ou indirectamente exerçam actividade de certificação nos termos do definido nesta politica, como são o caso da ECRaizEstado, das ECEstado e das subecestado e EREstado, caso existam. A Autoridade Credenciadora é o organismo responsável pela condução das auditorias de conformidade, podendo recorrer a pessoal externo FREQUÊNCIA OU MOTIVO DA AUDITORIA De acordo com o descrito no ponto 8, as diversas entidades são alvo de auditoria nas seguintes situações: a) No processo de integração na SCEE; b) Anualmente; e c) A qualquer momento, sem aviso prévio. As EC do Estado devem declarar na DPC a frequência das auditorias, sendo que estas devem ser realizadas pelo menos uma vez por ano, de forma a garantir a adequação do funcionamento e operação de acordo com a DPC. Podem ser levadas a cabo outras auditorias técnicas e de segurança segundo o estabelecido nas DPC. Cada EC deverá efectuar com uma regularidade a explicitar, auditorias de cumprimento de legislação e de protecção de dados pessoais 8.2. IDENTIDADE E QUALIFICAÇÕES DO AUDITOR O auditor é uma pessoa ou organização, de reconhecida idoneidade, com experiência e qualificações comprovadas na área da segurança da informação e dos sistemas de informação, infra-estruturas de chaves pública, familiarizado com as aplicações e programas de certificação digital e na execução de auditorias de segurança. A Autoridade Credenciadora é responsável pela selecção e nomeação do pessoal que realiza a auditoria. O auditor deverá ser seleccionado no momento da realização de cada auditoria, devendo em termos gerais cumprir os seguintes requisitos: a) Experiência em PKI, segurança e processos de auditoria em sistema de informação b) Independência a nível orgânico da Entidade Certificadora (para os casos de auditorias externas) Deve ser credenciado pelo Gabinete Nacional de Segurança 8.3. RELAÇÃO ENTRE O AUDITOR E A ENTIDADE CERTIFICADORA O auditor e membros da sua equipa são independentes, não actuando de forma parcial ou discriminatória em relação à entidade que é submetida à auditoria.74 Na Relação entre o auditor e a entidade submetida a auditoria, deve estar garantido inexistência de qualquer vínculo contratual. O Auditor e a parte auditada (Entidade Certificadora) não devem ter nenhuma relação, actual ou prevista, financeira, legal ou de qualquer outro género que possa originar um conflito de interesses. O cumprimento do estabelecido na legislação em vigor sobre a protecção de dados pessoais, deve ser tida em conta por parte do auditor, na medida em que o auditor poderá aceder a dados pessoais dos ficheiros dos titulares das EC ÂMBITO DA AUDITORIA A auditoria de segurança é efectuada com base nos requisitos mínimos definidos neste documento e na DPC da entidade que irá ser alvo da auditoria. As auditorias determinam a conformidade dos serviços das EC do Estado com estas Políticas de Certificados e com as Declarações de Práticas. Também devem determinar a adequação referente aos seguintes documentos: a) Política de Segurança b) Segurança Física c) Avaliação Tecnológica d) Gestão dos serviços da EC e) Selecção de Pessoal f) DPC e PC (em vigor) g) Contratos h) Política de Privacidade As auditorias podem ser completas ou parciais, incidir sobre qualquer outro tipo de documentos / procedimentos, tendo em consideração os critérios definidos no CWA PROCEDIMENTOS APÓS UMA AUDITORIA COM RESULTADO DEFICIENTE Se duma auditoria resultarem irregularidades, o auditor procede da seguinte forma: a) Documenta todas as deficiências encontradas durante a auditoria; b) No final da auditoria reúne com os responsáveis da entidade submetida a auditoria e apresenta de forma resumida um relatório de primeiras impressões (RPI); c) Elabora o relatório auditoria. Este relatório deverá estar organizado de modo a que todas as deficiências sejam escalonadas por ordem decrescente de gravidade/severidade; d) Submete o relatório de auditoria à Entidade de Certificação Electrónica do Estado e ao Conselho Gestor do SCEE para apreciação; e) Depois de apreciado e consolidado, é remetida uma cópia do relatório de auditoria Página 74 de 12075 final (RAF), para a entidade; f) Tendo em conta a irregularidades constantes no relatório, a entidade submetida à auditoria enviará uma relatório de correcção de irregularidades (RCI), para a ECEE, no qual deve estar descrito quais as acções, metodologia e tempo necessário para corrigir as irregularidades encontradas; g) A Entidade de Certificação Electrónica do Estado obtém parecer consultivo do Conselho Gestor e em conjunto com a Autoridade Credenciadora depois de analisar este relatório tomam uma das três seguintes opções, consoante o nível de gravidade/severidade das irregularidades: i. Aceitam os termos, permitindo que a actividade seja desenvolvida até à próxima inspecção; ii. Permitem que a entidade continue em actividade por um período máximo de 60 dias até à correcção das irregularidades antes da revogação; iii. Revogação imediata da actividade COMUNICAÇÃO DE RESULTADOS Os resultados devem ser comunicados de acordos com os prazos estabelecidos no quadro seguinte: COMUNICAÇÃO DE RESULTADOS AUDITOR ENTIDADE ECEE RPI RAF No final da auditoria 2 semanas RCI 1 semana Decisão sobre irregularidades 4 semanas Tabela 16 Prazos de comunicação dos resultados de Auditoria Página 75 de 12076 9. OUTRAS SITUAÇÕES E ASSUNTOS LEGAIS 9.1. TAXAS TAXAS POR EMISSÃO OU RENOVAÇÃO DE CERTIFICADOS As taxas de emissão ou renovação de certificados se existirem, devem estar detalhadas na DPC TAXAS PARA ACESSO A CERTIFICADO De forma geral, da a natureza pública de que se reveste a SCEE, o acesso será tendencialmente gratuito, no entanto, a EC deve descrever a sua aplicabilidade na sua DPC TAXAS PARA ACESSO A INFORMAÇÃO DO ESTADO CERTIFICADO OU DE REVOGAÇÃO O acesso a informação sobre o estado ou revogação dos certificados é livre e gratuita não se podendo aplicar nenhuma taxa TAXAS PARA OUTROS SERVIÇOS De forma geral, da a natureza pública de que se reveste a SCEE, o acesso será tendencialmente gratuito, no entanto, a EC deve descrever a sua aplicabilidade na sua DPC POLÍTICA DE REEMBOLSO Nos casos em que a DPC especifique alguma taxa aplicável à prestação de serviços de certificação ou revogação para determinado tipo de certificados, é obrigatório que esse documento especifique a Política de reembolso RESPONSABILIDADE FINANCEIRA SEGURO DE COBERTURA As Entidade Certificadoras do Estado, devem respeitar a legislação em vigor no que se concerne aos seguros de cobertura de responsabilidade civil, devendo identificar nas respectivas Declarações de Práticas o montante e a cobertura OUTROS RECURSOS Como as Entidades Certificadoras do SCEE pertencem ao Estado Português, não estão sujeitas aos riscos inerentes às Entidade Certificadoras Privadas.77 SEGURO OU GARANTIA DE COBERTURA PARA UTILIZADORES Existindo seguro de ou garantia de Cobertura para Utilizadores, as EC devem especifica-los na DPC CONFIDENCIALIDADE DA INFORMAÇÃO PROCESSADA O pedido de inclusão no certificado de dados pessoais da pessoa singular a constar como seu titular terá de ser expressamente autorizado pela própria ÂMBITO DA CONFIDENCIALIDADE DA INFORMAÇÃO Declara-se expressamente como informação confidencial aquela que não poderá ser divulgada a terceiros: a) As chaves privadas das Entidades que compõem a SCEE; b) As chaves privadas dos titulares da SCEE; c) Toda a informação relativa aos parâmetros de segurança, controlo e procedimentos de auditoria; d) Toda a informação de carácter pessoal proporcionada às EC durante o processo de registo dos subscritores de certificados, salvo se houver autorização explicita para a sua divulgação; e) Planos de continuidade de negócio e recuperação; f) Registos de transacções, incluindo os registos completos e os registos de auditoria das transacções; INFORMAÇÃO FORA DO ÂMBITO DA CONFIDENCIALIDADE DA INFORMAÇÃO Considera-se informação de acesso público: a) Política de Certificados b) Declaração de Práticas de Certificação c) Os certificados para efeitos de confidencialidade, desde que declarado na respectiva DPC; d) LCR e LER; e) Toda a informação classificada como pública As Entidades Certificadoras devem permitir o acesso a informação não confidencial sem prejuízo do que se venha a estabelecer nas DPC nos controles de segurança necessários para proteger a autenticidade e integridade da mesma RESPONSABILIDADE DE PROTECÇÃO DA CONFIDENCIALIDADE DA INFORMAÇÃO Página 77 de 12078 Deve ser declarado na DPC a responsabilidade de protecção da confidencialidade da informação PRIVACIDADE DOS DADOS PESSOAIS As Entidades Certificadoras devem ter uma Política de Privacidade nos seus repositórios, onde se declara o cumprimento das disposições estabelecidas na legislação de protecção de dados pessoais, tendo em consideração que: a) As EC só podem coligir dados pessoais necessários ao exercício das suas actividades e obtê-los directamente das pessoas interessadas na titularidade dos dados de criação e verificação de assinatura e respectivos certificados, ou de terceiros junto dos quais aquelas pessoas autorizem a sua colecta; b) Os dados pessoais coligidos pela EC não poderão ser utilizados para outra finalidade que não seja a de certificação, salvo se outro uso for consentido expressamente por lei ou pela pessoa interessada; c) As EC respeitarão as normas legais vigentes sobre a protecção, tratamento e circulação dos dados pessoais e sobre a protecção da privacidade no sector das telecomunicações MEDIDAS PARA GARANTIA DA PRIVACIDADE No cumprimento do estabelecido pela lei sobre assinaturas electrónicas, informação de carácter pessoal disponibilizada às EC do Estado pelos titulares de certificados, deve ser tratada de acordo com a lei de protecção de dados pessoais. Desta forma cada DPC deve declarar a existência de um ficheiro de dados utilizadores de assinaturas electrónicas, indicando a responsabilidade do mesmo e a autorização da CNPD INFORMAÇÃO PRIVADA A informação pessoal que não incluída nos certificados, bem como o mecanismo de comprovação do estado dos certificados, devem ser considerados informação de carácter privado. Em qualquer caso são exemplos de informação considerada privada: a) Pedidos de certificados, aprovados ou negados assim como toda a informação pessoal obtida para a emissão e manutenção de certificados; b) Chaves privadas geradas e/ou armazenadas pelas EC da SCEE c) Os dados pessoais a que se refere a Lei 67/98 Em nenhum caso as EC do Estado poderão incluir nos certificados que emitem, os dados que se faz referência no artigo 7 da Lei 67/98. Página 78 de 12079 INFORMAÇÃO NÃO PROTEGIDA PELA PRIVACIDADE Esta informação é referente à informação pessoal que se inclui no certificados e no mecanismo de comprovação do estado dos mesmos de com a secção 3.1 deste Documento. Esta informação, proporcionada aquando do pedido de certificado é incluída nos certificados. Esta informação não tem carácter privado / reservado, sendo deste modo pública caso seja consentido pelo titular. Em todo o caso não é considerada confidencial a seguinte informação: a) O período de validade do certificado assim como a data de emissão do certificado e a data de caducidade; b) O número de série do certificado; c) Os diferentes estados e situações do certificado e a data do inicio de cada um deles; d) As lista de revogação de certificados (CRL) assim como o resto das informação de estado de revogação; e) A informação contida no Repositório das EC RESPONSABILIDADE DE PROTECÇÃO DA INFORMAÇÃO PRIVADA As EC devem garantir o cumprimento das suas obrigações, como previsto neste documento NOTIFICAÇÃO E CONSENTIMENTO PARA UTILIZAÇÃO DE INFORMAÇÃO PRIVADA Para a prestação de serviço, as EC deverão obter o consentimento dos titulares dos dados necessários para a prestação do serviço de certificação. Considera-se obtido o consentimento por parte do titular a oposição da assinatura do TRT DIVULGAÇÃO RESULTANTE DE PROCESSO JUDICIAL OU ADMINISTRATIVO As EC só poderão fornecer dados e informações consideradas, no âmbito desta politica, como informação privada, nos pressupostos em que estes são requeridos pela autoridade pública competente no âmbito da lei vigente. Em concreto, as EC estão obrigadas a revelar a identidade dos assinantes quando lhes for solicitado pelos órgãos judiciais no exercício das funções que lhe sejam atribuídas OUTRAS CIRCUNSTÂNCIAS PARA REVELAÇÃO DE INFORMAÇÃO As EC devem incluir na sua política de privacidade prevista no ponto 9.4, regras para permitir a divulgação de informação dos titulares das chaves, directamente aos mesmos ou a terceiros. Página 79 de 12080 9.5. DIREITOS DE PROPRIEDADE INTELECTUAL Todos os direitos de propriedade intelectual, incluindo os que se referem a certificados e LCR emitidos, OID, DPC, PC e PCert, bem como qualquer outro documento, propriedade das EC pertencem à respectiva EC. As chaves privadas e as chaves públicas são propriedade do titular, independentemente do meio físico que se empregue para o seu armazenamento. O Titular conserva sempre o direito sobre as marcas, produtos ou nome comercial contido no certificado REPRESENTAÇÕES E GARANTIAS REPRESENTAÇÃO E GARANTIAS DAS ENTIDADES CERTIFICADORAS As Entidade Certificadoras do SCEE estão obrigadas a: a) Realizar as suas operações de acordo com esta Política; b) Declarar de forma clara todas as suas Práticas de Certificação no documento apropriado DPC; c) Proteger as suas chaves privadas; d) Emitir certificados de acordo com o standard X.509; e) Emitir certificados que estejam conformes com a informação conhecida no momento de sua emissão e livres de erros de input de dados; f) Garantir a confidencialidade no processo da geração dos dados da criação da assinatura e a sua entrega por um procedimento seguro ao titular; g) Utilizar sistemas e produtos fiáveis que estejam protegidos contra toda a alteração e que garantam a segurança técnica e criptográfica dos processos de certificação; h) Utilizar sistemas fiáveis para armazenar certificados reconhecidos que permitam comprovar a sua autenticidade e impedir pessoas não autorizadas alterem os dados; i) Arquivar sem alteração os certificados emitidos; j) Garantir que podem determinar com precisão da data e hora em que emitiu ou extingui ou suspendeu um certificado; k) Empregar pessoal com qualificações, conhecimentos e experiência necessárias para a prestação de serviços de certificação; l) Revogar os certificados nos termos da Ponto Suspensão e Revogação de Certificados deste documento e publicar os certificados revogados na CRL do repositório da respectiva EC, com a frequência estipulada no ponto ; m) Publicar a sua DPC e as Políticas de Certificado aplicáveis no seu repositório garantindo o acesso às versões actuais assim como as versões anteriores; n) Notificar com a rapidez necessária, por correio electrónico os titulares dos certificados em caso da EC proceder à revogação ou suspensão dos mesmos, indicando o Página 80 de 12081 motivo que originou esta acção; o) Colaborar com as auditorias dirigidas pela EGCP (Autoridade Credenciadora), para validar a renovação das suas próprias chaves; p) Operar de acordo com a legislação aplicável; q) Proteger em caso de existirem as chaves que estejam sobre sua custódia; r) Garantir a disponibilidade da CRL de acordo com as disposições do ponto 4.9.7; s) Em caso de cessar a sua actividade deverá comunicar com uma antecedência mínima de dois meses a todos os titulares dos certificados emitidos assim como à ECEE; t) Cumprir com as especificações contidas na norma sobre Protecção de Dados Pessoais; u) Conservar toda a informação e documentação relativa a um certificado reconhecido e as Declarações de Práticas de Certificação vigentes em cada momento e durante quinze anos desde o momento da emissão; v) Disponibilizar os certificados da sua EC e da ECRaizEstado REPRESENTAÇÃO E GARANTIAS DAS ENTIDADES DE REGISTO As entidade que operam Entidades de Registo integradas na hierarquia do SCEE estão obrigadas a: a) Realizar suas operações de acordo com esta Politica de Certificados; b) Realizar suas operações de acordo com as DPC da sua EC; c) Comprovar rigorosamente a identidade das pessoas as quais se concede o certificado digital por eles tratado, pelo que requer a presença física da pessoa; d) Não armazenar nem copiar os dados de criação de assinatura da pessoa a quem tenham prestado os seus serviços; e) Informar antes da emissão de um certificado, à pessoa que solicite seus serviços, das obrigações que assume, bem com deve guardar os dados de criação de assinatura e que procedimentos deve seguir para comunicar a perca ou utilização indevida dos dados ou dispositivos de criação ou verificação da assinatura, do seu preço, e das condições precisas para a utilização do certificado bem como das suas limitações de uso; f) Validar e enviar de forma segura à EC a que está subordinada a ER um pedido de certificação devidamente complementada com a informação fornecida pelo titular e assinada digitalmente e receber os certificados emitidos de acordo com esse pedido; g) Armazenar de forma segura até ao momento do envio, tanto a documentação fornecida pelo titular como a gerada pela própria ER durante o processo de registo ou revogação; h) Formalizar o Contrato de Certificação com o titular segundo o estabelecido na Declaração de Práticas; Página 81 de 12082 i) Solicitar a revogação de um certificado quando tenha conhecimento ou suspeita de compromisso de uma chave privada; j) Autenticar os pedidos dos utilizadores finais para a renovação ou revogação de seus certificados, gerar pedidos de renovação ou revogação assinados digitalmente e enviados a sua EC; k) Em caso de aprovação de um pedido de certificação, notificar o titular a emissão do certificado e a forma de obtê-lo; l) Em caso de negação de um pedido de certificação, notificar o titular desta recusa e o motivo da mesma; m) Tratando-se de certificados pessoais, deve utilizar ferramentas de pedido e envio na presença da pessoa; n) Manter sobre controlo restrito as ferramentas de tramitação de certificados digitais e notificar a sua EC qualquer mal funcionamento ou outra eventualidade que possa fugir ao comportamento normal; o) Enviar uma cópia assinada do contracto de certificação e dos seus pedidos de revogação à EC; p) Receber e tratar todos os pedido de revogação presenciais que receba, de forma imediata, depois de ter levar a cabo a respectiva identificação baseada no DN de quem solicita (BI, Passaporte, ); q) Colaborar nos vários aspectos da operação, auditoria ou controlo da ER se tal lhe for solicitado pela EC; r) Obrigada a confidencialidade durante e posteriormente à prestação de serviços como Entidade de Registo, no que diz respeito à informação recebida pela EC REPRESENTAÇÃO E GARANTIAS DOS TITULARES É obrigação dos titulares dos certificados emitidos: a) Limitar e adequar a utilização dos certificados de acordo com as utilizações previstas nas Politicas de Certificado; b) Tomar todos os cuidados e medidas necessárias para garantir a posse da sua chave privada; c) Solicitar de imediato a revogação de um certificado em caso de ter conhecimento ou suspeita de compromisso da chave privada correspondente à chave pública contida no certificado. Os moldes em que pode fazer este pedido devem estar especificados na DPC no ponto 4.9.3; d) Não utilizar um certificado digital que tenha perdido a sua eficácia, quer por ter sido revogado, suspendido ou por ter expirado o período de validade; e) Submeter às Entidade de Registo a informação que considerem exacta e completa com relação aos dados que estas solicitem para realizar o processo de registo. Deve informar a EC de qualquer modificação desta informação; f) Não monitorizar, manipular ou efectuar acções de engenharia inversa sobre a Página 82 de 12083 implantação técnica (hardware e software) dos serviços de certificação, sem a devida autorização prévia, por escrito, de EC REPRESENTAÇÃO E GARANTIAS DAS PARTES CONFIANTES É obrigação das partes que confiem nos confiem nos certificados emitidos pelas Entidade Certificadoras do Estado: a) Limitar a fiabilidade dos certificados às utilizações permitidas para os mesmos em conformidade com o expresso na Politica de Certificado correspondente; b) Verificar a validade dos certificados no momento de realizar qualquer operação baseada nos mesmos; c) Assumir a responsabilidade na correcta verificação das assinaturas digitais; d) Assumir a responsabilidade na comprovação da validade, revogação ou suspensão dos certificados em que confia; e) Ter pleno conhecimento das garantias e responsabilidades aplicáveis na aceitação e uso de certificados em que confia e aceitar sujeitar-se às mesmas; f) Notificar qualquer acontecimento ou situação anómala relativa ao certificado, que possa ser considerado como causa de revogação do mesmo, utilizando os meios que a EC publique no seu sítio Web (www.scee.gov.pt) REPRESENTAÇÃO E GARANTIAS DE OUTROS PARTICIPANTES Caso existam outros participantes as DPC devem declara-las nesta secção 9.7. RENUNCIA DE GARANTIAS As EC do Estado podem recusar todas as garantias de serviço que não se encontrem vinculadas nas obrigações estabelecidas LIMITAÇÕES ÀS OBRIGAÇÕES a) As EC responderão pelos danos e prejuízos que causem a qualquer pessoa em exercício da sua actividade de acordo com o Artº 26 do DL 62/2003; b) As EC responderão pelos prejuízos que causem aos titulares ou a terceiros pela falta ou atraso na inclusão no serviço de consulta sobre a vigência dos certificados, da revogação ou suspensão dum certificado, uma vez que tenha conhecimento dele; c) As EC assumem toda a responsabilidade mediante terceiros pela actuação dos titulares funções necessárias à prestação de serviços de certificação; d) A responsabilidade da administração / gestão das Entidades Certificadoras assenta sobre base objectivas e cobre todo o risco que os particulares sofram sempre que seja consequência do funcionamento normal ou anormal dos seus serviços; e) As EC só responderão pelos danos e prejuízos causados pelo uso indevido do Página 83 de 12084 certificado reconhecido, quando não tenha consignado no certificado, de forma clara reconhecida por terceiros o limite quanto ao possível uso; f) As EC não responderão quando o titular supere os limites que figuram no certificado quanto as suas possíveis utilizações, de acordo com as condições estabelecidas e comunicadas ao titular; g) As EC não responderão se o destinatário dos documentos assinados electronicamente não comprove e tenha em conta as restrições que figuram no certificado quanto às suas possíveis utilizações; h) As ER não assumem qualquer responsabilidade no caso de perca ou prejuízo; i) Dos serviços que prestam, em caso de guerra, desastres naturais ou qualquer outro caso de força maior; j) Ocasionados pelo uso dos certificados quando excedam os limites estabelecidos pelos mesmo na Politica de Certificados e correspondente DPC; k) Ocasionado pelo uso indevido ou fraudulento dos certificados ou CRL emitidos pelas EC 9.9. INDEMNIZAÇÕES De acordo com a legislação em vigor TERMO E CESSAÇÃO DA ACTIVIDADE TERMO Esta PC entra em vigor desde o momento de sua publicação no repositório de SCEE. Esta PC estará em vigor enquanto não for revogada expressamente pela emissão de uma nova versão ou pela renovação das chaves da AC Raiz, momento em que obrigatoriamente se redigira uma nova versão SUBSTITUIÇÃO E REVOGAÇÃO DA PC Esta PC será substituída por uma nova versão com independência da transcendência das mudanças efectuadas na mesma, de modo que será sempre de aplicação na sua totalidade. Quando a PC ficar revogada será retirada do repositório público, garantindo-se contudo que será conservada durante 20 anos. Página 84 de 12085 CONSEQUÊNCIAS DA CESSAÇÃO DA ACTIVIDADE As obrigações e restrições que estabelece esta PC, em referência a auditorias, informação confidencial, obrigações e responsabilidades da SCEE, nascidas sob sua vigência, subsistirão após sua substituição ou revogação por uma nova versão em tudo o que não se oponha a esta NOTIFICAÇÃO INDIVIDUAL E COMUNICAÇÃO AOS PARTICIPANTES Sem prejuízo do estabelecido no capitulo 4º desta PC, sobre requisitos operacionais para o ciclo de vida dos certificados, os titulares de Certificados poderão comunicar com a SCEE como entidade que tem atribuídas as competências da infra-estrutura de chave pública, através de mensagem electrónica ou por escrito através de correio postal dirigido a qualquer das direcções contidas no ponto 1.5 Administração das Políticas. No site estarão disponíveis outros mecanismos de contacto com a entidade competente. As comunicações electrónicas produzirão os seus efeitos assim que as receba o destinatário ao qual vão dirigidas ALTERAÇÕES PROCEDIMENTO PARA ALTERAÇÕES A Autoridade com atribuições para realizar e aprovar mudanças sobre esta PC é o Conselho Gestor do SCEE. Os dados de contacto do Conselho Gestor encontram-se na secção 1.5 Administração das Políticas desta PC PRAZO E MECANISMO DE NOTIFICAÇÃO No caso que o Conselho Gestor julgue que as mudanças à especificação podem afectar à aceitabilidade dos certificados para propósitos específicos comunicar-se-á aos utilizadores dos certificados correspondentes que se efectuou uma mudança e que devem consultar a nova PC no repositório estabelecido. O mecanismo de comunicação será o endereço de Internet e o Diário da República MOTIVOS PARA MUDAR DE OID Nos casos em que, a julgamento do Conselho Gestor do SCEE, as mudanças das especificações não afectem à aceitação dos certificados proceder-se-á ao aumento do número menor de versão do documento e o último número de Identificador de objecto (OID) que o representa, mantendo o número maior da versão do documento, assim como o resto de seu OID associado. Não se considera necessário comunicar este tipo de modificações aos utilizadores dos certificados. Página 85 de 12086 No caso em que o Conselho Gestor do SCEE julgue que as mudanças à especificação podem afectar à aceitabilidade dos certificados para propósitos específicos proceder-se-á ao aumento do número maior de versão do documento e colocado a zero o número menor da mesma. Também se modificarão os dois últimos números do Identificador de objecto (OID) que o representa. Este tipo de modificações comunicar-se-á aos utilizadores dos certificados segundo o estabelecido no ponto DISPOSIÇÕES PARA RESOLUÇÃO DE CONFLITOS Todas reclamações entre utilizadores e SCEE deverão ser comunicadas pela parte em disputa à Entidade de Certificação Electrónica do Estado, com o fim de tentar resolvê-lo entre as mesmas partes. Para a resolução de qualquer conflito que possa surgir com relação a esta PC, as partes, com renúncia a qualquer outro foro que pudesse corresponder-lhes, submetem-se à Jurisdição de Contencioso Administrativo LEGISLAÇÃO APLICÁVEL É aplicável à actividade das entidades certificadoras a seguinte legislação específica: a) Despacho nº 27008/2004, de 14 de Dezembro, publicado no D.R II, nº 302, de 28 de Dezembro; b) Portaria nº 1350/2004, de 23 de Outubro; c) Despacho nº 16445/2004, de 29 de Julho, publicado no D.R II, nº 190 de 13 de Agosto; d) Aviso nº 8134/2004, de 29 de Julho, publicado no D.R II, nº 190 de 13 de Agosto; e) Decreto Regulamentar nº. 25/2004, de 15 de Julho; f) Decreto-Lei nº 290-D/99, de 2 de Agosto com as alterações introduzidas pelo Decreto-Lei nº 62/2003, de 3 de Abril e Decreto-lei nº 165/2004, de 6 de Julho; g) Portaria nº 1370/2000, publicada no D.R. nº 211, II série de 12 de Setembro CONFORMIDADE COM A LEGISLAÇÃO EM VIGOR É responsabilidade do Conselho Gestor do SCEE zelar pelo cumprimento da legislação aplicável listada na secção PROVIDÊNCIAS VÁRIAS ACORDO COMPLETO Todas as partes confiantes assumem na sua totalidade o conteúdo da última versão desta PC. Página 86 de 12087 INDEPENDÊNCIA No caso que uma ou mais estipulações deste documento, sejam ou tendam a ser inválidas, nulas ou irreclamáveis, em termos jurídicos, deverão ser consideradas como não efectivas. A situação anterior é valida, apenas e só nos casos em que tais estipulações não sejam consideradas essenciais. É responsabilidade do Conselho Gestor do SCEE a avaliação da essencialidade das mesmas SEVERIDADE Não estipulado EXECUÇÕES (TAXAS DE ADVOGADOS E DESISTÊNCIA DE DIREITOS) Não estipulado FORÇA MAIOR Não estipulado OUTRAS PROVIDÊNCIAS Nada a assinalar. Página 87 de 12088 A. ANEXO - PERFIL DOS CERTIFICADOS A.1. PERFIL DE CERTIFICADO DE ECRAIZESTADO DESIGNAÇÃO (RFC3280) PERFIL OBSERVAÇÕES Basic Certificate Fields Certificate Fields tbscertificate Sim signaturealgorithm Sim Sha256withRsaEncryption e Sha1withRsaEncryption signaturevalue Sim TBSCertificate Version Sim Versão Serial number Sim Inteiro aleatório Signature Sim Issuer Sim CN=ECRaizEstado; O=SCEE; C=PT Validity Sim 24 Anos, com renovação a cada 12 anos Subject Sim CN=ECRaizEstado; O=SCEE; C=PT Subject Public Key Info Sim RSAEncrytion, com dimensão de 4096 bit Unique Identifiers Não Extensions Sim Standard Extensions Authority Key Identifier Não Subject Key Identifier Sim KeyIdentifier=Hash (SubjectPublicKey do certificado) Key Usage Crítica bit(s) activo(s): KeyCertSign; crlsign Private Key Usage Period Não Certificate Policies Sim policyidentifier= AnyPolicy com o OID: e cpsuri=http://www.scee.gov.pt Página 88 de 12089 Policy Mappings Não Subject Alternative Name Não Issuer Alternative Name Não Subject Directory Attributes Não Basic Constraints Crítica ca=true e PathLenConstraint= Name Constraints Não Policy Constraints Não Extended Key Usage Não CRL Distribution Points Não Inhibit Any-Policy Não Freshest CRL Não Internet Certificate Extensions Authority Information Access Não Subject Information Access Não Página 89 de 12090 A.2. PERFIL DE CERTIFICADO DE ECESTADO DESIGNAÇÃO (RFC3280) PERFIL OBSERVAÇÕES Basic Certificate Fields Certificate Fields tbscertificate Sim signaturealgorithm Sim Sha256withRsaEncryption e Sha1withRsaEncryption signaturevalue Sim TBSCertificate Version Sim Versão Serial number Sim Inteiro aleatório Signature Sim Issuer Sim CN=ECRaizEstado; O=SCEE; C=PT Validity Sim 12 Anos, com renovação a cada 6 anos Subject Sim CN=[...]; OU= ECEstado; O=SCEE; C=PT Subject Public Key Info Sim RSAEncrytion, com dimensão mínima de 2048 bit Unique Identifiers Sim Extensions Sim Standard Extensions Authority Key Identifier Sim KeyIdentifier=Hash (SubjectPublicKey do certificado do Issuer) Subject Key Identifier Sim KeyIdentifier=Hash (SubjectPublicKey do certificado) Key Usage CRÍTICA bit(s) activo(s): KeyCertSign; crlsign Private Key Usage Period Não Certificate Policies Sim policyidentifier= AnyPolicy com o OID: e cpsuri=[ ] Policy Mappings Não Subject Alternative Name Não Página 90 de 12091 Issuer Alternative Name Não Subject Directory Attributes Não Basic Constraints Crítica ca=true e PathLenConstraint=[ ] Name Constraints Não Policy Constraints Não Extended Key Usage Não CRL Distribution Points Sim distributionpoint = [Inserir a localização do(s) repositório(s) onde podem ser descarregada(s) as LRC] (1) HTTP - (2) [a DPC descreverá a existência ou não de outros pontos] Inhibit Any-Policy Não Freshest CRL Não Internet Certificate Extensions Authority Information Access Opcional accessmethod ::={ } id-ad-ocsp accesslocation ::= { Introduzir a localização do OCSP responder } Subject Information Access NÃO Página 91 de 12092 A.3. PERFIL DE CERTIFICADO DE ASSINATURA DIGITAL DESIGNAÇÃO (RFC3280) PERFIL OBSERVAÇÕES Basic Certificate Fields Certificate Fields tbscertificate Sim signaturealgorithm Sim signaturevalue Sim TBSCertificate Version Sim Versão Serial number Sim Inteiro aleatório Signature Sim Issuer Sim CN=[...]; OU= ECEstado; O=SCEE; C=PT Validity Sim 3 Anos Subject Sim CN=[nome]; OU=[organismo]; O=[ministério]; C=PT Subject Public Key Info Sim RSAEncrytion, com dimensão mínima de 1024 bit Unique Identifiers Não Extensions Sim Standard Extensions Authority Key Identifier Sim KeyIdentifier=Hash (SubjectPublicKey do certificado do Issuer) Subject Key Identifier Sim KeyIdentifier=Hash (SubjectPublicKey do certificado) Key Usage Crítica bit(s) activo(s): nonrepudiation (contentcommitement) Private Key Usage Period Não Certificate Policies Sim policyidentifier= scee-assinatura, com o OID: [ ] ; cpsuri=[...]; usernotice= O certificado emitido segundo esta Página 92 de 12093 política é equivalente a um certificado digital qualificado, nos termos, do definido na Legislação Portuguesa, aplicável para o efeito Policy Mappings Não Subject Alternative Name Não Issuer Alternative Name Opção Subject Directory Attributes Não Basic Constraints Crítica ca=false Name Constraints Não Policy Constraints Não Extended Key Usage Não CRL Distribution Points Sim distributionpoint = [Inserir a localização do(s) repositório(s) onde podem ser descarregada(s) as LRC] (1) HTTP - (2) [a DPC descreverá a existência ou não de outros pontos] Inhibit Any-Policy Não Freshest CRL Não Internet Certificate Extensions Authority Information Access Opcional accessmethod ::={ } id-ad-ocsp accesslocation ::= { Introduzir a localização do OCSP responder } Subject Information Access Não Página 93 de 12094 A.4. PERFIL DE CERTIFICADO DE AUTENTICAÇÃO DESIGNAÇÃO (RFC3280) PERFIL OBSERVAÇÕES Basic Certificate Fields Certificate Fields tbscertificate Sim signaturealgorithm Sim signaturevalue Sim TBSCertificate Version Sim Versão Serial number Sim Inteiro aleatório Signature Sim Issuer Sim CN=[...]; OU= ECEstado; O=SCEE; C=PT Validity Sim 3 Anos Subject Sim CN=[nome];OU=[organismo];O=[ministério]; C=PT Subject Public Key Info Sim RSAEncrytion, com dimensão mínima de 1024 bit Unique Identifiers Não Extensions Sim Standard Extensions Authority Key Identifier Não KeyIdentifier=Hash (SubjectPublicKey do certificado do Issuer) Subject Key Identifier Sim KeyIdentifier=Hash (SubjectPublicKey do certificado) Key Usage Crítica bit(s) activo(s): digitalsignature e/ou keyagreement Private Key Usage Period Não Certificate Policies Sim policyidentifier= scee-autenticacao, com o OID: [ ] ; cpsuri=[...] ; usernotice=[...] Policy Mappings Não Subject Alternative Name Não Página 94 de 12095 Issuer Alternative Name Não Subject Directory Attributes Não Basic Constraints Crítica ca=false Name Constraints Não Policy Constraints Não Extended Key Usage Opcional CRL Distribution Points Sim distributionpoint = [Inserir a localização do(s) repositório(s) onde podem ser descarregada(s) as LRC] (1) HTTP - (2) [a DPC descreverá a existência ou não de outros pontos] Inhibit Any-Policy Não Freshest CRL Não Internet Certificate Extensions Authority Information Access Opcional accessmethod ::={ } id-ad-ocsp accesslocation ::= { Introduzir a localização do OCSP responder } Subject Information Access Não Página 95 de 12096 A.5. PERFIL DE CERTIFICADO DE CONFIDENCIALIDADE DESIGNAÇÃO (RFC3280) PERFIL OBSERVAÇÕES tbscertificate Sim signaturealgorithm Sim signaturevalue Sim Basic Certificate Fields Certificate Fields TBSCertificate Version Sim Versão Serial number Sim Inteiro aleatório Signature Sim Issuer Sim CN=[...]; OU= ECEstado; O=SCEE; C=PT Validity Sim 3 Anos Subject Sim CN=[nome];OU=[organismo];O=[ministério]; C=PT Subject Public Key Info Sim RSAEncrytion, com dimensão mínima de 1024 bit Unique Identifiers Não Extensions Sim Standard Extensions Authority Key Identifier Não KeyIdentifier=Hash (SubjectPublicKey do certificado do Issuer) Subject Key Identifier Sim KeyIdentifier=Hash (SubjectPublicKey do certificado) Key Usage Crítica bit(s) activo(s): keyencipherment e/ou keyagreement Private Key Usage Period Não Certificate Policies Sim policyidentifier=scee-confidencialidade, com o OID: ; cpsuri=[...] ; usernotice=[...] Policy Mappings Não Subject Alternative Name Não Issuer Alternative Name Não Página 96 de 12097 Subject Directory Attributes Não Basic Constraints Crítica ca=false Name Constraints Não Policy Constraints Não Extended Key Usage Opcional CRL Distribution Points Sim distributionpoint = [Inserir a localização do(s) repositório(s) onde podem ser descarregada(s) as LRC] Inhibit Any-Policy Não Freshest CRL Não Internet Certificate Extensions Authority Information Access Opcional accessmethod ::={ } id-ad-ocsp accesslocation ::= { Introduzir a localização do OCSP responder } Subject Information Access Não Página 97 de 12098 B. ANEXO PERFIL DAS LCR DESIGNAÇÃO (RFC3280) PERFIL OBSERVAÇÕES CertificateList Fields tbscertlist signaturealgorithm Sim signaturevalue Sim tbscertlist Version Sim Signature Sim Issuer Name Sim This Update Sim Next Update Sim Revoked Certificates Sim Extensions Sim CRL Extensions Authority Key Identifier Sim Issuer Alternative Name Não CRL Number Sim Delta CRL Indicator Não Issuing Distribution Point Não Freshest CRL Não CRL Entry Extensions Reason Code Sim Hold Instruction Code Não Invalidity Date Não Certificate Issuer Não Página 98 de 12099 C. ANEXO NORMALIZAÇÃO TÉCNICA X.501 RFC3647 RFC3280 RFC 4325 RFC3161 Nome: Descrição: Nome: Descrição: Nome: Descrição: Nome: Descrição: Nome: ITU-T RECOMMENDATION X.501 ISO/IEC : Recommendation Fevereiro de 2001 International Telecommunications Union Information technology - Open Systems Interconnection - The Directory: Models RFC 3647 Torna obsoleto o RFC 2527 Request For Comments Novembro de 2003 Internet Engineering Task Force - PKIX Working Group Internet X.509 Public Key Infrastructure - Certificate Policy and Certification Practices Framework RFC 3280 Torna obsoleto o RFC 2459 e é actualizado pelo RFC 4325 Request For Comments Abril de 2002 Internet Engineering Task Force - PKIX Working Group Internet X.509 Public Key Infrastructure - Certificate and Certificate Revocation List (CRL). RFC 4325 Actualiza o RFC 3280 Request For Comments Dezembro de 2005 Internet Engineering Task Force - PKIX Working Group Internet X.509 Public Key Infrastructure - Authority Information Access Certificate Revocation List (CRL) Extension RFC Request For Comments Agosto de 2001 Página 99 de 120100 RFC2560 RFC2510 X.509 ISO17799 ISO Descrição: Nome: Descrição: Nome: Descrição: Nome: Descrição: Nome: Descrição: Nome: Internet Engineering Task Force - PKIX Working Group Internet X.509 Public Key Infrastructure - Time-Stamp Protocol (TSP) RFC Request For Comments Junho de 1999 Internet Engineering Task Force - PKIX Working Group X.509 Internet Public Key Infrastructure - Online Certificate Status Protocol - OCSP RFC Request For Comments Março 1999 Internet Engineering Task Force - PKIX Working Group Internet X.509 Public Key Infrastructure - Certificate Management Protocols ITU-T Recommendation X.509 (08/05) ISO/IEC Recommendation Agosto de 2005 International Telecommunications Union Information Technology Open Systems Interconnection - The Directory: Authentication Framework ISO/IEC 17799:2005 Actualiza a ISO/IEC 17799:2000 International Standard Junho de 2005 International Organization for Standardization e International Electrotechnical Commission Information technology - Security techniques - Code of practice for information security management ISO/IEC :2005 2ª Edição International Standard Página 100 de 120101 ISO ISO ISO9595 ISO Descrição: Nome: Descrição: Nome: Descrição: Nome: Descrição: Nome: Descrição: Outubro de 2005 International Organization for Standardization) e International Electrotechnical Commission Information technology -- Security techniques -- Evaluation criteria for IT security -- Part 3: Security assurance requirements ISO/IEC :2005 2ª Edição International Standard Outubro de 2005 International Organization for Standardization) e International Electrotechnical Commission Information technology -- Security techniques -- Evaluation criteria for IT security -- Part 2: Security functional requirements ISO/IEC :2005 2ª Edição International Standard Outubro de 2005 International Organization for Standardization) e International Electrotechnical Commission Information technology -- Security techniques -- Evaluation criteria for IT security -- Part 1: Introduction and general model ISO/IEC ª correcção International Standard 1998 International Organization for Standardization e International Electrotechnical Commission Information technology - Open Systems Interconnection - Common management information Service definition" ISO : Actualiza a versão de 1991 International Draft Maio de 2002 International Organization for Standardization Banking - Personal Identification Number (PIN) management and security - Part 1: Basic principles and requirements for online PIN handling in ATM and POS systems Página 101 de 120102 ISO ISO ISO ISO ISO Nome: Descrição: Nome: Descrição: Nome: Descrição: Nome: Descrição: Nome: Descrição: ISO Actualiza a versão de 1991 International Draft Janeiro de 2005 International Organization for Standardization Banking -- Personal Identification Number management and security -- Part 2: Approved algorithms for PIN encipherment ISO International Draft Novembro de 2003 International Organization for Standardization Banking -- Personal Identification Number management and security -- Part 3: Requirements for offline PIN handling in ATM and POS systems ISO International Draft Julho de 2003 International Organization for Standardization Code lists - country names and code elements - alpha-2 code elements ISO International Standard 2005 International Organization for Standardization Banking -- Key management (retail) - Part 1: Principles ISO International Standard 2005 International Organization for Standardization Banking -- Key management (retail) -- Part 2: Symmetric ciphers, their key management and life cycle ISO Nome: ISO Página 102 de 120103 ISO FIPS140-2 ETSI ETSI ETSI Descrição: Nome: Descrição: Nome: Descrição: Nome: Descrição: Nome: Descrição: Nome: International Standard 1998 International Organization for Standardization Banking -- Key management (retail) -- Part 4: Key management techniques using public key cryptosystems ISO International Standard 2005 International Organization for Standardization Banking -- Key management (retail) -- Part 5: Key life cycle for public key cryptosystems FIPS PUB Actualiza o FIPS PUB de Janeiro de 1994 FEDERAL INFORMATION PROCESSING STANDARDS PUBLICATION Março 2002 US National Institute of Standards and Technology "Security Requirements For Cryptographic Modules". ETSI TS V1.1.1 Março de 2004 X.509 V.3 Certificate Profile for Certificates Issued to Natural Persons ETSI TS V1.2.1 Julho de 2005 Electronic Signatures and Infrastructures (ESI); Part 1 - Algorithms and Parameters for Secure Electronic Signatures; ETSI TS V1.2.1 Página 103 de 120104 ETSI ETSI ETSI ETSI ETSI Descrição: Nome: Descrição: Nome: Descrição: Nome: Descrição: Nome: Descrição: Nome: Julho de 2005 Electronic Signatures and Infrastructures (ESI); Part 2: Secure channel protocols and algorithms for signature creation devices ETSI TS V1.1.1 Outubro de 2003 Electronic Signatures and Infrastructures (ESI); Policy requirements for Certification Service Providers issuing attribute certificates usable with Qualified certificates ETSI TS V1.2.2 Junho de 2005 Electronic Signatures and Infrastructures (ESI); Policy requirements for certification authorities issuing public key certificates ETSI TS Technical Specification Junho de 2005 ESI - Electronic Signatures and Infrastructures Policy Requirements for certification authorities issuing public key certificates ETSI TS V1.2.1 Technical Specification Janeiro de 2003 Electronic Signatures and Infrastructures (ESI); Policy requirements for time-stamping authorities ETSI TS V1.3.2 Technical Specification Março de 2006 Página 104 de 120105 ETSI Descrição: Nome: Descrição: Electronic Signatures and Infrastructures (ESI); XML Advanced Electronic Signatures (XAdES) ETSI TS V1.3.3 Technical Specification Janeiro de 2006 Electronic Signatures and Infrastructures (ESI); Qualified Certificate profile ETSI ETSI ETSI ETSI Nome: Descrição: Nome: Descrição: Nome: Descrição: Nome: Descrição: ETSI TS ETSI TS V1.3.1 Technical Specification Janeiro de 2006 Electronic Signatures and Infrastructures (ESI); Time stamping profile ETSI TS V1.6.3 Technical Specification Setembro de 2005 Electronic Signatures and Infrastructures (ESI); CMS Advanced Electronic Signatures (CAdES) ETSI TS V1.4.1 Technical Specification Janeiro de 2006 Electronic Signatures and Infrastructures (ESI); Policy requirements for certification authorities issuing qualified certificates Página 105 de 120106 CWA CWA Nome: Descrição: Nome: Descrição: Abril 2005 User Requirements for a European interoperable eid system within a smart card infrastructure April 2005 Best Practice Manual for card scheme operators exploiting a multiapplication card scheme incorporating interoperable IAS services CWA CWA Nome: Descrição: Nome: Descrição: Abril 2005 Architecture for a European interoperable eid system within a smart card infrastructure CWA Application Interface for smart cards used as Secure Signature Creation Devices - Part 2: Additional Services CWA Nome: CWA Página 106 de 120107 Descrição: Application Interface for smart cards used as Secure Signature Creation Devices - Part 1: Basic requirements CWA Nome: Descrição: CWA CEN Workshop Agreement European Committee for Standardization Guide on the Use of Electronic Signatures - Part 2: Protection Profile for Software Signature Creation Devices CWA CWA14355 CWA Nome: Descrição: Nome: Descrição: Nome: Descrição: CWA CEN Workshop Agreement European Committee for Standardization Guide on the Use of Electronic Signatures - Part 1: Legal and Technical Aspects CWA CEN Workshop Agreement Março de 2004 European Committee for Standardization Guidelines for the implementation of Secure Signature-Creation Devices CWA CEN Workshop Agreement European Committee for Standardization EESSI Conformity Assessment Guidance - Part 8: Time-stamping Authority services and processes CWA Nome: CWA CEN Workshop Agreement Página 107 de 120108 CWA CWA CWA CWA CWA Descrição: Nome: Descrição: Nome: Descrição: Nome: Descrição: Nome: Descrição: Nome: European Committee for Standardization EESSI Conformity Assessment Guidance - Part 7: Cryptographic modules used by Certification Service Providers for signing operations and key generation services CWA CEN Workshop Agreement European Committee for Standardization EESSI Conformity Assessment Guidance - Part 6: Signature-creation device supporting signatures other than qualified CWA CEN Workshop Agreement European Committee for Standardization EESSI Conformity Assessment Guidance - Part 5: Secure signaturecreation devices CWA CEN Workshop Agreement European Committee for Standardization EESSI Conformity Assessment Guidance - Part 4: Signature-creation applications and general guidelines for electronic signature verification CWA CEN Workshop Agreement European Committee for Standardization EESSI Conformity Assessment Guidance - Part 3: Trustworthy systems managing certificates for electronic signatures CWA CEN Workshop Agreement Página 108 de 120109 CWA CWA14171 CWA14170 CWA14169 CWA Descrição: Nome: Descrição: Nome: Descrição: Nome: Descrição: Nome: Descrição: Nome: Descrição: European Committee for Standardization EESSI Conformity Assessment Guidance - Part 2: Certification Authority services and processes CWA CEN Workshop Agreement European Committee for Standardization EESSI Conformity Assessment Guidance - Part 1: General introduction CWA CEN Workshop Agreement Maio de 2004 European Committee for Standardization General guidelines for electronic signature verification CWA CEN Workshop Agreement Maio de 2004 European Committee for Standardization Security requirements for signature creation applications CWA CEN Workshop Agreement Março de 2004 European Committee for Standardization Secure signature-creation devices EAL 4+ CWA CEN Workshop Agreement European Committee for Standardization Security Requirements for Trustworthy Systems Managing Certificates for Electronic Signatures - Part 4: Cryptographic module for CSP signing Página 109 de 120 Exibir mais
Política de Certificados Certificados Digitais de Infraestrutura POLI N.º 002/ECAR/2010 META INFORMAÇÃO DO DOCUMENTO Título Política de Certificados Certificados Digitais de Infraestrutura Referência POLI Leia mais Política de Certificado de Assinatura Digital Qualificada
Engineering for digital security Política de Certificado de Assinatura Digital Qualificada Políticas MULTICERT_PJ.CA3_24.1.2_0002_pt.doc Identificação do Projeto: PKI da MULTICERT Identificação da CA: Leia mais IMPRENSA OFICIAL DO ESTADO SA IMESP (AC IMPRENSA OFICIAL G4)
IMPRENSA OFICIAL DO ESTADO SA IMESP (AC IMPRENSA OFICIAL G4) DECLARAÇÃO DE VERSÃO 2.2 23/10/2014 Página 1 / 68 HISTÓRICO DE VERSÕES Data Versão Observações 23/10/2014 2.2 Redação Inicial AVISO LEGAL Copyright Leia mais Declaração de Práticas de Certificação. Certisign Certificadora Digital S.A.
Declaração de Práticas de Certificação Certisign Certificadora Digital S.A. Versão 3.1 Data Efetiva: 24 de Outubro de 2008 Certisign Certificadora Digital S.A. Rua do Passeio 70-7o. andar Centro Rio de Leia mais Declaração de Práticas de Certificação. da Autoridade Certificadora SINCOR DPC DA AC SINCOR
DIGITALSIGN CERTIFICAÇÃO DIGITAL LTDA. (AC DIGITALSIGN RFB) DECLARAÇÃO DE PRÁTICAS VERSÃO 1.1 25/06/2013 Página 1 / 77 HISTÓRICO DE VERSÕES Data Versão Observações 25/07/2012 0.0 Redação Inicial 31/01/2013 Leia mais Declaração de Práticas e Políticas de Certificação da AC SSL
Política de Certificado e Declaração de Práticas de Certificação da Autoridade Certificadora de Serviços SSL da Infra-estrutura de Chaves Públicas Para Pesquisa e Ensino (ICPEDU) Declaração de Práticas Leia mais Declaração de Práticas e Políticas de Certificação da AC-SSL USP
Política de Certificado e Declaração de Práticas de Certificação da Autoridade Certificadora de Serviços SSL da Infraestrutura de Chaves Públicas Para Pesquisa e Ensino (ICPEDU) Declaração de Práticas Leia mais Política de Certificado de Assinatura Digital Tipo A3. da Autoridade Certificadora da Ordem dos Advogados do Brasil PC A3 DA AC OAB
Política de Certificado de Assinatura Digital Tipo A3 da Autoridade Certificadora da Ordem dos Advogados do Brasil PC A3 DA AC OAB Versão 1.0-03 de Outubro de 2007 ÍNDICE 1. INTRODUÇÃO...6 1.1.VISÃO GERAL...6 Leia mais Declaração de Práticas de Certificação. da Autoridade Certificadora SAT SEFAZ SP DPC DA AC SAT SEFAZ SP
Declaração de Práticas de Certificação da Autoridade Certificadora SAT SEFAZ SP DPC DA AC SAT SEFAZ SP Versão 1.1 abril de 2015 ÍNDICE 1. INTRODUÇÃO... 7 1.1. VISÃO GERAL... 7 1.2. IDENTIFICAÇÃO... 7 1.3. Leia mais 2170 DIÁRIO DA REPÚBLICA I SÉRIE-A N. o 79 3 de Abril de 2003 MINISTÉRIO DA JUSTIÇA
2170 DIÁRIO DA REPÚBLICA I SÉRIE-A N. o 79 3 de Abril de 2003 MINISTÉRIO DA JUSTIÇA Decreto-Lei n. o 62/2003 de 3 de Abril O presente decreto-lei visa compatibilizar o regime jurídico da assinatura digital Leia mais GUIA IDENTIFICAÇÃO ELECTRÓNICA AUTENTICAÇÃO E ASSINATURA ELECTRÓNICA
GUIA IDENTIFICAÇÃO ELECTRÓNICA AUTENTICAÇÃO E ASSINATURA ELECTRÓNICA versão 0.9 25 de Maio de 2009 Agência para a Modernização Administrativa, IP Rua Abranches Ferrão n.º 10, 3º G 1600-001 LISBOA email: Leia mais Política de Certificado de Sigilo Tipo S3. da Autoridade Certificadora Imprensa Oficial. PC S3 DA AC Imprensa Oficial
Política de Certificado de Sigilo Tipo S3 da Autoridade Certificadora Imprensa Oficial PC S3 DA AC Imprensa Oficial Versão 4.0 24 de Julho de 2014 ÍNDICE 1. INTRODUÇÃO... 6 1.1.VISÃO GERAL... 6 1.2.IDENTIFICAÇÃO... Leia mais Política de Certificado de Assinatura Digital Tipo A3. da Autoridade Certificadora Imprensa Oficial SP para a Secretaria da Receita Federal do Brasil
Política de Certificado de Assinatura Digital Tipo A3 da Autoridade Certificadora Imprensa Oficial SP para a Secretaria da Receita Federal do Brasil PC A3 da AC Imprensa Oficial SP RFB Versão 2.2-25 de Leia mais MINISTÉRIO DOS NEGÓCIOS ESTRANGEIROS MINISTÉRIO DAS FINANÇAS E DA ADMINISTRAÇÃO PÚBLICA
Diário da República, 1.ª série N.º 226 20 de Novembro de 2008 8135 MINISTÉRIO DOS NEGÓCIOS ESTRANGEIROS Aviso n.º 222/2008 Por ordem superior se torna público que, em 22 de Outubro de 2007 e em 22 de Setembro Leia mais Política de Certificado de Assinatura Digital Tipo A3. da Autoridade Certificadora Imprensa Oficial SP para a Secretaria da Receita Federal do Brasil
Política de Certificado de Assinatura Digital Tipo A4 da Autoridade Certificadora Imprensa Oficial SP para a Secretaria da Receita Federal do Brasil PC A4 da AC Imprensa Oficial SP RFB Versão 2.2-25 de Leia mais Política de Certificado de Assinatura Digital Tipo A3. da Autoridade Certificadora SINCOR PC A3 DA AC SINCOR
Política de Certificado de Sigilo Tipo S1 da Autoridade Certificadora SINCOR PC S1 DA AC SINCOR Versão 3.1 30 de Novembro de 2011 ÍNDICE 1. INTRODUÇÃO...6 1.1.VISÃO GERAL...6 1.2.IDENTIFICAÇÃO...6 1.3.COMUNIDADE Leia mais VeriSign Trust Network Políticas de Certificados
VeriSign Trust Network Políticas de Certificados 12 VTN_PC_1.indd I 12/21/04 3:46:58 PM Versão 1.3 Data efetiva: 31 de março de 2004 VeriSign, Inc. 487 E. Middlefield Road Mountain View, CA 94043 USA +1 Leia mais POLÍTICA DE CERTIFICADO ASSINATURA DIGITAL TIPO A3 DA AUTORIDADE CERTIFICADORA CAIXA PF (PC AC CAIXA PF - A3)
POLÍTICA DE CERTIFICADO DE ASSINATURA DIGITAL TIPO A3 DA AUTORIDADE CERTIFICADORA CAIXA PF (PC AC CAIXA PF - A3) 17 de abril de 2015 Controle de Alterações Versão Data Motivo Descrição 5.1 17/04/15 Alteração Leia mais Anexo 3. Versão final do texto do Aviso, a encaminhar para publicação em D.R.
Anexo 3 Versão final do texto do Aviso, a encaminhar para publicação em D.R. TÍTULO I - DISPOSIÇÕES GERAIS Artigo 1.º Objecto Artigo 5.º Supervisão Artigo 2.º Definições Artigo 6.º Agentes de instituições Leia mais Política de Certificado de Assinatura Digital Tipo A3
Política de Certificado de Assinatura Digital Tipo A3 da Autoridade Certificadora Brasileira de Registros para a Secretaria da Receita Federal do Brasil PC A3 da AC BR RFB Versão 3.0-21 de Outubro de 2011 Leia mais MINISTÉRIO DO TRABALHO E DA SOLIDARIEDADE SOCIAL
8846-(2) Diário da República, 1.ª série N.º 237 10 de Dezembro de 2007 MINISTÉRIO DO TRABALHO E DA SOLIDARIEDADE SOCIAL Decreto Regulamentar n.º 84-A/2007 de 10 de Dezembro Com a aprovação do Quadro de Leia mais Política de Certificado de Assinatura Digital Tipo A1 da Autoridade Certificadora FENACON Certisign para a Secretaria da Receita Federal do Brasil
Política de Certificado de Assinatura Digital Tipo A1 da Autoridade Certificadora FENACON Certisign para a Secretaria da Receita Federal do Brasil PC A1 da AC FENACON Certisign RFB Versão 4.0-27 de Setembro Leia mais REGRAS DO REGISTO DE DOMÍNIOS.PT
Serviço de Registo de Domínios de.pt Apartado 50366 1708-001 Lisboa tel: 808 201 039 e-mail : request@dns.pt URL: www.dns.pt 1 1. INTRODUÇÃO A FCCN - Fundação para a Computação Científica Nacional, é uma Leia mais Política de Certificado de Assinatura Digital Tipo A1 da Certificadora SINCOR para a Secretaria da Receita Federal do Brasil
Política de Certificado de Assinatura Digital Tipo A1 da Certificadora SINCOR para a Secretaria da Receita Federal do Brasil PC A1 da AC SINCOR RFB Versão 3.0-27 de Setembro de 2012 ÍNDICE 1. INTRODUÇÃO... Leia mais CONDIÇÕES GERAIS DE ABERTURA DE CONTA
BiG001CONT/JUL2015 CONDIÇÕES GERAIS DE ABERTURA DE CONTA Pode consultar estas condições gerais no site www.big.pt Índice Capítulo I Abertura de Conta 1.ª Objecto e Âmbito de aplicação 2.ª Definições 3.ª Leia mais Sistema de Gestão de Segurança e Saúde no Trabalho SST
SISTEMA GESTÃO SEGURANÇA E SAÚDE NO TRABALHO 1. INTRODUÇÃO O Sistema de Gestão da Segurança e Saúde do Trabalho (SGSST) proporciona um conjunto de ferramentas que potenciam a melhoria da eficiência da Leia mais GRUPO DE TRABALHO PARA A PROTEÇÃO DE DADOS INSTITUÍDO PELO ARTIGO 29.º
GRUPO DE TRABALHO PARA A PROTEÇÃO DE DADOS INSTITUÍDO PELO ARTIGO 29.º 01037/12/PT GT 196 Parecer 05/2012 relativo a computação em nuvem Adotado em 1 de julho de 2012 Este grupo de trabalho foi instituído Leia mais 2016 © DocPlayer.com.br Política de Privacidade | Termos de serviço | Feedback