PKIX Certificate and CRL Profile RFC 5280 Maio de 2008

(1)

E

rn

a

n

d

es

PKIX Certificate and CRL Profile RFC 5280 Maio de 2008

OBS: A presente tradu¸c˜ao n˜ao oficial da (RFC5280) tem como finalidade facilitar o estudo e o entendimento da Norma.

Network Working Group D. Cooper

Request for Comments: 5280 NIST

Obsoletes: 3280, 4325, 4630 S. Santesson

Category: Standards Track Microsoft

S. Farrell Trinity College Dublin S. Boeyen Entrust R. Housley Vigil Security W. Polk NIST May 2008

Tradu¸c˜ao para o Portuguˆes

Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile

(2)

E

rn

a

n

d

es

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¸cão atual do documento “Internet Official Protocol Standards” (STD 1) para obter a situa¸cão de padro-niza¸cão e o estado do presente protocolo. A distribui¸cão deste documento é ilimitado. Resumo

Este documento define os perfis para o certificado X.509 v3 e a lista de certificados revo-gados (LCR) X.509.v2 para uso na Internet. A introdu¸cão fornece uma visão geral dessa abordagem e modelo. O formato do certificado X.509 v3 é descrito em detalhes, com in-forma¸cõ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.

´

E 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¸cão do caminho de certifica¸cão X.509. Nos apêndices são forneci-dos um módulo ASN.1 e exemplos.

(3)

E

rn

a

n

d

es

Sum´

ario

1 Introdu¸c˜ao 6

2 Requisitos e Pressupostos 8

2.1 Comunica¸c˜ao e Topologia . . . 8

2.2 Crit´erio de Acessibilidade . . . 8

2.3 Expectativas dos Usu´arios . . . 9

2.4 Expectativas dos Administradores . . . 9

3 Vis˜ao Geral do Modelo 9 3.1 Vers˜ao 3 do Certificado X.509 . . . 10

3.2 Caminhos de certifica¸c˜ao e Confian¸ca . . . 11

3.3 Revoga¸c˜ao . . . 13

3.4 Protocolos Operacionais . . . 14

3.5 Protocolos de Gerenciamento . . . 15

4 Perfil do Certificado e das Extens˜oes do Certificado 16 4.1 Campos B´asicos do Certificado . . . 16

4.1.1 Campos do Certificado . . . 17 4.1.1.1 tbsCertificate . . . 17 4.1.1.2 signatureAlgorithm . . . 17 4.1.1.3 signatureValue . . . 18 4.1.2 TBSCertificate . . . 18 4.1.2.1 Version . . . 18 4.1.2.2 Serial Number . . . 19 4.1.2.3 Signature . . . 19 4.1.2.4 Issuer . . . 19 4.1.2.5 Validity . . . 21 4.1.2.5.1 UTCTime . . . 22 4.1.2.5.2 GeneralizedTime . . . 22 4.1.2.6 Subject . . . 22

4.1.2.7 Subject Public Key Info . . . 24

4.1.2.8 Unique Identifiers . . . 24

4.1.2.9 Extensions . . . 24

4.2 Extens˜oes do Certificado . . . 24

4.2.1 Extens˜oes Padr˜ao . . . 25

4.2.1.1 Authority Key Identifier . . . 25

4.2.1.2 Subject Key Identifier . . . 26

4.2.1.3 Key Usage . . . 27

4.2.1.4 Certificate Policies . . . 29

4.2.1.5 Policy Mappings . . . 32

4.2.1.6 Subject Alternative Name . . . 32

4.2.1.7 Issuer Alternative Name . . . 35

4.2.1.8 Subject Directory Attributes . . . 35

4.2.1.9 Basic Constraints . . . 35

4.2.1.10 Name Constraints . . . 36

4.2.1.11 Policy Constraints . . . 38

4.2.1.12 Extended Key Usage . . . 39

(4)

E

rn

a

n

d

es

4.2.1.14 Inhibit anyPolicy . . . 42

4.2.1.15 Freshest CRL (Delta CRL Distribution Point) . . . 43

4.2.2 Extens˜oes Privadas Internet . . . 43

4.2.2.1 Authority Information Access . . . 44

4.2.2.2 Subject Information Access . . . 45

5 Perfil da LCR e das Extens˜oes da LCR 47 5.1 Campos da LCR . . . 49

5.1.1 Campos do CertiticateList . . . 49

5.1.1.1 tbsCertList . . . 49

5.1.1.2 signatureAlgorithm . . . 50

5.1.1.3 signatureValue . . . 50

5.1.2 Certificate List “A Ser Assinado” . . . 50

5.1.2.1 Version . . . 51 5.1.2.2 Signature . . . 51 5.1.2.3 Issuer Name . . . 51 5.1.2.4 This Update . . . 51 5.1.2.5 Next Update . . . 51 5.1.2.6 Revoked Certificates . . . 52 5.1.2.7 Extens˜oes . . . 52 5.2 Extens˜oes da LCR . . . 52

5.2.1 Authority Key Identifier . . . 53

5.2.2 Issuer Alternative Name . . . 53

5.2.3 CRL Number . . . 53

5.2.4 Delta CRL Indicator . . . 54

5.2.5 Issuing Distribution Points . . . 56

5.2.6 Freshest CRL (Ponto de Distribui¸c˜ao de LCR delta) . . . 58

5.2.7 Authority Informatioin Access . . . 58

5.3 Extens˜oes da Entrada da LCR . . . 59

5.3.1 Reason Code . . . 60

5.3.2 Invalidity Date . . . 60

5.3.3 Certificate Issuer . . . 61

6 Valida¸cão de Caminho de Certifica¸cão 61 6.1 Valida¸cão Básica de Caminho . . . 62

6.1.1 Entradas . . . 64

6.1.2 Inicializa¸c˜ao . . . 66

6.1.3 Processamento B´asico de Certificado . . . 68

6.1.4 Prepara¸c˜ao para o Certificado i+1 . . . 72

6.1.5 Procedimento de Encerramento . . . 74

6.1.6 Sa´ıdas . . . 75

6.2 Uso do Algoritmo de Valida¸c˜ao de Caminho . . . 75

6.3 Valida¸c˜ao de LCR . . . 76

6.3.1 Entradas de Revoga¸c˜ao . . . 76

6.3.2 Processamento de LCR . . . 77

7 Regras de Processamento para Nomes Internacionalizados 79 7.1 Nomes Internacionalizados em Distinguished Names . . . 80

(5)

E

rn

a

n

d

es

7.3 Nomes de Dom´ınio Internacionalizados em Distinguished Names . . . 82

7.4 Identificadores de Recurso Internacionalizados . . . 82

7.5 Endere¸cos de Correio Eletrˆonico Internacionalizados . . . 83

8 Considera¸cões de Seguran¸ca 84 9 Considera¸cões IANA 87 10 Agradecimento 87 11 Referências 88 11.1 Referências Normativas . . . 88

11.2 Referˆencias Informativas . . . 89

Apˆendice A. Estruturas e OIDs em Pseudo-ASN.1 91 A.1 M´odulo Explicitamente Rotulado, sintaxe 1988 . . . 91

A.2 M´odulo Implicitamente Rotulado, sintaxe 1988 . . . 105

Apˆendice B. Notas ASN.1 112 Apˆendice C. Exemplos 114 C.1 Certificado “auto-assinado” RSA . . . 115

C.2 Certificado de Entidade Final Usando RSA . . . 118

C.3 Certificado de Entidade Final Usando DSA . . . 121

C.4 Lista de Certificados Revogados . . . 125

Endere¸co dos Autores 127

Declara¸c˜ao Plena de Direitos Autorais 128

(6)

E

rn

a

n

d

es

1 Introdu¸c˜

ao

A presente especifica¸cão é parte do conjunto de padrões para o X.509 - Infraestrutura de Chaves Públicas (ICP) Internet.

A especifica¸cão define perfis do formato e da semântica de certificados, e listas de certifi-cados revogados(LCRs) para a ICP Internet. São descritos procedimentos necessários para o processamento dos caminhos de certifica¸cã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¸cão 2 descreve os requisitos de ICP na Internet e os pressupostos que se relacionam ao escopo deste documento. A Se¸cão 3 apresenta o modelo da arquitetura e descreve sua rela¸cão com a norma IETF anterior, assim como com as normas ISO/IEC/ITU-T. Em particular, é descrita a rela¸cão existente entre esta especifica¸cão e aquelas contidas nos documentos PEM IETF e ISO/IEC/ITU-T X.509.

Se¸cão 4 define perfis para o certificado X.509 v3, e seçcão 5 define perfis para a LCR X.509 v2. Os perfis incluem a identifica¸cã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¸cão 6 inclui procedimentos para valida¸cão do caminho de certifica¸cão. Estes procedimen-tos baseiam-se nas defini¸cões do ISO/IEC/ITU-T. É NECESS ÁRIO que as implementa¸cões obtenham os mesmos resultados, embora não seja requerido que estas utilizem os procedi-mentos especificados.

Os procedimentos para identifica¸cão e codifica¸cão de chave pública e assinaturas são defi-nidos em [RFC3279], [RFC4055] e [RFC4491]. Não é obrigatório que as implementa¸cões desta especifica¸cão usem quaisquer algoritmo criptográfico. Embora, as implementa¸cões em conformidade com esta especifica¸cão, e que usam os algoritmos identificados em [RFC3279], [RFC4055, e [RFC4491], DEVEM identificar e codificar os materiais de chave pública e as-sinaturas como descrito naquelas especifica¸cões.

Finalmente, são fornecidos três apêndices para ajudar nas implementa¸cões. O Apêndice A contém todas as estruturas ASN.1 definidas ou referenciadas nesta especifica¸cão. Como informado acima, o material é apresentado na versão ASN.1 de 1988. O apêndice B con-tém notas sobre caracter´ısticas menos conhecidas da nota¸cão ASN.1 utilizadas no presente documento. O Apêndice C contém exemplos de certificados e LCR em conformidade com esta especifica¸cão.

Esta especifica¸cão torna obsoleta a [RFC3280]. As diferen¸cas entre a presente especifica¸cão e aquela contida na [RFC3280] são listadas abaixo:

∗ Se¸cão 7 especifica o suporte avan¸cado a nomes internacionalizados, com regras para codifica¸cão e satisfazem os Nomes de Dom´ınios Internacionalizados, os Identificadores de Recursos Internacionalizados (IRIs), e nomes distintos. Estas regras estão alinha-das com regras de compara¸cão estabelecialinha-das em RFC atualizaalinha-das, incluindo entre estas, [RFC3490], [RFC3987], e [RFC4518].

(7)

E

rn

a

n

d

es

∗ As se¸cões 4.1.2.4 e 4.1.2.6 incorporam as condi¸cões para a continua¸cão de uso do legado dos esquemas de codifica¸cão especificados na [RFC4630]. Quando utilizado por ICP já estabelecida, a transi¸cão para UTF8String poderia causar nega¸cão de servi¸co baseado em falhas na cadeia de nomes ou processamento incorreto de restri¸cões de nomes. ∗ A se¸cão 4.2.1.4 da [RFC3280], que especifica a extensão de certificado

privateKeyU-sagePeriod, 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¸cão 4.2.15 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¸cão 4.2.1.11 recomenda a marca¸cã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¸c˜ao 5.2.7.

∗ A se¸cã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¸c˜ao 5.3.2 da [RFC3280], que especificava a extens˜ao holdInstructionCode de en-trada de LCR, foi removida.

∗ O algoritmo de valida¸cão de caminho especificado na se¸cão 6, não controla mais a criticidade das extensões de pol´ıticas de certificado nas cadeias de certificados. Na [RFC3280], esta informa¸cão era retornada para um terceiro confiável.

∗ A se¸cão de Considera¸cões de Seguran¸ca trata dos riscos relacionados a dependências circulares causados pelo uso de esquemas https ou similares nos pontos de distri-bui¸cão de LCR, acesso a informa¸cão de autoridade (AIA), ou extensões de acesso a informa¸cões de sujeito (SIA).

∗ A se¸c˜ao de Considera¸c˜oes de Seguran¸ca trata de riscos relacionados a ambiguidade de nomes.

∗ A se¸cão de Considera¸cões de Seguran¸ca referencia a [RFC4210] quanto a procedimen-tos para tratar mudan¸cas de opera¸cões de AC.

Os módulos ASN.1 contidos no apêndice A não foram modificados, exceto pelo conteúdo de ub-emailaddress-length que foi mudado de 128 para 255, para se alinhar ao PKCS #9 [RFC2985].

As palavras-chave“DEVE”,“N ÃO DEVE”,“NECESS ÁRIO”,“DEVER Á”,“N ÃO DEVER Á”,

“DEVERIA”, “N ˜AO DEVERIA”, “RECOMENDADO”, “PODE”, e “OPCIONAL”

contan-tes no presente documento (em letras mai´usculas, como mostrado), devem ser interpretados como descritas em [RFC2119].

(8)

E

rn

a

n

d

es

2 Requisitos e Pressupostos

O objetivo desta especifica¸cão é desenvolver um perfil para facilitar o uso de certificados X.509 dentro de aplica¸cões de Internet para as comunidades que pretendem fazer uso da tecnologia X.509. Tais aplica¸cões podem incluir WWW, correio eletrônico, WWW eletrô-nica, autentica¸cã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¸cã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¸cões especializadas ou em ambientes com autoriza¸cão adicional, garantia, ou requisitos operacionais. No entanto, para aplica¸cões básicas, representa¸cões comuns de atributos usados frequentemente são definidos para que os desenvolvedores de aplicativos possam obter as informa¸cõ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 Cer-tificadora (AC) antes de confiar nos servi¸cos de autentica¸cã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¸cão suplemen-tar e gestão de atributos, tais como os certificados de atributos, pode se tornar apropriado limitar o conjunto de atributos de autentica¸cã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¸c˜

ao e Topologia

Usuários de certificados irão operar em uma ampla gama de ambientes com rela¸cão a sua topologia de comunica¸cã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 disponi-bilidade de conexão. Além disso, o perfil permite a presen¸ca de firewall ou qualquer outro tipo de filtragem de comunica¸cão.

Este perfil não considera a implanta¸cã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¸cão do servi¸co de diretório X.500 ou de um diretório LDAP; desta forma, qualquer meio de distribui¸cão de certificados e listas de certificados revogados (LCRs) pode ser usado.

2.2 Crit´

erio de Acessibilidade

O objetivo da Infraestrutura de Chaves Pública (PKI) é atender as necessidades de fun¸cões determin´ısticas de identifica¸cão automatizada, autentica¸cão e controle de acesso, e autori-za¸cão. O suporte para esses servi¸cos determina os atributos contidos no certificado, bem como a informa¸cão de controle auxiliar contidas no certificado, tais como dados de pol´ıticas e restri¸cões quanto ao caminho de certifica¸cão.

(9)

E

rn

a

n

d

es

2.3 Expectativas dos Usu´

arios

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¸cões das plataformas usadas por esses usuários, assim como as limita¸cões em termos de sofistica¸cão e cuidados implementados pelos próprios usuários. Isso se manifesta na responsabilidade m´ınima sobre a configura¸cão do usuário (por exemplo, chaves confiáveis de AC, regras), as limita¸cões expl´ıcitas de uso da plataforma dentro do certificado, as restri¸cões quanto ao caminho de certifica¸cão para proteger o usuário de a¸cões maliciosas, e aplicativos que automatizam fun¸cões de valida¸cão de forma sensata.

2.4 Expectativas dos Administradores

Tal como acontece com as expectativas dos usuários, o perfil para ICP Internet é estru-turado de maneira a apoiar os indiv´ıduos que geralmente operam as ACs. Fornecer aos administradores op¸cões ilimitadas aumenta as chances de um erro sutil de um adminis-trador 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˜

ao 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¸cões.

Os componentes deste modelo s˜ao:

Entidade final: usu´ario de certificados da ICP e/ou sistema usu´ario final, representado no campo sujeito (subject) do certificado;

AC: autoridade certificadora;

AR: autoridade de registro, ou seja, é um sistema opcional para o qual a AC delega determinadas fun¸cões de gestão;

Emissor de LCR: sistema que gera e assina LCRs, e

Reposit´orio: sistema ou conjunto de sistemas distribu´ıdos que armazena certificados e LCRs e que serve como meio de distribui¸c˜ao dos certificados e LCRs para as entidades finais.

As ACs são responsáveis por indicar o status de revoga¸cão dos certificados que emitem. A informa¸cão sobre o estado de revoga¸cã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¸cões de status de revoga¸cã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)

E

rn

a

n

d

es

Note-se que uma Autoridade de Atributos (AA) tamb´em pode optar por delegar a publi-ca¸c˜ao de suas LCRs para um emissor de LCR.

+---+

| R | +---+

| e | <---> | Entidade Final |

| p | Transa¸c~oes +---+

| o | operacionais ^

| s | e transa¸c~oes de | Transa¸c~oes de

| i | gerenciamento | Gerenciamento Usu´arios

| t | v da ICP | ´o | ======================= +--+---+ ====================== | 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¸c~oes

| | Publica LCR +---+ v

| L | +---+

| C | | AC |

| R | +---+

+---+

Figura 1: Entidades da ICP

3.1 Vers˜

ao 3 do Certificado X.509

Os usuários de uma chave pública necessitam ter confian¸ca de que a chave privada as-sociada é de propriedade do sujeito remoto correto (pessoa ou sistema), com a qual um determinado mecanismo de criptografia ou assinatura digital será utilizado. Esta confian¸ca é obtido através da utiliza¸cã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¸cão de confian¸ca ocorre a partir da utiliza¸cão de AC confiável que assina digitalmente cada certificado. O AC pode basear esta afirma¸cão em meios técnicos (por exemplo, a prova da posse através de um protocolo de desafia e resposta), apresenta¸cão da chave privada, ou em um afirma¸cão do sujeito. Um certificado tem uma vida útil válida limitada, o que está indicado no seu con-teú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¸cão e sistemas de servi-dores não confiáveis , e podem ser armazenados, de forma insegura, em cache nos sistemas

(11)

E

rn

a

n

d

es

usu´arios.

O ITU-T X.509 (anteriormente CCITT X.509) ou ISO/IEC 9594-8, que foi publicado pela primeira vez em 1988, como parte das recomenda¸cões X.500 para diretório, define o for-mato de certificado padrão [X.509]. O forfor-mato 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 especi-fica¸cõ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 impor-tante, mais campos foram necessários para transportar informa¸cões que o projeto do PEM design e a experiência de implementa¸cã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¸cão ou comunidade. Em junho de 1996, a padroniza¸cã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 infor-ma¸cões adicionais para identifica¸cão do sujeito, inforinfor-ma¸cões de atributos-chave, inforinfor-ma¸cões pol´ıticas, e restri¸cões para o caminho de certifica¸cã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¸cões adicionais sujeito identifica¸cão, informa¸cões de atributo-chave, informa¸cões pol´ıticas, e res-tri¸cões de caminho de certifica¸cão.

No entanto, as extensões padrãoISO/IEC, ITU-T, e ANSI X9 são muito amplas em sua aplicabilidade. Para desenvolver implementa¸cõ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 medida para a Internet. É o objectivo deste documento, especificar um perfil para aplica¸cõ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¸c˜

ao e Confian¸ca

Um usuário de servi¸co de seguran¸ca que exige conhecimento de uma chave pública geral-mente 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¸cões relacionadas (como o per´ıodo de validade ou o nome de restri¸cõ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¸cão, e zero ou mais certificados adicionais de ACs assinados por outras ACs. Tais cadeias, chamadas de caminhos de certifica¸cã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)

E

rn

a

n

d

es

Existem diferentes formas de configura¸cão de ACs que possibilitam aos usuários de chaves públicas encontrarem os caminhos de certifica¸cã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¸cão PEM no n´ıvel 1. Emite certificados apenas para o próximo n´ıvel de autoridades, APC (Autoridade de Pol´ıtica de Certifica¸cão). Todos os caminhos de certifica¸cão come¸cam na ARPI.

(b) Autoridades de pol´ıticas de Certifica¸cão (APC): As APCs estão no n´ıvel 2 da hierarquia, cada APC a ser certificada pelo ARPI. A APC deve estabelecer e pu-blicar uma declara¸cão da sua pol´ıtica com rela¸cão aos usuários de certifica¸cão ou autoridades de certifica¸cão subordinadas. APCs distintas visam satisfazer as neces-sidades de usuários diferentes. Por exemplo, uma APC (uma APC organizacional) pode apoiar as necessidades gerais de correio eletrônico de organiza¸cões comerciais, e outra APC (uma APC de alta confian¸ca) 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¸cões particulares, unidades organizacionais particulares (por exemplo, departamentos, grupos, se¸cões), ou áreas geográficas espec´ıficas.

Além disso, a RFC 1422, tem uma regra para subordina¸cão de nome, que exige que a AC só possa emitir certificados para entidades cujos nomes são subordinados (na árvore de nomea¸cão X.500) para o nome da própria AC. A confian¸ca associada a um caminho de cer-tifica¸cão PEM está impl´ıcito no nome APC. A regra de subordina¸cã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¸cão só pode certificar enti-dades na árvore com o nome da organiza¸cão). Sistemas usuários de certificado são capazes de verificar mecanicamente que a regra de subordina¸cão de nome foi seguida.

A RFC 1422 utiliza o formato X.509 certificado v1. As limita¸cões do X.509 v1 tornam necessário a imposi¸cão de várias restri¸cões estruturais que associam claramente as infor-ma¸cões sobre a pol´ıtica ou restri¸cões quanto a utiliza¸cão dos certificados. Estas restri¸cões incluem:

(a) uma hierarquia top-down pura, na qual todos os caminhos de certifica¸c˜ao come¸cam na ARPI;

(b) uma regra de subordina¸c˜ao 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¸cão lógica da cadeia de certifica¸cã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´es das extens˜oes do certificado, sem a necessidade de restringir as estruturas das ACs

(13)

E

rn

a

n

d

es

13

utilizadas. Em particular, as extensões do certificado relacionadas com as pol´ıticas de certifica¸cão evitam a necessidade de uso de APCs e as restri¸cões contidas nas extensões torna desnecessário o uso das regra subordina¸cão de nome. Como resultado, esta norma suporta uma arquitetura mais flex´ıvel, incluindo:

(a) Os caminhos de certifica¸cão come¸cam 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¸car 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¸cões de nomes podem ser impostas através da inclusão de uma extensão para restri¸cã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¸cão. A aplica¸cão pode determinar se o cami-nho de certifica¸cão é aceitável com base no conteúdo dos certificados, em vez de um conhecimento a priori da APC. Isto permite a automatiza¸cão do processamento do caminho de certifica¸cã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¸cão externa exi-gida pelo PEM.

Esta especifica¸cã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 cru-zado, 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¸cão cruzada des-creve uma rela¸cão de confian¸ca 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¸cas na pol´ıtica ou nas opera¸cões. Certificados auto-assinados são aqueles nos quais a assinatura de digital pode ser verificada com a chave pública re-lacionada 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¸cão. Certi-ficados de entidade final são emitidos para aquelas entidades que não estão autorizadas a emitir certificados.

3.3 Revoga¸c˜

ao

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¸cão do cer-tificado antes da expira¸cão do seu prazo de validade. Tais circunstâncias incluem a mudan¸ca de nome, mudan¸ca de associa¸cão entre o sujeito e a AC (por exemplo, quando o empregado termina deixa de prestar servi¸cos a uma organiza¸cã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¸cã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)

E

rn

a

n

d

es

14

de CRL, e disponibilizada gratuitamente em um repositório público. Cada certificado re-vogado é identificado na LCR pelo número de série do certificado. Quando um sistema que faz uso de certifica¸cã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 recen-temente. 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¸cão após a notifica¸cão de revoga¸cão. Uma entrada não deve ser removido da LCR, até que apare¸ca em LCRs regulares emitidas após o per´ıodo de validade do certificado re-vogado.

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¸cões não seguros.

Uma limita¸cão do método de revoga¸cão por LCR, usando comunica¸cões e servidores não confiáveis, é que a granularidade do tempo de revoga¸cão é limitada ao prazo de emissão da LCR. Por exemplo, se a revoga¸cão for relatada agora, a revoga¸cã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 interopera-bilidade nas implementa¸cõ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¸cã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¸cão de re-voga¸cão são definidos em outras especifica¸cões do PKIX. Métodos de notifica¸cão on-line de revoga¸cão podem ser aplicáveis, em alguns ambientes, como alternativa para a LCR X.509. A verifica¸cão de revoga¸cão on-line pode reduzir significativamente a latência entre a gera¸cão do relatório de revoga¸cão e a sua distribui¸cão aos terceiros confiáveis. Uma vez que o AC aceite um relatório da revoga¸cão, como autêntico e confiável, qualquer consulta ao servi¸co on-line, refletirá corretamente os impactos da revoga¸cão na valida¸cão do certificado. No en-tanto, estes métodos impõem novos requisitos de seguran¸ca: o validador certificado precisa confiar no servi¸co de valida¸cão on-line, enquanto o repositório não precisa ser confiável.

3.4 Protocolos Operacionais

´

E necessário um conjunto de protocolos operacionais para entregar os certificados e CRLs (ou informa¸cõ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¸cão baseados em LDAP, HTTP, FTP e X.500. Os protocolos operacionais que dão suporte a estas fun¸cões são definidas em outras especi-fica¸cões do PKIX. Estas especiespeci-fica¸cões podem incluir defini¸cões de formatos de mensagem e procedimentos para suportar todos os ambientes operacionais acima referidos, incluindo defini¸cões ou referências para tipos apropriados de conteúdo MIME.

(15)

E

rn

a

n

d

es

15

3.5 Protocolos de Gerenciamento

Os protocolos de gerenciamento são necessários para dar suporte às intera¸cões entre os usuários da ICP e as entidades que realizam o seu gerenciamento. Como exemplo, um protocolo de administra¸cã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¸cão cruzada entre si. O conjunto de fun¸cõ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 (di-retamente, ou através de uma AR), ocorre antes da AC emitir o certificado ou certificados para o usuário.

(b) inicializa¸cão: Antes do sistema cliente poder operar de forma segura, é necessária a instala¸cão de materiais essenciais que têm a rela¸cã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¸cão garantidas pela AC(s), que serão utilizadas na valida¸cão dos caminhos de certifica¸cão. Além disso, um cliente normalmente tem de ser inicializado com seu próprio par(es) de chave(s).

(c) certifica¸cã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¸cão de par de chaves: Como op¸cã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¸cão.

(e) atualiza¸c˜ao 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˜ao de novos certificados

(f) solicita¸cão de revoga¸cão: Uma pessoa autorizada avisa uma AC sobre uma uma situa¸cão anormal e solicita a revoga¸cão do certificado.

(g) certifica¸cão cruzada: Duas ACs trocam informa¸cões utilizadas na cria¸cã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.

Note que os protocolos on-line não são a única maneira de implementar as fun¸cões acima. Para todas as fun¸cões, existem métodos off-line utilizados para obten¸cão do mesmo resul-tado, esta especifica¸cão não exige o uso de protocolos on-line. Por exemplo, quando são utilizados tokens, muitas das fun¸cões podem ser realizadas no próprio token. Além disso, algumas das fun¸cões acima descritas podem ser combinados em um protocolo de troca de mensagens. Em particular, dois ou mais registos, inicializa¸cão e fun¸cões de certifica¸cão podem ser combinados em uma troca de mensagens de protocolo.

(16)

E

rn

a

n

d

es

16

A série de especifica¸cões PKIX define um conjunto de formatos de mensagens padrão que suportam as fun¸cões acima. Os protocolos para transmitir estas mensagens em diferentes ambientes (por exemplo, a transferência de ficheiros de e-mail, e WWW) encontram-se descritos nessas especifica¸cões.

4 Perfil do Certificado e das Extens˜

oes do Certificado

Esta se¸cão apresenta o perfil para certificados de chaves públicas que promovem a intero-perabilidade e a utiliza¸cão continuada de uma ICP. Esta se¸cão é baseada no formato de certificado X.509 v3 e nas extensões de certificado padrão definidas no [X.509]. Os docu-mentos 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¸cã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¸cões e ambientes que abran-gem um largo espectro de objetivos de interoperabilidade e um espectro mais amplo ainda de requisitos operacionais e de seguran¸ca. O objetivo deste documento é estabelecer uma base comum para aplica¸cõ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¸cões WWW.

4.1 Campos B´

asicos 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¸cão (DER) do ASN.1 [X.690]. A codifica¸cão DER do ASN.1 DER é baseada em rótulo, e um sistema de codifica¸cã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

(17)

E

rn

a

n

d

es

17 } Version ::= INTEGER { v1(0), v2(1), v3(2) } 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.

4.1.1 Campos do Certificado

O certificado é uma SEQUÊNCIA de três campos obrigatórios. Os campos são detalhada-mente descritos nas subse¸cões abaixo.

4.1.1.1 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¸cões relacionadas. Os campos são descritos em detalhes na se¸cão 4.1.2; o campo tbsCertificate normalmente inclui extensões, que são descritas na se¸cão 4.2.

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

E

rn

a

n

d

es

18

Um identificador de algoritmo ´e definido pela estrutura ASN.1 a seguir:

AlgorithmIdentifier ::= SEQUENCE {

algorithm OBJECT IDENTIFIER,

parameters ANY DEFINED BY algorithm OPTIONAL }

O identificador de algoritmo é utilizado para identificar o algoritmo criptográfico. O com-ponente 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ˆencia de campos do tbsCertificate (se¸c˜ao 4.1.2.3).

4.1.1.3 signatureValue

O campo signatureValue contém a assinatura digital calculada sobre o campo tbsCertifi-cate codificado em DER do ASN.1. A codifica¸cão do tbsCertifitbsCertifi-cate é usada como entrada da fun¸cã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¸cão contida no campo tbsCertificate. Em particular, a AC se certifica da rela¸cão existente entre o material da chave pública e o sujeito do certificado.

4.1.2 TBSCertificate

A sequência TBSCertificate contém informa¸cões associadas ao sujeito do certificado e a AC que o emitiu. Todo TBSCertificate contém o nome do sujeito e o emissor, uma chave pú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¸cã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¸cão 4.2.

4.1.2.1 Version

Este campo descreve a versão do certificado codificado. Quando são utilizados extensões, como esperado na defini¸cã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, é conside-rado o valor padrão); embora a versão possa ser 2 ou 3.

As implementa¸cões DEVERIAM estar preparadas para aceitar qualquer versão de certifi-cado. No m´ınimo, as implementa¸cões que estão em conformidade DEVEM reconhecer os certificados de versão 3.

A gera¸cão de certificados de versão 2 não é esperado pelas implementa¸cões baseadas no presente perfil.

(19)

E

rn

a

n

d

es

19

4.1.2.2 Serial Number

O serial number DEVE ser um número inteiro positivo atribu´ıdo pela AC para cada certifi-cado. 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.

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˜ao se encontram em conformidade PODEM emitir certificados com n´ u-meros negativos ou iguais a zero. Os sistemas usu´arios de certificado DEVERIAM ser preparados para tratar adequadamente tais certificados.

4.1.2.3 Signature

Este campo cont´em 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¸cão 4.1.1.2). 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.

4.1.2.4 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 ::= SET SIZE (1..MAX) OF AttributeTypeAndValue

AttributeTypeAndValue ::= SEQUENCE {

type AttributeType,

value AttributeValue }

AttributeType ::= OBJECT IDENTIFIER

AttributeValue ::= ANY -- DEFINED BY AttributeType

(20)

E

rn

a

n

d

es

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

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 é de-terminado 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 codi-fica¸cão PrintableString ou UTF8String para codificar o DirectoryString, com duas exce¸cõ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¸cõ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¸cão que as ACs utilizam.

Como notado acima, os nomes distintos são compostos por atributos. A presente espcifi-ca¸cão não restringe o conjunto de tipos de atributos que podem aparecer nos nomes. En-tretanto, as implementa¸cões em conformidade DEVEM estar preparadas para receberem certificados com nomes contendo o conjunto de atributos listados a seguir. Esta especifica-¸cão RECOMENDA o suporte a tipos adicionais de atributos.

O conjunto padrão de atributos foi definido na série de especifica¸cões do X.500 [X.520]. As implementa¸cões deta especifica¸cão DEVEM estar preparadas para receberem os seguintes tipos de atributos de nomes padrão nos campos issuer e subject (se¸cão 4.1.2.6):

* pa´ıs,

* organiza¸c˜ao,

* unidade organizacional, * qualificador do nome distinto, * nome do estado ou provincia,

* nome comum (por exemplo, “Susan Housley”), e * n´umero serial.

Além disso, as implementa¸cões desta especifica¸cão DEVERIAM estar preparadas para re-ceberem os seguintes tipo de atributos padrão tanto no nome do emissor quanto no nome do sujeito:

* localidade * t´ıtulo,

(21)

E

rn

a

n

d

es

21 * sobrenome, * nome, * iniciais, * pseudˆonimo, e

* qualificador de gera¸c˜ao (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¸cões desta especifica¸cão DEVEM estar preparadas para re-ceberem 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¸cão que deseja usar DNs em paralelo aos nomes DNS. Isso não é uma substitui¸cão para o componente dNSName das extensões alternative name. Não é necessário que as implementa¸cõ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¸cão de nomes de dom´ınio internacionalizados para uso no atributo domainComponent serão especificadas na se¸cão 7.3.

Os sistemas usuários de certificados DEVEM ser preparados para processar campos con-tendo nomes distintos do emissor e do sujeito (se¸cão 4.1.2.6) para validar a cadeia de nome do caminho de certifica¸cão (se¸cão 6). A cadeia de nomes é executada fazendo a correspon-dência entre o nome distinto do emissor no certificado com o nome do sujeito no certificado da AC. As regras de compara¸cão de nomes distintos estão especificadas na se¸cão 7.1. Se os nomes nos campos emissor e sujeito de um certificado correspondem de acordo com as regras especificadas na se¸cão 7.1 então o certificado é auto-emitido.

4.1.2.5 Validity

O per´ıodo de validade do certificado é o intervalo de tempo durante o qual a AC garante que vai manter as informa¸cõ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¸ca (notBefore) e a data na qual o per´ıodo de validade do certificado termina (notAfter). Am-bos notBefore e notAfter podem ser codificados como UTCTime ou GeneralizedTime. As ACS em conformidade com esse perfil deve sempre codificar datas de validade de cer-tificado até o ano de 2049 como UTCTime; data de validade de cercer-tificado em 2050 ou posterior, deve ser codificada como GeneralizedTime. As aplica¸cões em conformidade de-vem 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 ´e o per´ıodo de tempo compreendido entre notBe-fore e notAfter, inclusive nestas datas.

Em algumas situa¸cões, são fornecidos aos dispositivos certificados para os quais nenhuma data de expira¸cã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,

(22)

E

rn

a

n

d

es

22

´e esperado que tal certificado seja utilizado durante toda a vida ´util do dispositivo.

Para indicar que um certificado n˜ao tem data de validade bem definida, ao campo notAfter deve ser atribu´ıdo o valor de GeneralizedTime igual a 99991231235959Z.

Quando o emissor não é capaz de manter informa¸cões de estado até a data notAfter (inclu-sive quando a data contida em notAfter for 99991231235959Z), o emissor DEVE assegurar que não existirá nenhum caminho de certifica¸cão válido para o certificado após encerrada a manuten¸cão de informa¸cões sobre o estado do certificado. Isto pode ser conseguido através de expira¸cão ou revoga¸cão de todos os certificados de AC contendo a chave pública usada para verificar a assinatura do certificado e com a interrup¸cão do uso da chave pública utilizada para verificar a assinatura do certificado como âncora de confian¸ca.

4.1.2.5.1 UTCTime

O tipo de tempo universal, UTCTime, é um tipo padrão ASN.1 usado para representa¸cão de datas e tempo. O UTCTime especifica para ano os dois d´ıgitos de mais baixa órdem e o tempo é especificado com a precisão de um minuto ou um segundo. O UTCTime inclui tanto Z (para Zulu, ou Greenwich Mean Time) ou um tempo diferencial de tempo.

Para os propósitos deste perfil, os valores UTCTime DEVEM ser expressos em Greenwich Mean Time (Zulu) e DEVEM incluir os segundos (por exemplo, tempos são representados por YYMMDDHHMMSSZ), mesmo onde o número relacionado aos segundos seja zero. Os sistemas em conformidade DEVEM interpretar o campo ano (YY) como:

Quando YY for maior que ou igual a 50, o ano DEVER ´A ser interepretado como 19YY; e

Quando YY for menor que 50, o ano DEVER ´A ser interpretado como 20YY.

4.1.2.5.2 GeneralizedTime

O tipo tempo generalizado, GeneralizedTime, é um tipo padrão ASN.1 para representa¸cão precisa de tempo variável. Opcionalmente, o campo GeneralizedTime pode incluir a repre-senta¸cão do diferencial do tempo entre o tempo local e o Greenwich Mean Time.

Para os propósitos deste perfil, os valores de GeneralizedTime DEVEM ser expressos em Greenwich Mean Time (Zulu) e DEVEM incluir segundos (por exemplo, tempos são repre-sentados por YYYYMMDDHHMMMSSZ), mesmo quando o número de segundos for igual a zero. Os valores de GeneralizedTime N ÃO DEVEM incluir fra¸cões de segundos.

4.1.2.6 Subject

O campo subject identifica a entidade associada com a chave pública armazenada no campo subject public key. O nome do sujeito PODE ocorrer no campo subject e/ou na extensão subjectAltName. Se o sujeito é uma AC (por exemplo, a extensão basic constraints, a ser discutida na se¸cão 4.2.1.9, ocorre e o valor do campo cA será TRUE), então o campo sub-ject DEVE ser preenchido com um nome distinto não vazio correspondente ao conteúdo do campo issuer (se¸cão 4.1.2.4) em todos os certificados emitidos com o sujeito AC. Quando o sujeito for um emissor de LCR (por exemplo, na extensão key usage, discutida na se¸cão

(23)

E

rn

a

n

d

es

23

4.2.1.3, estará presente e o valor de cRLSign será TRUE), então o campo subject DEVE ser preenchido com um nome distinto não vazio correspondente ao conteúdo do campo issuer (se¸cão 5.1.2.3) em todas as LCRs emitidas pelo emissor de LCR. Quando a informa¸cão de nome do sujeito estiver presente apenas na extensão subjectAltName (por exemplo, uma chave relacionada apenas a um endere¸co de email ou URI), então o nome do sujeito DEVE ser uma sequência vazia e a extensão subjectAltName DEVE ser marcada como cr´ıtica. Quando o campo subject não for vazio, DEVE conter um nome distinto (DN) X.500. O DN DEVE ser único para cada entidade sujeito certificado por uma AC como definido no campo issuer. Uma AC PODE emitir mais que um certificado com o mesmo DN para a mesma entidade sujeito.

O campo subject é definido como um nome tipo X.501. Os requisitos de implementa¸cão para este campo são aqueles definidos para o campo issuer (se¸cão 4.1.2.4). As implementa-¸cões desta especifica¸cão DEVEM se preparadas para receberem nomes de sujeito contendo os tipos de atributos necessários para o campo issuer. As implementa¸cões desta especi-fica¸cão DEVERIAM ser preparadas para receber nomes de sujeito contendo os tipos de atributos recomendados para o campo issuer. A sintaxe e os identificadores de objetos (OIDs) associados a estes tipos de atributos são fornecidos nos módulos ASN.1 do apêndice A. As implementa¸cões desta especifica¸cão DEVEM usar as regras de compara¸cão contidas na se¸cão 7.1 para processar os tipos de atributos não comuns (por exemplo, para come de cadeia) cujos valores de atributos usam uma das op¸cões de codifica¸cão definidas como DirectoryString. Compara¸cões binárias deveriam ser utilizadas quando tipos de atribu-tos incomuns incluirem valores de atribuatribu-tos com op¸cões de codifica¸cão diferentes daquelas encontradas no DirectoryString. Isso permite às implementa¸cões processarem certificados com atributos incomuns presentes no nome de sujeito.

Na codifica¸cão dos valores de atributos do tipo DirectoryString, as ACs em conformidade DEVEM usar codifica¸cão PrintableString ou UTF8String, com as seguintes exce¸cões:

(a) Quando o sujeito de um certificado for uma AC, o campo subject DEVE ser codi-ficado da mesma forma que ele foi codicodi-ficado no campo issuer (se¸cão 4.1.2.4) em todos os certificados emitidos pelo sujeito AC. Assim, se o sujeito AC codificar atributos nos campos issuer do certificado dos certificados que ela emite usando codifica¸cão TeletexSting, BMPString, ou UniversalString, o campo subject dos certificados emitidos para aquela AC DEVEM usar a mesma codifica¸cão.

(b) Quando o sujeito de um certificado ´e um emissor de LCR, o campo subject DEVE ser codificado da mesma forma que foi codificado no campo issuer (se¸c˜ao 5.1.2.3) em todas as LCRs emitidas pelo sujeito emissor da LCR.

(c) TeletexString, BMPString e UniversalString são inclu´ıdos para compatibilidade com o legado, e N ÃO DEVERIAM ser usados em certificados para novos sujei-tos. Entretanto, estes tipos PODEM ser usados em certificados onde o nome foi previamente estabelecido, incluindo os casos nos quais um novo certificado esta sendo emitido para um novo sujeito onde os atributos sendo codificados foram previamente estabelecidos no certificado emitido para outros sujeitos. Os usuários do certificado DEVERIAM ser preparados para receberem certificados com esses tipos.

Implementa¸c˜oes do legado existem onde um endere¸co de email est´a incorporado no nome distinto do sujeito como um atributo emailAddress [RFC2985]. O valor do atributo para

(24)

E

rn

a

n

d

es

24

emailAddress é do tipo IA5String para permitir inclusão do caractere “@”, que não é parte do conjunto de caracteres PrintableString. Valores de atributo emailAddress não são sens´ı-veis quanto a maiúsculas e minúsculas (por exemplo, “[email protected]” é o mesmo que “[email protected]”).

As implementa¸cões em conformidade quando da gera¸cão de novos certificados com endere¸cos de email PODEM usar o rfc822Name na extensão de nome de sujeito alternativo (se¸cão 4.2.1.6) para descrever tal identidade. Inclusões simultâneas do atributo emailAddress no nome distinto do sujeito para suportar implementa¸cões do legado não é uma prática incentivada, embora seja permitida.

4.1.2.7 Subject Public Key Info

Este campo é utilizado para incluir a chave pública e o identificar o algoritmo com o qual a chave é usada (por exemplo, RSA, DSA ou Diffie-Hellman). O algoritmo é identificado usando a estrutura AlgorithmIdentifier especificada na se¸cão 4.1.1.2. O identificador de objeto para o algoritmo suportado e o método de codifica¸cão do material da chave p´ u-blica (chave pública e os seus parâmetros) são especificados em [RFC3279], [RFC4055] e [RFC4491].

4.1.2.8 Unique Identifiers

Esses campos somente DEVEM estar presentes quando a versão for 2 ou 3 (se¸cão 4.1.2.1). Esses campos N ÃO DEVEM aparecer quando a versão for 1. O subject e issuer unique identifiers estão presentes no certificado para possibilitar a reutiliza¸cão do nome do sujeito e/ou emissor no decorrer do tempo. Este perfil RECOMENDA que os nomes não sejam reutilizados para entidades diferentes. ACs em conformidade com este perfil N ÃO DEVEM gerar certificados com unique identifiers. As aplica¸cões em conformidade com este perfil DEVERIAM ser capazes de analisar certificados que incluem unique identifiers, mas não há nenhum requisito de processamento associado ao unique identifiers.

4.1.2.9 Extensions

Este campo DEVE aparecer apenas quando a versão for 3 (se¸cão 4.1.2.1). Quando presente, o campo é uma SEQUENCE de um ou mais extensões de certificado. O formato e o conteúdo das extensões de certificado da ICP de Internet estão definidos na se¸cão 4.2.

4.2 Extens˜

oes do Certificado

As extensões definidas para certificados X.509 v3 fornecem métodos para associar atribu-tos adicionais aos usuários ou chaves públicas, e também para a gestão das rela¸cões entre ACs. O formato do certificado X.509 v3 também permite que comunidades definam ex-tensões privadas que levam informa¸cões exclusivas a essas comunidades. Cada uma das extensões do certificado é designada como cr´ıtica ou não cr´ıtica. O sistema que utiliza cer-tificado deve rejeitar o cercer-tificado quando encontrar uma extensão cr´ıtica não reconhecida ou uma extensão cr´ıtica que contenha informa¸cões que não podem ser processadas. A ex-tensão não-cr´ıtica PODE ser ignorada quando não reconhecida, mas DEVE ser processada quando reconhecido. As se¸cões seguintes apresentam extensões recomendadas usadas nos certificados Internet Internet e os localiza¸cão padrão para a informa¸cão. As comunidades

(25)

E

rn

a

n

d

es

25

podem optar por usar extensões adicionais, no entanto, todo cuidado deve ser tomado na ado¸cão de qualquer extensão cr´ıtica que possam inviabilizar o seu uso em um contexto geral. Cada extensão inclui um OID e uma estrutura ASN.1. Quando uma extensão aparece em um certificado, o respectivo OID ocorre como um campo extnID e a estrutura codificada em DER do ASN.1 é o valor do string de octetos contido no extnValue. O certificado N ÃO DEVE incluir mais que uma instância de uma determinada extensão. Por exemplo, o certificado pode conter apenas uma extensão authority key identifier (se¸cão 4.2.1.1). Uma extensão inclui a op¸cão de criticidade como um valor booleano, com valor padrão FALSE. O texto relacionado a cada das extensões, especifica os valores aceitáveis para campo cr´ıtico para ACs em conformidade com este perfil.

As ACs em conformidade DEVEM suportar as extensões key identifiers (se¸cão 4.2.1.1 e 4.2.1.2), basic constraints (se¸cão 4.2.1.9), key usage (se¸cão 4.2.1.3), e certificate policies (se¸cão 4.2.1.4). Quando uma AC emite certificados com uma sequência vazia para o campo subject, a AC DEVE suportar a extensão subject alternative name (se¸cão 4.2.1.6). O suporte às extensões restantes permanece opcional. As ACs em conformidade PODEM su-portar extensões que não são identificadas nesta especifica¸cão; os emissores de certificados com estas extensões que as marcarem como cr´ıticas podem dificultar a interoperabilidade. No m´ınimo, as aplica¸cões em conformidade com este perfil DEVEM reconhecer as seguintes extensões: key usage (se¸cão 4.2.1.3), certificate policies (se¸cão 4.2.1.4), subject alternative name (se¸cão 4.2.1.6), basic constraints (se¸cão 4.2.1.9), name constraints (se¸cão 4.2.1.10), policy constraints (se¸cão 4.2.1.11), extended key usage (se¸cão 4.2.1.12), e inhibir anyPolicy (se¸cão 4.2.1.14).

Adicionalmente, as aplica¸cões em conformidade com este perfil DEVERIAM reconhecer as extensões authority and subject key identifier (se¸cão 4.2.1.1 e 4.2.1.2) e policy mappings (se¸cão 4.2.1.5).

4.2.1 Extens˜oes Padr˜ao

Esta se¸cão identifica as extensões padrão de certificado no [X.509] para uso na ICP Internet. Cada extensão é associada a um OID definido em [X.509]. Esses OIDs são membros do arco de OID id-ce-arc, que é definido da seguinte forma:

id-ce OBJECT IDENTIFIER ::= { joint-iso-ccitt(2) ds(5) 29 }

4.2.1.1 Authority Key Identifier

A extensão authority key identifier fornece um meio de identifica¸cão da chave pública cor-respondente a chave privada usada para assinar o certificado. Esta extensão é utilizada quando um emissor tem múltiplas chaves de assinatura (também d devido a ocorrência de vários pares de chaves simultâneos ou devido à mudan¸ca do par de chaves). A identifica¸cão PODE ser baseada tanto no key identifier (identificador da chave do sujeito no certificado do emissor) como no nome do emissor e número serial.

O campo keyIdentifier da extensão authorityKeyIdentifier DEVE ser inclu´ıdo em todos os certificados gerados por ACs em conformidade para facilitar a constru¸cão do caminho de certifica¸cão. Existe uma exce¸cão; quando uma AC distribui sua chave pública na forma de certificado “auto-assinado”, o identificador de chave da autoridade PODE ser omitido.

(26)

E

rn

a

n

d

es

26

A assinatura em um certificado auto-assinado é gerada com a chave privada associada a chave pública do sujeiro do certificado. (Isso prova que o emissor tem a posse tanto da chave pública quanto da privada). Neste caso, o sujeito e o identificador de chave de au-toridade devem ser idênticos, mas apenas o identificador de chave do sujeito é necessário para a constru¸cão do caminho de certifica¸cão.

O valor do campo keyIdentifier DEVERIA ser derivado a partir da chave pública utilizada para verificar a assinatura do certificado ou do método que gera valores únicos. Dois mé-todos comuns para gera¸cão de identificadores para chave pública são descritos na se¸cão 4.2.1.2. Quando o identificador de chave não tiver sido previamente definido, esta especifi-ca¸cão RECOMENDA o uso de um desses métodos para a gera¸cão do keyIdentifiers ou o uso de um método similar que usa um algoritmo de hash diferente. Quando um identificador de chave tiver sido previamente definido, a AC DEVERIA usar o identificador previamente definido.

Este perfil RECOMENDA suporte ao método de identificão de chave a todos os usuários de certificado.

As ACs em conformidade DEVEM marcar esta extens˜ao como n˜ao cr´ıtica. id-ce-authorityKeyIdentifier OBJECT IDENTIFIER ::= { id-ce 35 }

AuthorityKeyIdentifier ::= SEQUENCE {

keyIdentifier [0] KeyIdentifier OPTIONAL,

authorityCertIssuer [1] GeneralNames OPTIONAL,

authorityCertSerialNumber [2] CertificateSerialNumber OPTIONAL }

KeyIdentifier ::= OCTET STRING 4.2.1.2 Subject Key Identifier

A extensão subject key identifier fornece meios para identifica¸cão de certificados que con-tém uma determinada chave pública.

Para facilitar a constru¸cão do caminho de certifica¸cão, esta extensão DEVE aparecer em todos os certificados de AC, ou seja, todos os certificados que incluem a extensão basic constraints (se¸cão 4.2.1.9) nos quais o valor de cA é TRUE. Nos certificados de AC em conformidade, o valor do subject key identifier DEVE ser o valor colocado no campo key identifier da extensão authority key identifier (se¸cão 4.2.1.1) dos certificados emitidos pelo sujeito deste certificado. As aplica¸cões não precisam verificar que os identificadores de chave corresponde quando realizam a valida¸cão do caminho de certifica¸cão.

Para certificados de AC, os identificadores de chave de sujeito DEVERIAM ser derivados da chave pública ou a partir de um método que gera valores únicos. Dois métodos comuns para gera¸cão de identificadores de chave a partir da chave pública são:

(1) o keyIdentifier é composto por um hash de 160 bits SHA-1 do valor do BIT STRING subjectPublicKey (exclu´ıdos o rótulo, o tamanho e o número de bits não utilizados).