PKIX Certificate and CRL Profile RFC 5280 Maio de 2008

Transcrição

1 1 PKIX Certificate and CRL Profile RFC 5280 Maio de 2008 OBS: A presente tradução não oficial da (RFC5280) tem como finalidade facilitar o estudo e o entendimento da Norma. Network Working Group Request for Comments: 5280 Obsoletes: 3280, 4325, 4630 Category: Standards Track Tradução para o Português Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile D. Cooper NIST S. Santesson Microsoft S. Farrell Trinity College Dublin S. Boeyen Entrust R. Housley Vigil Security W. Polk NIST May 2008

2 2 PKIX Certificate and CRL Profile RFC 5280 Maio de 2008 Estado do Documento Este documento especifica o protocolo padrão Internet a ser seguido para a Comunidade Internet, e solicita discussão e sugestões para sua melhoria. Consulte a edição atual do documento Internet Official Protocol Standards (STD 1) para obter a situação de padronização e o estado do presente protocolo. A distribuição deste documento é ilimitado. Resumo Este documento define os perfis para o certificado X.509 v3 e a lista de certificados revogados (LCR) X.509.v2 para uso na Internet. A introdução fornece uma visão geral dessa abordagem e modelo. O formato do certificado X.509 v3 é descrito em detalhes, com informações adicionais sobre seu formato e a semântica dos formulários de nome Internet. São descritas as extensões padrão do certificado e duas extensões específicas da Internet. É especificado o conjunto exigido de extensões. São descritos detalhes do formato da LCR X.509 v2, juntamente com as extensões padrão e aquelas específicas da Internet. É descrito um algoritmo para validação do caminho de certificação X.509. Nos apêndices são fornecidos um módulo ASN.1 e exemplos.

3 3 PKIX Certificate and CRL Profile RFC 5280 Maio de 2008 Sumário 1 Introdução 6 2 Requisitos e Pressupostos Comunicação e Topologia Critério de Acessibilidade Expectativas dos Usuários Expectativas dos Administradores Visão Geral do Modelo Versão 3 do Certificado X Caminhos de certificação e Confiança Revogação Protocolos Operacionais Protocolos de Gerenciamento Perfil do Certificado e das Extensões do Certificado Campos Básicos do Certificado Campos do Certificado tbscertificate signaturealgorithm signaturevalue TBSCertificate Version Serial Number Signature Issuer Validity UTCTime GeneralizedTime Subject Subject Public Key Info Unique Identifiers Extensions Extensões do Certificado Extensões Padrão Authority Key Identifier Subject Key Identifier Key Usage Certificate Policies Policy Mappings Subject Alternative Name Issuer Alternative Name Subject Directory Attributes Basic Constraints Name Constraints Policy Constraints Extended Key Usage CRL Distribution Points

4 4 PKIX Certificate and CRL Profile RFC 5280 Maio de Inhibit anypolicy Freshest CRL (Delta CRL Distribution Point) Extensões Privadas Internet Authority Information Access Subject Information Access Perfil da LCR e das Extensões da LCR Campos da LCR Campos do CertiticateList tbscertlist signaturealgorithm signaturevalue Certificate List A Ser Assinado Version Signature Issuer Name This Update Next Update Revoked Certificates Extensões Extensões da LCR Authority Key Identifier Issuer Alternative Name CRL Number Delta CRL Indicator Issuing Distribution Points Freshest CRL (Ponto de Distribuição de LCR delta) Authority Informatioin Access Extensões da Entrada da LCR Reason Code Invalidity Date Certificate Issuer Validação de Caminho de Certificação Validação Básica de Caminho Entradas Inicialização Processamento Básico de Certificado Preparação para o Certificado i Procedimento de Encerramento Saídas Uso do Algoritmo de Validação de Caminho Validação de LCR Entradas de Revogação Processamento de LCR Regras de Processamento para Nomes Internacionalizados Nomes Internacionalizados em Distinguished Names Nome de Domínio Internacionalizados em GeneralName

5 5 7.3 Nomes de Domínio Internacionalizados em Distinguished Names Identificadores de Recurso Internacionalizados Endereços de Correio Eletrônico Internacionalizados Considerações de Segurança 84 9 Considerações IANA Agradecimento Referências Referências Normativas Referências Informativas Apêndice A. Estruturas e OIDs em Pseudo-ASN.1 91 A.1 Módulo Explicitamente Rotulado, sintaxe A.2 Módulo Implicitamente Rotulado, sintaxe Apêndice B. Notas ASN Apêndice C. Exemplos 114 C.1 Certificado auto-assinado RSA C.2 Certificado de Entidade Final Usando RSA C.3 Certificado de Entidade Final Usando DSA C.4 Lista de Certificados Revogados Endereço dos Autores 127 Declaração Plena de Direitos Autorais 128 Propriedade Intelectual 128

6 6 1 Introdução A presente especificação é parte do conjunto de padrões para o X Infraestrutura de Chaves Públicas (ICP) Internet. A especificação define perfis do formato e da semântica de certificados, e listas de certificados revogados(lcrs) para a ICP Internet. São descritos procedimentos necessários para o processamento dos caminhos de certificação no ambiente da Internet. Finalmente, nos apêndices, são fornecidos módulos em ASN.1 para todas as estruturas de dados definidas ou referenciadas. A seção 2 descreve os requisitos de ICP na Internet e os pressupostos que se relacionam ao escopo deste documento. A Seção 3 apresenta o modelo da arquitetura e descreve sua relação com a norma IETF anterior, assim como com as normas ISO/IEC/ITU-T. Em particular, é descrita a relação existente entre esta especificação e aquelas contidas nos documentos PEM IETF e ISO/IEC/ITU-T X.509. Seção 4 define perfis para o certificado X.509 v3, e secção 5 define perfis para a LCR X.509 v2. Os perfis incluem a identificação de extensões ISO/IEC/ITU-T e extensões ANSI que podem ser úteis na ICP Internet. Os perfis são apresentados em Syntax Notation One (ASN.1) de 1988, em vez da sintaxe ASN.1 de 1997, utilizada nas normas mais recentes do ISO/IEC/ITU-T. Seção 6 inclui procedimentos para validação do caminho de certificação. Estes procedimentos baseiam-se nas definições do ISO/IEC/ITU-T. É NECESSÁRIO que as implementações obtenham os mesmos resultados, embora não seja requerido que estas utilizem os procedimentos especificados. Os procedimentos para identificação e codificação de chave pública e assinaturas são definidos em [RFC3279], [RFC4055] e [RFC4491]. Não é obrigatório que as implementações desta especificação usem quaisquer algoritmo criptográfico. Embora, as implementações em conformidade com esta especificação, e que usam os algoritmos identificados em [RFC3279], [RFC4055, e [RFC4491], DEVEM identificar e codificar os materiais de chave pública e assinaturas como descrito naquelas especificações. Finalmente, são fornecidos três apêndices para ajudar nas implementações. O Apêndice A contém todas as estruturas ASN.1 definidas ou referenciadas nesta especificação. Como informado acima, o material é apresentado na versão ASN.1 de O apêndice B contém notas sobre características menos conhecidas da notação ASN.1 utilizadas no presente documento. O Apêndice C contém exemplos de certificados e LCR em conformidade com esta especificação. Esta especificação torna obsoleta a [RFC3280]. As diferenças entre a presente especificação e aquela contida na [RFC3280] são listadas abaixo: Seção 7 especifica o suporte avançado a nomes internacionalizados, com regras para codificação e satisfazem os Nomes de Domínios Internacionalizados, os Identificadores de Recursos Internacionalizados (IRIs), e nomes distintos. Estas regras estão alinhadas com regras de comparação estabelecidas em RFC atualizadas, incluindo entre estas, [RFC3490], [RFC3987], e [RFC4518].

7 7 Asseções e incorporamascondiçõesparaacontinuaçãodeusodolegado dos esquemas de codificação especificados na[rfc4630]. Quando utilizado por ICP já estabelecida, a transição para UTF8String poderia causar negação de serviço baseado em falhas na cadeia de nomes ou processamento incorreto de restrições de nomes. A seção da [RFC3280], que especifica a extensão de certificado privatekeyusageperiod, mas não incentiva o uso, foi removida. O uso dessa extensão padrão ISO nem é incentivada, nem recomendada para ser utilizada em ambientes de ICP Internet. A seção recomenda que a extensão policy mappigns seja marcada como crítica. A [RFC3280] recomendava que esta extensão fosse marcada como não crítica. A seção recomenda a marcação da extensão policy constraints como crítica. A [RFC3280] permitia que esta extensão fosse marcada como crítica ou não crítica. A extensão Authority Information Access (AIA) da LCR, como especificada em [RFC4325], foi adicionada na seção A seção 5.2 e 5.3 esclarece as regra para o tratamento de extensões não reconhedidas da LCR, assim como extensões de entrada da LCR, respectivamente. A seção da [RFC3280], que especificava a extensão holdinstructioncode de entrada de LCR, foi removida. O algoritmo de validação de caminho especificado na seção 6, não controla mais a criticidade das extensões de políticas de certificado nas cadeias de certificados. Na [RFC3280], esta informação era retornada para um terceiro confiável. A seção de Considerações de Segurança trata dos riscos relacionados a dependências circulares causados pelo uso de esquemas https ou similares nos pontos de distribuição de LCR, acesso a informação de autoridade (AIA), ou extensões de acesso a informações de sujeito (SIA). A seção de Considerações de Segurança trata de riscos relacionados a ambiguidade de nomes. A seção de Considerações de Segurança referencia a [RFC4210] quanto a procedimentos para tratar mudanças de operações de AC. Os módulos ASN.1 contidos no apêndice A não foram modificados, exceto pelo conteúdo de ub- address-length que foi mudado de 128 para 255, para se alinhar ao PKCS #9 [RFC2985]. Aspalavras-chave DEVE, NÃODEVE, NECESSÁRIO, DEVERÁ, NÃODEVERÁ, DEVERIA, NÃO DEVERIA, RECOMENDADO, PODE, e OPCIONAL contantes no presente documento (em letras maiúsculas, como mostrado), devem ser interpretados como descritas em [RFC2119].

8 8 2 Requisitos e Pressupostos O objetivo desta especificação é desenvolver um perfil para facilitar o uso de certificados X.509 dentro de aplicações de Internet para as comunidades que pretendem fazer uso da tecnologia X.509. Tais aplicações podem incluir WWW, correio eletrônico, WWW eletrônica, autenticação de usuário, e IPsec. A fim de aliviar alguns dos obstáculos ao uso de certificados X.509, este documento define um perfil para promover o desenvolvimento de sistemas de gerenciamento de certificado, o desenvolvimento de ferramentas de aplicação e a interoperabilidade determinada pela política. Algumas comunidades terão de complementar ou substituir possivelmente, este perfil, a fim de satisfazer as exigências de domínios de aplicações especializadas ou em ambientes com autorização adicional, garantia, ou requisitos operacionais. No entanto, para aplicações básicas, representações comuns de atributos usados frequentemente são definidos para que os desenvolvedores de aplicativos possam obter as informações necessárias sem levar em conta o emissor de um certificado especial ou a Lista de Certificados Revogados (LCR). O usuário de certificado deveria rever a política de certificado gerado pela Autoridade Certificadora(AC) antes de confiar nos serviços de autenticação ou não-repúdio associados com a chave pública contida em determinado certificado. Por isso, esta norma não prescreve regras juridicamente vinculativas ou deveres. Com o surgimento de ferramentas adicionais para o tratamento de autorização suplementar e gestão de atributos, tais como os certificados de atributos, pode se tornar apropriado limitar o conjunto de atributos de autenticação inclusos no certificado. Essas ferramentas adicionais de gestão podem fornecer métodos mais adequados para transmissão de muitos atributos autenticados. 2.1 Comunicação e Topologia Usuários de certificados irão operar em uma ampla gama de ambientes com relação a sua topologia de comunicação, especialmente os usuários de correio eletrônico seguro. Este perfil suporta usuários sem banda larga, em tempo real, conectividade IP, ou alta disponibilidade de conexão. Além disso, o perfil permite a presença de firewall ou qualquer outro tipo de filtragem de comunicação. Este perfil não considera a implantação de um sistema de diretório X.500 [X.500] ou de um Lightweight Directory Access Protocol (LDAP) [RFC4510]. O perfil não proíbe a utilização do serviço de diretório X.500 ou de um diretório LDAP; desta forma, qualquer meio de distribuição de certificados e listas de certificados revogados (LCRs) pode ser usado. 2.2 Critério de Acessibilidade O objetivo da Infraestrutura de Chaves Pública (PKI) é atender as necessidades de funções determinísticas de identificação automatizada, autenticação e controle de acesso, e autorização. O suporte para esses serviços determina os atributos contidos no certificado, bem como a informação de controle auxiliar contidas no certificado, tais como dados de políticas e restrições quanto ao caminho de certificação.

9 9 2.3 Expectativas dos Usuários Os usuários da ICP Internet são pessoas e processos que usam o software cliente e são os sujeitos nomeados nos certificados. Estes usos incluem destinatários e remetentes de correio eletrônico, clientes de navegadores WWW, servidores WWW, e o gerenciador de chave para IPsec dentro de um roteador. Este perfil reconhece as limitações das plataformas usadas por esses usuários, assim como as limitações em termos de sofisticação e cuidados implementados pelos próprios usuários. Isso se manifesta na responsabilidade mínima sobre a configuração do usuário (por exemplo, chaves confiáveis de AC, regras), as limitações explícitas de uso da plataforma dentro do certificado, as restrições quanto ao caminho de certificação para proteger o usuário de ações maliciosas, e aplicativos que automatizam funções de validação de forma sensata. 2.4 Expectativas dos Administradores Tal como acontece com as expectativas dos usuários, o perfil para ICP Internet é estruturado de maneira a apoiar os indivíduos que geralmente operam as ACs. Fornecer aos administradores opções ilimitadas aumenta as chances de um erro sutil de um administrador resulte em comprometimento amplo. Além disso, as escolhas ilimitadas aumentam muito a complexidade do software que processa e valida os certificados criados pela AC. 3 Visão Geral do Modelo A seguir é uma visão simplificada do modelo de arquitetura assumido pela infra-estrutura de chave pública usando X.509 (PKIX) especificações. Os componentes deste modelo são: Entidade final: AC: AR: usuário de certificados da ICP e/ou sistema usuário final, representado no campo sujeito (subject) do certificado; autoridade certificadora; autoridade de registro, ou seja, é um sistema opcional para o qual a AC delega determinadas funções de gestão; Emissor de LCR: sistema que gera e assina LCRs, e Repositório: sistema ou conjunto de sistemas distribuídos que armazena certificados e LCRs e que serve como meio de distribuição dos certificados e LCRs para as entidades finais. As ACs são responsáveis por indicar o status de revogação dos certificados que emitem. A informação sobre o estado de revogação pode ser fornecida através do Online Certificate Status Protocol (OCSP) [RFC2560], através de Listas de Certificados Revogados (LCR), ou algum outro mecanismo. Em geral, quando as informações de status de revogação são fornecida por CRLs, a AC também é o emissor da CRL. No entanto, uma AC pode delegar a responsabilidade pela emissão das LCRs para uma entidade diferente.

10 10 Note-se que uma Autoridade de Atributos (AA) também pode optar por delegar a publicação de suas LCRs para um emissor de LCR R e < > Entidade Final p Transaç~oes o operacionais ^ s e transaç~oes de Transaç~oes de i gerenciamento Gerenciamento Usuários t v da ICP ó ======================= ====================== r ^ ^ entidades de i gerenciamento da o v ICP d < AR <----+ e Publica certificado v v C e < AC r Publica certificado t Publica LCR ^ ^ gerenciamento & < Emissor de LCR <---+ de transaç~oes Publica LCR v L C AC R Figura 1: Entidades da ICP 3.1 Versão 3 do Certificado X.509 Os usuários de uma chave pública necessitam ter confiança de que a chave privada associada é de propriedade do sujeito remoto correto (pessoa ou sistema), com a qual um determinado mecanismo de criptografia ou assinatura digital será utilizado. Esta confiança é obtido através da utilização de certificados de chave pública, que são estruturas de dados que relacionam os valores de chave pública a indivíduos. Esta relação de confiança ocorre a partir da utilização de AC confiável que assina digitalmente cada certificado. O AC pode basear esta afirmação em meios técnicos (por exemplo, a prova da posse através de um protocolo de desafia e resposta), apresentação da chave privada, ou em um afirmação do sujeito. Um certificado tem uma vida útil válida limitada, o que está indicado no seu conteúdo assinado. Pelo fato da assinatura do certificado e o seu período de validade poderem ser verificados de maneira independente pelo sistema usuário, que faz uso da tecnologia, os certificados podem ser distribuídos através de meios de comunicação e sistemas de servidores não confiáveis, e podem ser armazenados, de forma insegura, em cache nos sistemas

11 usuários. 11 O ITU-T X.509 (anteriormente CCITT X.509) ou ISO/IEC , que foi publicado pela primeira vez em 1988, como parte das recomendações X.500 para diretório, define o formato de certificado padrão [X.509]. O formato do certificado no padrão de 1988 é chamado versão 1 (v1) do formato. O X.500 foi revisto em 1993, quando mais dois campos foram adicionados, resultando na versão 2 (v2) do formato. A RFC do Internet Privacy Enhanced Mail (PEM), publicada em 1993, incluiu especificações para uma infraestrutura de chaves públicas baseada em certificados X.509 v1 [RFC1422]. A experiência adquirida na tentativa de implantar RFC 1422 deixou claro que os formatos de certificado v1 e v2 eram deficientes em vários aspectos. O mais importante, mais campos foram necessários para transportar informações que o projeto do PEM design e a experiência de implementação tinham considerado necessário. Em resposta a estes novos requisitos, a ISO/IEC, ITU-T, e ANSI X9 desenvolveu o X.509 versão 3 (v3) do formato do certificado. O formato v3 estende o formato v2 incluindo previsões para campos de extensão adicionais. Tipos de extensões particulares podem vir especificados em normas ou pode ser definido e registrado por qualquer organização ou comunidade. Em junho de 1996, a padronização do formato v3 básica foi concluída [X.509]. A ISO/IEC, ITU-T, e ANSI X9 também desenvolveram extensões padrão para uso no campo extensões v3 [X.509] [X9.55]. Estas extensões podem transmitir dados como informações adicionais para identificação do sujeito, informações de atributos-chave, informações políticas, e restrições para o caminho de certificação. ISO / IEC, ITU-T, e ANSI X9 também desenvolveram extensões padrão para uso no campo extensões v3 [X.509] [X9.55]. Estas extensões podem transmitir dados como informações adicionais sujeito identificação, informações de atributo-chave, informações políticas, e restrições de caminho de certificação. No entanto, as extensões padrãoiso/iec, ITU-T, e ANSI X9 são muito amplas em sua aplicabilidade. Para desenvolver implementações interoperáveis de sistemas X.509 v3 para uso na Internet, é necessário especificar um perfil para uso das extensões X.509 v3 sob medidaparaainternet. Éoobjectivodestedocumento,especificarumperfilparaaplicações WWW Internet, correio eletrônico, e IPsec. Ambientes com requisitos adicionais podem implementar usando esse perfil ou pode substituí-lo. 3.2 Caminhos de certificação e Confiança Um usuário de serviço de segurança que exige conhecimento de uma chave pública geralmente precisa obter e validar o certificado contendo a chave pública utilizada. Se o usuário da chave pública não é titular de uma cópia segura da chave pública da AC que assinou o certificado, o nome da AC, e as informações relacionadas (como o período de validade ou o nome de restrições), então ele pode precisar de um certificado adicional para obter a chave pública. Em geral, uma cadeia de múltiplos certificados pode se tornar necessário, compreendendo o certificado do dono da chave pública (a entidade final) assinado por uma autoridade de certificação, e zero ou mais certificados adicionais de ACs assinados por outras ACs. Tais cadeias, chamadas de caminhos de certificação, são necessárias porque um usuário de chave pública só é inicializado com um número limitado de chaves públicas garantidas pela AC.

12 12 Existem diferentes formas de configuração de ACs que possibilitam aos usuários de chaves públicas encontrarem os caminhos de certificação. Para o PEM, a RFC 1422 foi definido uma estrutura hierárquica rígida para ACs. Existem três tipos de autoridade certificadora PEM: (a) Autoridade de Registro de Política de Internet(ARPI): Esta autoridade, operando sob os auspícios da Internet Society, atua como a raiz da hierarquia de certificação PEM no nível 1. Emite certificados apenas para o próximo nível de autoridades, APC (Autoridade de Política de Certificação). Todos os caminhos de certificação começam na ARPI. (b) Autoridades de políticas de Certificação (APC): As APCs estão no nível 2 da hierarquia, cada APC a ser certificada pelo ARPI. A APC deve estabelecer e publicar uma declaração da sua política com relação aos usuários de certificação ou autoridades de certificação subordinadas. APCs distintas visam satisfazer as necessidades de usuários diferentes. Por exemplo, uma APC (uma APC organizacional) pode apoiar as necessidades gerais de correio eletrônico de organizações comerciais, e outra APC (uma APC de alta confiança) pode ter uma política mais rigorosa, projetada para satisfazer os requisitos legalmente vinculativos de assinatura digital. (c) Autoridades Certificadoras (ACs): ACs estão no nível 3 da hierarquia e podem também estar em níveis mais baixos. As de nível 3 são certificadas pela APC. As ACs representam, por exemplo, organizações particulares, unidades organizacionais particulares (por exemplo, departamentos, grupos, seções), ou áreas geográficas específicas. Além disso, a RFC 1422, tem uma regra para subordinação de nome, que exige que a AC só possa emitir certificados para entidades cujos nomes são subordinados (na árvore de nomeação X.500) para o nome da própria AC. A confiança associada a um caminho de certificação PEM está implícito no nome APC. A regra de subordinação de nome garante que ACs abaixo da APC sejam sensivelmente restritas ao conjunto de entidades subordinadas que podem certificar (por exemplo, uma AC para uma organização só pode certificar entidades na árvore com o nome da organização). Sistemas usuários de certificado são capazes de verificar mecanicamente que a regra de subordinação de nome foi seguida. A RFC 1422 utiliza o formato X.509 certificado v1. As limitações do X.509 v1 tornam necessário a imposição de várias restrições estruturais que associam claramente as informações sobre a política ou restrições quanto a utilização dos certificados. Estas restrições incluem: (a) uma hierarquia top-down pura, na qual todos os caminhos de certificação começam na ARPI; (b) uma regra de subordinação de nomes que restringe os nomes de sujeito de AC; e (c) uso do conceito APC, que requer o conhecimento de APCs individuais para serem incluídos para verificação lógica da cadeia de certificação. O conhedimento de APCs individuais é necessário para determinar se a cadeia pode ser aceita. Com o X.509 v3, a maioria dos requisitos abordados na RFC 1422 podem ser resolvidos através das extensões do certificado, sem a necessidade de restringir as estruturas das ACs

13 utilizadas. Em particular, as extensões do certificado relacionadas com as políticas de certificação evitam a necessidade de uso de APCs e as restrições contidas nas extensões torna desnecessário o uso das regra subordinação de nome. Como resultado, esta norma suporta uma arquitetura mais flexível, incluindo: 13 (a) Os caminhos de certificação começam com a chave pública de uma Autoridade Certificadora no próprio domínio do usuário, ou com a chave pública da árvore superior de uma hierarquia. Começar com a chave pública de uma Autoridade de Certificadora no domínio do usuário tem certas vantagens. Em certos ambientes, o domínio local é o mais confiável. (b) Restrições de nomes podem ser impostas através da inclusão de uma extensão para restrição explícita de nomes no certificado, mas isso não é requisito. (c) Extensões de Política e mapeamentos de política substituem o conceito de APC, permitindo um maior grau de automação. A aplicação pode determinar se o caminho de certificação é aceitável com base no conteúdo dos certificados, em vez de um conhecimento a priori da APC. Isto permite a automatização do processamento do caminho de certificação. O X.509 v3 também inclui uma extensão que identifica o sujeito de um certificado como sendo uma CA ou uma entidade final, reduzindo a dependência de informação externa exigida pelo PEM. Esta especificação abrange duas classes de certificados: certificados de AC e certificados de entidade final. Os certificados de AC podem ser divididos em três classes: certificado cruzado, certificado auto-emitido e certificado auto-assinado. O certificado cruzado é aquele no qual o emissor e o sujeito do certificado são entidades distintas. A certificação cruzada descreve uma relação de confiança entre duas ACs. O certificado auto-emitido é aquele no qual o emissor e o sujeito do certificado são a mesma entidade. A auto-emissão de certificados ocorre em suporte a mudanças na política ou nas operações. Certificados auto-assinados são aqueles nos quais a assinatura de digital pode ser verificada com a chave pública relacionada contida no próprio certificado. Certificados auto-assinados são utilizados para transmitir uma chave pública para uso como início de um caminho de certificação. Certificados de entidade final são emitidos para aquelas entidades que não estão autorizadas a emitir certificados. 3.3 Revogação Quando um certificado é emitido, é esperado que ele seja utilizado durante todo o seu período de validade. No entanto, várias circunstâncias podem causar a invalidação do certificado antes da expiração do seu prazo de validade. Tais circunstâncias incluem a mudança de nome, mudança de associação entre o sujeito e a AC (por exemplo, quando o empregado termina deixa de prestar serviços a uma organização), comprometimento ou suspeita de comprometimento da chave privada correspondente. Sob tais circunstâncias, o AC tem que revogar o certificado. O X.509 define um método para revogação de certificado. Este método envolve a emissão periódica de uma estrutura de dados assinada, chamada de lista de certificados revogados (LCR) por cada AC da infraestrutura. A LCR é uma lista datada com carimbo de tempo que identifica os certificados revogados, assinada pela AC que o emitiu ou por um emissor

14 de CRL, e disponibilizada gratuitamente em um repositório público. Cada certificado revogado é identificado na LCR pelo número de série do certificado. Quando um sistema que faz uso de certificação, usa um certificado (por exemplo, para verificar a assinatura digital de um usuário remoto), o sistema não verifica somente a assinatura do certificado e sua validade, mas também adquire uma LCR adequadamente recente e verifica que o número de série do certificado não na LCR. O significado de adequadamente recente pode variar de acordo com a política local, mas isso normalmente remete a LCR emitida mais recentemente. A nova lista é emitida em base regular e periódica (por exemplo, a cada hora, diariamente ou semanalmente). Uma entrada é adicionada a LCR como parte da próxima atualização após a notificação de revogação. Uma entrada não deve ser removido da LCR, até que apareça em LCRs regulares emitidas após o período de validade do certificado revogado. Uma vantagem deste método é que as CRLs podem ser distribuídas da mesma forma que os certificados propriamente ditos, ou seja, através de servidores e meios de comunicações não seguros. Uma limitação do método de revogação por LCR, usando comunicações e servidores não confiáveis, é que a granularidade do tempo de revogação é limitada ao prazo de emissão da LCR. Por exemplo, se a revogação for relatada agora, a revogação não será confiável ao sistema que faz uso do certificado até que todas as LCRs sejam atualizadas conforme o agendamento de emissão - o que pode ser de até uma hora, um dia ou uma semana, dependendo da frequência de emissão das LCRs. Tal como acontece com o formato de certificado X.509 v3, a fim de facilitar a interoperabilidade nas implementações de vários fornecedores, o formato de LCR X.509 v2 tem que ter um perfil adequado ao uso na Internet. Um dos objetivos do presente documento é a especificação deste perfil. No entanto, o perfil não define os requisitos para emissão de LCRs. Os formatos de mensagens e protocolos de suporte on-line para notificação de revogação são definidos em outras especificações do PKIX. Métodos de notificação on-line de revogação podem ser aplicáveis, em alguns ambientes, como alternativa para a LCR X.509. A verificação de revogação on-line pode reduzir significativamente a latência entre a geração do relatório de revogação e a sua distribuição aos terceiros confiáveis. Uma vez que o AC aceite um relatório da revogação, como autêntico e confiável, qualquer consulta ao serviço on-line, refletirá corretamente os impactos da revogação na validação do certificado. No entanto, estes métodos impõem novos requisitos de segurança: o validador certificado precisa confiar no serviço de validação on-line, enquanto o repositório não precisa ser confiável. 3.4 Protocolos Operacionais É necessário um conjunto de protocolos operacionais para entregar os certificados e CRLs (ou informações de status) aos sistemas clientes que fazem uso de certificado. Torna-se necessário provisões para uma variedade de diferentes meios de certificado e entrega de LCR, incluindo procedimentos de distribuição baseados em LDAP, HTTP, FTP e X.500. Os protocolos operacionais que dão suporte a estas funções são definidas em outras especificações do PKIX. Estas especificações podem incluir definições de formatos de mensagem e procedimentos para suportar todos os ambientes operacionais acima referidos, incluindo definições ou referências para tipos apropriados de conteúdo MIME. 14

15 3.5 Protocolos de Gerenciamento Os protocolos de gerenciamento são necessários para dar suporte às interações entre os usuários da ICP e as entidades que realizam o seu gerenciamento. Como exemplo, um protocolo de administração pode ser utilizado entre a AC e um sistema cliente com o qual um par de chave está associada, ou entre duas ACs que implementem certificação cruzada entre si. O conjunto de funções que, potencialmente, têm de ser suportados por protocolos de gestão incluem: (a) registro: É o processo no qual o usuário primeiro se faz conhecido pela AC (diretamente, ou através de uma AR), ocorre antes da AC emitir o certificado ou certificados para o usuário. (b) inicialização: Antes do sistema cliente poder operar de forma segura, é necessária a instalação de materiais essenciais que têm a relação adequada com as chaves armazenadas em outras partes da infra-estrutura. Por exemplo, o cliente tem de ser inicializado de maneira segura com a chave pública e outras informação garantidas pela AC(s), que serão utilizadas na validação dos caminhos de certificação. Além disso, um cliente normalmente tem de ser inicializado com seu próprio par(es) de chave(s). (c) certificação: Este é o processo no qual a AC emite o certificado de chave pública para o usuário, e retorna esse certificado para o sistema cliente do usuário e/ou publica o certificado em um repositório. (d) recuperação de par de chaves: Como opção, os materiais de chave do usuário cliente (por exemplo, a chave privada de um usuário utilizado para fins de criptografia) pode ser suportado por uma CA ou um sistema de backup de chave. Se um usuário precisa recuperar esses materiais de backup de chave (por exemplo, como resultado de uma senha esquecida ou perda do arquivo da cadeia da chave), um protocolo de troca de mensagem on-line protocolo pode ser necessários para das suporte a esta ação. (e) atualização de par de chaves: Todos os pares de chaves precisam ser atualizados regularmente, ou seja, substituído por um novo par de chaves, e emissão de novos certificados (f) solicitação de revogação: Uma pessoa autorizada avisa uma AC sobre uma uma situação anormal e solicita a revogação do certificado. (g) certificação cruzada: Duas ACs trocam informações utilizadas na criação de um certificado cruzado. Um certificado cruzado é um certificado emitido por uma AC para outra AC que contém uma chave de assinatura de AC usada na emissão de certificados. 15 Note que os protocolos on-line não são a única maneira de implementar as funções acima. Para todas as funções, existem métodos off-line utilizados para obtenção do mesmo resultado, esta especificação não exige o uso de protocolos on-line. Por exemplo, quando são utilizados tokens, muitas das funções podem ser realizadas no próprio token. Além disso, algumas das funções acima descritas podem ser combinados em um protocolo de troca de mensagens. Em particular, dois ou mais registos, inicialização e funções de certificação podem ser combinados em uma troca de mensagens de protocolo.

16 A série de especificações PKIX define um conjunto de formatos de mensagens padrão que suportam as funções acima. Os protocolos para transmitir estas mensagens em diferentes ambientes (por exemplo, a transferência de ficheiros de , e WWW) encontram-se descritos nessas especificações Perfil do Certificado e das Extensões do Certificado Esta seção apresenta o perfil para certificados de chaves públicas que promovem a interoperabilidade e a utilização continuada de uma ICP. Esta seção é baseada no formato de certificado X.509 v3 e nas extensões de certificado padrão definidas no [X.509]. Os documentos ISO/IEC e ITU-T utiliza a versão de 1997 do ASN.1, enquanto este documento usa versão de 1988 da sintaxe ASN.1, o certificado codificado e suas extensões padrão são equivalentes. Esta seção também define as extensões privadas necessárias para suportar uma ICP na comunidade da Internet. Os certificados podem ser utilizados numa vasta gama de aplicações e ambientes que abrangem um largo espectro de objetivos de interoperabilidade e um espectro mais amplo ainda de requisitos operacionais e de segurança. O objetivo deste documento é estabelecer uma base comum para aplicações genéricas que exigem ampla interoperabilidade e requisitos de propósitos especiais limitados. Em particular, a ênfase será em apoiar o uso de certificados X.509 v3 para uso no correio eletrônico informal da Internet, no IPsec e nas aplicações WWW. 4.1 Campos Básicos do Certificado A sintaxe básica do certificado X.509 v3 segue abaixo. Para o cálculo da assinatura, os dados que serão assinados é codificado usando as regras de codificação (DER) do ASN.1 [X.690]. A codificação DER do ASN.1 DER é baseada em rótulo, e um sistema de codificação desse valor para cada elemento. Certificate ::= SEQUENCE { tbscertificate TBSCertificate, signaturealgorithm AlgorithmIdentifier, signaturevalue BIT STRING } TBSCertificate ::= SEQUENCE { version [0] EXPLICIT Version DEFAULT v1, serialnumber CertificateSerialNumber, signature AlgorithmIdentifier, issuer Name, validity Validity, subject Name, subjectpublickeyinfo SubjectPublicKeyInfo, issueruniqueid [1] IMPLICIT UniqueIdentifier OPTIONAL, -- If present, version MUST be v2 or v3 subjectuniqueid [2] IMPLICIT UniqueIdentifier OPTIONAL, -- If present, version MUST be v2 or v3 extensions [3] EXPLICIT Extensions OPTIONAL -- If present, version MUST be v3

17 } Version ::= INTEGER { v1(0), v2(1), v3(2) } 17 CertificateSerialNumber ::= INTEGER Validity ::= SEQUENCE { notbefore Time, notafter Time } Time ::= CHOICE { utctime UTCTime, generaltime GeneralizedTime } UniqueIdentifier ::= BIT STRING SubjectPublicKeyInfo ::= SEQUENCE { algorithm AlgorithmIdentifier, subjectpublickey BIT STRING } Extensions ::= SEQUENCE SIZE (1..MAX) OF Extension Extension ::= SEQUENCE { extnid OBJECT IDENTIFIER, critical BOOLEAN DEFAULT FALSE, extnvalue OCTET STRING -- contains the DER encoding of an ASN.1 -- value corresponding to the extension -- type identified by extnid } Os itens a seguir descrevem os certificados X.509 v3 para uso na Internet Campos do Certificado O certificado é uma SEQUÊNCIA de três campos obrigatórios. Os campos são detalhadamente descritos nas subseções abaixo tbscertificate Esse campo contém os nomes do sujeito e do emissor, uma chave pública associada ao sujeito, um período de validade, e outras informações relacionadas. Os campos são descritos em detalhes na seção 4.1.2; o campo tbscertificate normalmente inclui extensões, que são descritas na seção signaturealgorithm O campo signaturealgorithm contém o identificador do algoritmo criptográfico usado pela AC para assinar o certificado. [RFC3279], [RFC4055], e [RFC4491] lista os algoritmos de assinatura suportados, mas outros algoritmos também PODEM ser suportados.

18 Um identificador de algoritmo é definido pela estrutura ASN.1 a seguir: AlgorithmIdentifier ::= SEQUENCE { algorithm OBJECT IDENTIFIER, parameters ANY DEFINED BY algorithm OPTIONAL } 18 O identificador de algoritmo é utilizado para identificar o algoritmo criptográfico. O componente OBJECT IDENTIFIER identifica o algoritmo (como o DSA com SHA-1). O conteúdo do do campo parameters variam de acordo com o algoritmo identificado. Este campo DEVE conter os mesmos identificadores de algoritmo que o campo signature na sequência de campos do tbscertificate (seção ) signaturevalue O campo signaturevalue contém a assinatura digital calculada sobre o campo tbscertificate codificado em DER do ASN.1. A codificação do tbscertificate é usada como entrada da função de assinatura. Este valor de assinatura é codificado como um BIT STRING e incluído no campo de assinatura. Os detalhes deste processo são especificados para cada algoritmo listado em [RFC3279], [RFC4055] e [RFC4491]. Para gerar a assinatura, a AC de certifica da validade da informação contida no campo tbscertificate. Em particular, a AC se certifica da relação existente entre o material da chave pública e o sujeito do certificado TBSCertificate A sequência TBSCertificate contém informações associadas ao sujeito do certificado e a AC queoemitiu. TodoTBSCertificatecontémonomedosujeitoeoemissor,umachavepública associada ao sujeito, um período de validade, o número da versão e o número serial; alguns PODEM conter campos opcionais de identificador único. O restante desta seção descreve a sintaxe e a semântica dos três campos. O TBSCertificate geralmente inclui extensões. As extensões para ICP na Internet são descritos na seção Version Este campo descreve a versão do certificado codificado. Quando são utilizados extensões, como esperado na definição do perfil, o valor deste campo deve ser 3 (valor igual a 2). Caso não ocorra nenhuma extensão, mas o UniqueIdentifier esteja presente, a versão DEVERIA ser 2 (valor igual a 1); entretanto, a versão PODE ser 3. Quando apenas os campos básicos estiverem presentes, a versão DEVERIA ser 1 (o valor é omitido do certificado, é considerado o valor padrão); embora a versão possa ser 2 ou 3. As implementações DEVERIAM estar preparadas para aceitar qualquer versão de certificado. No mínimo, as implementações que estão em conformidade DEVEM reconhecer os certificados de versão 3. A geração de certificados de versão 2 não é esperado pelas implementações baseadas no presente perfil.

19 Serial Number O serial number DEVE ser um número inteiro positivo atribuído pela AC para cada certificado. Ele DEVE ser único para cada certificado emitido pela respectiva AC (por exemplo, o nome do emissor e o número serial identificam um certificado único) As ACs DEVEM garantir que o serialnumber seja um número inteiro não negativo. 19 Dada a unicidade requerida acima, é esperado que este campo contenha números inteiros longos. Os sistemas usuários de certificado DEVEM ser capazes de processar números inteiros de até 20 octetos. Quando em conformidade, as ACs NÃO DEVEM utilizar serial- Number com valores maiores que 20 octetos. Nota: ACs que não se encontram em conformidade PODEM emitir certificados com números negativos ou iguais a zero. Os sistemas usuários de certificado DEVERIAM ser preparados para tratar adequadamente tais certificados Signature Este campo contém o identificador de algoritmo para o algoritmo utilizado pela AC para assinar o certificado. Este campo DEVE conter o mesmo identificador de algoritmo do campo signaturealgorithm na sequência de campos do certificado(seção ). O conteúdo dos parâmetros opcionais variam de acordo com o identificador do algoritmo. [RFC3279], [RFC4055] e [RFC4491] listam os algoritmos de assinatura suportados, mas outros algoritmos PODEM também ser suportados Issuer O campo issuer identifica a entidade que assinou e emitiu o certificado. O campo issuer DEVE conter um valor não vazio de nome distinto (DN). O campo issuer é definido com o tipo Name do ASN.1 [X.500]. Name é definido pela estrutura ASN.1 a seguir: Name ::= CHOICE { -- only one possibility for now -- rdnsequence RDNSequence } RDNSequence ::= SEQUENCE OF RelativeDistinguishedName RelativeDistinguishedName ::= AttributeTypeAndValue ::= SEQUENCE { type AttributeType, value AttributeValue } SET SIZE (1..MAX) OF AttributeTypeAndValue AttributeType ::= OBJECT IDENTIFIER AttributeValue ::= ANY -- DEFINED BY AttributeType DirectoryString ::= CHOICE {

20 teletexstring TeletexString (SIZE (1..MAX)), printablestring PrintableString (SIZE (1..MAX)), universalstring UniversalString (SIZE (1..MAX)), utf8string UTF8String (SIZE (1..MAX)), bmpstring BMPString (SIZE (1..MAX)) } 20 O tipo Name descreve um nome hierárquico composto de atributos, tais como o nome do país, e os valores correspondentes, como US. O tipo de componente AttributeValue é determinado pelo AttributeType; geralmente será um DirectoryString. O tipo DirectoryString é definido como uma selecão entre PrintableString, TelexString, BMPString e UniversalString. As ACs em conformidade com este perfil DEVEM usar codificação PrintableString ou UTF8String para codificar o DirectoryString, com duas exceções. Quando ACs tiverem emitido anteriormente certificados com campos issuer com atributos codificados usando TelexString, BMPString ou UniversalString, a AC PODE continuar a usar essas codificações para o DirectoryString de maneira a preservar a compatibilidade do legado. Também no caso de novas ACs serem adicionadas a um domínio onde existem ACs que emitem certificados com campos issuer com atributos codificados usando TelexString, BMPString ou UniversalString PODEM codificar os atributos que elas trocam com as ACs existentes usando a mesma codificação que as ACs utilizam. Como notado acima, os nomes distintos são compostos por atributos. A presente espcificação não restringe o conjunto de tipos de atributos que podem aparecer nos nomes. Entretanto, as implementações em conformidade DEVEM estar preparadas para receberem certificados com nomes contendo o conjunto de atributos listados a seguir. Esta especificação RECOMENDA o suporte a tipos adicionais de atributos. O conjunto padrão de atributos foi definido na série de especificações do X.500 [X.520]. As implementações deta especificação DEVEM estar preparadas para receberem os seguintes tipos de atributos de nomes padrão nos campos issuer e subject (seção ): * país, * organização, * unidade organizacional, * qualificador do nome distinto, * nome do estado ou provincia, * nome comum (por exemplo, Susan Housley ), e * número serial. Além disso, as implementações desta especificação DEVERIAM estar preparadas para receberem os seguintes tipo de atributos padrão tanto no nome do emissor quanto no nome do sujeito: * localidade * título,

21 * sobrenome, * nome, * iniciais, 21 * pseudônimo, e * qualificador de geração (por exemplo, Jr, 3º, ou IV ). A sintaxe e identificadores de objeto (OIDs) para esses tipos de atributos são fornecidos nos módulos ASN.1 do apêndice A. Adicionalmente, as implementações desta especificação DEVEM estar preparadas para receberem atributos domaincomponent, como descrito em [RFC4519]. O Sistema de Nome de Domínio (DNS) fornece um sistema de rótulos hierárquico. Este atributo fornece um mecanismo adequado para organização que deseja usar DNs em paralelo aos nomes DNS. Isso não é uma substituição para o componente dnsname das extensões alternative name. Não é necessário que as implementações convertam estes nomes em nomes DNS. A sintaxe associada e o OID para este tipo de atributo são fornecidos nos módulos ASN.1 do apêndice A. Regras para a codificação de nomes de domínio internacionalizados para uso no atributo domaincomponent serão especificadas na seção 7.3. Os sistemas usuários de certificados DEVEM ser preparados para processar campos contendo nomes distintos do emissor e do sujeito (seção ) para validar a cadeia de nome do caminho de certificação (seção 6). A cadeia de nomes é executada fazendo a correspondência entre o nome distinto do emissor no certificado com o nome do sujeito no certificado da AC. As regras de comparação de nomes distintos estão especificadas na seção 7.1. Se os nomes nos campos emissor e sujeito de um certificado correspondem de acordo com as regras especificadas na seção 7.1 então o certificado é auto-emitido Validity O período de validade do certificado é o intervalo de tempo durante o qual a AC garante que vai manter as informações sobre o status do certificado. O campo é representado como uma sequência de duas datas: a data em que o período de validade do certificado começa (notbefore) e a data na qual o período de validade do certificado termina (notafter). Ambos notbefore e notafter podem ser codificados como UTCTime ou GeneralizedTime. As ACS em conformidade com esse perfil deve sempre codificar datas de validade de certificado até o ano de 2049 como UTCTime; data de validade de certificado em 2050 ou posterior, deve ser codificada como GeneralizedTime. As aplicações em conformidade devem ser capazes de processar datas de validade que são codificados em tanto em UTCTime quanto em GeneralizedTime. O período de validade de um certificado é o período de tempo compreendido entre notbefore e notafter, inclusive nestas datas. Em algumas situações, são fornecidos aos dispositivos certificados para os quais nenhuma data de expiração boa pode ser atribuída. Por exemplo, pode ser emitido um certificado para um dispositivo que vincula o seu modelo e número de série com a sua chave pública,