network working group d. cooper request for comments: 5280 … · 2013. 3. 6. · es 2 pkix...

Ern

andes

1

PKIX Certificate and CRL Profile RFC 5280 Maio de 2008

OBS: A presente traducao nao oficial da (RFC5280) tem como finalidadefacilitar o estudo e o entendimento da Norma.

Network Working Group D. CooperRequest for Comments: 5280 NISTObsoletes: 3280, 4325, 4630 S. SantessonCategory: Standards Track Microsoft

S. FarrellTrinity College Dublin

S. BoeyenEntrust

R. HousleyVigil Security

W. PolkNIST

May 2008

Traducao para o PortuguesInternet X.509 Public Key Infrastructure Certificate

and Certificate Revocation List (CRL) Profile

Cooper, et al. Standards Track Traducao para Estudo

Ern

andes

2


Estado do Documento

Este documento especifica o protocolo padrao Internet a ser seguido para a ComunidadeInternet, e solicita discussao e sugestoes para sua melhoria. Consulte a edicao atual dodocumento “Internet Official Protocol Standards” (STD 1) para obter a situacao de padro-nizacao e o estado do presente protocolo. A distribuicao deste documento e 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 introducao fornece uma visao geral dessaabordagem e modelo. O formato do certificado X.509 v3 e descrito em detalhes, com in-formacoes adicionais sobre seu formato e a semantica dos formularios de nome Internet.Sao descritas as extensoes padrao do certificado e duas extensoes especıficas da Internet.E especificado o conjunto exigido de extensoes. Sao descritos detalhes do formato da LCRX.509 v2, juntamente com as extensoes padrao e aquelas especıficas da Internet. E descritoum algoritmo para validacao do caminho de certificacao X.509. Nos apendices sao forneci-dos um modulo ASN.1 e exemplos.


Ern

andes

3


Sumario

1 Introducao 6

2 Requisitos e Pressupostos 82.1 Comunicacao e Topologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.2 Criterio de Acessibilidade . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.3 Expectativas dos Usuarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.4 Expectativas dos Administradores . . . . . . . . . . . . . . . . . . . . . . . . 9

3 Visao Geral do Modelo 93.1 Versao 3 do Certificado X.509 . . . . . . . . . . . . . . . . . . . . . . . . . . 103.2 Caminhos de certificacao e Confianca . . . . . . . . . . . . . . . . . . . . . . 113.3 Revogacao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133.4 Protocolos Operacionais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143.5 Protocolos de Gerenciamento . . . . . . . . . . . . . . . . . . . . . . . . . . 15

4 Perfil do Certificado e das Extensoes do Certificado 164.1 Campos Basicos do Certificado . . . . . . . . . . . . . . . . . . . . . . . . . 16

4.1.1 Campos do Certificado . . . . . . . . . . . . . . . . . . . . . . . . . . 174.1.1.1 tbsCertificate . . . . . . . . . . . . . . . . . . . . . . . . . . 174.1.1.2 signatureAlgorithm . . . . . . . . . . . . . . . . . . . . . . . 174.1.1.3 signatureValue . . . . . . . . . . . . . . . . . . . . . . . . . 18

4.1.2 TBSCertificate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184.1.2.1 Version . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184.1.2.2 Serial Number . . . . . . . . . . . . . . . . . . . . . . . . . 194.1.2.3 Signature . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194.1.2.4 Issuer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194.1.2.5 Validity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

4.1.2.5.1 UTCTime . . . . . . . . . . . . . . . . . . . . . . . 224.1.2.5.2 GeneralizedTime . . . . . . . . . . . . . . . . . . . 22

4.1.2.6 Subject . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224.1.2.7 Subject Public Key Info . . . . . . . . . . . . . . . . . . . . 244.1.2.8 Unique Identifiers . . . . . . . . . . . . . . . . . . . . . . . . 244.1.2.9 Extensions . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

4.2 Extensoes do Certificado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244.2.1 Extensoes Padrao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

4.2.1.1 Authority Key Identifier . . . . . . . . . . . . . . . . . . . . 254.2.1.2 Subject Key Identifier . . . . . . . . . . . . . . . . . . . . . 264.2.1.3 Key Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . 274.2.1.4 Certificate Policies . . . . . . . . . . . . . . . . . . . . . . . 294.2.1.5 Policy Mappings . . . . . . . . . . . . . . . . . . . . . . . . 324.2.1.6 Subject Alternative Name . . . . . . . . . . . . . . . . . . . 324.2.1.7 Issuer Alternative Name . . . . . . . . . . . . . . . . . . . . 354.2.1.8 Subject Directory Attributes . . . . . . . . . . . . . . . . . 354.2.1.9 Basic Constraints . . . . . . . . . . . . . . . . . . . . . . . . 354.2.1.10 Name Constraints . . . . . . . . . . . . . . . . . . . . . . . 364.2.1.11 Policy Constraints . . . . . . . . . . . . . . . . . . . . . . . 384.2.1.12 Extended Key Usage . . . . . . . . . . . . . . . . . . . . . . 394.2.1.13 CRL Distribution Points . . . . . . . . . . . . . . . . . . . . 41


Ern

andes

4


4.2.1.14 Inhibit anyPolicy . . . . . . . . . . . . . . . . . . . . . . . . 424.2.1.15 Freshest CRL (Delta CRL Distribution Point) . . . . . . . . 43

4.2.2 Extensoes Privadas Internet . . . . . . . . . . . . . . . . . . . . . . . 434.2.2.1 Authority Information Access . . . . . . . . . . . . . . . . . 444.2.2.2 Subject Information Access . . . . . . . . . . . . . . . . . . 45

5 Perfil da LCR e das Extensoes da LCR 475.1 Campos da LCR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

5.1.1 Campos do CertiticateList . . . . . . . . . . . . . . . . . . . . . . . . 495.1.1.1 tbsCertList . . . . . . . . . . . . . . . . . . . . . . . . . . . 495.1.1.2 signatureAlgorithm . . . . . . . . . . . . . . . . . . . . . . . 505.1.1.3 signatureValue . . . . . . . . . . . . . . . . . . . . . . . . . 50

5.1.2 Certificate List “A Ser Assinado” . . . . . . . . . . . . . . . . . . . . 505.1.2.1 Version . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 515.1.2.2 Signature . . . . . . . . . . . . . . . . . . . . . . . . . . . . 515.1.2.3 Issuer Name . . . . . . . . . . . . . . . . . . . . . . . . . . . 515.1.2.4 This Update . . . . . . . . . . . . . . . . . . . . . . . . . . 515.1.2.5 Next Update . . . . . . . . . . . . . . . . . . . . . . . . . . 515.1.2.6 Revoked Certificates . . . . . . . . . . . . . . . . . . . . . . 525.1.2.7 Extensoes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

5.2 Extensoes da LCR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 525.2.1 Authority Key Identifier . . . . . . . . . . . . . . . . . . . . . . . . . 535.2.2 Issuer Alternative Name . . . . . . . . . . . . . . . . . . . . . . . . . 535.2.3 CRL Number . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 535.2.4 Delta CRL Indicator . . . . . . . . . . . . . . . . . . . . . . . . . . . 545.2.5 Issuing Distribution Points . . . . . . . . . . . . . . . . . . . . . . . . 565.2.6 Freshest CRL (Ponto de Distribuicao de LCR delta) . . . . . . . . . . 585.2.7 Authority Informatioin Access . . . . . . . . . . . . . . . . . . . . . . 58

5.3 Extensoes da Entrada da LCR . . . . . . . . . . . . . . . . . . . . . . . . . . 595.3.1 Reason Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 605.3.2 Invalidity Date . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 605.3.3 Certificate Issuer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

6 Validacao de Caminho de Certificacao 616.1 Validacao Basica de Caminho . . . . . . . . . . . . . . . . . . . . . . . . . . 62

6.1.1 Entradas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 646.1.2 Inicializacao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 666.1.3 Processamento Basico de Certificado . . . . . . . . . . . . . . . . . . 686.1.4 Preparacao para o Certificado i+1 . . . . . . . . . . . . . . . . . . . . 726.1.5 Procedimento de Encerramento . . . . . . . . . . . . . . . . . . . . . 746.1.6 Saıdas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

6.2 Uso do Algoritmo de Validacao de Caminho . . . . . . . . . . . . . . . . . . 756.3 Validacao de LCR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

6.3.1 Entradas de Revogacao . . . . . . . . . . . . . . . . . . . . . . . . . . 766.3.2 Processamento de LCR . . . . . . . . . . . . . . . . . . . . . . . . . . 77

7 Regras de Processamento para Nomes Internacionalizados 797.1 Nomes Internacionalizados em Distinguished Names . . . . . . . . . . . . . . 807.2 Nome de Domınio Internacionalizados em GeneralName . . . . . . . . . . . . 81


Ern

andes

5


7.3 Nomes de Domınio Internacionalizados em Distinguished Names . . . . . . . 827.4 Identificadores de Recurso Internacionalizados . . . . . . . . . . . . . . . . . 827.5 Enderecos de Correio Eletronico Internacionalizados . . . . . . . . . . . . . . 83

8 Consideracoes de Seguranca 84

9 Consideracoes IANA 87

10 Agradecimento 87

11 Referencias 8811.1 Referencias Normativas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8811.2 Referencias Informativas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

Apendice A. Estruturas e OIDs em Pseudo-ASN.1 91A.1 Modulo Explicitamente Rotulado, sintaxe 1988 . . . . . . . . . . . . . . . . . 91A.2 Modulo Implicitamente Rotulado, sintaxe 1988 . . . . . . . . . . . . . . . . . 105

Apendice B. Notas ASN.1 112

Apendice C. Exemplos 114C.1 Certificado “auto-assinado” RSA . . . . . . . . . . . . . . . . . . . . . . . . . 115C.2 Certificado de Entidade Final Usando RSA . . . . . . . . . . . . . . . . . . . 118C.3 Certificado de Entidade Final Usando DSA . . . . . . . . . . . . . . . . . . . 121C.4 Lista de Certificados Revogados . . . . . . . . . . . . . . . . . . . . . . . . . 125

Endereco dos Autores 127

Declaracao Plena de Direitos Autorais 128

Propriedade Intelectual 128


Ern

andes

6


1 Introducao

A presente especificacao e parte do conjunto de padroes para o X.509 - Infraestrutura deChaves Publicas (ICP) Internet.

A especificacao define perfis do formato e da semantica de certificados, e listas de certifi-cados revogados(LCRs) para a ICP Internet. Sao descritos procedimentos necessarios parao processamento dos caminhos de certificacao no ambiente da Internet. Finalmente, nosapendices, sao fornecidos modulos em ASN.1 para todas as estruturas de dados definidasou referenciadas.

A secao 2 descreve os requisitos de ICP na Internet e os pressupostos que se relacionamao escopo deste documento. A Secao 3 apresenta o modelo da arquitetura e descreve suarelacao com a norma IETF anterior, assim como com as normas ISO/IEC/ITU-T. Emparticular, e descrita a relacao existente entre esta especificacao e aquelas contidas nosdocumentos PEM IETF e ISO/IEC/ITU-T X.509.

Secao 4 define perfis para o certificado X.509 v3, e seccao 5 define perfis para a LCR X.509v2. Os perfis incluem a identificacao de extensoes ISO/IEC/ITU-T e extensoes ANSI quepodem ser uteis na ICP Internet. Os perfis sao apresentados em Syntax Notation One(ASN.1) de 1988, em vez da sintaxe ASN.1 de 1997, utilizada nas normas mais recentes doISO/IEC/ITU-T.

Secao 6 inclui procedimentos para validacao do caminho de certificacao. Estes procedimen-tos baseiam-se nas definicoes do ISO/IEC/ITU-T. E NECESSARIO que as implementacoesobtenham os mesmos resultados, embora nao seja requerido que estas utilizem os procedi-mentos especificados.

Os procedimentos para identificacao e codificacao de chave publica e assinaturas sao defi-nidos em [RFC3279], [RFC4055] e [RFC4491]. Nao e obrigatorio que as implementacoesdesta especificacao usem quaisquer algoritmo criptografico. Embora, as implementacoes emconformidade com esta especificacao, e que usam os algoritmos identificados em [RFC3279],[RFC4055, e [RFC4491], DEVEM identificar e codificar os materiais de chave publica e as-sinaturas como descrito naquelas especificacoes.

Finalmente, sao fornecidos tres apendices para ajudar nas implementacoes. O ApendiceA contem todas as estruturas ASN.1 definidas ou referenciadas nesta especificacao. Comoinformado acima, o material e apresentado na versao ASN.1 de 1988. O apendice B con-tem notas sobre caracterısticas menos conhecidas da notacao ASN.1 utilizadas no presentedocumento. O Apendice C contem exemplos de certificados e LCR em conformidade comesta especificacao.

Esta especificacao torna obsoleta a [RFC3280]. As diferencas entre a presente especificacaoe aquela contida na [RFC3280] sao listadas abaixo:

∗ Secao 7 especifica o suporte avancado a nomes internacionalizados, com regras paracodificacao e satisfazem os Nomes de Domınios Internacionalizados, os Identificadoresde Recursos Internacionalizados (IRIs), e nomes distintos. Estas regras estao alinha-das com regras de comparacao estabelecidas em RFC atualizadas, incluindo entreestas, [RFC3490], [RFC3987], e [RFC4518].


Ern

andes

7


∗ As secoes 4.1.2.4 e 4.1.2.6 incorporam as condicoes para a continuacao de uso do legadodos esquemas de codificacao especificados na [RFC4630]. Quando utilizado por ICP jaestabelecida, a transicao para UTF8String poderia causar negacao de servico baseadoem falhas na cadeia de nomes ou processamento incorreto de restricoes de nomes.

∗ A secao 4.2.1.4 da [RFC3280], que especifica a extensao de certificado privateKeyU-sagePeriod, mas nao incentiva o uso, foi removida. O uso dessa extensao padraoISO nem e incentivada, nem recomendada para ser utilizada em ambientes de ICPInternet.

∗ A secao 4.2.15 recomenda que a extensao policy mappigns seja marcada como crıtica.A [RFC3280] recomendava que esta extensao fosse marcada como nao crıtica.

∗ A secao 4.2.1.11 recomenda a marcacao da extensao policy constraints como crıtica.A [RFC3280] permitia que esta extensao fosse marcada como crıtica ou nao crıtica.

∗ A extensao Authority Information Access (AIA) da LCR, como especificada em[RFC4325], foi adicionada na secao 5.2.7.

∗ A secao 5.2 e 5.3 esclarece as regra para o tratamento de extensoes nao reconhedidasda LCR, assim como extensoes de entrada da LCR, respectivamente.

∗ A secao 5.3.2 da [RFC3280], que especificava a extensao holdInstructionCode de en-trada de LCR, foi removida.

∗ O algoritmo de validacao de caminho especificado na secao 6, nao controla mais acriticidade das extensoes de polıticas de certificado nas cadeias de certificados. Na[RFC3280], esta informacao era retornada para um terceiro confiavel.

∗ A secao de Consideracoes de Seguranca trata dos riscos relacionados a dependenciascirculares causados pelo uso de esquemas https ou similares nos pontos de distri-buicao de LCR, acesso a informacao de autoridade (AIA), ou extensoes de acesso ainformacoes de sujeito (SIA).

∗ A secao de Consideracoes de Seguranca trata de riscos relacionados a ambiguidadede nomes.

∗ A secao de Consideracoes de Seguranca referencia a [RFC4210] quanto a procedimen-tos para tratar mudancas de operacoes de AC.

Os modulos ASN.1 contidos no apendice A nao foram modificados, exceto pelo conteudode ub-emailaddress-length que foi mudado de 128 para 255, para se alinhar ao PKCS #9[RFC2985].

As palavras-chave“DEVE”,“NAO DEVE”,“NECESSARIO”,“DEVERA”,“NAO DEVERA”,“DEVERIA”, “NAO DEVERIA”, “RECOMENDADO”, “PODE”, e “OPCIONAL” contan-tes no presente documento (em letras maiusculas, como mostrado), devem ser interpretadoscomo descritas em [RFC2119].


Ern

andes

8PKIX Certificate and CRL Profile RFC 5280 Maio de 2008

2 Requisitos e Pressupostos

O objetivo desta especificacao e desenvolver um perfil para facilitar o uso de certificadosX.509 dentro de aplicacoes de Internet para as comunidades que pretendem fazer uso datecnologia X.509. Tais aplicacoes podem incluir WWW, correio eletronico, WWW eletro-nica, autenticacao de usuario, e IPsec. A fim de aliviar alguns dos obstaculos ao uso decertificados X.509, este documento define um perfil para promover o desenvolvimento desistemas de gerenciamento de certificado, o desenvolvimento de ferramentas de aplicacao ea interoperabilidade determinada pela polıtica.

Algumas comunidades terao de complementar ou substituir possivelmente, este perfil, a fimde satisfazer as exigencias de domınios de aplicacoes especializadas ou em ambientes comautorizacao adicional, garantia, ou requisitos operacionais. No entanto, para aplicacoesbasicas, representacoes comuns de atributos usados frequentemente sao definidos para queos desenvolvedores de aplicativos possam obter as informacoes necessarias sem levar emconta o emissor de um certificado especial ou a Lista de Certificados Revogados (LCR).

O usuario de certificado deveria rever a polıtica de certificado gerado pela Autoridade Cer-tificadora (AC) antes de confiar nos servicos de autenticacao ou nao-repudio associados coma chave publica contida em determinado certificado. Por isso, esta norma nao prescreveregras juridicamente vinculativas ou deveres.

Com o surgimento de ferramentas adicionais para o tratamento de autorizacao suplemen-tar e gestao de atributos, tais como os certificados de atributos, pode se tornar apropriadolimitar o conjunto de atributos de autenticacao inclusos no certificado. Essas ferramentasadicionais de gestao podem fornecer metodos mais adequados para transmissao de muitosatributos autenticados.

2.1 Comunicacao e Topologia

Usuarios de certificados irao operar em uma ampla gama de ambientes com relacao a suatopologia de comunicacao, especialmente os usuarios de correio eletronico seguro. Esteperfil suporta usuarios sem banda larga, em tempo real, conectividade IP, ou alta disponi-bilidade de conexao. Alem disso, o perfil permite a presenca de firewall ou qualquer outrotipo de filtragem de comunicacao.

Este perfil nao considera a implantacao de um sistema de diretorio X.500 [X.500] ou de umLightweight Directory Access Protocol (LDAP) [RFC4510]. O perfil nao proıbe a utilizacaodo servico de diretorio X.500 ou de um diretorio LDAP; desta forma, qualquer meio dedistribuicao de certificados e listas de certificados revogados (LCRs) pode ser usado.

2.2 Criterio de Acessibilidade

O objetivo da Infraestrutura de Chaves Publica (PKI) e atender as necessidades de funcoesdeterminısticas de identificacao automatizada, autenticacao e controle de acesso, e autori-zacao. O suporte para esses servicos determina os atributos contidos no certificado, bemcomo a informacao de controle auxiliar contidas no certificado, tais como dados de polıticase restricoes quanto ao caminho de certificacao.


Ern

andes

9


2.3 Expectativas dos Usuarios

Os usuarios da ICP Internet sao pessoas e processos que usam o software cliente e sao ossujeitos nomeados nos certificados. Estes usos incluem destinatarios e remetentes de correioeletronico, clientes de navegadores WWW, servidores WWW, e o gerenciador de chave paraIPsec dentro de um roteador. Este perfil reconhece as limitacoes das plataformas usadas poresses usuarios, assim como as limitacoes em termos de sofisticacao e cuidados implementadospelos proprios usuarios. Isso se manifesta na responsabilidade mınima sobre a configuracaodo usuario (por exemplo, chaves confiaveis de AC, regras), as limitacoes explıcitas de usoda plataforma dentro do certificado, as restricoes quanto ao caminho de certificacao paraproteger o usuario de acoes maliciosas, e aplicativos que automatizam funcoes de validacaode forma sensata.

2.4 Expectativas dos Administradores

Tal como acontece com as expectativas dos usuarios, o perfil para ICP Internet e estru-turado de maneira a apoiar os indivıduos que geralmente operam as ACs. Fornecer aosadministradores opcoes ilimitadas aumenta as chances de um erro sutil de um adminis-trador resulte em comprometimento amplo. Alem disso, as escolhas ilimitadas aumentammuito a complexidade do software que processa e valida os certificados criados pela AC.

3 Visao Geral do Modelo

A seguir e uma visao simplificada do modelo de arquitetura assumido pela infra-estruturade chave publica usando X.509 (PKIX) especificacoes.

Os componentes deste modelo sao:

Entidade final: usuario de certificados da ICP e/ou sistema usuario final, representadono campo sujeito (subject) do certificado;

AC: autoridade certificadora;

AR: autoridade de registro, ou seja, e um sistema opcional para o qual a ACdelega determinadas funcoes de gestao;

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

Repositorio: sistema ou conjunto de sistemas distribuıdos que armazena certificadose LCRs e que serve como meio de distribuicao dos certificados e LCRspara as entidades finais.

As ACs sao responsaveis por indicar o status de revogacao dos certificados que emitem. Ainformacao sobre o estado de revogacao pode ser fornecida atraves do Online CertificateStatus Protocol (OCSP) [RFC2560], atraves de Listas de Certificados Revogados (LCR),ou algum outro mecanismo. Em geral, quando as informacoes de status de revogacao saofornecida por CRLs, a AC tambem e o emissor da CRL. No entanto, uma AC pode delegara responsabilidade pela emissao das LCRs para uma entidade diferente.


Ern

andes

10


Note-se que uma Autoridade de Atributos (AA) tambem pode optar por delegar a publi-cacao de suas LCRs para um emissor de LCR.

+---+

| R | +--------------------+

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

| p | Transac~oes +--------------------+

| o | operacionais ^

| s | e transac~oes de | Transac~oes de

| i | gerenciamento | Gerenciamento Usuarios

| 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 transac~oes

| | Publica LCR +--------------+ v

| L | +------+

| C | | AC |

| R | +------+

+---+

Figura 1: Entidades da ICP

3.1 Versao 3 do Certificado X.509

Os usuarios de uma chave publica necessitam ter confianca de que a chave privada as-sociada e de propriedade do sujeito remoto correto (pessoa ou sistema), com a qual umdeterminado mecanismo de criptografia ou assinatura digital sera utilizado. Esta confiancae obtido atraves da utilizacao de certificados de chave publica, que sao estruturas de dadosque relacionam os valores de chave publica a indivıduos. Esta relacao de confianca ocorrea partir da utilizacao de AC confiavel que assina digitalmente cada certificado. O AC podebasear esta afirmacao em meios tecnicos (por exemplo, a prova da posse atraves de umprotocolo de desafia e resposta), apresentacao da chave privada, ou em um afirmacao dosujeito. Um certificado tem uma vida util valida limitada, o que esta indicado no seu con-teudo assinado. Pelo fato da assinatura do certificado e o seu perıodo de validade poderemser verificados de maneira independente pelo sistema usuario, que faz uso da tecnologia, oscertificados podem ser distribuıdos atraves de meios de comunicacao e sistemas de servi-dores nao confiaveis , e podem ser armazenados, de forma insegura, em cache nos sistemas


Ern

andes

11


usuarios.

O ITU-T X.509 (anteriormente CCITT X.509) ou ISO/IEC 9594-8, que foi publicado pelaprimeira vez em 1988, como parte das recomendacoes X.500 para diretorio, define o for-mato de certificado padrao [X.509]. O formato do certificado no padrao de 1988 e chamadoversao 1 (v1) do formato. O X.500 foi revisto em 1993, quando mais dois campos foramadicionados, resultando na versao 2 (v2) do formato.

A RFC do Internet Privacy Enhanced Mail (PEM), publicada em 1993, incluiu especi-ficacoes para uma infraestrutura de chaves publicas baseada em certificados X.509 v1[RFC1422]. A experiencia adquirida na tentativa de implantar RFC 1422 deixou claroque os formatos de certificado v1 e v2 eram deficientes em varios aspectos. O mais impor-tante, mais campos foram necessarios para transportar informacoes que o projeto do PEMdesign e a experiencia de implementacao tinham considerado necessario. Em resposta aestes novos requisitos, a ISO/IEC, ITU-T, e ANSI X9 desenvolveu o X.509 versao 3 (v3)do formato do certificado. O formato v3 estende o formato v2 incluindo previsoes paracampos de extensao adicionais. Tipos de extensoes particulares podem vir especificadosem normas ou pode ser definido e registrado por qualquer organizacao ou comunidade. Emjunho de 1996, a padronizacao do formato v3 basica foi concluıda [X.509].

A ISO/IEC, ITU-T, e ANSI X9 tambem desenvolveram extensoes padrao para uso nocampo extensoes v3 [X.509] [X9.55]. Estas extensoes podem transmitir dados como infor-macoes adicionais para identificacao do sujeito, informacoes de atributos-chave, informacoespolıticas, e restricoes para o caminho de certificacao.

ISO / IEC, ITU-T, e ANSI X9 tambem desenvolveram extensoes padrao para uso no campoextensoes v3 [X.509] [X9.55]. Estas extensoes podem transmitir dados como informacoesadicionais sujeito identificacao, informacoes de atributo-chave, informacoes polıticas, e res-tricoes de caminho de certificacao.

No entanto, as extensoes padraoISO/IEC, ITU-T, e ANSI X9 sao muito amplas em suaaplicabilidade. Para desenvolver implementacoes interoperaveis de sistemas X.509 v3 parauso na Internet, e necessario especificar um perfil para uso das extensoes X.509 v3 sobmedida para a Internet. E o objectivo deste documento, especificar um perfil para aplicacoesWWW Internet, correio eletronico, e IPsec. Ambientes com requisitos adicionais podemimplementar usando esse perfil ou pode substituı-lo.

3.2 Caminhos de certificacao e Confianca

Um usuario de servico de seguranca que exige conhecimento de uma chave publica geral-mente precisa obter e validar o certificado contendo a chave publica utilizada. Se o usuarioda chave publica nao e titular de uma copia segura da chave publica da AC que assinouo certificado, o nome da AC, e as informacoes relacionadas (como o perıodo de validadeou o nome de restricoes), entao ele pode precisar de um certificado adicional para obtera chave publica. Em geral, uma cadeia de multiplos certificados pode se tornar necessa-rio, compreendendo o certificado do dono da chave publica (a entidade final) assinado poruma autoridade de certificacao, e zero ou mais certificados adicionais de ACs assinados poroutras ACs. Tais cadeias, chamadas de caminhos de certificacao, sao necessarias porqueum usuario de chave publica so e inicializado com um numero limitado de chaves publicasgarantidas pela AC.


Ern

andes

12


Existem diferentes formas de configuracao de ACs que possibilitam aos usuarios de chavespublicas encontrarem os caminhos de certificacao. Para o PEM, a RFC 1422 foi definidouma estrutura hierarquica rıgida para ACs. Existem tres tipos de autoridade certificadoraPEM:

(a) Autoridade de Registro de Polıtica de Internet(ARPI): Esta autoridade, operandosob os auspıcios da Internet Society, atua como a raiz da hierarquia de certificacaoPEM no nıvel 1. Emite certificados apenas para o proximo nıvel de autoridades,APC (Autoridade de Polıtica de Certificacao). Todos os caminhos de certificacaocomecam na ARPI.

(b) Autoridades de polıticas de Certificacao (APC): As APCs estao no nıvel 2 dahierarquia, cada APC a ser certificada pelo ARPI. A APC deve estabelecer e pu-blicar uma declaracao da sua polıtica com relacao aos usuarios de certificacao ouautoridades de certificacao subordinadas. APCs distintas visam satisfazer as neces-sidades de usuarios diferentes. Por exemplo, uma APC (uma APC organizacional)pode apoiar as necessidades gerais de correio eletronico de organizacoes comerciais,e outra APC (uma APC de alta confianca) pode ter uma polıtica mais rigorosa,projetada para satisfazer os requisitos legalmente vinculativos de assinatura digital.

(c) Autoridades Certificadoras (ACs): ACs estao no nıvel 3 da hierarquia e podemtambem estar em nıveis mais baixos. As de nıvel 3 sao certificadas pela APC. AsACs representam, por exemplo, organizacoes particulares, unidades organizacionaisparticulares (por exemplo, departamentos, grupos, secoes), ou areas geograficasespecıficas.

Alem disso, a RFC 1422, tem uma regra para subordinacao de nome, que exige que a ACso possa emitir certificados para entidades cujos nomes sao subordinados (na arvore denomeacao X.500) para o nome da propria AC. A confianca associada a um caminho de cer-tificacao PEM esta implıcito no nome APC. A regra de subordinacao de nome garante queACs abaixo da APC sejam sensivelmente restritas ao conjunto de entidades subordinadasque podem certificar (por exemplo, uma AC para uma organizacao so pode certificar enti-dades na arvore com o nome da organizacao). Sistemas usuarios de certificado sao capazesde verificar mecanicamente que a regra de subordinacao de nome foi seguida.

A RFC 1422 utiliza o formato X.509 certificado v1. As limitacoes do X.509 v1 tornamnecessario a imposicao de varias restricoes estruturais que associam claramente as infor-macoes sobre a polıtica ou restricoes quanto a utilizacao dos certificados. Estas restricoesincluem:

(a) uma hierarquia top-down pura, na qual todos os caminhos de certificacao comecamna ARPI;

(b) uma regra de subordinacao de nomes que restringe os nomes de sujeito de AC; e

(c) uso do conceito APC, que requer o conhecimento de APCs individuais para seremincluıdos para verificacao logica da cadeia de certificacao. O conhedimento deAPCs individuais e necessario para determinar se a cadeia pode ser aceita.

Com o X.509 v3, a maioria dos requisitos abordados na RFC 1422 podem ser resolvidosatraves das extensoes do certificado, sem a necessidade de restringir as estruturas das ACs


Ern

andes

13


utilizadas. Em particular, as extensoes do certificado relacionadas com as polıticas decertificacao evitam a necessidade de uso de APCs e as restricoes contidas nas extensoestorna desnecessario o uso das regra subordinacao de nome. Como resultado, esta normasuporta uma arquitetura mais flexıvel, incluindo:

(a) Os caminhos de certificacao comecam com a chave publica de uma AutoridadeCertificadora no proprio domınio do usuario, ou com a chave publica da arvoresuperior de uma hierarquia. Comecar com a chave publica de uma Autoridade deCertificadora no domınio do usuario tem certas vantagens. Em certos ambientes,o domınio local e o mais confiavel.

(b) Restricoes de nomes podem ser impostas atraves da inclusao de uma extensao pararestricao explıcita de nomes no certificado, mas isso nao e requisito.

(c) Extensoes de Polıtica e mapeamentos de polıtica substituem o conceito de APC,permitindo um maior grau de automacao. A aplicacao pode determinar se o cami-nho de certificacao e aceitavel com base no conteudo dos certificados, em vez de umconhecimento a priori da APC. Isto permite a automatizacao do processamento docaminho de certificacao.

O X.509 v3 tambem inclui uma extensao que identifica o sujeito de um certificado comosendo uma CA ou uma entidade final, reduzindo a dependencia de informacao externa exi-gida pelo PEM.

Esta especificacao abrange duas classes de certificados: certificados de AC e certificados deentidade final. Os certificados de AC podem ser divididos em tres classes: certificado cru-zado, certificado auto-emitido e certificado auto-assinado. O certificado cruzado e aquele noqual o emissor e o sujeito do certificado sao entidades distintas. A certificacao cruzada des-creve uma relacao de confianca entre duas ACs. O certificado auto-emitido e aquele no qualo emissor e o sujeito do certificado sao a mesma entidade. A auto-emissao de certificadosocorre em suporte a mudancas na polıtica ou nas operacoes. Certificados auto-assinadossao aqueles nos quais a assinatura de digital pode ser verificada com a chave publica re-lacionada contida no proprio certificado. Certificados auto-assinados sao utilizados paratransmitir uma chave publica para uso como inıcio de um caminho de certificacao. Certi-ficados de entidade final sao emitidos para aquelas entidades que nao estao autorizadas aemitir certificados.

3.3 Revogacao

Quando um certificado e emitido, e esperado que ele seja utilizado durante todo o seuperıodo de validade. No entanto, varias circunstancias podem causar a invalidacao do cer-tificado antes da expiracao do seu prazo de validade. Tais circunstancias incluem a mudancade nome, mudanca de associacao entre o sujeito e a AC (por exemplo, quando o empregadotermina deixa de prestar servicos a uma organizacao), comprometimento ou suspeita decomprometimento da chave privada correspondente. Sob tais circunstancias, o AC tem querevogar o certificado.

O X.509 define um metodo para revogacao de certificado. Este metodo envolve a emissaoperiodica de uma estrutura de dados assinada, chamada de lista de certificados revogados(LCR) por cada AC da infraestrutura. A LCR e uma lista datada com carimbo de tempoque identifica os certificados revogados, assinada pela AC que o emitiu ou por um emissor


Ern

andes

14


de CRL, e disponibilizada gratuitamente em um repositorio publico. Cada certificado re-vogado e identificado na LCR pelo numero de serie do certificado. Quando um sistema quefaz uso de certificacao, usa um certificado (por exemplo, para verificar a assinatura digitalde um usuario remoto), o sistema nao verifica somente a assinatura do certificado e suavalidade, mas tambem adquire uma LCR adequadamente recente e verifica que o numerode serie do certificado nao na LCR. O significado de “adequadamente recente” pode variarde acordo com a polıtica local, mas isso normalmente remete a LCR emitida mais recen-temente. A nova lista e emitida em base regular e periodica (por exemplo, a cada hora,diariamente ou semanalmente). Uma entrada e adicionada a LCR como parte da proximaatualizacao apos a notificacao de revogacao. Uma entrada nao deve ser removido da LCR,ate que apareca em LCRs regulares emitidas apos o perıodo de validade do certificado re-vogado.

Uma vantagem deste metodo e que as CRLs podem ser distribuıdas da mesma forma queos certificados propriamente ditos, ou seja, atraves de servidores e meios de comunicacoesnao seguros.

Uma limitacao do metodo de revogacao por LCR, usando comunicacoes e servidores naoconfiaveis, e que a granularidade do tempo de revogacao e limitada ao prazo de emissaoda LCR. Por exemplo, se a revogacao for relatada agora, a revogacao nao sera confiavelao sistema que faz uso do certificado ate que todas as LCRs sejam atualizadas conformeo agendamento de emissao - o que pode ser de ate uma hora, um dia ou uma semana,dependendo da frequencia de emissao das LCRs.

Tal como acontece com o formato de certificado X.509 v3, a fim de facilitar a interopera-bilidade nas implementacoes de varios fornecedores, o formato de LCR X.509 v2 tem queter um perfil adequado ao uso na Internet. Um dos objetivos do presente documento ea especificacao deste perfil. No entanto, o perfil nao define os requisitos para emissao deLCRs. Os formatos de mensagens e protocolos de suporte on-line para notificacao de re-vogacao sao definidos em outras especificacoes do PKIX. Metodos de notificacao on-line derevogacao podem ser aplicaveis, em alguns ambientes, como alternativa para a LCR X.509.A verificacao de revogacao on-line pode reduzir significativamente a latencia entre a geracaodo relatorio de revogacao e a sua distribuicao aos terceiros confiaveis. Uma vez que o ACaceite um relatorio da revogacao, como autentico e confiavel, qualquer consulta ao servicoon-line, refletira corretamente os impactos da revogacao na validacao do certificado. No en-tanto, estes metodos impoem novos requisitos de seguranca: o validador certificado precisaconfiar no servico de validacao on-line, enquanto o repositorio nao precisa ser confiavel.

3.4 Protocolos Operacionais

E necessario um conjunto de protocolos operacionais para entregar os certificados e CRLs(ou informacoes de status) aos sistemas clientes que fazem uso de certificado. Torna-senecessario provisoes para uma variedade de diferentes meios de certificado e entrega deLCR, incluindo procedimentos de distribuicao baseados em LDAP, HTTP, FTP e X.500.Os protocolos operacionais que dao suporte a estas funcoes sao definidas em outras especi-ficacoes do PKIX. Estas especificacoes podem incluir definicoes de formatos de mensageme procedimentos para suportar todos os ambientes operacionais acima referidos, incluindodefinicoes ou referencias para tipos apropriados de conteudo MIME.


Ern

andes

15


3.5 Protocolos de Gerenciamento

Os protocolos de gerenciamento sao necessarios para dar suporte as interacoes entre osusuarios da ICP e as entidades que realizam o seu gerenciamento. Como exemplo, umprotocolo de administracao pode ser utilizado entre a AC e um sistema cliente com o qualum par de chave esta associada, ou entre duas ACs que implementem certificacao cruzadaentre si. O conjunto de funcoes que, potencialmente, tem de ser suportados por protocolosde gestao incluem:

(a) registro: E o processo no qual o usuario primeiro se faz conhecido pela AC (di-retamente, ou atraves de uma AR), ocorre antes da AC emitir o certificado oucertificados para o usuario.

(b) inicializacao: Antes do sistema cliente poder operar de forma segura, e necessariaa instalacao de materiais essenciais que tem a relacao adequada com as chavesarmazenadas em outras partes da infra-estrutura. Por exemplo, o cliente tem de serinicializado de maneira segura com a chave publica e outras informacao garantidaspela AC(s), que serao utilizadas na validacao dos caminhos de certificacao. Alemdisso, um cliente normalmente tem de ser inicializado com seu proprio par(es) dechave(s).

(c) certificacao: Este e o processo no qual a AC emite o certificado de chave publicapara o usuario, e retorna esse certificado para o sistema cliente do usuario e/oupublica o certificado em um repositorio.

(d) recuperacao de par de chaves: Como opcao, os materiais de chave do usuario cliente(por exemplo, a chave privada de um usuario utilizado para fins de criptografia)pode ser suportado por uma CA ou um sistema de backup de chave. Se um usuarioprecisa recuperar esses materiais de backup de chave (por exemplo, como resultadode uma senha esquecida ou perda do arquivo da cadeia da chave), um protocolo detroca de mensagem on-line protocolo pode ser necessarios para das suporte a estaacao.

(e) atualizacao de par de chaves: Todos os pares de chaves precisam ser atualizadosregularmente, ou seja, substituıdo por um novo par de chaves, e emissao de novoscertificados

(f) solicitacao de revogacao: Uma pessoa autorizada avisa uma AC sobre uma umasituacao anormal e solicita a revogacao do certificado.

(g) certificacao cruzada: Duas ACs trocam informacoes utilizadas na criacao de umcertificado cruzado. Um certificado cruzado e um certificado emitido por uma ACpara outra AC que contem uma chave de assinatura de AC usada na emissao decertificados.

Note que os protocolos on-line nao sao a unica maneira de implementar as funcoes acima.Para todas as funcoes, existem metodos off-line utilizados para obtencao do mesmo resul-tado, esta especificacao nao exige o uso de protocolos on-line. Por exemplo, quando saoutilizados tokens, muitas das funcoes podem ser realizadas no proprio token. Alem disso,algumas das funcoes acima descritas podem ser combinados em um protocolo de troca demensagens. Em particular, dois ou mais registos, inicializacao e funcoes de certificacaopodem ser combinados em uma troca de mensagens de protocolo.


Ern

andes

16


A serie de especificacoes PKIX define um conjunto de formatos de mensagens padrao quesuportam as funcoes acima. Os protocolos para transmitir estas mensagens em diferentesambientes (por exemplo, a transferencia de ficheiros de e-mail, e WWW) encontram-sedescritos nessas especificacoes.

4 Perfil do Certificado e das Extensoes do Certificado

Esta secao apresenta o perfil para certificados de chaves publicas que promovem a intero-perabilidade e a utilizacao continuada de uma ICP. Esta secao e baseada no formato decertificado X.509 v3 e nas extensoes de certificado padrao definidas no [X.509]. Os docu-mentos ISO/IEC e ITU-T utiliza a versao de 1997 do ASN.1, enquanto este documentousa versao de 1988 da sintaxe ASN.1, o certificado codificado e suas extensoes padrao saoequivalentes. Esta secao tambem define as extensoes privadas necessarias para suportaruma ICP na comunidade da Internet.

Os certificados podem ser utilizados numa vasta gama de aplicacoes e ambientes que abran-gem um largo espectro de objetivos de interoperabilidade e um espectro mais amplo aindade requisitos operacionais e de seguranca. O objetivo deste documento e estabelecer umabase comum para aplicacoes genericas que exigem ampla interoperabilidade e requisitos depropositos especiais limitados. Em particular, a enfase sera em apoiar o uso de certificadosX.509 v3 para uso no correio eletronico informal da Internet, no IPsec e nas aplicacoesWWW.

4.1 Campos Basicos do Certificado

A sintaxe basica do certificado X.509 v3 segue abaixo. Para o calculo da assinatura, os dadosque serao assinados e codificado usando as regras de codificacao (DER) do ASN.1 [X.690].A codificacao DER do ASN.1 DER e baseada em rotulo, e um sistema de codificacao dessevalor 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


Ern

andes

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 e uma SEQUENCIA de tres campos obrigatorios. Os campos sao detalhada-mente descritos nas subsecoes abaixo.

4.1.1.1 tbsCertificate

Esse campo contem os nomes do sujeito e do emissor, uma chave publica associada aosujeito, um perıodo de validade, e outras informacoes relacionadas. Os campos sao descritosem detalhes na secao 4.1.2; o campo tbsCertificate normalmente inclui extensoes, que saodescritas na secao 4.2.

4.1.1.2 signatureAlgorithm

O campo signatureAlgorithm contem o identificador do algoritmo criptografico usado pelaAC para assinar o certificado. [RFC3279], [RFC4055], e [RFC4491] lista os algoritmos deassinatura suportados, mas outros algoritmos tambem PODEM ser suportados.


Ern

andes

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 e utilizado para identificar o algoritmo criptografico. O com-ponente OBJECT IDENTIFIER identifica o algoritmo (como o DSA com SHA-1). Oconteudo do do campo parameters variam de acordo com o algoritmo identificado.

Este campo DEVE conter os mesmos identificadores de algoritmo que o campo signaturena sequencia de campos do tbsCertificate (secao 4.1.2.3).

4.1.1.3 signatureValue

O campo signatureValue contem a assinatura digital calculada sobre o campo tbsCertifi-cate codificado em DER do ASN.1. A codificacao do tbsCertificate e usada como entradada funcao de assinatura. Este valor de assinatura e codificado como um BIT STRING eincluıdo no campo de assinatura. Os detalhes deste processo sao especificados para cadaalgoritmo listado em [RFC3279], [RFC4055] e [RFC4491].

Para gerar a assinatura, a AC de certifica da validade da informacao contida no campotbsCertificate. Em particular, a AC se certifica da relacao existente entre o material dachave publica e o sujeito do certificado.

4.1.2 TBSCertificate

A sequencia TBSCertificate contem informacoes associadas ao sujeito do certificado e a ACque o emitiu. Todo TBSCertificate contem o nome do sujeito e o emissor, uma chave publicaassociada ao sujeito, um perıodo de validade, o numero da versao e o numero serial; algunsPODEM conter campos opcionais de identificador unico. O restante desta secao descreve asintaxe e a semantica dos tres campos. O TBSCertificate geralmente inclui extensoes. Asextensoes para ICP na Internet sao descritos na secao 4.2.

4.1.2.1 Version

Este campo descreve a versao do certificado codificado. Quando sao utilizados extensoes,como esperado na definicao do perfil, o valor deste campo deve ser 3 (valor igual a 2). Casonao ocorra nenhuma extensao, mas o UniqueIdentifier esteja presente, a versao DEVERIAser 2 (valor igual a 1); entretanto, a versao PODE ser 3. Quando apenas os campos basicosestiverem presentes, a versao DEVERIA ser 1 (o valor e omitido do certificado, e conside-rado o valor padrao); embora a versao possa ser 2 ou 3.

As implementacoes DEVERIAM estar preparadas para aceitar qualquer versao de certifi-cado. No mınimo, as implementacoes que estao em conformidade DEVEM reconhecer oscertificados de versao 3.

A geracao de certificados de versao 2 nao e esperado pelas implementacoes baseadas nopresente perfil.


Ern

andes

19


4.1.2.2 Serial Number

O serial number DEVE ser um numero inteiro positivo atribuıdo pela AC para cada certifi-cado. Ele DEVE ser unico para cada certificado emitido pela respectiva AC (por exemplo,o nome do emissor e o numero serial identificam um certificado unico) As ACs DEVEMgarantir que o serialNumber seja um numero inteiro nao negativo.

Dada a unicidade requerida acima, e esperado que este campo contenha numeros inteiroslongos. Os sistemas usuarios de certificado DEVEM ser capazes de processar numerosinteiros de ate 20 octetos. Quando em conformidade, as ACs NAO DEVEM utilizar serial-Number com valores maiores que 20 octetos.

Nota: ACs que nao se encontram em conformidade PODEM emitir certificados com nu-meros negativos ou iguais a zero. Os sistemas usuarios de certificado DEVERIAM serpreparados para tratar adequadamente tais certificados.

4.1.2.3 Signature

Este campo contem o identificador de algoritmo para o algoritmo utilizado pela AC paraassinar o certificado.

Este campo DEVE conter o mesmo identificador de algoritmo do campo signatureAlgorithmna sequencia de campos do certificado (secao 4.1.1.2). O conteudo dos parametros opcionaisvariam de acordo com o identificador do algoritmo. [RFC3279], [RFC4055] e [RFC4491]listam os algoritmos de assinatura suportados, mas outros algoritmos PODEM tambem sersuportados.

4.1.2.4 Issuer

O campo issuer identifica a entidade que assinou e emitiu o certificado. O campo issuerDEVE conter um valor nao vazio de nome distinto (DN). O campo issuer e definido com otipo Name do ASN.1 [X.500]. Name e 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

DirectoryString ::= CHOICE {


Ern

andes

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 hierarquico composto de atributos, tais como o nome dopaıs, e os valores correspondentes, como US. O tipo de componente AttributeValue e de-terminado pelo AttributeType; geralmente sera um DirectoryString.

O tipo DirectoryString e definido como uma selecao entre PrintableString, TelexString,BMPString e UniversalString. As ACs em conformidade com este perfil DEVEM usar codi-ficacao PrintableString ou UTF8String para codificar o DirectoryString, com duas excecoes.Quando ACs tiverem emitido anteriormente certificados com campos issuer com atributoscodificados usando TelexString, BMPString ou UniversalString, a AC PODE continuar ausar essas codificacoes para o DirectoryString de maneira a preservar a compatibilidade dolegado. Tambem no caso de novas ACs serem adicionadas a um domınio onde existem ACsque emitem certificados com campos issuer com atributos codificados usando TelexString,BMPString ou UniversalString PODEM codificar os atributos que elas trocam com as ACsexistentes usando a mesma codificacao que as ACs utilizam.

Como notado acima, os nomes distintos sao compostos por atributos. A presente espcifi-cacao nao restringe o conjunto de tipos de atributos que podem aparecer nos nomes. En-tretanto, as implementacoes em conformidade DEVEM estar preparadas para receberemcertificados com nomes contendo o conjunto de atributos listados a seguir. Esta especifica-cao RECOMENDA o suporte a tipos adicionais de atributos.

O conjunto padrao de atributos foi definido na serie de especificacoes do X.500 [X.520]. Asimplementacoes deta especificacao DEVEM estar preparadas para receberem os seguintestipos de atributos de nomes padrao nos campos issuer e subject (secao 4.1.2.6):

* paıs,

* organizacao,

* unidade organizacional,

* qualificador do nome distinto,

* nome do estado ou provincia,

* nome comum (por exemplo, “Susan Housley”), e

* numero serial.

Alem disso, as implementacoes desta especificacao DEVERIAM estar preparadas para re-ceberem os seguintes tipo de atributos padrao tanto no nome do emissor quanto no nomedo sujeito:

* localidade

* tıtulo,


Ern

andes

21


* sobrenome,

* nome,

* iniciais,

* pseudonimo, e

* qualificador de geracao (por exemplo, “Jr”, “3º”, ou “IV”).

A sintaxe e identificadores de objeto (OIDs) para esses tipos de atributos sao fornecidosnos modulos ASN.1 do apendice A.

Adicionalmente, as implementacoes desta especificacao DEVEM estar preparadas para re-ceberem atributos domainComponent, como descrito em [RFC4519]. O Sistema de Nomede Domınio (DNS) fornece um sistema de rotulos hierarquico. Este atributo fornece ummecanismo adequado para organizacao que deseja usar DNs em paralelo aos nomes DNS.Isso nao e uma substituicao para o componente dNSName das extensoes alternative name.Nao e necessario que as implementacoes convertam estes nomes em nomes DNS. A sintaxeassociada e o OID para este tipo de atributo sao fornecidos nos modulos ASN.1 do apendiceA. Regras para a codificacao de nomes de domınio internacionalizados para uso no atributodomainComponent serao especificadas na secao 7.3.

Os sistemas usuarios de certificados DEVEM ser preparados para processar campos con-tendo nomes distintos do emissor e do sujeito (secao 4.1.2.6) para validar a cadeia de nomedo caminho de certificacao (secao 6). A cadeia de nomes e executada fazendo a correspon-dencia entre o nome distinto do emissor no certificado com o nome do sujeito no certificadoda AC. As regras de comparacao de nomes distintos estao especificadas na secao 7.1. Seos nomes nos campos emissor e sujeito de um certificado correspondem de acordo com asregras especificadas na secao 7.1 entao o certificado e auto-emitido.

4.1.2.5 Validity

O perıodo de validade do certificado e o intervalo de tempo durante o qual a AC garanteque vai manter as informacoes sobre o status do certificado. O campo e representado comouma sequencia de duas datas: a data em que o perıodo de validade do certificado comeca(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 ate o ano de 2049 como UTCTime; data de validade de certificado em 2050 ouposterior, deve ser codificada como GeneralizedTime. As aplicacoes em conformidade de-vem ser capazes de processar datas de validade que sao codificados em tanto em UTCTimequanto 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 situacoes, sao fornecidos aos dispositivos certificados para os quais nenhumadata de expiracao boa pode ser atribuıda. Por exemplo, pode ser emitido um certificadopara um dispositivo que vincula o seu modelo e numero de serie com a sua chave publica,


Ern

andes

22


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

Para indicar que um certificado nao tem data de validade bem definida, ao campo notAfterdeve ser atribuıdo o valor de GeneralizedTime igual a 99991231235959Z.

Quando o emissor nao e capaz de manter informacoes de estado ate a data notAfter (inclu-sive quando a data contida em notAfter for 99991231235959Z), o emissor DEVE assegurarque nao existira nenhum caminho de certificacao valido para o certificado apos encerrada amanutencao de informacoes sobre o estado do certificado. Isto pode ser conseguido atravesde expiracao ou revogacao de todos os certificados de AC contendo a chave publica usadapara verificar a assinatura do certificado e com a interrupcao do uso da chave publicautilizada para verificar a assinatura do certificado como ancora de confianca.

4.1.2.5.1 UTCTime

O tipo de tempo universal, UTCTime, e um tipo padrao ASN.1 usado para representacaode datas e tempo. O UTCTime especifica para ano os dois dıgitos de mais baixa ordem eo tempo e especificado com a precisao de um minuto ou um segundo. O UTCTime incluitanto Z (para Zulu, ou Greenwich Mean Time) ou um tempo diferencial de tempo.

Para os propositos deste perfil, os valores UTCTime DEVEM ser expressos em GreenwichMean Time (Zulu) e DEVEM incluir os segundos (por exemplo, tempos sao representadospor YYMMDDHHMMSSZ), mesmo onde o numero relacionado aos segundos seja zero. Ossistemas em conformidade DEVEM interpretar o campo ano (YY) como:

Quando YY for maior que ou igual a 50, o ano DEVERA ser interepretado como19YY; e

Quando YY for menor que 50, o ano DEVERA ser interpretado como 20YY.

4.1.2.5.2 GeneralizedTime

O tipo tempo generalizado, GeneralizedTime, e um tipo padrao ASN.1 para representacaoprecisa de tempo variavel. Opcionalmente, o campo GeneralizedTime pode incluir a repre-sentacao do diferencial do tempo entre o tempo local e o Greenwich Mean Time.

Para os propositos deste perfil, os valores de GeneralizedTime DEVEM ser expressos emGreenwich Mean Time (Zulu) e DEVEM incluir segundos (por exemplo, tempos sao repre-sentados por YYYYMMDDHHMMMSSZ), mesmo quando o numero de segundos for iguala zero. Os valores de GeneralizedTime NAO DEVEM incluir fracoes de segundos.

4.1.2.6 Subject

O campo subject identifica a entidade associada com a chave publica armazenada no camposubject public key. O nome do sujeito PODE ocorrer no campo subject e/ou na extensaosubjectAltName. Se o sujeito e uma AC (por exemplo, a extensao basic constraints, a serdiscutida na secao 4.2.1.9, ocorre e o valor do campo cA sera TRUE), entao o campo sub-ject DEVE ser preenchido com um nome distinto nao vazio correspondente ao conteudo docampo issuer (secao 4.1.2.4) em todos os certificados emitidos com o sujeito AC. Quandoo sujeito for um emissor de LCR (por exemplo, na extensao key usage, discutida na secao


Ern

andes

23


4.2.1.3, estara presente e o valor de cRLSign sera TRUE), entao o campo subject DEVE serpreenchido com um nome distinto nao vazio correspondente ao conteudo do campo issuer(secao 5.1.2.3) em todas as LCRs emitidas pelo emissor de LCR. Quando a informacao denome do sujeito estiver presente apenas na extensao subjectAltName (por exemplo, umachave relacionada apenas a um endereco de email ou URI), entao o nome do sujeito DEVEser uma sequencia vazia e a extensao subjectAltName DEVE ser marcada como crıtica.

Quando o campo subject nao for vazio, DEVE conter um nome distinto (DN) X.500. ODN DEVE ser unico para cada entidade sujeito certificado por uma AC como definido nocampo issuer. Uma AC PODE emitir mais que um certificado com o mesmo DN para amesma entidade sujeito.

O campo subject e definido como um nome tipo X.501. Os requisitos de implementacaopara este campo sao aqueles definidos para o campo issuer (secao 4.1.2.4). As implementa-coes desta especificacao DEVEM se preparadas para receberem nomes de sujeito contendoos tipos de atributos necessarios para o campo issuer. As implementacoes desta especi-ficacao DEVERIAM ser preparadas para receber nomes de sujeito contendo os tipos deatributos recomendados para o campo issuer. A sintaxe e os identificadores de objetos(OIDs) associados a estes tipos de atributos sao fornecidos nos modulos ASN.1 do apendiceA. As implementacoes desta especificacao DEVEM usar as regras de comparacao contidasna secao 7.1 para processar os tipos de atributos nao comuns (por exemplo, para comede cadeia) cujos valores de atributos usam uma das opcoes de codificacao definidas comoDirectoryString. Comparacoes binarias deveriam ser utilizadas quando tipos de atribu-tos incomuns incluirem valores de atributos com opcoes de codificacao diferentes daquelasencontradas no DirectoryString. Isso permite as implementacoes processarem certificadoscom atributos incomuns presentes no nome de sujeito.

Na codificacao dos valores de atributos do tipo DirectoryString, as ACs em conformidadeDEVEM usar codificacao PrintableString ou UTF8String, com as seguintes excecoes:

(a) Quando o sujeito de um certificado for uma AC, o campo subject DEVE ser codi-ficado da mesma forma que ele foi codificado no campo issuer (secao 4.1.2.4) emtodos os certificados emitidos pelo sujeito AC. Assim, se o sujeito AC codificaratributos nos campos issuer do certificado dos certificados que ela emite usandocodificacao TeletexSting, BMPString, ou UniversalString, o campo subject doscertificados emitidos para aquela AC DEVEM usar a mesma codificacao.

(b) Quando o sujeito de um certificado e um emissor de LCR, o campo subject DEVEser codificado da mesma forma que foi codificado no campo issuer (secao 5.1.2.3)em todas as LCRs emitidas pelo sujeito emissor da LCR.

(c) TeletexString, BMPString e UniversalString sao incluıdos para compatibilidadecom o legado, e NAO DEVERIAM ser usados em certificados para novos sujei-tos. Entretanto, estes tipos PODEM ser usados em certificados onde o nome foipreviamente estabelecido, incluindo os casos nos quais um novo certificado estasendo emitido para um novo sujeito onde os atributos sendo codificados forampreviamente estabelecidos no certificado emitido para outros sujeitos. Os usuariosdo certificado DEVERIAM ser preparados para receberem certificados com essestipos.

Implementacoes do legado existem onde um endereco de email esta incorporado no nomedistinto do sujeito como um atributo emailAddress [RFC2985]. O valor do atributo para


Ern

andes

24


emailAddress e do tipo IA5String para permitir inclusao do caractere “@”, que nao e partedo conjunto de caracteres PrintableString. Valores de atributo emailAddress nao sao sensı-veis quanto a maiusculas e minusculas (por exemplo, “[email protected]” e o mesmoque “[email protected]”).

As implementacoes em conformidade quando da geracao de novos certificados com enderecosde email PODEM usar o rfc822Name na extensao de nome de sujeito alternativo (secao4.2.1.6) para descrever tal identidade. Inclusoes simultaneas do atributo emailAddressno nome distinto do sujeito para suportar implementacoes do legado nao e uma praticaincentivada, embora seja permitida.

4.1.2.7 Subject Public Key Info

Este campo e utilizado para incluir a chave publica e o identificar o algoritmo com o quala chave e usada (por exemplo, RSA, DSA ou Diffie-Hellman). O algoritmo e identificadousando a estrutura AlgorithmIdentifier especificada na secao 4.1.1.2. O identificador deobjeto para o algoritmo suportado e o metodo de codificacao do material da chave pu-blica (chave publica e os seus parametros) sao especificados em [RFC3279], [RFC4055] e[RFC4491].

4.1.2.8 Unique Identifiers

Esses campos somente DEVEM estar presentes quando a versao for 2 ou 3 (secao 4.1.2.1).Esses campos NAO DEVEM aparecer quando a versao for 1. O subject e issuer uniqueidentifiers estao presentes no certificado para possibilitar a reutilizacao do nome do sujeitoe/ou emissor no decorrer do tempo. Este perfil RECOMENDA que os nomes nao sejamreutilizados para entidades diferentes. ACs em conformidade com este perfil NAO DEVEMgerar certificados com unique identifiers. As aplicacoes em conformidade com este perfilDEVERIAM ser capazes de analisar certificados que incluem unique identifiers, mas naoha nenhum requisito de processamento associado ao unique identifiers.

4.1.2.9 Extensions

Este campo DEVE aparecer apenas quando a versao for 3 (secao 4.1.2.1). Quando presente,o campo e uma SEQUENCE de um ou mais extensoes de certificado. O formato e oconteudo das extensoes de certificado da ICP de Internet estao definidos na secao 4.2.

4.2 Extensoes do Certificado

As extensoes definidas para certificados X.509 v3 fornecem metodos para associar atribu-tos adicionais aos usuarios ou chaves publicas, e tambem para a gestao das relacoes entreACs. O formato do certificado X.509 v3 tambem permite que comunidades definam ex-tensoes privadas que levam informacoes exclusivas a essas comunidades. Cada uma dasextensoes do certificado e designada como crıtica ou nao crıtica. O sistema que utiliza cer-tificado deve rejeitar o certificado quando encontrar uma extensao crıtica nao reconhecidaou uma extensao crıtica que contenha informacoes que nao podem ser processadas. A ex-tensao nao-crıtica PODE ser ignorada quando nao reconhecida, mas DEVE ser processadaquando reconhecido. As secoes seguintes apresentam extensoes recomendadas usadas noscertificados Internet Internet e os localizacao padrao para a informacao. As comunidades


Ern

andes

25


podem optar por usar extensoes adicionais, no entanto, todo cuidado deve ser tomado naadocao de qualquer extensao crıtica que possam inviabilizar o seu uso em um contexto geral.

Cada extensao inclui um OID e uma estrutura ASN.1. Quando uma extensao aparece emum certificado, o respectivo OID ocorre como um campo extnID e a estrutura codificadaem DER do ASN.1 e o valor do string de octetos contido no extnValue. O certificadoNAO DEVE incluir mais que uma instancia de uma determinada extensao. Por exemplo, ocertificado pode conter apenas uma extensao authority key identifier (secao 4.2.1.1). Umaextensao inclui a opcao de criticidade como um valor booleano, com valor padrao FALSE.O texto relacionado a cada das extensoes, especifica os valores aceitaveis para campo crıticopara ACs em conformidade com este perfil.As ACs em conformidade DEVEM suportar as extensoes key identifiers (secao 4.2.1.1 e4.2.1.2), basic constraints (secao 4.2.1.9), key usage (secao 4.2.1.3), e certificate policies(secao 4.2.1.4). Quando uma AC emite certificados com uma sequencia vazia para o camposubject, a AC DEVE suportar a extensao subject alternative name (secao 4.2.1.6). Osuporte as extensoes restantes permanece opcional. As ACs em conformidade PODEM su-portar extensoes que nao sao identificadas nesta especificacao; os emissores de certificadoscom estas extensoes que as marcarem como crıticas podem dificultar a interoperabilidade.

No mınimo, as aplicacoes em conformidade com este perfil DEVEM reconhecer as seguintesextensoes: key usage (secao 4.2.1.3), certificate policies (secao 4.2.1.4), subject alternativename (secao 4.2.1.6), basic constraints (secao 4.2.1.9), name constraints (secao 4.2.1.10),policy constraints (secao 4.2.1.11), extended key usage (secao 4.2.1.12), e inhibir anyPolicy(secao 4.2.1.14).

Adicionalmente, as aplicacoes em conformidade com este perfil DEVERIAM reconhecer asextensoes authority and subject key identifier (secao 4.2.1.1 e 4.2.1.2) e policy mappings(secao 4.2.1.5).

4.2.1 Extensoes Padrao

Esta secao identifica as extensoes padrao de certificado no [X.509] para uso na ICP Internet.Cada extensao e associada a um OID definido em [X.509]. Esses OIDs sao membros doarco de OID id-ce-arc, que e definido da seguinte forma:

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

4.2.1.1 Authority Key Identifier

A extensao authority key identifier fornece um meio de identificacao da chave publica cor-respondente a chave privada usada para assinar o certificado. Esta extensao e utilizadaquando um emissor tem multiplas chaves de assinatura (tambem d devido a ocorrencia devarios pares de chaves simultaneos ou devido a mudanca do par de chaves). A identificacaoPODE ser baseada tanto no key identifier (identificador da chave do sujeito no certificadodo emissor) como no nome do emissor e numero serial.

O campo keyIdentifier da extensao authorityKeyIdentifier DEVE ser incluıdo em todos oscertificados gerados por ACs em conformidade para facilitar a construcao do caminho decertificacao. Existe uma excecao; quando uma AC distribui sua chave publica na formade certificado “auto-assinado”, o identificador de chave da autoridade PODE ser omitido.


Ern

andes

26


A assinatura em um certificado auto-assinado e gerada com a chave privada associada achave publica do sujeiro do certificado. (Isso prova que o emissor tem a posse tanto dachave publica quanto da privada). Neste caso, o sujeito e o identificador de chave de au-toridade devem ser identicos, mas apenas o identificador de chave do sujeito e necessariopara a construcao do caminho de certificacao.

O valor do campo keyIdentifier DEVERIA ser derivado a partir da chave publica utilizadapara verificar a assinatura do certificado ou do metodo que gera valores unicos. Dois me-todos comuns para geracao de identificadores para chave publica sao descritos na secao4.2.1.2. Quando o identificador de chave nao tiver sido previamente definido, esta especifi-cacao RECOMENDA o uso de um desses metodos para a geracao do keyIdentifiers ou o usode um metodo similar que usa um algoritmo de hash diferente. Quando um identificadorde chave tiver sido previamente definido, a AC DEVERIA usar o identificador previamentedefinido.

Este perfil RECOMENDA suporte ao metodo de identificao de chave a todos os usuariosde certificado.

As ACs em conformidade DEVEM marcar esta extensao como nao 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 extensao subject key identifier fornece meios para identificacao de certificados que con-tem uma determinada chave publica.

Para facilitar a construcao do caminho de certificacao, esta extensao DEVE aparecer emtodos os certificados de AC, ou seja, todos os certificados que incluem a extensao basicconstraints (secao 4.2.1.9) nos quais o valor de cA e TRUE. Nos certificados de AC emconformidade, o valor do subject key identifier DEVE ser o valor colocado no campo keyidentifier da extensao authority key identifier (secao 4.2.1.1) dos certificados emitidos pelosujeito deste certificado. As aplicacoes nao precisam verificar que os identificadores dechave corresponde quando realizam a validacao do caminho de certificacao.

Para certificados de AC, os identificadores de chave de sujeito DEVERIAM ser derivadosda chave publica ou a partir de um metodo que gera valores unicos. Dois metodos comunspara geracao de identificadores de chave a partir da chave publica sao:

(1) o keyIdentifier e composto por um hash de 160 bits SHA-1 do valor do BIT STRINGsubjectPublicKey (excluıdos o rotulo, o tamanho e o numero de bits nao utilizados).


Ern

andes

27


(2) o keyIdentifier e composto por um campo de quatro bit com o valor 0100 seguidodos 60 bits menos significativos do hash SHA-1 calculado sobre o valor em BITSTRING do subjectPublicKey (excluıdos o rotulo, tamanho, e numero de bits naoutilizados).

Tambem sao aceitos outros metodos de geracao de numeros unicos.

Para certificados de entidades finais, a extensao de identificacao de chave de sujeito forneceum meio de identificacao de certificados contendo uma chave publica especıfica utilizadaem uma aplicacao. Quando uma entidade tiver obtido multiplos certificados, especialmentede multiplas ACs, o identificador de chave de sujeito fornece meios de identificacao rapidado conjunto de certificados que contem uma chave publica especıfica. Para auxiliar as apli-cacoes na identificacao do certificado de entidade final apropriado, a extensao DEVERIAser incluıda em todos os certificados de entidade final.

Para certificados de entidade final, os identificadores de chave de sujeito DEVERIAM serderivados da chave publica. Abaixo sao identificados dois metodos para geracao de identi-ficadores de chave a partir da chave publica.

Quando o identificador de chave nao tiver sido previamente definido, esta especificacao RE-COMENDA o uso de um dos metodos para geracao de keyIdentifiers ou usar um metodosimilar que utilize um algoritmo de hash diferente. Quando um identificador de chave tiversido previamente definido a AC DEVERIA usar o identificador ja definido.

As ACs em conformidade DEVEM marcar esta extensao como nao crıtica.

id-ce-subjectKeyIdentifier OBJECT IDENTIFIER ::= { id-ce 14 }

SubjectKeyIdentifier ::= KeyIdentifier

4.2.1.3 Key Usage

A extensao key usage define o proposito (por exemplo, codificacao, assinatura, assinaturade certificado) da chave contida no certificado. A restricao de uso pode ser empregadaquando uma chave que poderia ser usada para mais de uma operacao deve ter seu escopode uso restrito. Por exemplo, quando uma chave RSA deve ser utilizada somente para averificacao de assinatura em objetos diferentes de certificados de chave publica e LCRs, osbits digitalSignature e/ou nonRepudiation estariam ativados. Da mesma forma, quandouma chave RSA for utilizada somente para gerenciamento de chave, o bit keyEnciphermentestaria ativado.

As ACs em conformidade DEVEM incluir esta extensao nos certificados que contem chavespublicas que sao usados para validar assinaturas digitais em outros certificados de chavepublica ou LCRs. Quando presente, as ACs em conformidade DEVERIAM marcar estaextensao como crıtica.

id-ce-keyUsage OBJECT IDENTIFIER ::= { id-ce 15 }

KeyUsage ::= BIT STRING {

digitalSignature (0),

nonRepudiation (1),


Ern

andes

28


-- recent editions of X.509 have

-- renamed this bit to contentCommitment

keyEncipherment (2),

dataEncipherment (3),

keyAgreement (4),

keyCertSign (5),

cRLSign (6),

encipherOnly (7),

decipherOnly (8) }

Os bits para definicao do tipo de uso, contidos na extensao KeyUsage, sao utilizados daseguinte forma:

O bit digitalSignature e ativado quando a chave publica do sujeito e utilizada paraverificar as assinaturas digitais, exceto assinaturas em certificados (bit 5) e LCR (bit6), tais como os utilizados em um servico de autenticacao de uma entidade, um servicode dados de autenticacao de origem, e/ou um servico de integridade.

O bit nonRepudiation e ativado quando a chave publica do sujeito e usada paraverificar as assinaturas digitais, diferentes das assinaturas de certificados (bit 5) ede CRL (bit 6), usado para fornecer um servico nao-repudio que protege contra umanegacao falsa por parte da entidade que assinou negando alguma acao realizada. Nestecaso de conflito, uma terceira parte confiavel pode determinar a autenticidade do dadoassinado. (Note que as edicoes recentes do X.509 ter renomeado o bit nonRepudiationpara contentCommitment.)

O bit keyEncipherment e ativado quando a chave publica do sujeito e utilizada paracodificar chaves privadas ou secretas, ou seja, para o transporte de chaves. Por exem-plo, este bit sera ativado quando uma chave publica RSA e usada para criptografaruma chave de decodificacao de conteudo simetrica ou uma chave assimetrica privada.

O bit dataEncipherment e ativado quando a chave publica do sujeito e utilizada paracifrar dados, sem a utilizacao de um algoritmo intermediario de cifra simetrica. Noteque a utilizacao deste bit e extremamente raro; quase todos os aplicativos usam otransporte de chave ou acordo de chave para estabelecer uma chave simetrica.

O bit keyAgreement e ativado quando a chave publica do sujeito e usada para acordode chave. Por exemplo, quando uma chave Diffie-Hellman e para ser utilizado para ogerenciamento de chaves, entao esse bit e ativado.

O bit keyCertSign e ativado quando a chave publica do sujeito e usada para verificacaode assinaturas em certificados de chaves publicas. Se o bit keyCertSign e ativado,entao o bit de cA na extensao basic constraints (Secao 4.2.1.9) tambem DEVE serativado.

O bit cRLSign e ativado quando a chave publica do sujeito e usada para verificacaode assinaturas na listas de certificados revogados (por exemplo, LCRs, delta LCRsou CRLs, CRLs delta, ou LARs).

A funcao do bit encipherOnly fica indefinida na ausencia do bit keyAgreement.Quando o bit encipherOnly e ativado e o bit keyAgreement tambem e ativado, nessecaso, a chave publica do sujeito so pode ser utilizado para cifragem de dados durantea execucao de acordo de chave.


Ern

andes

29


A funcao do bit decipherOnly fica indefinida na ausencia do bit keyAgreement.Quando o bit decipherOnly e ativado e o bit keyAgreement tambem e ativado, achave publica do sujeito so pode ser utilizado para decifrar dados durante a execucaode acordo de chave.

Se a extensao keyUsage estiver presente, entao a chave publica do sujeito NAO DEVE serusada para verificacao assinaturas em certificados ou LCRs a menos que o bit keyCert-Sign ou cRLSign correspondente esteja ativado. Se a chave publica do sujeito deve serutilizado somente para verificacao de assinaturas em certificados e/ou LCRs, entao os bitsDigitalSignature e nonRepudiation NAO DEVERIAM ser ativados. No entanto, os bits di-gitalSignature e/ou nonRepudiation PODEM ser ativados alem dos bits keyCertSign e/oucRLSign se a chave publica do sujeito e para ser utilizada na verificacao de assinaturas emcertificados e/ou LCRs, bem como em outros objetos.

A combinacao do bit nonRepudiation na extensao keyUsage do certificado com outros bitsdessa extensao pode ter implicacoes na seguranca, dependendo do contexto no qual o cer-tificado seja utilizado. Outras distincoes entre os bits digitalSignature e nonRepudiationpodem ser fornecidas em polıticas especıficas de certificados.

Este perfil nao restringe as combinacoes de bits que podem ser ativados em uma instan-cia da extensao keyUsage. No entanto, valores apropriados para as extensoes KeyUsage,para determinados algoritmos, sao especificados em [RFC3279], [RFC4055] e [RFC4491].Quando a extensao keyUsage aparece no certificado, pelo menos um dos bits DEVE serdefinido como 1 (ativado).

4.2.1.4 Certificate Policies

A extensao polıticas de certificado contem uma sequencia de um ou mais termos de in-formacao da polıtica, cada um desses consistindo de um identificador de objeto (OID) equalificadores opcionais. Os qualificadores opcionais, que PODEM estar presentes, nao saoprevistos para alterar a definicao da polıtica. Um OID de polıtica de certificado, NAODEVE aparecer mais que uma vez como extensao polıticas de certificado.

Em um certificado de entidade final, esses termos de informacao sobre polıtica indicam apolıtica sob a qual o certificado foi emitido e os fins para os quais o certificado pode serusado. Em um certificado de AC, esses termos de informacao sobre polıtica limitam oconjunto de polıticas utilizadas para obtencao dos caminhos de certificacao que incluem ocertificado. Quando uma AC nao deseja limitar o conjunto de polıticas para caminhos decertificacao que incluem o seu certificado, PODE atribuir uma polıtica especial, anyPolicy,com um valor de 2 5 29 32 0.

Para aplicacoes com requisitos de polıticas especıficas e esperado que implementem umalista daquelas polıticas que serao aceitas e possam comparar OIDs contidos nos certificadoscom aqueles constantes na lista. Quando essa extensao for crıtica, o software de validacaode caminho DEVE ser capaz de interpretar essa extensao (incluindo o qualificador opcio-nal), ou DEVE rejeitar o certificado.

Para promover a interoperabilidade, este perfil RECOMENDA que os termos de informa-cao sobre polıtica consistam de apenas um OID. Quando um unico OID e insuficiente, esteperfil recomenda que o uso de qualificadores seja limitado aqueles identificados nesta secao.


Ern

andes

30


Quando qualificadores sao utilizados com a polıtica especial anyPolicy, eles DEVEM serlimitados aos qualificadores identificados nesta secao. Apenas os qualificadores retornadoscomo resultado da validacao do caminho sao considerados.

Esta especificacao define dois tipos de qualificadores de polıtica para serem por criadores depolıtica de certificados e emissores de certificado. Os tipos de qualificacao sao CPS Pointerse User Notice.

O qualificador CPS Pointers contem um ponteiro para uma Declaracao de Praticas de Cer-tificacao (DPC), publicado pela AC. O ponteiro esta na forma de uma URI. Os requisitosde processamento para esse qualificador e tratado localmente. Nenhuma acao e definidapor esta especificacao, independentemente da criticidade atribuıda a extensao.

O qualificador do tipo User Notice e indicado para a exposicao a uma terceira parte confia-vel quando um certificado e utilizado. Apenas User Notice, retornado como um resultadoda validacao de caminho, e destinado a exibicao para o usuario. Se esse aviso estiver repe-tido, apenas uma copia precisa ser exibida. Para evitar essa duplicacao, esse qualificadorapenas DEVERIA estar em presente em certificados de entidade final e certificados de CAemitidos para outras organizacoes.

O qualificador User Notice possui dois campos opcionais: o campo noticeRef e o campoexplicitText. As ACs em conformidade com este perfil NAO DEVERIAM utilizar a opcaonoticeRef.

O campo noticeRef, quando utilizado, nomeia uma organizacao e identifica, por nu-mero, uma declaracao textual especıfica preparada pela organizacao. Por exemplo,ele pode identificar a organizacao “CertsRUs” e anunciar o numero 1. Em uma imple-mentacao tıpica, o software aplicativo tera um arquivo de aviso contendo o conjuntoatual de avisos para CertsRUs, o aplicativo ira extrair o texto de aviso a partir doarquivo e exibi-lo. As mensagens podem ocorrer em varias lınguas, permitindo aosoftware selecionar uma linguagem particular para de mensagem para o seu proprioambiente.

O campo explicitText inclui uma declaracao textual diretamente no certificado. Ocampo explicitText e uma string com um tamanho maximo de 200 caracteres. As ACsem conformidade DEVERIAM usar codificacao UTF8String para explicitText, masPODEM usar IA5String. As ACs em conformidade NAO DEVEM codificar explicit-Text como VisibleString ou BMPString. A sequencia de explicitText NAO DEVERIAincluir qualquer caractere de controle (por exemplo, U+0000 ate U+001F e U+007Fate U+009F). Quando a codificacao UTF8String for utilizada, todas as sequenciasde caracteres DEVERIAM ser normalizados de acordo com Unicode NormatizationForm C (NFC) [NFC].

Se tanto a opcao noticeRef quanto explicitText forem incluıdas no qualificador um e se osoftware aplicativo for capaz de localizar o texto de aviso indicado pela opcao noticeRef,entao o texto DEVERIA ser apresentado; caso contrario, a sequencia contida em explicit-Text DEVERIA ser exibida.


Ern

andes

31


Nota: Enquanto o explicitText tem um tamanho maximo de 200 caracteres, algumas ACsque nao se encontram em conformidade excedem este limite. Portanto, os usuarios cer-tificado DEVERIAM ser capazes de processar campos explicitText contendo mais de 200caracteres.

id-ce-certificatePolicies OBJECT IDENTIFIER ::= { id-ce 32 }

anyPolicy OBJECT IDENTIFIER ::= { id-ce-certificatePolicies 0 }

certificatePolicies ::= SEQUENCE SIZE (1..MAX) OF PolicyInformation

PolicyInformation ::= SEQUENCE {

policyIdentifier CertPolicyId,

policyQualifiers SEQUENCE SIZE (1..MAX) OF

PolicyQualifierInfo OPTIONAL }

CertPolicyId ::= OBJECT IDENTIFIER

PolicyQualifierInfo ::= SEQUENCE {

policyQualifierId PolicyQualifierId,

qualifier ANY DEFINED BY policyQualifierId }

-- policyQualifierIds for Internet

-- policy qualifiers

id-qt OBJECT IDENTIFIER ::= { id-pkix 2 }

id-qt-cps OBJECT IDENTIFIER ::= { id-qt 1 }

id-qt-unotice OBJECT IDENTIFIER ::= { id-qt 2 }

PolicyQualifierId ::= OBJECT IDENTIFIER ( id-qt-cps | id-qt-unotice )

Qualifier ::= CHOICE {

cPSuri CPSuri,

userNotice UserNotice }

CPSuri ::= IA5String

UserNotice ::= SEQUENCE {

noticeRef NoticeReference OPTIONAL,

explicitText DisplayText OPTIONAL }

NoticeReference ::= SEQUENCE {

organization DisplayText,

noticeNumbers SEQUENCE OF INTEGER }

DisplayText ::= CHOICE {

ia5String IA5String (SIZE (1..200)),

visibleString VisibleString (SIZE (1..200)),

bmpString BMPString (SIZE (1..200)),

utf8String UTF8String (SIZE (1..200)) }


Ern

andes

32


4.2.1.5 Policy Mappings

Esta extensao e usada em certificados de AC. Ele lista de um ou mais pares de OIDs; cadapar inclui um campo issuerDomainPolicy e um campo subjectDomainPolicy. O par indicaa AC emissora, considerando o seu equivalente issuerDomainPolicy para o sujeito da ACcontida em subjectDomainPolicy.

Usuarios da AC emissora podem aceitar uma issuerDomainPolicy para determinadas apli-cacoes. O mapeamento polıtica define a lista de polıticas associadas ao sujeito da AC quepodem ser aceitas como comparavel ao issuerDomainPolicy.

Cada issuerDomainPolicy nomeado na extensao policy mappings tambem DEVERIA estarindicada na extensao de polıticas de certificado no mesmo certificado. Polıticas NAO DE-VEM ser mapeados para ou a partir do valor especial anyPolicy (Secao 4.2.1.4).

Em geral, as polıticas de certificados que aparecem no campo issuerDomainPolicy da ex-tensao mapeamentos policy mappings nao sao consideradas aceitaveis para inclusao emcertificados posteriores do caminho de certificacao. Em algumas circunstancias, uma ACpode querer mapear uma polıtica (p1) para uma outra (p2), mas ainda quer que o issuerDo-mainPolicy (p1), seja considerado aceitavel para a inclusao em certificados subsequentes.Isto pode ocorrer, por exemplo, se a AC esta em processo de transicao a partir do usoda polıtica p1 para a utilizacao de uma polıtica p2 e tem certificados validos que foramemitidos em cada uma das polıticas. A AC pode indicar isso, incluindo duas extensoespolicy mappings nos certificados de AC que ela emitir. Cada policy mapping teria um is-suerDomainPolicy de p1, um policy mapping teria um subjectDomainPolicy de p1; o outroteria o subjectDomainPolicy de p2.

Esta extensao pode ser suportado por CAs e/ou aplicacoes. As ACs em conformidadeDEVERIAM marcar esta extensao como crıtica.

id-ce-policyMappings OBJECT IDENTIFIER ::= { id-ce 33 }

PolicyMappings ::= SEQUENCE SIZE (1..MAX) OF SEQUENCE {

issuerDomainPolicy CertPolicyId,

subjectDomainPolicy CertPolicyId }

4.2.1.6 Subject Alternative Name

A extensao Subject Alternative Name permite que outras identidades sejam relacionadas aosujeito do certificado. Estas identidades podem ser incluıdas em adicao ou no lugar da iden-tidade no campo de sujeito do certificado. Opcoes previamente definidas incluem enderecode correio eletronico da Internet, um nome de DNS, um endereco IP, e um Uniform Re-source Identifier (URI). Existem outras opcoes, incluindo definicoes completamente locais.Formas multiplas de nome, e varias instancias de cada forma de nome, podem ser incluıdas.Sempre que essas identidades tiverem que ser relacionadas em um, a extensao subject al-ternative name (ou issuer alternative name) DEVEM ser usadas. No entanto, um nome deDNS tambem PODE ser representado no campo subject, usando o atributo DomainCompo-nent como descrito na Secao 4.1.2.4. Observe que onde tais nomes forem representados nasimplementacoes do campo subject nao e requerido a conversao dos mesmos em nomes DNS.


Ern

andes

33


Pelo motivo do subject alternative name ser considerado definitivamente ligada a chavepublica, todas as sua partes devem ser verificadas pela AC.

Alem disso, se a unica identidade de sujeito incluıda no certificado for uma forma de nomealternativo (por exemplo, um endereco de correio eletronico), entao, o nome distinto dosujeito deve permanecer vazio (uma sequencia vazia), e a extensao subjectAltName devemestar presentes. Se o campo subject tiver uma sequencia vazia, entao a AC que emissoraDEVE incluir uma extensao subjectAltName que e marcada como crıtica. Quando incluıdaa extensao subjectAltName em um certificado que tem um campo subject distinguishedname nao-vazio, as ACs em conformidade DEVERIAM marcar a extensao subjectAltNamecomo nao-crıtica.

Quando a extensao subjectAltName tiver um endereco de correio da Internet, o enderecoDEVE ser armazenado em rfc822Name. O formato de um nome rfc822Name e uma “caixade correio”, como definido na Secao 4.1.2 da [RFC2821]. Uma caixa de correio tem oformato “Parte-Local@Domınio”. Note que uma caixa de correio nao possui nenhuma ex-pressao (tal como um nome comum), antes dele, nao contem observacoes (texto limitado porparenteses) apos ele, e nao e limitado por“<”e“>”. As regras para codificacao de enderecosde e-mail que incluem nomes de domınio internacionalizados sao especificados na seccao 7.5.

Quando a extensao subjectAltName tiver um IPAddress, o endereco deve ser armazenadoem string de octeto de “ordem de byte da rede”, conforme especificado no [RFC791]. O bitmenos significativo (LSB) de cada octeto e o bit menos significativo do byte correspondentedo endereco de rede. Para o IP versao 4, conforme especificado em [RFC791], o string deocteto deve conter exatamente quatro octetos. Para o IP versao 6, conforme especificadoem [RFC2460], o string de octeto deve conter exatamente 16 octetos.

Quando a extensao subjectAltName tiver um rotulo de sistema de nome de domınio, onome de domınio DEVE ser armazenado no dNSName (um IA5String). O nome DEVEestar na “prefered name syntax”, conforme especificado pela Secao de 3.5 da [RFC1034] ecomo modificado pela Seccao de 2.1 da [RFC1123]. Observe que, embora letras maiuscu-las e minusculas sejam permitidas para nomes de domınio, nenhum significado existe emrelacao ao tamanho de caractere. Alem disso, apesar do string “” ser um nome de domıniolegal, extensoes subjectAltName com dNSName de “” NAO DEVE ser usado. Finalmente,o uso da representacao DNS para enderecos de correio da Internet (em vez de [email protected] usar subscriber.example.com) NAO DEVE ser usado; essas identidadessao codificados como rfc822Name. As regras para codificacao de nomes de domınio inter-nacionalizados sao especificados na seccao 7.2.

Quando a extensao subjectAltName tiver uma URI, o nome deve ser armazenado no uni-formResourceIdentifier (um IA5String). O nome nao deve ser um nome URI relativo, eele deve seguir a sintaxe de URI e as regras de codificacao especificado em [RFC3986]. Onome deve incluir tanto o esquema (por exemplo, “http” ou “ftp”) e um esquema da parteespecıfica. URIs que incluem uma autoridade ([RFC3986], Secao 3.2) DEVE conter umnome de domınio totalmente qualificado ou endereco IP do host. Regras para codificacaode identificadores de recurso internacionalizados (IRIS) sao especificadas na seccao 7.4.

Conforme especificado em [RFC3986], o nome do esquema nao diferencia maiusculas deminusculas (por exemplo, “http” e equivalente a “HTTP”). A parte do host, se estiver pre-sente, tambem nao e sensıvel a maiusculas e minusculas, mas outros componentes da parte


Ern

andes

34


especıfica do esquema podem ser sensıveis ao tamanho do caractere. Regras para compararURIs sao especificados na seccao 7.4.

Quando a extensao subjectAltName tiver um DN no directoryName, as regras de codifica-cao sao as mesmas especificadas para o campo emissor na Seccao 4.1.2.4. O DN deve serunico para cada entidade de sujeita certificada por uma AC, tal como definido pelo campoissuer. A AC pode emitir mais de um certificado com o mesmo DN para a mesma entidadesujeito.

O subjectAltName PODE conter tipos de nome adicionais atraves da utilizacao do campoOthername. O formato e a semantica do nome sao indicados atraves do identificador doobjeto no campo type-id. O proprio nome e transmitido como campo value do Othername.Por exemplo,formatos de nomes Kerberos [RFC4120] podem ser codificados no Othername,usando o OID para Kerberos 5 principal name e uma sequencia de realM e PrincipalName.

Nomes alternativos de sujeito PODEM ser limitados da mesma forma que nomes distintosde sujeitos usando a extensao name constraints como descrito na Secao 4.2.1.10.

Se a extensao subjectAltName estiver presente, a sequencia DEVE ter pelo menos umaentrada. Ao contrario do campo subject, as AC em conformidade NAO DEVEM emitircertificados com subjectAltNames contendo campos GeneralName vazios. Por exemplo, umrfc822Name e representado como um IA5String. Enquanto um string vazio e um IA5Stringvalido, tal rfc822Name nao e permitido por este perfil. O comportamento dos clientes queencontrarem esse tipo de certificado, ao processar um caminho de certificacao, nao e defi-nido neste perfil.

Finalmente, a semantica de nomes alternativos de sujeito que incluem caracteres curinga(por exemplo, como um espaco reservado para um conjunto de nomes) nao sao abordadospor esta especificacao. Aplicacoes com requisitos especıficos podem usar tais nomes, maseles devem definir a semantica.

id-ce-subjectAltName OBJECT IDENTIFIER ::= { id-ce 17 }

SubjectAltName ::= GeneralNames

GeneralNames ::= SEQUENCE SIZE (1..MAX) OF GeneralName

GeneralName ::= CHOICE {

otherName [0] OtherName,

rfc822Name [1] IA5String,

dNSName [2] IA5String,

x400Address [3] ORAddress,

directoryName [4] Name,

ediPartyName [5] EDIPartyName,

uniformResourceIdentifier [6] IA5String,

iPAddress [7] OCTET STRING,

registeredID [8] OBJECT IDENTIFIER }

OtherName ::= SEQUENCE {

type-id OBJECT IDENTIFIER,


Ern

andes

35


value [0] EXPLICIT ANY DEFINED BY type-id }

EDIPartyName ::= SEQUENCE {

nameAssigner [0] DirectoryString OPTIONAL,

partyName [1] DirectoryString }

4.2.1.7 Issuer Alternative Name

Da mesma forma da secao 4.2.1.6, esta extensao e usada para associar identidades que se-guem forma Internet, ao emissor do certificado. A extensao Issuer Alternative Name DEVEser codificada com definido em 4.2.1.6. Estas extensoes nao sao processadas como partedo algoritmo de validacao de caminho de certificacao conforme secao 6. (ou seja, os nomesalternativos de emissor, nao sao usados em name chaining e nem o seu uso e incentivadoem name constraints.)

Quando presente, as ACs em conformidade DEVERIAM marcar esta extensao como naocrıtica.

id-ce-issuerAltName OBJECT IDENTIFIER ::= { id-ce 18 }

IssuerAltName ::= GeneralNames

4.2.1.8 Subject Directory Attributes

A extensao subject directory attributes e utilizada para transmitir atributos de identificacao(por exemplo, a nacionalidade) do sujeito. A extensao e definida como uma sequencia deum ou mais atributos. As ACs em conformidade DEVEM marcar esta extensao como naocrıtica.

id-ce-subjectDirectoryAttributes OBJECT IDENTIFIER ::= { id-ce 9 }

SubjectDirectoryAttributes ::= SEQUENCE SIZE (1..MAX) OF Attribute

4.2.1.9 Basic Constraints

A extensao basic constraints identifica se o sujeito de um certificado e uma AC e a profun-didade maxima dos caminhos de certicacao validos que incluem o certificado.

O campo booleano cA indica a chave publica do certificado pode ser utilizada para verificarassinaturas de certificados. Se o booleano cA nao for ativado, entao o bit keyCertSign naextensao key usage NAO DEVE ser ativado. Se a extensao basic constraints nao estiverpresente em um certificado X.509v3, ou se a extensao estiver presente, mas o campo boole-ano cA nao tiver nenhum valor atribuıdo, entao o certificado de chave publica NAO DEVEser usado para verificacao de assinatura de certificado.

O campo pathLenConstraints tem significancia apenas quando o campo booleano cA forativado e a extensao key usage, quando presente, tiver o bit keyCertSign ativado (secao4.2.1.3). Neste caso, ela fornece o numero maximo de certificados intermediarios nao auto-assinados que podem seguir o certificado em um caminho de certificacao valido. (Nota: oultimo certificado em um caminho de certificacao nao e um certificado intermediario, e nemesta incluıdo neste limite. Normalmente, o ultimo certificado e um certificado de entidade


Ern

andes

36


final, mas ele tambem pode ser um certificado de AC.) Um campo pathLenConstraints comvalor zero indica que nenhum certificado intermediario de AC nao auto assinado pode seguirem um caminho de certificacao valido. Quando ele aparecer, o campo pathLenConstraintsDEVE ser maior ou igual a zero. Quando pathLenConstraings nao aparecer, nenhum limitee imposto.

As ACs em conformidade DEVEM incluir esta extensao em todos os certificados de ACque contenham chaves publicas usadas para validar assinaturas digitais de certificados eDEVEM marcar esta extensao como crıtica neste tipo de certificado. Esta extensao PODEaparecer como crıtica ou nao crıtica em certificados de AC que contenham chaves publi-cas usadas exclusivamente para propositos diferentes daquele da validacao de assinaturade certificados. Tais certificados incluem aqueles cujas chaves publicas sao utilizadas ex-clusivamente para validacao de assinaturas digitais de LCRs e aqueles que contem chavespublicas de gerenciamento de chaves usados em protocolos de negociacao de chaves. Estaextensao pode aparecer como crıtica ou nao crıtica em certificados de entidades finais.

As ACs NAO DEVEM incluir o campo pathLenConstraints a menos que o campo booleanocA seja ativado e que o bit keyCertSign da extensao key usage tambem seja ativado.

id-ce-basicConstraints OBJECT IDENTIFIER ::= { id-ce 19 }

BasicConstraints ::= SEQUENCE {

cA BOOLEAN DEFAULT FALSE,

pathLenConstraint INTEGER (0..MAX) OPTIONAL }

4.2.1.10 Name Constraints

A extensao name constraints, que DEVE ser usada apenas em certificado de AC, indica oespaco de nome dentro do qual todos os nomes de sujeito em certificados subsequentes docaminho de certificacao DEVEM estar contidos. As restricoes se aplicam ao nome distintode sujeito e nomes alternativos de sujeito. As restricoes sao aplicaveis apenas quando aforma de nome especificado estiver presente. Se nenhum nome do tipo estiver no certificado,o certificado e aceitavel.

Name constraints nao sao aplicados em certificados auto-assinados (a menos que o certifi-cado seja o certificado final no caminho). (Isso poderia impedir que AC que usam nameconstraints em certificados auto-assinados, implementem substituicao de chave.)

As restricoes sao definidas em termos de subarvores de nomes permitidas ou excluıdas.Qualquer nome correspondente em um campo excludedSubtrees e invalido independente-mente da informacao contida na permittedSubtrees. As ACs em conformidade DEVEMmarcar esta extensao como crıtica e NAO DEVERIAM impor restricoes de nomes as for-mas x400address, ediPartyName ou formas de nome registeredID. As ACs em conformidadeNAO DEVEM emitir certificados onde name constraints e uma sequencia vazia. Ou seja,tanto o permittedSubtree quanto o excludedSubtree DEVEM estar presentes.

As aplicacoes em conformidade com este perfil DEVEM ser capazes de processar restricoesde nome que sao impostas em formas de nome directoryName e DEVERIAM ser capazesde processar restricoes de nome que sao impostas nas formas rfc822Name, uniformResour-ceIdentifier, dNSName, e iPAddress. Se a extensao name constraints que e marcada como


Ern

andes 37


crıtica impor restricoes a uma forma especıfica, e uma instancia daquelas formas de nomeaparecerem em um campo subject ou extensao subjectAltName de um certificado subse-quente, entao a aplicacao DEVE processar a restricao ou rejeitar o certificado.

Dentro deste perfil, os campos mınimo e maximo nao sao utilizados nas formas any name,assim, o mınimo DEVE ser zero, e o maximo DEVE estar ausente. Entretanto, se umaaplicacao encontra uma extensao name constraints crıtica que especifica outros valores paramınimo ou maximo para uma forma de nome que aparece em um certificado subsequente,a aplicacao DEVE processar estes campos ou rejeitar o certificado.

Para URIs, a restricao e aplicada a parte host do nome. A restricao DEVE ser especificadacomo um nome de domınio totalmente qualificado e PODE especificar um host ou um do-mınio. Seriam exemplos “host.example.com” e “.example.com”. Quando a restricao comecacom um ponto, ela PODE ser expandida com um ou mais rotulos. Ou seja, a restricao“.example.com” e satisfeita por tanto host.example.com quanto por my.host.example.com.Entretanto, a restricao “.example.com” nao e satisfeita por “example.com”. Quando a res-tricao nao comecar com um ponto, ela especifica um host. Se uma restricao e aplicada aforma de nome uniformResourceIdentifier e um certificado subsequente inclui uma exten-sao subjectAltName com um uniformResourceIdentifier que nao inclui uma componenteautoridade com o nome de host especificado como nome de domınio totalmente qualificado(por exemplo, se uma URI nao inclui um componente autoridade ou inclui um componenteautoridade no qual o nome do host e especificado como um endereco IP), entao a aplicacaoDEVE rejeitar o certificado.

Uma restricao de nome para endereco de correio eletronico Internet PODE especificar umacaixa de correio particular, todos os enderecos de um host em particular, ou todas as caixaspostais de um domınio. Para indicar uma caixa de correio particular, a restricao e o ende-reco completo de correio eletronico. Por exemplo, “[email protected]”indica a caixa postalroot no host “example.com”, a restricao “example.com” e satisfeita por qualquer enderecode correio eletronico no host “example.com”. Para especificar qualquer endereco dentrode um domınio, a restricao e especificada com ponto na frente (como ocorre com URIs).Por exemplo, “.example.com” indica todos os enderecos de correio eletronico no domınio“example.com”, mas nao todos os enderecos de correio eletronico no host “example.com”.

As restricoes a nomes DNS sao expressas como host.example.com. Qualquer nome DNSque possa ser construıdo simplesmente adicionando zero ou mais rotulos ao lado mais aesquerda do nome satisfara a restricao de nome. Por exemplo, www.host.example.com sa-tisfaria a restricao, mas host1.example.com nao satisfaria.

Existem implementacoes no legado nas quais um endereco de correio eletronico foi incor-porado no nome distinto de sujeito em um atributo do tipo emailAddress (secao 4.1.2.6).Quando sao impostas restricoes na forma de nome rfc822Name, mas o certificado naoinclui um nome alternativo de sujeito, a limitacao rfc822Name DEVE ser aplicada ao atri-buto do tipo emailAddress no campo subject distinguished name. A sintaxe ASN.1 paraemailAddress e o seu OID correspondente e fornecida no Apendice A.

Restricoes da forma directoryName DEVEM ser aplicadas ao campo subject do certifi-cado (quando o certificado incluir um campo subject nao vazio) e a qualquer nome do tipodirectoryName da extensao subjectAltName. Restricoes da forma x400Address DEVEMser aplicadas a qualquer nome do tipo x400Address na extensao subjectAltName.


Ern

andes 38


Quando aplicar restricoes da forma directoryName, a aplicacao DEVE comparar os atri-butos DN. No mınimo, as aplicacoes DEVEM executar as regras de comparacao para DNespecificadas na secao 7.1. As ACs que emitem certificados com uma restricao da formadirectoryName NAO DEVERIAM confiar em implementacoes do algoritmo de comparacaode nome ISO DN completo. Isso implica que as restricoes de nome DEVEM ser defini-das de maneira identica para a codificacao usada no campo subject ou para a extensaosubjectAltName.

A sintaxe de iPAddress DEVE ser aquela descrita na secao 4.2.1.6 com as adicoes seguin-tes especificamente para restricoes de nomes. Para enderecos IPv4, o campo endereco deGeneralName DEVE conter oito (8) octetos, condificados no estilo da RFC 4632 (CIDR)para representar o escopo de enderecamento [RFC4632]. Para enderecos IPv6, o campoiPAddress DEVE conter 32 octetos codificados de maneira similar. Por exemplo, umarestricao de nome para subrede “classe C” 192.0.2.0 e representado e representada pelosoctetos C0 00 02 00 FF FF FF 00, representando a notacao CIDR 192.0.2.0/24 (mascara255.255.255.0).

Regras adicionais para codificacao e processamento de restricoes de nome sao especificadasna secao 7.

A sintaxe e a semantica para restricoes de nome para otherName, ediPartyName, e re-gisteredID nao sao definidas nesta especificacao, entretanto, a sintaxe e a semantica pararestricoes de nome para formas other name podem ser especificadas em outros documentos.

id-ce-nameConstraints OBJECT IDENTIFIER ::= { id-ce 30 }

NameConstraints ::= SEQUENCE {

permittedSubtrees [0] GeneralSubtrees OPTIONAL,

excludedSubtrees [1] GeneralSubtrees OPTIONAL }

GeneralSubtrees ::= SEQUENCE SIZE (1..MAX) OF GeneralSubtree

GeneralSubtree ::= SEQUENCE {

base GeneralName,

minimum [0] BaseDistance DEFAULT 0,

maximum [1] BaseDistance OPTIONAL }

BaseDistance ::= INTEGER (0..MAX)

4.2.1.11 Policy Constraints

A extensao policy constraints pode ser usada em certificados emitidos para ACs. A ex-tensao restringe validacao de caminho de certificacao de duas formas. Pode ser utilizadapara impedir o mapeamento de polıtica ou requerer que todo certificado de um caminhocontenha um identificador de polıtica aceitavel.

Se o campo inhibitPolicyMapping estiver presente, o valor indica o numero de certificadosadicionais que podem aparecer no caminho antes do mapeamento de polıtica ser proibido.Por exemplo, o valor um indica que policy mapping pode ser processado em certificados


Ern

andes 39


emitidos pelo sujeito do certificado, mas nao em certificados adicionais do caminho.

Se o campo requireExplicitPolicy estiver presente, o valor de requireExplicitPolicy indicao numero de certificados adicionais que podem aparecer no camiinho ante de uma explicitpolicy ser requerido para o caminho inteiro. Quando uma polıtica explıcita for requerida,e necessario que todos os certificados do caminho contenham um identificador de polıticaaceitavel na extensao certificate policy. Um indentificador de polıtica aceitavel e o identifi-cador de uma polıtica requerida pelo usuario do caminha de certificacao ou o identificadorde uma polıtica que for declarada como equivalente atraves da extensao policy mapping.

Aplicacoes em conformidade DEVEM ser capazes de processar o campo requireExplicit-Policy e DEVERIAM ser capazes de processar o campo inhibitPolicyMapping. Aplicacoesque suportarem o campo inhibitPolicyMapping DEVEM tambem implementar suporte aextensao policyMappings. Se a estensao policyConstraints estiver marcada como crıticae o campo inhibitPolicyMapping estiver presente, as aplicacoes que nao implementaremsuporte ao campo inhibitPolicyMapping DEVEM rejeitar o certificado.

As ACs em conformidade NAO DEVEM emitir certificados onde policy constraints e umasequencia vazia. Ou seja, tanto o campo inhibitPolicyMapping ou o campo requireExplicit-Policy DEVE estar presente. O comportamento do cliente que encontra um campo policyconstraints vazio nao e tratado neste perfil.

As ACs em conformidade DEVEM marcar esta extensao como crıtica.

id-ce-policyConstraints OBJECT IDENTIFIER ::= { id-ce 36 }

PolicyConstraints ::= SEQUENCE {

requireExplicitPolicy [0] SkipCerts OPTIONAL,

inhibitPolicyMapping [1] SkipCerts OPTIONAL }

SkipCerts ::= INTEGER (0..MAX)

4.2.1.12 Extended Key Usage

Esta extensao indica um ou mais propositos para os quais o certificado de chave publicapode ser usado, em adicao a ou em substituicao ao indicado no campo basic purpose naextensao key usage.

id-ce-extKeyUsage OBJECT IDENTIFIER ::= { id-ce 37 }

ExtKeyUsageSyntax ::= SEQUENCE SIZE (1..MAX) OF KeyPurposeId

KeyPurposeId ::= OBJECT IDENTIFIER

O proposito da chave pode ser definido por qualquer organizacao com esta demanda. Identi-ficadores de objeto utilizados para identificar os propositos da chave DEVEM ser atribuıdosem conformidade com o IANA ou a recomendacao ITU-T X.660 [X.660].

Esta extensao PODE, dependendo da opcao do emissor do certificado, ser marcada comocrıtica ou nao-crıtica.


Ern

andes 40


Se a extensao estiver presente, entao o certificado DEVE apenas ser utilizado para um dospropositos indicados. Se multiplos propositos forem indicados, a aplicacao nao necessitareconhecer todos eles, desde que o proposito pretendido esteja presente. Aplicacoes queusam certificados PODEM requerer que a extensao extended key usage estejam presentee que seja indicado um proposito particular para que o certificado seja aceito pela aplicacao.

Se uma AC inclui a extensao extended key usage para satisfazer tais aplicacoes, mas naoquerem restringir o uso da chave, a AC pode incluir o valor especial anyExtendedKeyUsageao campo KeyPurposeID em adicao ao proposito especıfico requerido pelas aplicacoes. ACsem conformidade NAO DEVERIAM marcar esta extensao como crıtica anyExtendedKeyU-sage no campo KeyPurposeId estiver presente. Aplicacoes que necessitarem a presenca deum proposito particular PODEM rejeitar certificados que tiverem incluıdo o OID anyEx-tendedKeyUsage, mas nao o OID especıfico aguardado pela aplicacao.

Se um certificado tiver tanto a extensao key usage e uma extensao extended key usage, en-tao ambas as extensoes DEVEM ser processadas independentemente e o certificado DEVEser utilizado apenas para o proposito consistente com ambas as extensoes. Se nao existirnenhum proposito consistente em ambas as extensoes, entao o certificado NAO DEVE serusado para nenhum dos propositos.

Sao definidos propositos de uso para chave:

id-kp OBJECT IDENTIFIER ::= { id-pkix 3 }

id-kp-serverAuth OBJECT IDENTIFIER ::= { id-kp 1 }

-- TLS WWW server authentication

-- Key usage bits that may be consistent: digitalSignature,

-- keyEncipherment or keyAgreement

id-kp-clientAuth OBJECT IDENTIFIER ::= { id-kp 2 }

-- TLS WWW client authentication

-- Key usage bits that may be consistent: digitalSignature

-- and/or keyAgreement

id-kp-codeSigning OBJECT IDENTIFIER ::= { id-kp 3 }

-- Signing of downloadable executable code


id-kp-emailProtection OBJECT IDENTIFIER ::= { id-kp 4 }

-- Email protection

-- Key usage bits that may be consistent: digitalSignature,

-- nonRepudiation, and/or (keyEncipherment or keyAgreement)

id-kp-timeStamping OBJECT IDENTIFIER ::= { id-kp 8 }

-- Binding the hash of an object to a time


-- and/or nonRepudiation

id-kp-OCSPSigning OBJECT IDENTIFIER ::= { id-kp 9 }

-- Signing OCSP responses


Ern

andes 41



-- and/or nonRepudiation

4.2.1.13 CRL Distribution Points

A extensao CRL Distribution Points identifica como a informacao da LCR e obtida. Aextensao DEVERIA ser marcada como nao-crıtica, mas este perfil RECOMENDA suportea esta extensao, tanto nas ACS quanto nas aplicacoes. Uma discussao adicional sobre ogerenciamento de LCR esta incluıda na secao 5.

A extensao cRLDistributionPoints e uma sequencia de DistributionPont. Um Distributi-onPoint e formado por tres campos, cada um deles opcional: distributionPoint, reasons,e cRLIssuer. Embora cada um desses campos seja opcional, um DistributionPoint NAODEVE consistir de apenas do campo reasons, o distributionPoint ou cRLIssuer DEVE estarpresente. Se o emissor do certificado nao for o emissor da LCR, entao o campo cRLIssuerDEVE estar presente, e conter o nome do emissor da LCR. Se o emissor do certificado tam-bem for o emissor da LCR, as ACs em conformidade DEVEM omitir o campo cRLIssuer eDEVEM incluir o campo distributioinPoint.

Quando o distributionPoint estiver presente, ele pode conter tanto uma SEQUENCE degeneral names como um valor unico, nameRelativeToCRLIssuer. Se o DistributionPoints-Name tiver multiplos valores, cada nome descreve um mecanismo distinto para obtencaoda mesma LCR. Por exemplo, a mesma LCR poderia estar disponıvel para recuperacaotanto atraves do LDAP quanto do HTTP.

Se o campo distributionPoints tiver um directoryName, a entrada para aquele directory-Name contem a LCR atual para as razoes relacionadas e a LCR e emitida pelo cRLIs-suer associado. A LCR pode estar armazenada tanto no atributo certificateRevocationListquanto no atributo authotityRevocationList. A LCR a ser obtida pela aplicacao a partirde qualquer servidor de diretorio e configurada localmente. O protocolo utilizado pela apli-cacao para acessar o diretorio (por exemplo, DAP ou LDAP) e uma questao local.

Se o DistributionPointName tiver um general name do tipo URI, a seguinte semanticaDEVE ser considerada: A URI e um apontador para a LCR atual para as razoes rela-cionadas e sera emitida pelo cRLIssuer associado. Quando o forem utilizados os esque-mas HTTP ou FTP URI, a URI deve apontar para uma unica LCR codificada em DER,conforme especificado em [RFC2585]. Implementacoes de servidor HTTP acessado viaURI DEVERIAM especificar o tipo de meio application/pkix-crl no campo de cabecalhocontent-type na resposta. Quando o esquema LDAP URI [RFC4516] for utilizado, a URIDEVE incluir um campo <dn> contendo o nome distinto da entrada da LCR, DEVEincluir um unico <attrdesc> que contem uma descricao de atributo apropriado para oatributo que mantem a LCR [RFC4523], e DEVERIA incluir um <host> (por exemplo,<ldap://ldap.example.com/cn=example%20CA,dc=example, dc=com?certificateRevoca-tionList;binary>). Omitir o <host> (por exemplo, <ldap://cn=CA,dc=examplo,dc=?au-thorityRevocationList,binary>) tem o efeito de confiar em qualquer conhecimento, que ocliente detenha a priori, para contactar o servidor apropriado. Quando presente, Distribu-tionPointName DEVERIA incluir no mınimo uma URI LDAP ou HTTP.

Se o DistributionPointName tiver o valor unico nameRelativeToCRLIssuer, o valor forneceum fragmento do distinguished name. O fragmento e acrescentado ao distinguished name


Ern

andes 42


X.500, do emissor da LCR, para obter o nome do ponto de distribuicao. Se o campo cR-LIssuer no DistributionPoint estiver presente, entao o fragmento do nome e adicionado aodisntinguished name que ele contem; de outra forma, o fragmento de nome e adicionadoao distinguished name do emissor do certificado. ACs em conformidade NAO DEVERIAMusar nameRalativeToCRLIssuer para indicacao de nomes de ponto de distribuicao. O Dis-tributionPointName NAO DEVE usar o nameRelativeToCRLIssuer alternativo quando ocRLIssuer tiver mais que um distinguished name.

Se o DistributionPoint omitir o campo reasons, a CRL DEVE incluir informacoes de revo-gacao para todas as razoes. Este perfil RECOMENDA evitar a segmentacao de LCRs peloscodigos contidos em reason. Quando um AC em conformidade incluir a extensao cRLDis-tributionPoints em um certificado, ela DEVE incluir no mınimo um DistributionPoint queaponta para uma LCR que cobre o certificado para todas as razoes.

O cRLIssuer identifica a entrada que assina e emite a LCR, Se presente, a cRLIssuer DEVEconter apenas o nome distinto (DN) do campo issuer da LCR para a qual o Distribution-Point esta apontando. A codificacao do nome no campo cRLissuer DEVE ser exatamenteo mesmo que a codificacao no campo issuer da LCR. Se o campo sRLIssuer estiver in-cluıdo e o DN naquele campo nao corresponder a uma entrada de diretorio X.500 ou LDAPna qual a LCR esta localizada, entao as ACs em conformidade DEVEM incluir o campodistributionPoint.

id-ce-cRLDistributionPoints OBJECT IDENTIFIER ::= { id-ce 31 }

CRLDistributionPoints ::= SEQUENCE SIZE (1..MAX) OF DistributionPoint

DistributionPoint ::= SEQUENCE {

distributionPoint [0] DistributionPointName OPTIONAL,

reasons [1] ReasonFlags OPTIONAL,

cRLIssuer [2] GeneralNames OPTIONAL }

DistributionPointName ::= CHOICE {

fullName [0] GeneralNames,

nameRelativeToCRLIssuer [1] RelativeDistinguishedName }

ReasonFlags ::= BIT STRING {

unused (0),

keyCompromise (1),

cACompromise (2),

affiliationChanged (3),

superseded (4),

cessationOfOperation (5),

certificateHold (6),

privilegeWithdrawn (7),

aACompromise (8) }

4.2.1.14 Inhibit anyPolicy

A extensao inhibit anyPolicy pode ser utilizada em certificados emitidos para ACs. A ex-tensao inhibit anyPolicy indica que o OID especial anyPolicy, com o valor 2 5 29 32 0 ,


Ern

andes 43


nao e considerado uma correspondencia explicita para outras polıticas de certificado excetoquanto aparecerem em um certificado intermediario de AC auto-assinado. O valor indica onumero de certificados adicionais nao-auto-assinados que pode aparecer no caminho antesde anyPolicy nao mais ser permitido. Por exemplo, o valor um idica que anyPolicy podeser processado em certificados emitidos pelo sujeito do certificado, mas nao em certificadosadicionais no caminho.

As ACs em conformidade DEVEM marcar esta extensao como crıtica.

id-ce-inhibitAnyPolicy OBJECT IDENTIFIER ::= { id-ce 54 }

InhibitAnyPolicy ::= SkipCerts


4.2.1.15 Freshest CRL (Delta CRL Distribution Point)

A extensao freshest CRL identifica como a informacao de LCR delta e obtida. A extensaoDEVE ser marcada como nao-crıtica nas ACs em conformidade. A secao 5 contem umadiscussao adicional sobre o gerenciamento.

A mesma sintaxe e usada para esta extensao, e a extensao cRLDistributionPoints, e descritana secao 4.2.1.13. A mesma convencao e aplicada as duas extensoes.

id-ce-freshestCRL OBJECT IDENTIFIER ::= { id-ce 46 }

FreshestCRL ::= CRLDistributionPoints

4.2.2 Extensoes Privadas Internet

Esta secao define duas extensoes em Infraestruturas de Chave Publica Internet. Estas ex-tensoes podem ser utilizadas para direcionar aplicacoes para informacoes on-line sobre oemissor ou sobre o sujeito do certificado. Cada extensao contem uma sequencia de metodosde acesso e locais de acesso. O metodo de acesso e um identificador de objeto que indica otipo de informacao que esta disponıvel. O local de acesso e um GeneralName que implicita-mente especifica o local e o formato da informacao, e o metodo para obtencao da informacao.

Identificadores de objeto sao definidos para as extensoes privadas. Os identificadores deobjeto associado a extensoes privadas sao devinidos sob o arco is-pe dentro do arco id-pkix.Quaisquer extensoes futuras definidas para a ICP Internet tambem e esperando que sejamdefinidas sob o arco id-pe.

id-pkix OBJECT IDENTIFIER ::=

{ iso(1) identified-organization(3) dod(6) internet(1)

security(5) mechanisms(5) pkix(7) }

id-pe OBJECT IDENTIFIER ::= { id-pkix 1 }


Ern

andes

44


4.2.2.1 Authority Information Access

A extensao authority information access (acesso a informacao de autoridade) indica comoacessar informacao e servicos para o emissor do certificado no qual a extensao ocorre.Informacao e servicos podem incluir servicos de validacao on-line e dado de polıtica deAC. (A localizacao de LCRs nao e especificada nesta extensao; essa informacao e fornecidapela extensao cRLDistributionPoints.) Esta extensao pode ser incluıda em certificadosde entidade final ou de AC. ACs em conformidade DEVEM marcar esta extensao comonao-crıtica.

id-pe-authorityInfoAccess OBJECT IDENTIFIER ::= { id-pe 1 }

AuthorityInfoAccessSyntax ::=

SEQUENCE SIZE (1..MAX) OF AccessDescription

AccessDescription ::= SEQUENCE {

accessMethod OBJECT IDENTIFIER,

accessLocation GeneralName }

id-ad OBJECT IDENTIFIER ::= { id-pkix 48 }

id-ad-caIssuers OBJECT IDENTIFIER ::= { id-ad 2 }

id-ad-ocsp OBJECT IDENTIFIER ::= { id-ad 1 }

Cada entrada na sequencia AuthorityInformationAccessSyntax descreve o formato e a lo-calizacao da informacao adicional fornecida pelo emissor do certificado no qual a extensaoocorre. O tipo e o formato da informacao sao especificados pelo campo accessMethod; ocampo accessLocation especifica o local da informacao. O mecanismo de recuperacao podeestar implıcito no accessMethod ou estar ser especificado no accessLocation.

Este perfil define dois OIDs para accessMethod: id-ad-caIssuers e id-ad-ocsp.

No certificado de chave publica, o OID id-ad-caIssuers e usado quando a informacao adi-cional lista certificados que foram emitidos para a AC que emitiu o certificado que tem aextensao. A descricao de AC emissoras referenciada tem como finalidade ajudar os usuariosde certificado na selecao de um caminho de certificacao que termina em um ponto que econsiderado confiavel pelo usuario do certificado.

Quando id-ad-caIssuers aparece como accessMethod, o campo accessLocation descreve oservidor da descricao referenciada e o protocolo de acesso para obtencao da descricao re-ferenciada. O campo accessLocation e definido como GeneralName, que pode ter variasformas.

Quando o accessLocation e um directoryName, a informacao a ser obtida pela aplicacao apartir de qualquer servidor de diretorio e localmente configurada. A entrada para o direc-toryName contem certificados de AC em crossCertificatePair e/ou atributos cACertificatecomo especificado em [RFC4523]. O protocolo que as aplicacoes utilizaram para acessor odiretorio (ex, DAP ou LDAP) e uma questao local.

Onde a informacao estiver disponıvel atraves do LDAP, o accessLocation DEVERIA serum uniformResourceIdentifier. A URI LDAP [RFC4516] DEVE incluir um campo <dn>contendo o nome distinto do entrada com o certificado, DEVE incluir um campo <attribu-tes> que lista a descricoes apropriadas ao atributo para os atributos que detem certificados


Ern

andes

45


codificados em DEF ou pares de certificados cruzados [RFC4523], e DEVERIAM incluir um<host> (ex, <ldap://ldap.example.com/cn=CA,dc=example,dc=com?cACertificate;bina-ry,crossCertificatePair,binary>). Omitindo o <host> (ex, <ldap:///cn=exampleCA,dc=e-xample,dc=com?cACertificate;binary>) tem o efeito de confiar em qualquer conhecimentoque o cliente possa ter, a priori, para contactar um servidor apropriado.

Onde a informacao estiver disponıvel atraves de HTTP ou FTP, accessLocation DEVE serum uniformResourceIdentifier e a URI DEVE apontar tanto para um unico certificado, co-dificado em DER como especificado em [RFC2585] como para uma colecao de certificadosem uma mensagem CMS tipo “certs-only” codificada em BER ou DER , conforme especi-ficado em RFC2797].

Aplicacoes em conformidade que suportam HTTP ou FTP para acessar certificados DE-VEM ser capazes de aceitar certificados individuais codificados em DER e DEVERIAM sercapazes de aceitar mensagens CMS “certs-only”.

Implementacoes de servidores HTTP acessados via URI DEVERIAM especificar o tipode mıdia aplication/pkix-cert [RFC2585] no campo de cabecalho content-type da respostapara mensagens CMS “certs-only”. Para FTP, o nome do arquivo que contem um certifi-cado unico codificado em DER DEVERIA possuir um sufixo “.cer” [RFC2585] e o nomedo arquivo que contem uma mensagem CMS “certs-only” DEVERIA ter o sufixo “.p7c”[RFC2797]. Clientes consumidores podem usar o tipo de mıdia ou extensao de arquivocomo uma dica para o conteudo, mas nao deve depender apenas da presenca do tipo demıdia correto ou extensao de arquivo na resposta do servidor.

A semantica de outras formas de nome id-ad-caIssuers accessLocation nao sao definidas.

Uma extensao authorityInfoAccess pode incluir multiplas instancias de id-ad-caIssuers ac-cessMethod. As diferentes instancias podem especificar diferentes metodos para acessar amesma informacao ou podem apontar para informacao diferente. Quando o id-ad-caIssuersaccessMethod e usado, no mınimo uma instancia DEVERIA especificar uma accessLocationque e uma URI HTTP [RFC2616] ou LDAP [RFC4516].

O OID id-ad-ocsp e usado quando informacao de revogacao para o certificado contendoesta extensao se encontra disponıvel usando o Online Certificate Status Protocol (OCSP)[RFC2560].

Quando id-ad-ocsp aparece como accessMethod, o campo accessLocation e o local do res-pondedor OCSP, usando as convencoes definidas em [RFC2560].

Descritores adicionais de acesso podem ser definidos em outras especificacoes PKIX.

4.2.2.2 Subject Information Access

A extensao subject information access indica como acessar informacao e servicos para osujeito do certificado no qual a extensao ocorre. Quando o sujeito e uma AC, informacoese servicos podem incluir servicos de validacao de certificado e dados de polıtica de AC.Quando o sujeito e uma entidade final, a informacao descreve o tipo de servicos oferecidose como acessa-los. Neste caro, o conteudo desta extensao e definido na especificacao doprotocolo para os servicos suportados. Esta extensao pode ser incluıda em certificados de


Ern

andes

46


entidade final ou de AC. ACs em conformidade DEVEM marcar esta extensao como nao-crıtica.

id-pe-subjectInfoAccess OBJECT IDENTIFIER ::= { id-pe 11 }

SubjectInfoAccessSyntax ::=





Cada entrada na sequEncia SubjectInfoAccessSyntax descreve o formato e a localizacao dainformacao adicional fornecida pelo sujeito do certificado no qual a extensao ocorre. O tipoe o formato da informacao sao especificados no campo accessMethod; o campo accessLo-cation especifica o local da informacao. O mecanismo de recuperacao pode estar implıcitono accessMethod ou ser especificado por accessLocation.

Este perfil define um metodo de acesso para ser usado quando o sujeito e uma AC e ummetodo de acesso para ser usado quando o sujeito e uma entidade final. Metodos de acessoadicionais podem ser definidos no futuro em especificacoes de protocolos para outros servi-cos.

O OID id-ad-caRepository e usado quando o sujeito e uma AC que publica certificados queela emite em um repositorio. O campo accessLocation e como um GeneralName, que podeter diversas formas.

Quando o accessLocation e um directoryName, a informacao e para ser obtida pela aplica-cao de qualquer diretorio localmente configurado. Quando a extensao e usada para apontarpara certificados de AC, a entrada para o directoryName contem certificados de AC nocrossCertificatePair e/ou atributos cACertificate como especificado em [RFC4523]. O pro-tocolo que a aplicacao usa para acessar o diretorio (ex: DAP ou LDAP) e uma questao local.

Onde a informacao for disponibilizada atraves do LDAP, o accessLocation DEVERIA serum uniformResourceIdentifier. A URI LDAP [RFC4516] DEVE incluir um campo <dn>contendo o nome distinto da entrada que detem os certificados, DEVE incluir um campo<attributes> que lista os descritores de atributo apropriados para o atributo que detem oscertificados codificados em DER ou pares cross-certificate [RFC4523], e DEVERIA incluirum<host> (ex: <ldap://ldap.example.com/cn=AC,dc=example,dc=com?cACertificate;bi-nary,crossCertificatePair;binary>).

Omitir o <host> (ex: <ldap:///cn=exampleCA,dc=example,dc=com?cACertificate;bina-ry>) tem o efeito de confiar em qualquer conhecimento, a priori, o cliente poderia ter paracontactar um servidor apropriado.

Onde a informacao estiver disponıvel via HTTP ou FTP, accessLocation DEVE ser umuniformResourceIdentifier e a URI DEVE apontar para um unico certificado codificado emDER como especificado em [RFC2585] ou uma colecao de certificados codificados em BER


Ern

andes

47


ou DER de uma mensagem CMS “certs-only” como especificado em [RFC2797].

Aplicacoes em conformidade que suportam HTTP ou FTP para acessar certificados DE-VEM ser capazes de aceitar certificados individuais codificados em DER e DEVEM sercapazes de aceitar mensagens CMS “certs-only”.

Implementacoes de servidores HTTP acessados via URI DEVERIAM especificar a tipo demıdia application/pkix-cert [RFC2585] no campo content-type do cabecalho da respostapara um unico certificado codificado em DER e DEVERIA especificar o tipo de mıdiaapplication/pkcs7-mime [RFC2797] no campo content-type do cabecalho da resposta paramensagens CMS “certs-only”. Para FTP, o nome do arquivo que contem um unico cer-tificado codificado em DER DEVERIA ter sufixo “.cer” [RFC2585] e o nome do arquivocontendo uma mensagem “certs-only” DEVERIA ter um sufixo “.p7c” [RFC2797]. Clientesconsumidores podem usar o campo media type ou file extension como uma sugestao parao conteudo, mas nao deveria depender somente da presenca do tipo correto de mıdia ou daextensao arquivo na resposta do servidor.

A semantica de outra forma id-ad-caRepository para nome accessLocation nao e definida.

Uma extensao subjectAccess pode incluir multiplas instancias de id-ad-caRepository ac-cessMethod. As diferentes instancias podem especificar diferentes metodos para acessar amesma informacao ou apontar para informacao diferente. Quando o id-ad-caRepositoryaccessMethod e usado, no mınimo uma instancia DEVERIA especificar um accessLocationque seja URI HTTP [RFC2616] ou LDAP [RFC4516].

O OID id-ad-timeStamping e usado quando o sujeito oferece servicos de timestampingusando o Time Stamp Protocol definido em [RFC3161]. Onde os servicos de timestampingestiveres disponıveis via HTTP ou FTP, accessLocation DEVE ser um uniformResourceI-dentifier. Onde os servicos de timestamping estiverem disponıveis via correio eletronico,accessLocation DEVE ser um rfc822name. Onde servicos de timestamping estiverem dispo-nıveis usando TCP/IP, o dNSName ou formas de nome tipo iPAddress podem ser utilizadas.As semanticas de outras formas de nome de accessLocation (quando accessMethod e id-ad-timeStamping) nao sao definidas nesta especificacao.

Outros descritores de acesso adicionais podem ser definidos em outras especificacoes PKIX.


id-ad-caRepository OBJECT IDENTIFIER ::= { id-ad 5 }

id-ad-timeStamping OBJECT IDENTIFIER ::= { id-ad 3 }

5 Perfil da LCR e das Extensoes da LCR

Como discutido acima, um objetivo deste perfil para LCR X.509 v2 e fomentar a criacao deuma ICP Internet interoperavel e reutilizavel. Para atingir este objetivo, sao especificadasdiretrizes para o uso de extensoes, e sao feitas consideracoes sobre a natureza da informacaocontida na LCR.


Ern

andes

48


As LCRs podem ser utilizadas numa vasta gama de aplicacoes e ambientes que abran-gem um largo espectro de objetivos de interoperabilidade e um espectro ainda mais amplode requisitos operacionais e de seguranca. Este perfil estabelece uma base comum paraaplicacoes genericas que exigem ampla interoperabilidade. O perfil define um conjuntode informacoes que podem ser esperadas em cada LCR. Alem disso, o perfil define locaiscomuns dentro do LCR para atributos usados com frequencia, assim como representacoescomuns para esses atributos.

Os emissores de LCR emitem LCRs. O emissor da LCR pode ser tanto a AC quanto umaentidade que foi autorizada pelo AC para emitir LCRs. ACs publicam LCRs para fornecerinformacoes de estado de revogacao dos certificados por ela emitidos. No entanto, uma ACpode delegar esta responsabilidade a uma outra autoridade confiavel.

Cada LCR possui um escopo especıfico. O escopo da LCR e o conjunto de certificados quepodem aparecer em uma dada LCR. Por exemplo, o escopo pode ser “todos os certificadosemitidos pela AC X”, “todos os certificados de AC emitidos pela AC X”, “todos os certifica-dos emitidos pela AC X que foram revogados por razoes de comprometimento da chave ecomprometimento da AC”, ou um conjunto de certificados com base em informacoes locaisarbitrarias, como “todos os certificados emitidos aos funcionarios do NIST localizados emBoulder”.

Uma LCR completa lista todos os certificados em curso, dentro do seu ambito, que foramrevogados por um dos motivos de revogacao abrangidos pelo escopo da LCR. Uma LCRinteira e completa lista todos os certificados ainda nao vencidos emitidos por uma CA queforam revogados por qualquer motivo. (Note que, as ACs e emissores de LCR sao identi-ficados pelo nome, o escopo de uma LCR nao e afetado pela chave usada para assinar aLCR ou a(s) chave(s) usada(s) para assinar certificados.)

Se o escopo da LCR inclui um ou mais certificados emitidos por uma entidade distinta doemitente da LCR, entao ela e um LCR indireta. O escopo de uma LCR indireta pode serlimitada aos certificados emitidos por uma unica CA ou pode incluir certificados emitidospor multiplas ACs. Se o emitente da LCR indireta e uma AC, entao, o escopo da LCRindireta tambem pode incluir certificados emitidos pelo emissor da LCR.

O emissor da LCR tambem PODE gerar LCRs delta. Um LCR delta lista apenas os certi-ficados, no seu escopo, cuja estado de revogacao mudou desde a emissao da CRL completareferenciada. A LCR completa referenciada e indicada como uma LCR base. O escopo deuma LCR delta deve ser a mesma que a LCR base a qual faz referencia.

Este perfil define uma extensao privada para LCR Internet, mas nao define qualquer ex-tensao privada para entrada da LCR.

Ambientes com requisito adicional ou especial podem implementar esse perfil ou podesubstituı-lo.

As ACs em conformidade nao sao obrigadas a emitir LCRs quando sao fornecidos outrosmecanismos para consulta do estado de revogacao de certificados. Quando as LCRs saoemitidas, as LCRs DEVEM ser LCRs versao 2, incluir a data em que a proxima LCR seraemitida no campo nextUpdate (Secao 5.1.2.5), incluir a extensao number da LCR (Secao5.2.3), e incluir a autoridade extensao authority key identifier (Secao 5.2.1). As aplicacoes


Ern

andes

49


em conformidade que suportarem LCRs sao REQUERIDAS fazer o processamento tantoda versao 1 quanto da versao 2 das LCRs completas que fornecem informacoes de revoga-cao sobre todos os certificados emitidos por uma AC. Aplicacoes em conformidade nao saoobrigadas a suportar o processamento de LCRs delta, LCRs indiretas, ou LCRs com umescopo diferente daquele utilizado para todos os certificados emitidos por uma AC.

5.1 Campos da LCR

A sintaxe da LCR X.509 v2 e a seguinte. Para o calculo da assinatura o dado deve serassinado e aquele codificado em DER do ASN.1. A codificacao DER do ASN.1 e formadopor um rotulo, tamanho, e um sistema de codificacao de valor para cada elemento. id-pe-subjectInfoAccess OBJECT IDENTIFIER ::= id-pe 11SubjectInfoAccessSyntax ::= SEQUENCE SIZE (1..MAX) OF AccessDescription

CertificateList ::= SEQUENCE {

tbsCertList TBSCertList,


signatureValue BIT STRING }

TBSCertList ::= SEQUENCE {

version Version OPTIONAL,

-- if present, MUST be v2


issuer Name,

thisUpdate Time,

nextUpdate Time OPTIONAL,

revokedCertificates SEQUENCE OF SEQUENCE {

userCertificate CertificateSerialNumber,

revocationDate Time,

crlEntryExtensions Extensions OPTIONAL

-- if present, version MUST be v2

} OPTIONAL,

crlExtensions [0] EXPLICIT Extensions OPTIONAL

-- if present, version MUST be v2

}

-- Version, Time, CertificateSerialNumber, and Extensions

-- are all defined in the ASN.1 in Section 4.1

-- AlgorithmIdentifier is defined in Section 4.1.1.2

Os itens a seguir descrevem o uso de LCR X.509 v2 em ICP Internet.

5.1.1 Campos do CertiticateList

O campo CertificateList e uma sequencia de tres campos obrigatorios. Os campos saodescritos em detalhes nas subsecoes seguintes.

5.1.1.1 tbsCertList

O primeiro campo na sequeencia e o tbsCertList. O campo e por si, uma sequencia con-tendo o nome do emissor, a data de emissao, a data da emissao da proxima lista, a lista


Ern

andes

50


opcional de certificados revogados, e extensoes opcionais da LCR. Quando nao existiremcertificados revogados, a lista de certificados revogados nao estara presente. Quando umou mais certificados tiverem sido revogados, cada entrada da lista de certificados revoga-dos e definida como uma sequencia de numeros seriais de certificados de usuario, data darevogacao e entradas para extensoes opcionais da LCR.

5.1.1.2 signatureAlgorithm

O campo signatureAlgorithm contem o identificador de algoritmo para o algoritmo usadopelo emissor da LCR para assinar o CertificateList. O campo e do tipo AlgorithmIdentifier,que e definido na secao 4.1.1.2. [RFC4055], [RFC4055], e [RFC4491] lista os algoritmos su-portados por esta especificacao, mas outros algoritmos de assinatura tambem PODEM sersuportados.

Este campo DEVE conter o mesmo identificador de algoritmo que o indicado no camposignature da sequencia tbsCertList (secao 5.1.2.2).

5.1.1.3 signatureValue

O campo signatureValue contem uma assinatura digital calculada sobre o campo tbsCer-tList codificado em DER do ASN.1. O tbsCertList codificado e usado como entrada para afuncao de assinatura. Esse valor de assinatura e codificado como um string de bit e incluıdono campo signatureValue da LCR. Os detalhes desse processo sao especificados para cadaum dos algoritmos suportados em [RFC3279], [RFC4055], e [RFC4491].

As ACs que tambem sao emissoras de LCR PODEM usar uma chave privada para assinardigitalmente certificados e LCRs, ou PODEM usar chaves privadas separadas para assi-nar digitalmente certificados e LCRs. Quando empregadas chaves separadas, cada uma daschaves publicas relacionadas com essas chaves privadas e incluıda em certificados separados,um com o bit cRLSign ativado na extensao key usage (secao 4.2.1.3). Quando forem em-pregadas chaves privadas separadas, os certificados emitidos pela AC contem um authoritykey identifier, e as LCRs correspondentes, contem um authority key identifier diferente. Ouso de certificados de AC separados para validacao de assinaturas de certificado e assinatu-ras de LCR, podem oferecer uma melhor caracterıstica de seguranca; no entanto, impoemum fardo a mais para as aplicacoes, e pode limitar a interoperabilidade. Muitas aplicacoesconstroem um caminho de certificacao, e entao validam o caminho de certificacao (secao6). A validacao da LCR, por sua vez, requer um caminho de certificacao separado, a serconstruıdo e validado para a validacao do certificado de assinatura da LCR usado pela AC.As aplicacoes que executam validacao de LCR DEVEM suportar validacao de caminho decertificacao quando os certificados e LCRs sao assinados digitalmente pela mesma chaveprivada. Estas aplicacoes tambem DEVERIAM suportar validacao de caminho de certifi-cacao quando forem utilizadas chaves privadas distintas para assinatura de certificados eLCRs.

5.1.2 Certificate List “A Ser Assinado”

O campo certificate list a ser assinado, ou TBSCertList, e uma sequencia de campos obri-gatorios e opcionais. Os campos obrigatorios identificam o emissor da LCR, o algoritmo


Ern

andes

51


utilizado para assinar a LCR, e a data e o tempo da emissao da LCR.

Campos adicionais incluem a data e o tempo no qual o emissor da CLR emitira a proximaLCR, a lista de certificados revogados, e extensoes da LCR. A lista de certificados revogadose opcional, para suportar o caso no qual a AC nao possui nenhum certificado, por elaemitido, revogado dentro do perıodo de validade. Este perfil requer que os emissores deLCR em conformidade incluam o campo nextUpdate e o numero da LCR, e a extensaoauthority key identifier em todas as LCRs emitidas.

5.1.2.1 Version

Este campo opcional descreve a versao da LCR codificada. Quando as extensoes forem usa-das, como obrigatorio para este perfil, este campo DEVE estar presente e DEVE especificara versao 2 (o valor inteiro utilizado e 1).

5.1.2.2 Signature

Este campo contem o identificador do algoritmo para o algoritmo utilizado para assinar aLCR. [RFC3279], [RFC4055], e [RFC4491] lista os OIDs para os algoritmos de assinaturamais comuns usados na ICP Internet.

Este campo DEVE conter o mesmo identificador de algoritmo que o campo signatureAlgo-rithm na sequencia CertificateList (secao 5.1.1.2).

5.1.2.3 Issuer Name

O campo issuer name identifica a entidade que assinou e emitiu a LCR. A identidadedo emissor e informada no campo issuer. Formas alternativas de nome tambem podemaparecer na extensao issuerAltName (secao 5.2.2). O campo issuer DEVE conter um nomedistinto (DN) X.500 nao vazio. O campo issuer e definido como um tipo Name do X.501,e DEVE seguir as regras de codificacao para o campo issuer name do certificado (secao4.1.2.4).

5.1.2.4 This Update

Este campo indica a data de emissao da LCR. thisUpdate pode ser codificado como UTC-Time ou GeneralizedTime.

Emissores de LCR em conformidade com este perfil DEVEM codificar thisUpdate comoUTCTime para datas ate o ano 2049. Emissores de LCR em conformidade com este perfilDEVEM codificar thisUpdate como GeneralizedTime para datas no ano 2050 para frente.Aplicacoes em conformidade DEVEM ser capazes de processar datas que estejam codifica-das tanto em UTCTime como em GeneralizedTime.

Quando codificada como UTCTime, thisUpdate DEVE ser especificada e interpretada comodefinido na secao 4.1.2.5.1. Quando codificadas como GenerelizedTime, thisUpdate DEVEser especificada e interpretada como definido na secao 4.1.2.5.2.

5.1.2.5 Next Update


Ern

andes

52


Este campo indica a data na qual a proxima LCR sera emitida. A proxima LCR pode seremitida antes da data indicada. Emissores de LCR DEVERIAM emitir LCRs com o temponextUpdate iqual ou maior que todas as LCRs enteriores. nextUpdate pode ser codificadocomo UTCTime ou GeneralizedTime.

Os emissores de LCR em conformidade DEVEM incluir o campo nextUpdate em todasas LCRs. Note que a sintaxe ASN.1 de TBSCertList descreve este campo como opcional,que esta consistente com a estrutura ASN.1 definida em [X.509]. O comportamento de cli-entes que processam LCRs que omitem o campo nextUpdate nao e especificado neste perfil.

Emissores de LCR em conformidade com este perfil DEVEM codificar nextUpdate comoUTCTime para datas ate o ano de 2049. Emissores de LCR em conformidade com esteperfil DEVEM codificar nextUpdate como GeneralizedTime para datas no ano 2050 e pos-teriores. Aplicacoes em conformidade DEVEM ser capazes de processar datas que estejamcodificadas tanto em UTCTime quanto em GeneralizedTime.

Quando codificadas como UTCTime, nextUpdate DEVE ser especificado e interpretadocomo definido na secao 4.1.2.5.1. Quando codificada como GeneralizedTime, nextUpdateDEVE ser especificado e interpretado como definido na secao 4.1.2.5.2.

5.1.2.6 Revoked Certificates

Quando nao existirem certificados revogados, a lista de certificados revogados DEVE estarausente. De outra forma, os certificados revogados sao listados pelos seus numeros seriais.Certificados revogados pela AC sao identificados unicamente pelo numero serial do certi-ficado. A data na qual a revogacao ocorreu e especificada. O tempo para revocationDateDEVE ser expresso conforme descrito na secao 5.1.2.4. Informacao adicional pode ser for-necida nas extensoes das entradas da LCR; extensoes de entrada da LCR serao discutidasna secao 5.3.

5.1.2.7 Extensoes

Este campo apenas ocorre se a versao for 2 (secao 5.1.2.1). Se presente, este campo e umasequencia de um ou mais extensoes de LCR. As extensoes de LCR sao serao discutidas nasecao 5.2.

5.2 Extensoes da LCR

As extensoes para LCRs X.509 v2 definidas nos padroes ANSI X.9, ISO/IEC e ITU-T[X.509] [X9.55] fornecem metodos para associacao de atributos adicionais as LCRs. O for-mato X.509 para LCR tambem permite que comunidades definam extensoes privadas paratransferir informacoes particulares aquelas comunidades. Cada extensao da LCR pode serdesignada como crıtica ou nao-crıtica. Se um LCR tiver uma extensao crıtica que a apli-cacao nao possa processar, entao a aplicacao NAO DEVE usar a LCR para determinar oestado de revogacao dos certificados. Entretanto, as aplicacoes podem ignorar as extensoesnao-crıticas. As subsecoes seguintes apresentam aquelas extensoes usadas com LCRs Inter-net. As comunidades podem decidir incluir extensoes na LCR que nao estao definidas nestaespecificacao. No entanto, devem ter cuidado na adocao de quaisquer extensoes crıtica nasLCRs que podem ser utilizadas em contexto geral.


Ern

andes

53


Os emissores de LCR em conformidade NECESSITAM incluir a extensoes authority KeyIdentifier (secao 5.2.1) e CRL number (secao 5.2.3) em todas as LCRs emitidas.

5.2.1 Authority Key Identifier

A extensao authority key identifier fornece um meio para identificar a chave publica corres-pondente a chave privada usada para assinar a LCR. A identificacao pode ser baseada tantono identificador da chave (campo subject key identifier do certificado usado para assinar aLCR) ou no campo issuer name e serial number. Esta extensao e especialmente util quandoum emissor tem mais de uma chave para assinatura, por questoes de multiplos pares dechaves concorrentes ou devido a troca de chave.

Emissores de LCR em conformidade DEVEM usar o metodo key identifier, e DEVEM in-cluir esta extensao em todas as LCRs emitidas.

A sintaxe para esta extensao da LCR e definida na secao 4.2.1.1.

5.2.2 Issuer Alternative Name

A extensao issuer alternative name permite que identidades adicionais sejam associadas aoemissor da LCR. Opcoes definidas incluem endereco de e-mail (ref822Name), nome DNS,endereco IP, e URI. Multiplas instancias de uma forma de nome e multiplas formas denome podem ser incluıdas. Sempre que tais identidades forem utilizadas, a extensao issueralternative name DEVE ser utilizada; no entanto, um nome DNS PODE ser representadono campo issuer usando o atributo domainComponent conforme descrito na secao 4.1.2.4.

Emissores de LCR em conformidade DEVERIAM marcar a extensao issuerAltName comonao-crıtica.

O OID e a sintaxe para este extensao de LCR estao definidos na secao 4.2.1.7.

5.2.3 CRL Number

A extensao CRL number e uma extensao nao-crıtica que contem uma sequencia monoto-nicamente crescente de numeros para um dado escopo de LCR e emissor de LCR. Estaextensao permite que os usuarios facilmente determinem quando uma LCR em particu-lar sucede uma outra LCR. Numeros de LCR tambem suportam identificacao para LCRscomplementares inteiras e para LCRs delta. Emissores de LCR em conformidade com esteperfil DEVEM incluir esta extensao em todas as LCRs e DEVEMmarca-la como nao-crıtica.

Se um emissor de LCR gerar LCRs delta em complemento a LCRs completas para umdado escopo, as LCRs completas e as LCRs delta devem compartilhar uma unica sequencianumerica. Se uma LCR delta e uma LCR completa que cobrem o mesmo escopo forememitidas no mesmo tempo, elas DEVEM possuir o mesmo numero de LCR e fornecerem amesma informacao de revogacao. Ou seja, a combinacao da LCR delta e uma LCR com-pleta aceitavel DEVE fornecer a mesma informacao sobre revogacao que a LCR completasimultaneamente emitida.

Se o emissor de LCR gera duas LCRs (duas LCRs completas, duas LCRs delta, ou umaLCR completa e uma delta) para o mesmo escopo em momentos diferentes do tempo, as


Ern

andes

54


duas LCRs NAO DEVEM possuir o mesmo numero de LCR. Isto e, se o campo this up-date (secao 5.1.2.4) nas duas LCRs nao forem identicos, os numeros das LCRs DEVEM serdiferentes.

Considerando os requisitos acima, numeros de LCR podem aguardados como inteiros lon-gos. Os verificadores de LCR DEVEM ser capazes de processar valores contidos no CRL-Number de ate 20 octetos. Emissores de LCR em conformidade NAO DEVEM usar valoresmaiores que 20 octetos para CRLNumber.

id-ce-cRLNumber OBJECT IDENTIFIER ::= { id-ce 20 }

CRLNumber ::= INTEGER (0..MAX)

5.2.4 Delta CRL Indicator

A extensao delta CRL indicator e crıtica e identifica que uma LCR e delta. As LCRs deltacontem atualizacoes de informacao de revogacao previamente distribuıdas, ao inves de con-ter todas as informacoes constantes de uma LCR completa. O uso de LCRs delta podesignificativamente reduzir o carregamento da rede e o tempo de processamento em deter-minados ambientes. LCRs delta sao geralmente menores que as LCRs que elas atualizam,assim, as aplicacoes que obtem LCRs delta consomem menos banda da rede que aplicacoesque obtem as LCRs completas correspondentes. Aplicacoes que armazenam informacao derevogacao em formato diferente da estrutura da LCR podem adicionar nova informacao derevogacao a base de dados local sem a necessidade de reprocessar toda informacao.

A extensao delta CRL indicator contem um valor unico do tipo BaseCRLNumber. O CRLnumber identifica a LCR, completa para um dado escopo, que foi utilizada como ponto dereferencia para a geracao da presente LCR delta. Um emissor de LCR em conformidadeDEVE publicar a LCR base referenciada como uma LCR completa. A LCR delta contemtodas as atualizacoes de estado de revogacao para um mesmo escopo. A combinacao deuma LCR delta mais a LCR base referenciada e equivalente a uma LCR completa, para oescopo considerado, no tempo da publicacao da LCR delta.

Quando um emissor de LCR gera uma LCR delta, a LCR delta DEVE incluir a extensaocrıtica delta CRL indicator.

Quando uma LCR delta e emitida, ela DEVE cobrir o mesmo conjunto de razoes e o mesmoconjunto de certificados que foram cobertos pela LCR base que ela referencia. Isto e, o es-copo da LCR delta DEVE ser o mesmo escopo da LCR completa referenciada como LCRbase. A LCR base referenciada e a LCR delta DEVEM omitir a extensao issuing ditributionpoint ou conter extensoes issuing distribution point iguais. Alem disso, o emissor de LCRDEVE usar a mesma chave privada para assinar a LCR delta e qualquer LCR completaque a LCR delta atualiza.

A aplicacao que suporta LCRs delta pode construir uma LCR completa para um dadoescopo, combinando a LCR delta para aquele escopo com, tanto uma LCR emitida paraaquele escopo que seja completa ou uma LCR localmente construıda que seja completapara aquele escopo.


Ern

andes

55


Quando um LCR delta e combinada com uma LCR completa ou uma LCR localmenteconstruıda, a LCR resultante, localmente construıda, tem como CRL number aquele espe-cificado na extensao CRL number encontrada na LCR delta, utilizada para a sua constru-cao. Adicionalmente, a LCR resultante, localmente construıda, tem os tempos thisUpdatee nextUpdate especificados nos campos correspondentes da LCR delta utilizada na suaconstrucao. Alem disso, a LCR localmente construıda herda os calores contidos em issuingdistribution point da LCR delta.

Uma LCR completa e uma LCR delta PODEM ser combinadas quando as quatro condicoesa seguir forem satisfeitas:

(a) A LCR completa e a LCR delta possuem o mesmo emissor.

(b) A LCR completa e a LCR delta possuem o mesmo escopo. As duas LCRs possuemo mesmo escopo se ocorrer uma das seguintes condicoes:

(1) A extensao issuingDistributionPoint e omitida tanto na LCR completaquanto na LCR delta.

(2) A extensao issuingDistributionPoint estiver presente tanto na LCR com-pleta quanto na LCR delta, e o valor desses campos for o mesmo nas duasLCRs.

(c) O CRL number da LCR completa e iqual ou maior que o BaseCRLNumber es-pecificado na LCR delta. Isto e, a LCR completa contem (no mınimo) toda ainformacao de revogacao tratada pela LCR base referenciada.

(d) O CRL number da LCR completa e menor que o numero da LCR delta. Isto e, aLCR delta seque a LCR completa na sequencia de numeracao.

Os emissores de LCR DEVEM garantir que a combinacao de uma LCR delta e qualquerLCR completa apropriada refletira exatamente a estado de revogacao atual. O emissor deLCR DEVE incluir uma entrada na LCR delta para cada certificado dentro do escopo daLCR delta cujo estado tiver mudado desde a geracao da LCR base referenciada:

(a) Se o certificado esta revogado por uma razao incluıda no escopo da LCR, listar ocertificado como revogado.

(b) Se o certificado estiver valido e estiver listado na LCR base referenciada ou qual-quer LCR subsequente, com o codigo razao certificateHold, e o codigo da razaocertificateHold estiver incluıdo no escopo da LCR, listar o certificado com o codigorazao removeFromLCR.

(c) Se o certificado estiver revogado por uma razao externa ao escopo da LCR, mas ocertificado for listado na LCR base referenciada ou qualquer LCR subsequente como codigo razao incluso no escopo desta LCR, listar o certificado como revogado,mas omitir o codigo razao.

(d) Se o certificado estiver revogado por uma razao externa ao escopo da LCR e o cer-tificado nao se encontrar listado na LCR base referenciada, nem em qualquer LCRsubsequente com a razao existente no escopo desta LCR, nao listar o certificadonesta LCR.


Ern

andes

56


O estado de um certificado e considerado modificado se ele estiver revogado (por qualquerrazao, incluindo certificateHold), se ele estiver liberado da suspensao, ou se as razoes desua revogacao mudarem.

E apropriado listar um certificado com codigo razao removeFromCRL na LCR delta mesmose o certificado nao estiver suspenso na LCR base referenciada. Se o certificado foi colocadoem suspensao em qualquer LCR emitida apos a LCR base, mas antes desta LCR delta eentao liberado da suspensao, ele DEVE ser listado na LCR delta com codigo de revogacaoremoveFromCRL.

O emissor de LCR DEVE opcionalmente listar um certificado na LCR delta com codigorazao removeFromCRL se o tempo notAfter especificado no certificado preceder o tempothisUpdate especificado na LCR delta e o certificado for listado na LCR base referenciadaou em qualquer LCR emitida apos a base, mas antes desta LCR delta.

Se um aviso de revogacao de certificado aparecer primeiro na LCR delta, entao e possıvelque o perıodo de validade do certificado expire antes da proxima LCR completa, para omesmo escopo, ser emitida. Neste caso, o aviso de revogacao e incluıdo em, no mınimo,uma LCR completa emitida explicitamente para este escopo.

Uma aplicacao que suporte LCR delta DEVE ser capaz de construir uma LCR completaatualizada, combinando a LCR completa emitida previamente e a LCR delta mais atual.Uma aplicacao que suporte LCR delta PODE tambem ser capaz de construir uma LCRcompleta atual pela combinacao de uma LCR completa construıda localmente e a LCRdelta atual. Uma LCR delta e considerada ser a atual se o tempo no momento estiver entreos tempos contidos nos campos thisUpdate e nextUpdate. Sob certas circunstancias, oemissor de LCR pode publicar uma ou mais LCRs delta antes do tempo indicado no camponextUpdate. Se mais de uma LCR delta atual para um mesmo escopo for encontrada, aaplicacao DEVERIA considerar aquela com o ultimo valor em thisUpdate como sendo amais atualizada.

id-ce-deltaCRLIndicator OBJECT IDENTIFIER ::= { id-ce 27 }

BaseCRLNumber ::= CRLNumber

5.2.5 Issuing Distribution Points

A issuing distribution point e uma extensao crıtica de LCR que identifica os pontos dedistribuicao da LCR e o escopo para uma LCR especıfica, e indica se se a LCR cobre re-vogacao apenas para certificados de entidade final, apenas para certificados de AS, apenascertificados de atributo, ou um conjunto limitado de codigos razao. Embora a extensaoseja crıtica, implementacoes em conformidade nao sao obrigadas a suportar esta extensao.Entretanto, as implementacoes que nao suportarem esta extensao DEVEM tanto tratar oestado de revogacao de qualquer certificado nao listado nesta LCR como desconhecido oulocalizar uma outra LCR que nao contenha qualquer extensao crıtica nao reconhecida.

A LCR e assinada usando a chave privada do emissor da LCR. Os pontos de distribuicao deLCR nao possuem seus proprios pares de chave. Se a LCR for armazenada em um diretorioX.500, ela e gravada em uma entrada do diretorio correspondendo ao ponto de distribuicaoda LCR, que pode ser diferente da entrada de diretorio do emissor da LCR.


Ern

andes

57


Os codigos razao associados com um ponto de distribuicao DEVE ser especificado em only-SomeReasons. Se onlySomeReasons nao aparece, o ponto de distribuicao DEVE conterrevogacoes para todos os codigos razao. ACs podem usar os pontos de distribuicao paraparticionar a LCR com base nos compromissos e rotinas de revogacao. Neste caso, as re-vogacoes com codigos razao keyCompromise (1), cACompromise (2), e aACompromise (8)aparecem em um ponto de distribuicao, e as revogacoes com outros codigos razao aparecemem outro ponto de distribuicao.

Se uma LCR incluir uma extensao issuingDistributionPoint com onlySomeReasons pre-sente, entao todo certificado no escopo da LCR que estiver revogado DEVE ter uma razaode revogacao associada, diferente de nao especificado. A razao de revogacao associada eusada para determinar em qual LCR(s) listar o certificado revogado, embora, nao existarequisito para incluir a extensao de entrada na LCR reasonCode na entrada LCR corres-pondente.

A sintaxe e a semantica para o campo distributionPoint sao as mesmas utilizadas para ocampo distributionPoint na extensao cRLDistributionPoints (secao 4.2.1.13). Se o campodistributionPoint estiver presente, entao ele DEVE incluir no mınimo um dos nomes parao campo distributionPoint correspondente a extensao cRLDistributionPoints de todo cer-tificado que esteja dentro do escopo desta LCR. Uma codificacao identica DEVE ser usadanos campos distributionPoint do certificado e da LCR.

Se o escopo da LCR incluir apenas certificados emitidos pelo emissor da LCR, entao aocampo booleano de indirectCRL, DEVE ser atribuıdo o valor FALSE. De outra forma, seo escopo da LCR incluir certificados emitidos por uma ou mais autoridades distintas doemissor da LCR, ao campo booleano indirectCRL deve ser atribuıdo o valor TRUE. a au-toridade responsavel por cada entrada e indicada pelo emissor do certificado na entrada daextensao na LCR (secao 5.3.3).

Se o escopo da LCR incluir apenas certificados de chave publica de entidade final, entao,onlyContainsUserCerts DEVE ter o valor TRUE. Se o escopo da LCR incluir apenas certi-ficados de AC, entao deve ser atribuıdo o valor TRUE ao campo onlyContaisCACerts. Setanto onlyContainsUserCerts ou onlyContainsCACerts tiverem o valor TRUE, entao o es-copo da LCR NAO DEVE incluir qualquer certificado com versao 1 ou versao 2. Emissoresde LCR em conformidade DEVEM atribuir o valor FALSE ao campo onlyContainsAttri-buteCerts.

Emissores de LCR em conformidade NAO DEVEM emitir LCRs onde a codificacao DERda extensao issuing distribution point e uma sequencia vazia. Ou seja, se onlyContainsU-serCerts, onlyContainsCACerts indirectCRL, e onlyContainsAttributeCerts tiverem todoso valor FALSE, entao ou o campo distributionPoint ou onlySomeReasons DEVE estarpresente.

id-ce-issuingDistributionPoint OBJECT IDENTIFIER ::= { id-ce 28 }

IssuingDistributionPoint ::= SEQUENCE {


onlyContainsUserCerts [1] BOOLEAN DEFAULT FALSE,

onlyContainsCACerts [2] BOOLEAN DEFAULT FALSE,

onlySomeReasons [3] ReasonFlags OPTIONAL,


Ern

andes

58


indirectCRL [4] BOOLEAN DEFAULT FALSE,

onlyContainsAttributeCerts [5] BOOLEAN DEFAULT FALSE }

-- at most one of onlyContainsUserCerts, onlyContainsCACerts,

-- and onlyContainsAttributeCerts may be set to TRUE.

5.2.6 Freshest CRL (Ponto de Distribuicao de LCR delta)

A extensao freshest CRL identifica como a informacao da LCR delta para a LCR completae obtida. Emissores de LCR em conformidade DEVEM marcar esta extensao como nao-crıtica. Esta extensao NAO DEVE aparecer em LCRs delta.

A mesma sintaxe utilizada para a extensao de certificado cRLDistributionPoints e utilizadanesta extensao, e esta descrita na secao 4.2.1.13. Embora, apenas o campo distributionpoint e significativo neste contexto. Os campos reasons e cRLIssuer DEVEM ser omitidosnesta extensao de LCR.

Cada nome de ponto de distribuicao fornece a localizacao na qual a LCR delta para a LCRcompleta pode ser encontrada. O escopo dessas LCRs delta DEVE ser o mesmo escopo daLCR completa. Os conteudos desta extensao de LCR sao usados apenas para localizacaode LCRs delta, os conteudos nao sao usados para validar a LCR ou para referenciar LCRsdelta. As convencoes de codificacao definidas para distribution points na secao 4.2.1.13tambem se aplicam a esta extensao.



5.2.7 Authority Informatioin Access

Esta secao define o uso da extensao Authority Information Access na LCR. A sintaxe e asemantica definidas na secao 4.2.2.1 para a extensao em certificado tambem sao utilizadaspara esta extensao na LCR.

Esta extensao de LCR DEVE ser marcada como nao-crıtica.

Quando presente em um LCR, esta extensao DEVE incluir no mınimo um AccessDescrip-tion especificando id-ad-caIssuers como o accessMethod. O OID id-ad-caIssuers e usadoquando a informacao disponıvel lista certificados que podem ser utilizados para verificar aassinatura na LCR (ex: certificados cujo nome do sujeito correspondem ao nome do emis-sor na LCR e que um chave publica do sujeito correspondente a chave privada utilizadapara assinar a LCR). Tipos de metodo de acesso diferente de id-ad-caIssuers NAO DEVEMser incluıdos. No mınimo uma instancia de AccessDescription DEVERIA especificar umaccessLocation para URI HTTP [RFC2616] ou LDAP [RFC4516].

Quando a informacao estiver disponıvel via HTTP ou FTP, o accessLocation DEVE serum uniformResourceIdentifier e a URI DEVE apontar para um unico certificado codificadoem DER como especificado em [RFC2585] ou uma colecao de certificados codificados emBER ou DER de uma mensagem CMS “certs-only” como especificado em [RFC2797].


Ern

andes

59


Aplicacoes em conformidade que suportam HTTP ou FTP para acessar certificados DE-VEM ser capazes de aceitar certificados individuais codificados em DER e DEVERIAM sercapazes de aceitar mensagens CMS “certs-only”.

Implementacoes de servidor HTTP acessados via URI DEVERIAM especificar o tipo demeio application/pki-cert [RFC2585] no campo content-type do cabecalho de mensagensde resposta para um unico certificado codificado em DER e DEVERIA especificar o tipode meio application/pkcs7-mime [RFC2797] no campo content-type do cabecalho da men-sagens de resposta CMS “certs-only”. Pra FTP, o nome do arquivo que contem um unicocertificado codificado em DER DEVERIA ter o sufixo “.cer” [RFC2585] e o nome de umarquivo que contenha o sufixo “.p7c” para arquivos que contenham mensagem CMS “certs-only” [RFC2797]. Cliente consumidores podem usar o tipo meio ou extensao de arquivocomo um indicador para o conteudo, mas nao deveriam depender somente da presenca deum tipo de meio correto ou extensao de arquivo constante na resposta do servidor.

Quando o accessLocation e um directoryName, a informacao pode ser obtida pela apli-cacao a partir de qualquer servidor de diretorio, e uma configuracao local. Quando umachave publica de AC e usada para validar assinaturas em certificados e LCRs, o respectivocertificado de AC e guardado nos atributos crossCertificatePair e/ou cACerttificate comoespecificado em [RFC4523]. Quando chaves publicas distintas forem utilizadas para validarassinaturas em certificados e LCRs, o respectivo certificado e guardado no atributo user-Certificate como especificado em [RFC4523]. Assim, implementacoes que suportem a formadirectoryName de accessLocation DEVEM ser preparadas para encontrar o certificado ne-cessario em algum desses tres atributos. O protocolo que a aplicacao usa para acessar odiretorio (ex: DAP ou LDAP) e definido localmente.

Quando a informacao estiver disponıvel atraves de LDAP, o accessLocation DEVERIAser um uniformResourceIdentifier. A URI LDAP [RFC4516] DEVE incluir um campo<dn> contendo o nome distinto da entrada que contem o certificado, DEVE incluir umcampo <attributes> que lista descritores apropriados de atributo para os atributos quecontem os certificados codificados em DER ou pares de certificados cruzados [RFC4523].e DEVERIAM incluir um <host> (ex: <ldap://ldap.example.com/cn=CA,dc=example,dc=com?cACertificate;binary,crossCertificatePair;binary>). Omitir o <host> (ex: <ldap:///cn=exampleCA,dc=example,dc=com?cACertificate;binary>) tem o efeito de confiar emqualquer conhecimento previo que o cliente possa ter para contactar o servidor apropriado.

5.3 Extensoes da Entrada da LCR

As extensoes das entradas da LCR definidas para LCRs X.509 v2 pela ISO/IEC, ITU-T eANSI-X9 fornece metodos para associacao de atributos adicionais com as entradas da LCR[X.509] [X9.55]. O formato da LCR X.509 v2 tambem permite que comunidades especıficasdefinam extenso0es privadas para entradas da LCR para transmitir informacoes relevantesaquelas comunidades. Cada extensao na entrada da LCR pode designada como crıtica ounao-crıtica. Se uma LCR tiver uma extensao de entrada da LCR crıtica que a aplicacao naopossa processar, entao a aplicacao NAO DEVE usar esta LCR para determinar o estado derevogacao de qualquer certificado. Entretanto, as aplicacoes podem ignorar extensoes dasentradas de LCR marcadas como nao-crıticas.

As subsecoes seguintes apresentam as extensoes recomendadas para serem utilizadas nas en-tradas de LCR Internet e os locais padrao para informacao. Comunidades especıficas podem


Ern

andes

60


usar extensoes das entradas da LCR adicionais; entretanto, isso deve ser feito com muitocuidado quando se tratar de extensoes crıticas que podem ser usadas em um contexto geral.

O suporte as extensoes das entradas da LCR definidas nesta especificacao e opcional paraemissores de LCR e aplicacoes em conformidade. No entanto, os emissores de LCR DEVE-RIAM incluir codigos razao (reason code) (secao 5.3.1) e datas de invelidez (secao 5.3.2)sempre que esta informacao estiver disponıvel.

5.3.1 Reason Code

A extensao reasonCode e uma extensao nao-crıtica para entrada da LCR que identifica arazao para a revogacao do certificado. Os emissores de LCR sao incentivados a incluıremcodigos razao significativos na entradas da LCR; no entanto, o codigo razao da extensaoda entrada da LCR DEVERIA estar ausente ao inves do uso do valor unspecified (0) parareasonCode.

O valor de reasonCode igual a removeFromCRL (8) apenas pode ocorrer em LCRs delta eindica que um certificado esta para ser removido da LCR devido ou a expiracao do certi-ficado ou que nao esta mais suspenso. Todos os outros codigos razao podem aparecer emqualquer LCR e indica que o certificado especificado deveria ser considerado revogado.

id-ce-cRLReasons OBJECT IDENTIFIER ::= { id-ce 21 }

-- reasonCode ::= { CRLReason }

CRLReason ::= ENUMERATED {

unspecified (0),

keyCompromise (1),

cACompromise (2),


superseded (4),



-- value 7 is not used

removeFromCRL (8),


aACompromise (10) }

5.3.2 Invalidity Date

A extensao invalidity date, da entrada da CLR, e uma extensao nao-crıtica que fornecea data na qual a chave privada foi considerada comprometida ou considerada suspeita deestar comprometida, ou caso contrario, que ele se tornou invalida. Esta e a data pode seranterior a data de revogacao na entrada da LCR, que e a data na qual a AC processou arevogacao. Quando uma revogacao e publicada primeiro pelo emissor de LCR, na LCR, adata de invalidez do certificado pode preceder a data da emissao das LCRs mais recentes,mas a data de revogacao NAO DEVERIA preceder a data da emissao das ultimas LCRs.Sempre que esta informacao estiver disponıvel, e fortemente sugerido aos emissores de LCR


Ern

andes

61


que compartilhem a informacao com os usuarios de LCR.

Os valores GeneralizedTime incluıdos neste campo DEVEM ser expressos em GreenwichMean Time (Zulu), e DEVEM ser especificado e interpretados como definido na secao4.1.2.5.2.

id-ce-invalidityDate OBJECT IDENTIFIER ::= { id-ce 24 }

InvalidityDate ::= GeneralizedTime

5.3.3 Certificate Issuer

Esta extensao de entrada da LCR identifica o emissor do certificado associado com a entradaem uma LCR indireta, ou seja, a LCR que tem o indicador indirectCRL ativado na extensaoissuing distribution point. Quando presente, a extensao da entrada certificate issuer da LCRinclui um ou mais nomes da extensao issuer e/ou issuer alternative name do certificado quecorresponde a entrada LCR. Se esta extensao nao estiver presente na primeira entradade uma entrada LCR, o emissor padrao para certificate issuer e o emissor da LCR. Nasentradas subsequentes da LCR indireta, se esta extensao nao estiver presente, o emissor docertificado para a entrada, e o mesmo da entrada precedente. Este campo e definido daseguinte forma:

id-ce-certificateIssuer OBJECT IDENTIFIER ::= { id-ce 29 }

CertificateIssuer ::= GeneralNames

Emissores de LCR em conformidade DEVEM incluir nesta extensao o nome distinto (DN)do campo issuer do certificado correspondente a esta entrada da LCR. A codificacao do DNDEVE ser igual aquela usada no certificado.

Os emissores de LCR DEVEM marcar esta extensao como crıtica desde que implemen-tacoes que ignoram esta extensao poderiam nao atribuir corretamente entradas da LCRa certificados. Este especificacao RECOMENDA que as implementacoes reconhecam estaextensao.

6 Validacao de Caminho de Certificacao

Os procedimentos de validacao de caminho para ICP Internet sao baseados no algoritmofornecido em [X.509]. O processamento do caminho de certificacao verifica a associacaoentre o nome distinto ou nome alternativo do sujeito e a chave publica do sujeito. A asso-ciacao e limitada pelas restricoes especificadas nos certificados que compoem o caminho einsumos especificados pela terceira parte confiavel. As extensoes basic constraints e policyconstraints permitem a logica de processamento de caminho de certificacao automatizar oprocesso de tomada de decisao.

Esta secao descreve um algoritmo para validacao de caminhos de certificacao. Nao e so-licitado as implementacoes em conformidade desta especificacao implementarem este al-goritmo, mas DEVEM fornecer funcionalidade equivalente para o comportamento externoresultante deste procedimento. Qualquer algoritmo pode ser usado por uma implementacao


Ern

andes

62


em particular, desde que derivem o resultado correto.

Na secao 6.1, o texto descreve a validacao basica de caminho. Os caminhos basicos co-mecam com certificados emitidos por uma ancora confiavel. O algoritmo requer a chavepublica da AC, o nome da CA, e qualquer restricao sobre o conjunto de caminhos quepodem ser validados usando esta chave.

A selecao de uma ancora de confianca e uma questao de polıtica: pode ser a AC que seencontra no topo de uma ICP hierarquica, a AC que emitiu o(s) proprio(s) certificado(s),ou qualquer AC em uma rede de ICP. O procedimento de validacao de caminho e o mesmoindependente da escolha da ancora de confianca. Adicionalmente, aplicacoes diferentes po-dem confiar em diferentes ancoras de confianca, ou podem aceitar caminhos que comecemcom qualquer uma em um conjunto de ancoras de confianca.

A secao 6.2 descreve metodos para utilizacao do algoritmo de validacao de caminho emimplementacoes especıficas.

A secao 6.3 descreve os passos necessarios para determinar se um certificado esta revogadoquando LCRs sao o mecanismo de revogacao usado pelo emissor do certificado.

6.1 Validacao Basica de Caminho

Este texto descreve um algoritmo para o processamento de caminhos X.509. Um imple-mentacao em conformidade DEVE incluir um procedimento de processamento de caminhoque seja funcionalmente equivalente ao comportamento externo deste algoritmo. No en-tanto, o suporte para algumas extensoes processadas por este algoritmo seja OPCIONALpara implementacoes em conformidade. Os clientes que nao suportarem essas extensoesPODEM omitir os passos correspondentes no algoritmo de validacao de caminho.

Por exemplo, nao e requerido que os clientes suportem a extensao policy mappings. Osclientes que nao tiverem suporte a esta extensao PODEM omitir os passos da validacaode caminho nos quais esta extensao e processada. Note que os clientes DEVEM rejeitar ocertificado se ele tiver uma extensao crıtica nao suportada.

Enquanto o perfil para certificado e LCR especificados nas secoes 4 e 5 deste documentoespecificam valores para campos de certificados e LCRs e para extensoes que sao conside-radas apropriadas para ICP Internet, o algoritmo apresentado nesta secao nao e limitadoesta limitado a aceitacao de certificados e LCRs que estao em conformidade com este perfil.Portanto, o algoritmo apenas inclui a checagem para verificacao da validade do caminhode certificacao de acordo com o X.509 e nao inclui checagem para verificacao da confor-midade dos certificados e LCRs com o perfil. Embora o algoritmo pudesse ser estendidopara incluir checagem de conformidade com os perfis definidos nas secoes 4 e 5, este perfilRECOMENDA que nao sejam incluıdos tais verificacoes.

O algoritmo apresentado nesta secao valida o certificado no que diz respeito a data e horaatual. Uma implementacao em conformidade PODE tambem suportar validacao com res-peito a algum momento no passado. Note que os mecanismos nao sao disponibilizados paraa validacao de um certificado no que diz respeito ao tempo fora do perıodo de validade docertificado.


Ern

andes

63


A ancora de confianca e uma entrada para o algoritmo. Nao ha requisito para que a mesmaancora de confianca seja utilizada para validar todos os caminhos de certificacao. Ancorasde confianca distintas PODEM ser utilizadas para validar diferentes caminhos, como dis-cutido adiante na secao 6.2.

A primeira meta da validacao de caminho e verificar a associacao entre o nome distinto deum sujeito ou o seu nome alternativo e a chave publica do sujeito, como representado nocertificado alvo, baseado na chave publica de uma ancora de confianca. Na maioria doscasos, o certificado alvo sera um certificado de entidade final, mas o certificado alvo podeser um certificado de AC contanto que a chave publica ocorra para ser utilizada para umproposito diferente da verificacao de assinatura em um certificado de chave publica. A ve-rificacao da associacao entre o nome e a chave publica do sujeito requer a obtencao de umasequencia de certificados que dao suporte a esta associacao. O procedimento executadopara obter esta sequencia de certificados esta fora do escopo desta especificacao.

Para satisfazer esta meta, o processo de validacao de caminho verifica, entre outras coisas,que um caminho de certificacao prospectivo (uma sequencia de n certificados) satisfaz asseguintes condicoes:

(a) para todo x em {1, ..., n-1}, o sujeito do certificado x seja o emissor do certificadox+1;

(b) o certificado 1 seja emitido pela ancora de confianca;

(c) o certificado n seja o certificado a ser validado (ex: o certificado alvo); e

(d) para todo x em {1, ..., n} o certificado era valido no tempo em questao.

Um certificado NAO DEVE aparecer mais que uma vez em um caminho de certificacaoprospectivo.

Quando uma ancora de confianca for provida na forma de um certificado auto-assinado, estecertificado auto-assinado nao e incluıdo como parte do caminho prospectivo de certificacao.Informacao sobre ancoras de confianca sao fornecidas como entrada para o algoritmo devalidacao de caminho de certificacao (secao 6.1.1).

Um caminho de certificacao particular nao deve, contudo, ser apropriado para todas asaplicacoes. Portanto, uma aplicacao PODE aumentar este algoritmo para um limite supe-rior aquele estabelecido para o conjunto de caminhos validos. O processo de validacao docaminho tambem determina o conjunto de polıticas de certificado que sao validas para estecaminho, baseado na extensao certificate policies, na extensao policy mappings, na exten-sao policy constraints e na extensao inhibit anyPolicy. Para alcancar isso, o algoritmo decaminho de validacao constroi uma arvore de polıtica valida. Se o conjunto de polıticas decertificado que sao validas para este caminho nao estiver vazio, entao o resultado sera umaarvore de polıtica valida de profundidade n, de outra forma o resultado sera uma arvore depolıtica valida nula.

Um certificado e auto-assinado se o mesmo DN aparecer tanto no campo subject como nocamo issuer (os dois DNs sao os mesmos se eles corresponderem de acordo com as regrasespecificadas na secao 7.1). Em geral, o emissor e o sujeito do certificado que formam ocaminho sao diferentes para cada certificado. Embora, uma AC possa emitir um certificado


Ern

andes

64


para ela mesma para suportar a atualizacao de chave ou modificacao nas polıticas de cer-tificado. Esses certificados auto-assinados nao sao contados na avaliacao do comprimentodo caminho ou para restricoes de nome.

Esta secao apresenta o algoritmo em quatro passos basicos: (1) inicializacao, (2) processa-mento basico de certificado, (3) preparacao para o proximo certificado, e (4) encerramento.Os passos (1) e (4) sao executados exatamente uma vez. O passo (2) e executado paratodos os certificados no caminho. O passo (3) e executado para todos os certificados nocaminho exceto para o certificado final. A figura 2 fornece um fluxograma deste algoritmo.

+--------+

| INICIO |

+--------+

|

V

+-----------------+

| Inicializac~ao |

+-----------------+

|

+<---------------------------+

| |

V |

+-------------------------+ |

| Processar Certificado | |

+-------------------------+ |

| |

V |

+========================+ |

| SE Ultimo Certificado | |

| no Caminho | |

+========================+ |

| | |

ENT~AO | | SEN~AO |

V V |

+--------------+ +---------------------+ |

| Encerramento | | Preparar para | |

+--------------+ | Proximo Certificado | |

| +---------------------+ |

V | |

+------+ +-------------+

| PARE |

+------+

Figura 2: Fluxograma do Processamento do Caminho de Certificacao

6.1.1 Entradas

Este algoritmo considera que as seguintes nove entradas sao fornecidas para a logica deprocessamento do caminho:


Ern

andes

65


(a) um caminho de certificacao prospectivo de comprimento n.

(b) a data/tempo atual.

(c) user-initial-policy-set: um conjunto de identificadores de polıtica de certificado queda nome as polıticas aceitaveis para o usuario do certificado. O user-initial-policy-set contem o valor especial any-policy quando o usuario nao faz referencia a polıticade certificado.

(d) informacao sobre a ancora de confianca, descrevendo uma AC que serve comoancora de confianca para o caminho de certificacao. A informacao sobre a ancorade confianca inclui:

(1) o nome confiavel do emissor,

(2) o algoritmo confiavel de chave publica,

(3) a chave publica confiavel, e

(4) opcionalmente, os parametros confiaveis de chave publica associados achave publica.

A informacao da ancora confiavel pode ser fornecida ao procedimento de processa-mento do caminho na forma de um certificado auto-assinado. Quando a informacaoda ancora de confianca for fornecida na forma de um certificado, o nome no camposubject e usado como o nome confiavel do emissor e o conteudo do campo sub-jectPublicKeyInfo e usado como fonte para o algoritmo confiavel de chave publicae a chave publica confiavel. A informacao confiavel da ancora e confiavel porquefoi entregue ao procedimento de processamento por algum procedimento externoconfiavel. Se o algoritmo de chave publica confiavel requerer parametros, entao osparametros serao fornecidos juntamente com a chave publica confiavel.

(e) initial-policy-mapping-inhibit, que indica se a o mapeamento de polıtica e permi-tido no caminho de certificacao.

(f) initial-explicit-policy, que indica se o caminho deve ser valido para no mınimo umadas polıticas de certificado contidas em user-initial-policy-set.

(g) initial-any-policy-inhibit, que indica se o OID anyPolicy deveria ser processadoquando incluıdo no certificado.

(h) initial-permitted-subtrees, que indica para cada tipo de nome (ex: nomes distintosX.500, enderecos de email, ou enderecos IP) um conjunto de sub-arvores no qualtodos os nomes de sujeito em todos os certificados do caminho DEVEM corres-ponder. A entrada initial-permitted-subtree inclui um conjunto para cada tipo denome. Para cada tipo de nome, o conjunto pode consistir de uma unica sub-arvoreque inclui todos os nome de um tipo name ou uma ou mais sub-arvores nas quaisespecifica um sub-conjunto de nomes do tipo name, ou o conjunto pode ser vazio.Se o o conjunto para um tipo name for vazio, entao o caminho de certificacao seraconsiderado invalido se qualquer certificado no caminho de certificacao incluir umnome daquel tipo name.

(i) initial-excluded-subtrees, que indica para cada tipo name (ex: nomes distintosX.500, enderecos de email, ou enderecos IP) um conjunto de sub-arvores dentro do


Ern

andes

66


qual cada nenhum nome de sujeito de qualquer certificado no caminho de certifi-cacao pode pertencer. A entrada initial-excluded-subtrees inclui um conjunto paracada tipo nome. Para cada tipo nome, o conjunto pode ser vazio ou pode consistirde uma ou mais sub-arvores onde, cada uma delas especifica um sub-conjunto denomes daquele tipo nome. Se o conjunto para o tipo nome for vazio, entao nenhumnome daquele tipo nome e excluıdo.

Nao e demandado as implementacoes em conformidade suportarem o conjunto de todasessas entradas. Por exemplo, uma implementacao em conformidade pode ser designadapara validar todos os caminhos de certificacao usando um valor FALSE para initial-any-policy-inhibit.

6.1.2 Inicializacao

A fase de inicializacao estabelece onze estados variaveis baseados nas nove entradas:

(a) valid policy tree: Uma arvore de polıticas de certificado com seus qualificadoresopcionais; cada uma das folhas da arvore representam uma polıtica valida nestafaze da validacao do caminho de certificacao. Se uma polıtica valida existe nessafase da validacao do caminho de certificacao, a profundidade da arvore e igualao numero de certificados na cadeia que esta sendo processada. Se nao existirempolıticas validas nesta fase da validacao do caminho de certificacao, a arvore edefinida como NULL (nula). Uma vez que a arvore seja definida como NULL, oprocessamento de polıtica e encerrado.

Cada nodo na valid policy tree inclui tres objetos de dados: a polıtica valida, umconjunto de qualificadores associados a polıtica, e um conjunto de um ou mais va-lores esperados para a polıtica. Se o nodo possui a profundidade x, os componentesdo nodo tem a seguinte semantica:

(1) A valid policy e um OID unico de polıtica que representa uma polıticavalida para o caminho de comprimento x.

(2) O qualifier set e um conjunto de qualificadores de polıtica associados coma polıtica valida do certificado x.

(3) O expected policy set contem um ou mais OIDs de polıtica que satisfariaesta polıtica no certificado x+1.

O valor inicial de valid policy tree e um nodo unico com valid policy anypolicy,um conjunto vazio de qualifier set, e um expected policy set com o valor anyPolicyunico. A profundidade deste nodo e considerada como zero.

A figura 3 e uma representacao grafica do estado inicial da valid policy tree. Fi-guras adicionais usarao este formato para descrever mudancas na valid policy treedurante o processamento do caminho.

(b) permitted subtree: um conjunto de nomes raiz para cada tipo de nome (ex: nomesdistintos X.500, enderecos de email, ou enderecos IP) que definem um conjunto desub-arvores nas quais todos os nomes de sujeito nos certificados subsequentes nocaminho de certificacao DEVEM ocorrer. Esta variavel inclui um conjunto paracada tipo de nome, e o valor inicial e initial-permitted-subtrees.


Ern

andes

67


+--------------+

| anyPolicy | <------ valid_policy

+--------------+

| {} | <------ qualifier_set

+--------------+

| {anyPolicy} | <------ expected_policy_set

+--------------+

Figura 3: Valor Inicial da Variavel de Estado valid policy tree

(c) excluded subtrees: um inteiro que indica se e necessario uma valid policy tree non-NULL (nao nula). O inteiro indica o numero de certificados nao-auto-assinados aserem processados antes deste requisito ser imposto. Uma vez estabelecida, estavariavel pode ser decrementada, mas nao pode ser incrementada. Ou seja, se umcertificado no caminho requer uma valid policy tree nao nula, um certificado pos-terior nao pode remover este requisito. Se a initial-explicit-policy estiver definida,entao o valor inicial e 0, de outra forma o valor inicial e n+1.

(d) inhibit anyPolicy: um inteiro que indica se o identificador de polıtica anyPolicye considerado na correspondencia. O inteiro indica o numero de certificados nao-auto-assinados a serem processados antes do OID anyPolicy, se atribuıdo em umcertificado diferente de um certificado intermediario auto-assinado, e ignorado.Uma vez definida, esta variavel pode ser decrementada, mas nao pode ser in-crementada. Ou seja, se um certificado no caminho inibir o processamento deanyPolicy, um certificado posterior nao podera permiti-lo. Se a initial-any-policy-inhibit estiver definida, entao o valor inicial e 0, de outra forma, o valor inicial en+1.

(e) policy mapping: um inteiro que indica se o mapeamento de polıtica e permitido.O inteiro indica o numero de certificados nao-auto-assinados a serem processadoantes do mapeamento de polıtica ser inibido. Um vez definida, esta variavel podeser decrementada, mas nao pode ser incrementada. Ou seja, se um certificado nocaminho especificar que o mapeamento de polıtica nao e permitido, esta definicaonao podera ser substituıda por um certificado posterior da cadeia. Se a variavelinitial-policy-mapping-inhibit for definida, entao o valor inicial e 0, de outra formao valor inicial e n+1.

(f) working public key algorithm: e o algoritmo de assinatura digital utilizado paraverificar a assinatura do certificado. A variavel working public key algorithm einicializada a partir do algoritmo de chave publica confiavel fornecido na informacaoda ancora de confianca.

(g) working public key: a chave publica usada para verificar a assinatura de um certi-ficado. A variavel working public key e inicializada com a chave publica confiavelfornecida na informacao da ancora de confianca.

(h) working public key parameters: parametros associados a chave publica atual quepode ser requerido para verificar uma assinatura (dependendo do algoritmo). Avariavel working public key parameters e inicializada a partir dos parametros dechave publica confiavel fornecidos pela informacao da ancora confiavel.


Ern

andes

68


(i) working issuer name: o nome distinto de emissor esperado no proximo certificadoda cadeia. A variavel working issuer name e inicializada com o nome de emissorconfiavel fornecido na informacao da ancora confiavel.

(j) max path length: este inteiro e inicializado com n, e decrementado para cadacertificado nao-auto-assinado do caminho, e pode ser reduzido ao valor constantedo campo path length constraint da extensao basic constraints de um certificadode AC.

Apos a conclusao das etapas de inicializacao, execute as etapas basicas de processamentode certificados especificadas em 6.1.3.

6.1.3 Processamento Basico de Certificado

As acoes de processamento basico de caminho a serem executadas para certificado i (paratodo i em [1..n]) sao listadas abaixo:

(a) Verificar a informacao basica do certificado. O certificado DEVE satisfazer a cadauma das seguintes condicoes:

(1) A assinatura no certificado pode ser verificada usando as variaveis wor-king public key algorithm, working public key, e working public key para-meters.

(2) O perıodo da validade do certificado inclui a data atual.

(3) No tempo atual, o certificado nao estar revogado. Isto pode ser determi-nado pela obtencao da LCR apropriada (secao 6.3), pela informacao deestado, ou por outro mecanismo externo.

(4) O nome do emissor do certificado e o working issuer name.

(b) Se o certificado i e auto-emitido e ele nao e certificado final no caminho, pule estepasso para o certificado i. De outra forma, verifique se o nome do sujeito nao se en-contra dentro de qualquer nome constante na variavel excluded subtree para nomesdistintos X.500, e verifique que cada um dos nomes alternativos na extensao sub-jectAltName (crıtica ou nao-crıtica) nao esteja em qualquer dos excluded subtreespara este tipo nome.

(c) Se a extensao certificate policies estiver presente no certificado e a variavel va-lid policy tree nao tiver o valor Null, processe a informacao de polıtica executandoos seguintes passos, na ordem a seguir:

(1) Para cada polıtica P nao igual a anyPolicy na extensao certificate poli-cies, tenha P-OID denotando a polıtica P e P-Q denotando o conjuntoqualificado para a polıtica P. Execute os seguintes passos, na ordem deapresenta cao:

(i) Para cada nodo de profundidade i-1 na valid policy tree onde P-OID esta no expected policy set, crie um nodo filho da seguinteforma: defina o valid policy para P-OID, defina o conjunto quali-ficado para P-Q e defina o expected policy set para {P-OID}.


Ern

andes

69


Por exemplo, considere uma valid policy tree com um nodo deprofundidade i-1 onde expected policy set seja {Gold,White}. Con-sidere que as polıticas de certificado Gold e Silver aparecam naextensao certificate policies do certificado i. A polıtica Gold cor-responde, mas a polıtica Silve nao. Esta regra criara um nodofilho, de profundidade i, para a polıtica Gold. O resultado e mos-trado na figura 4.

+---------------+

| Red |

+---------------+

| {} |

+---------------+ nodo de profundidade i-1

| {Gold, White} |

+---------------+

|

|

|

V

+---------------+

| Gold |

+---------------+

| {} |

+---------------+ nodo de profundidade i

| {Gold} |

+---------------+

Figura 4: Processamento de uma Correspondencia Exata

(ii) Se nao ocorreu nenhuma correspondencia no passo (i) e a va-lid policy tree inclui um nodo de profundidade i-1 com a valid poli-cy igual a anyPolicy, crie um nodo filho com os seguintes valores:defina a variavel valid policy para P-OID, o conjunto qualificadopara P-Q, e o expected policy set para {P-OID}.

Por exemplo, considere uma valid policy tree com um nodo deprofunidade i-1 onde o valor de valid policy seja anyPolicy. Con-sidere que as polıticas de certificado Gold e Silver aparecem naextensao certificate policies do certificado i. A polıtica Gold naotem um qualificador, mas a polıtica Silver possui o qualificadorQ-Silver. Se Gold e Silver corresponderem em (i) acima, eta regracriara dois nodos filhos de profundidade i, um para cada polıtica.O resultado e mostrado na figura 5.

(2) Se a extensao certificate policies incluir a polıtica anyPolicy com o qualifi-cador definido AP-Q e ou (a) inhibit anyPolicy e maior que 0 ou (b) i<ne o certificado for auto-emitido, entao:

Para cada nodo no valid policy tree de profundidade i-1, para cada valorna expectec policy set (incluindo anyPolicy) que nao apareca em um nodofilho, crie um nodo filho com os seguintes valorres: defina valid policy com


Ern

andes

70


+---------------+

| anyPolicy |

+---------------+

| {} |

+---------------+ nodo de profundidade i-1

| {anyPolicy} |

+---------------+

/ \

/ \

/ \

/ \

+---------------+ +---------------+

| Gold | | Silver |

+---------------+ +---------------+

| {} | | {Q-Silver} |

+---------------+ nodo de +---------------+

| {Gold} | profundidade i | {Silver} |

+---------------+ +---------------+

Figura 5: Processamento Polıticas Nao-Correspondentes Quado um Nodo Folha EspecificaanyPolicy

o valor de expected policy set no nodo pai, defina qualifier set para AP-Q, e defina expected policy set para o valor de valid policy para este nodo.

Por exemplo, considere uma valid policy tree com um nodo de profundi-dade i-1 onde expected policy ser e {Gold, Silver}. Considere que any-Policy aparece na extensao certificate policies do certificado i sem quali-ficadores de polıtica, mas Gold e Silver nao aparecem. Esta regra criaradois nodos filhos de profundidade i, um para cada polıtica. O resultado emostrado abaixo, na figura 6.

(3) Se existir um nodo na valid policy tree de profundidade i-1 ou menor sequalquer nodo filho, apague este nodo. Repita este passo ate que naoexiste nodos de profundidade i-1 ou menor sem filho.

Por exemplo, considere oa valid policy tree mostrada na figura 7 abaixo.Os dois nodos na profundidade i-1 que estao marcados com um “X” naotem filhos, e eles sao apagados. Aplicando esta regra a arvore resultantecausara que os nodos na profundidade i-2 que estao marcados com “Y”sejam apagados. Na arvore resultante, nao ocorre nodos de profundidadei-1 ou menor sem filhos, e este passo e finalizado.

(4) Se a extensao certificate policies nao estiver presente, defina a variavelvalid policy tree como NULL.

(5) verifique que ou explicit policy seja maior que o ou que valid policy treenao seja igual a NULL.

Se qualquer dos passos (a), (b), (c), ou (f) falhar, o procedimento terminara, re-tornando um indicador de falha e uma razao apropriada.


Ern

andes

71


+----------------+

| anyPolicy |

+----------------+

| {} |

+----------------+ nodo de profundidade i-1

| {Gold, Silver} |

+----------------+

/ \

/ \

/ \

/ \

+---------------+ +---------------+

| Gold | | Silver |

+---------------+ +---------------+

| {} | | {} |

+---------------+ nodo de +---------------+

| {Gold} | profundidade i | {Silver} |

+---------------+ +---------------+

Figura 6: Processamento Polıticas Nao-Correspondentes Quando a Extensao CertificatePolicies Especifica anyPolicy

Se i nao for igual a n, continue executando os passos preparatorios listados na secao6.1.4. Se i for igual a n, execute o passo de encerramento listado na secao 6.1.5.

+----------------+

| anyPolicy | nodo de profundidade i-3

+----------------+

/ | \

/ | \

/ | \

+------------+ +------------+ +------------+

| | | | | Y | nodos de

+------------+ +------------+ +------------+ profundidade i-2

/ \ | |

/ \ | |

/ \ | |

+------------+ +------------+ +------------+ +------------+

| | | | | | | X | nodos de

+------------+ +------------+ +------------+ +------------+ profundidade i-1

| / | \

| / | \

| / | \

+------------+ +------------+ +------------+ +------------+

| | | | | | | X | nodos de

+------------+ +------------+ +------------+ +------------+ profundidade i

Figura 7: Podando a valid policy tree


Ern

andes

72


6.1.4 Preparacao para o Certificado i+1

Para preparar o processamento do certificado i+1, execute os seguintes passos para o cer-tificado i:

(a) Se a extensao policy mappings estiver presente, verifique que o valor especial any-Policy nao apareca como um issuerDomainPolicy ou um subjectDomainPolicy.

(b) Se a extensao policy mappings estiver presente, entao para cada issuerDomainPo-licy ID-P na extensao policy mappings:

(1) Se a variavel policy mapping for maior que 0, para cada nodo na va-lid policy tree de profundidade i onde ID-P e valid policy, defina expec-ted policy set com o conjunto dos valores subjectDomainPolicy que sejamespecificados como equivalente ao ID-P pela extensao policy mappings.

Se nehum nodo de profundidade i na valid policy tree tiver uma valid policyde ID-P mas existir um nodo de profundidade i com uma valid policy comvalor anyPolicy, entao crie um nodo filho de um nodo de profundidade i-1que tenha o valid policy com valor anyPolicy seguindo:

(i) defina a valid policy para ID-P;

(ii) defina o qualifier set para o conjunto de qualificadores da polıticaanyPolicy na extensao polıticas de certificado i, e

(iii) defina a expect policy set com o conjunto de valores subjectDo-mainPoliciy que sao especificados como equivalentes a ID-P pelaextensao policy-mappings.

(2) se a variavel policy mapping for igual a 0:

(i) apague cada nodo de profundidade i na valid policy tree onde ID-P seja a valid policy.

(ii) Se existir um nodo na valid policy tree de profundidade i-1 oumenor sem nenhum nodo filho, apague este nodo. Repita estepasso ate que nao existam nodos de profundidade i-1 ou menorsem nodos filhos.

(c) Atribua o nome do sujeito do certificado a working issuer name.

(d) Atribua subjectPublicKey do certificado a working public key.

(e) Se o campo subjectPublicKeyInfo do certificado tiver um campo algorithm comparametros null ou os parametros forem omitidos, atribua os parametros a variavelworking public key parameters.

Se o campo subjectPublicKeyInfo do certificado tiver um campo algorithm comparametros null ou os parametros forem omitidos, compare o campo subjectPu-blicKey algorithm ao working public key algorithm. Se o campo subjectPublicKeyalgorithm do certificado e o working public key algorithm forem diferentes, definaworking public key parameters como null.

(f) Atribua o algorithm subjectPublicKey do certificado a variavelworking public key algorithm.


Ern

andes

73


(g) Se a extensao name constraints estiver incluıda no certificado, modifique as varia-veis permitted subtree e excluded subtrees da seguinte forma:

(1) Se permittedSubtrees estiver presente no certificado, defina a variavel deestado permitted subtrees a interseccao do seu valor previo e o valor in-dicado no campo extensao. Se permittedSubtrees nao incluir um tiponome particular, a variaveis de estado permitted subtrees nao e modifi-cada para este tipo de nome. Por exemplo, a interseccao de example.come foo.example e foo.example.com. E a interseccao de example.com e exam-ple.net e um conjunto vazio..

(2) Se excludedSubtrees estiver presente no certificado, defina a variavel deestado excluded subtrees como a uniao do seu valor previo e o valor indi-cado no campo extensao. Se excludedSubtrees nao inclui um tipo nomeparticular, a variavel de estado excluded subtrees nao e modificada paraeste tipo nome. Por exemplo, a uniao dos espacos de nome example.com efoo.example.com e example.com. E a uniao de example.com e example.netseria os dois espacos de nome.

(h) Se o certificado i nao for auto-emitido:

(1) Se explicit policy nao for 0, decremente explicit policy de 1.

(2) Se policy mapping nao for 0, decremente policy mapping de 1.

(3) Se inhibit anyPolicy nao for 0, decremente inhibit anyPolicy de 1.

(i) Se a extensao policy constraints estiver incluıda no certificado, modifique as varia-veis de estado explicit policy e policy mapping da seguinte forma:

(1) Se requireExplicitPolicy estiver presente e for menor que explicit policy,defina explicit policy com o valor de requireExplicitPolicy.

(2) Se inhibitPolicyMapping estiver presente e for menor que policy mapping,defina policy mapping com o valor de inhibitPolicyMapping.

(j) Se a extensao inhibitAnyPolicy estiver incluıda no certificado e for menor queinhibit anyPolicy, defina inhibit anyPolicy com o valor de inhibitAnyPolicy.

(k) Se o certificado i tiver a versao 3 de certificado, verifique se a extensao basicCons-traints esta presente e que cA tem valor TRUE. (Se o certificado i for versao 1ou versao 2, entao a aplicacao DEVE ou verificar se o certificado i e um certifi-cado de AC atraves de meios externos ou rejeitar o certificado. Implementacoesem conformidade podem escolher rejeitar todas as versoes 1 e 2 em certificadosintermediarios.)

(l) Se o certificado nao tiver sido auto-emitido, verificar se max path lenght e maiorque 0 e decrementar max path length de 1.

(m) Se pathLenConstraints estiver presente no certificado e for menor que max path len-gth, defina max path lenght com o valor de pathLenConstraint.

(n) Se a extensao key usage estiver presente, verifique se o bit keyCertSign esta ativado.

(o) Reconhecer e processar qualquer outra extensao crıtica presente no certificado.Processar qualquer outra extensao nao-crıtica presente no certificado, que sejarelevante ao processamento do caminho.


Ern

andes

74


Se as verificacoes (1), (k), (l), (n) ou (o) falharem, o procedimento e finalizado, retornandouma indicacao de falha e uma razao apropriada.

Se (a), (k), (l), (n), e (o) forem completadas com sucesso, incremente i e execute o proces-samento basico de certificado especificado na secao 6.1.3.

6.1.5 Procedimento de Encerramento

Para completar o processamento do certificado alvo, execute os passos para o certificado n:

(a) Se explicit policy nao for 0, decremente explicit policy de 1.

(b) Se a extensao policy contraints estiver incluıda no certificado e requireExplicitPo-licy estiver presente e tiver o valor de 0, defina a variavel de estado explicit policycom o valor 0.

(c) Atribua o campo subjectPublicKey do certificado a variavel working public key.

(d) Se o campo subjectPublicKeyInfo do certificado tiver um campo algorithm com pa-rametros null (nulos) ou os parametros forem omitidos, compare subjectPublicKeyalgorithm do certificado com a variavel working public key algorithm. Se o camposubjectPublicKey algorithm do certificado e a variavel working public key algorithmforem diferentes, defina a variavel working public key parameters como null.

(e) Atribua o valor de subjectPublicKey algorithm do certificado a variavel working pu-blic key algorithm.

(f) Reconheca e processe qualquer outra extensao crıtica presente no certificado n.Processe qualquer outra extensao nao-crıtica presente no certificado n, que sejarelevante ao processamento do caminho.

(g) Calcule a interseccao de valid policy tree e user-initial-policy-set, da seguinte forma:

(i) Se a valid policy tree for NULL, a interseccao e NULL.

(ii) Se a valid policy nao for NULL e a user-initial-policy-set for any-policy, ainterseccao sera a valid policy tree completa.

(iii) Se a valid policy tree nao for NULL e a user-initial-policy-set nao for any-policy, calcule a interseccao de valid policy tree e user-initial-policy-setconforme:

1. Determine o conjunto de polıticas de nodos cujos nodos pais te-nham uma variavel valid policy do tipo anyPolicy. Este e o va-lid policy node set.

2. Se o valid policy de qualquer nodo no valid policy node set naoestiver em user-initial-policy-ser e nao for anyPolicy, apague estenodo e todos os nodos filhos.

3. Se valid policy tree inclui um nodo de profundidade n com o va-lid policy com valor anyPolicy e user-initial-policy-ser nao for any-policy, execute os seguintes passos:

a. Defina P-Q para o qualifier set no nodo de profundidaden com valid policy igual a anyPolicy.


Ern

andes

75


b. Para cada P-OID no user-initial-policy-set que nao foro valid policy de um nodo no valid policy node set, crieum nodo filho cujo parente seja o nodo de profundidaden-1 com valid policy igual a anyPolicy. Defina os valoresno nodo filho como a seguir: defina o valid policy paraP-OID, defina o qualifier set para P-Q, e defina a expec-ted policy ser para P-OID.

c. Apague o nodo de profundidade n com valid policy iguala anyPolicy.

4. Se existir um nodo na valid policy tree de profundidade n-1 oumenor sem qualquer nodo filho, apague este nodo. Repetir estepasso ate que nao existam nodos de profundidade n-1 ou menorsem filhos.

Se (1) o valor da variavel explicit policy e maior que zero ou (2) o valor da variavel va-lid policy tree nao e NULL, entao o processamento do caminho obteve sucesso.

6.1.6 Saıdas

Se o processamento do caminho obteve sucesso, o procedimento termina, retornando um in-dicador de sucesso junto com o valor final das variaveis valid policy tree, working public key,working public key algorithm, e working public key parameters.

6.2 Uso do Algoritmo de Validacao de Caminho

O algoritmo de validacao de caminho descreve o processo de validacao de um unico caminhode certificacao. Embora cada caminho de certificacao comece com uma ancora de confiancaespecıfica, nao ha exigencia de que todos os caminhos de certificacao validados por umsistema particular compartilhem a mesma ancora de confianca. A selecao de uma ou maisACs confiaveis e uma decisao local. Um sistema pode fornecer qualquer uma das suas ACsconfiaveis como a ancora de confianca para um caminho particular. As entradas para oalgoritmo de validacao de caminho podem ser diferente para cada caminho. As entradasutilizadas para processar um caminho podem refletir requisitos especıficos da aplicacao oulimitacoes na confianca atribuıda uma ancora de confianca particular. Por exemplo, umaAC confiavel pode ser confiavel apenas para um determinada polıtica de certificado. Estarestricao pode ser expressa atraves das entradas para o procedimento de validacao de ca-minho.

Uma implementacao PODE aumentar o algoritmo apresentado na secao 6.1 para limitarainda mais o conjunto de caminhos de certificacao validos que comecem com uma determi-nada ancora de confianca. Por exemplo, uma implementacao PODE modificar o algoritmopara aplicar uma restricao de comprimento de caminho a uma determinada ancora du-rante a fase de inicializacao, ou a aplicacao PODE ter como requisito a presenca de umadeterminada forma de nome alternativo no certificado alvo, ou a aplicacao PODE imporcomo requisitos, extensoes especıficas para a aplicacao. Assim, o algoritmo de validacaode caminho apresentado na secao 6.1 define as condicoes mınimas para um caminho serconsiderado valido.

Quando uma AC distribuir certificados auto-assinados para especificar informacao da an-cora de confianca, as extensoes do certificado podem ser usadas para especificar as entradas


Ern

andes

76


recomendadas para a validacao de caminho. Por exemplo, uma extensao policy constraintspoderia ser incluıda no certificado auto-assinado para indicar que os caminhos que come-carem com esta ancora de confianca deveria ser confiavel apenas para polıticas especıficas.De maneira similar, uma extensao name constraints poderia ser incluıda para indicar queos caminhos comecando com esta ancora de confianca deveriam ser confiaveis apenas paradeterminados espacos de nome. O algoritmo de validacao de caminho apresentado na se-cao 6.1 nao assume que a informacao da ancora de confianca e fornecida em certificadosauto-assinados e nao especifica regras de processamento para informacao adicionais incluı-das em tais certificados. As implementacoes que usarem certificados auto-assinados paraespecificar informacao sobre ancora de confianca estao livres para processar ou ignorar estainformacao.

6.3 Validacao de LCR

Esta secao descreve os passos necessarios para determinar se um certificado esta revogadoquando LCRs sao o mecanismo de revogacao utilizado pelo emissor do certificado. As im-plementacoes em conformidade que suportarem LCRs nao obrigadas a implementarem estealgoritmo, mas elas DEVEM ser funcionalmente equivalentes ao comportamento externo re-sultante deste procedimento, quando processarem LCRs que sao emitidas em conformidadecom este perfil. Qualquer algoritmo pode ser utilizado por determinada implementacao,desde que derivem o resultado correto.

Esta algoritmo considera que todas as LCRs necessarias estarao disponıveis em uma cachelocal. Alem disso, se o tempo da proxima atualizacao de LCR tiver passado, o algoritmoassume que um mecanismo buscara a LCR atual e a colocara na cache de LCR local.

Este algoritmo define um conjunto de entradas, um conjunto de variaveis de estado, epassos de processamento que sao executados para cada certificado do caminho. A saıda doalgoritmo e o estado de revogacao do certificado.

6.3.1 Entradas de Revogacao

Para dar suporte ao processo de revogacao, o algoritmo precisa de duas entradas:

(a) certificado: O algoritmo precisa do numero serial do certificado e do nome do emis-sor para determinar se o certificado esta em uma determinada LCR. A extensaobasicConstraints e utilizada para determinar se o certificado fornecido esta associ-ado a uma AC ou a uma entidade final. Se presente, o algoritmo usa as extensoescRLDistributionPoints e freshestCRL para determinar o estado de revogacao.

(b) use-deltas: entrada booleana que determina se serao aplicadas LCRs delta a LCR.

Para suportar o processamento de LCR, o algoritmo requer as seguintes variaveis de estado:

(a) reasons mask: Esta variavel contem o conjunto de razoes de revogacao suportaspelas LCRs e LCRs delta processadas ate o agora. Os membros legais do conjuntosao as possıveis razoes de revogacao menos aqueles nao especificados: keyCompro-mise, cACompromise, affiliationChanged, superseded, cessationOfOperation, certi-ficateHold, privilegeWithdrawn, and aACompromise. O valor especial all-reasonse usado para denotar o conjunto de todos os membros integrantes. Esta variavel einicializada com um conjunto vazio.


Ern

andes

77


(b) cert status: Esta variavel contem o estado do certificado. A esta variavel podeser atribuıdo um dos seguintes valores: unspecified, keyCompromise, cACompro-mise, affiliationChanged, superseded, cessationOfOperation, certificateHold, remo-veFromCRL, privilegeWithdrawn, aACompromise, o valor especial UNREVOKED,ou o valor especial UNDETERMINED. Esta variavel e inicializada com o valor es-pecial UNREVOKED.

(c) interim reasons mask: Esta contem o conjunto de razoes de revogacao suportadopela LCR ou LCR delta que esta sendo processada no momento atual.

Nota: Em alguns ambientes, nao e necessario verificar todos os codigos razao. Por exem-plo, alguns ambientes estao relacionados apenas ao cACompromid e keyCompromise paracertificados de AC. Este algoritmo verifica todos os codigos razao. Processamento adicionale variaveis de estado podem ser necessario para limitar a verificacao a um subconjunto doscodigos razao.

6.3.2 Processamento de LCR

Este algoritmo comeca assumindo que o certificado nao esta revogado. O algoritmo verificaum ou mais LCRs ate que o estado do certificado seja determinado como revogado ou queum numero suficiente de LCRs tenham sido verificadas para cobrir todos os codigos razao.

Para cada ponto de distribuicao (DP) na extensao CRL distribution points do certificado,para cada LCR correspondente na cache local, enquento ((reasons mask nao for all-reasons)e (cert status for UNREVOKED)) execute o seguinte:

(a) Atualize a cache de LCR local obtendo uma LCR completa, uma LCR delta, con-forme necessario:

(1) Se o tempo atual e apos o valor do campo next update da LCR, entao facauma das seguintes opcoes:

(i) Se use-delta estiver ativado e o certificado ou a LCR tiver a exten-sao freshest CRL, obtenha a LCR delta com o valor next updateque seja apos a data atual e possa ser utilizado para atualizar aLCR armazenada no cache local, como especificado na secao 5.2.4.

(ii) Atualize a cache de LCR local com a LCR completa atual, verifi-que se o tempo atual e anterior ao valor de next update da novaLCR, e continue o processamento com a nova LCR. Se use-deltasestiver ativado e o certificado ou a LCR tiver a extensao freshestCRL, entao obtenha a LCR delta atual que pode ser usada paraatualizar a nova LCR completa gravada na cache local, como es-pecificado na secao 5.2.4.

(2) Se o tempo atual e anterior ao valor do campo next update, use-deltasestiver ativado, e o certificado ou a LCR tiver a extensao freshest CLR,entao obtenha a LCR delta atual que pode ser usada para atualizar a LCRcompleta gravada na cache local, como especificado na secao 5.2.4.

(b) Verifique o emissor e o escopo da LCR completa da seguinte forma:

(1) Se o DP inclui cRLIssuer, entao verifique se o campo issuer na LCR com-pleta corresponde ao cRLIssuer do DP e que a LCR completa contem uma


Ern

andes

78


extensao issuig distribution point com o campo booleano indirectCRL ati-vado. Se outra forma, verifique que o campo CRL issuer corresponde aoao campo certificate issuer.

(2) Se a LCR completa tiver a extensao de LCR issuing distribution point(IDP), verifique o seguinte:

(i) Se distribution point name estiver presente na extensao IDP daLCR e o campo distribution estiver presente na DP, entao verifiqueque um dos nomes da IDP corresponde a um dos nomes da DP.Se o distribution point name estiver presente na extensao IDP daLCR e o campo distribution for omitido na DP, entao verifiqueque um dos nomes na IDP corresponde a um dos nomes no campocRLIssuer da DP.

(ii) Se o campo booleano onlyContainsUserCerts estiver atribuıdo naextensao IDP da LCR, verifique se o certificado nao inclui a ex-tensao basic contraints como o campo booleano cA ativado.

(iii) Se o campo booleano onlyContainsCACerts estiver atribuıdo naestensao IDP da LCR, verifique se o certificado inclui a extensaobasic constraints com o campo booleano cA ativado.

(iv) Verifique que o campo booleano onlyContainsAttributeCerts naoesta ativado.

(c) Se use-deltas estiver ativado, verifique o usuario e o escopo da LCR delta da se-guinte forma:

(1) Verifique se delta CRL issuer corresponde a complete CRL issuer.

(2) Se a LCR completa inclui a extensao de LCR issuing distribution point(IDP), verifique se a LCR delta contem uma extensao de LCR IDP. Se aLCR completa omite a extensao IDP da LCR, verifique se a LCR deltatambem omite a extensao IDP da LCR .

(3) Verifique se a extensao authority key identifier da LCR delta correspondea extensao authority key identifier da LCR completa.

(d) Processe a variavel interim reasons mask para esta LCR da seguinte forma:

(1) Se a extensao issuing distribution point da LCR estiver presente e incluironlySomeReasons e a DP incluir reasons, entao defina interim reasons maskcom a interseccao de reasons da DP e onlySomeReasons da extensao IDPda LCR.

(2) Se a extensao IDP da LCR incluir onlySomeReasons, mas a DP omitir rea-sons, entao defina interim reasons mask com o valor de onlySomeReasonsda extesnao IDP da LCR.

(3) Se a estensao IDP da LCR nao estiver presente ou omitir onlySomeRea-sons, mas a DP incluir reasons, entao defina interim reasons mask com ovalor de reasons da DP.

(4) Se a extensao IDP da LCR nao estiver presente ou omitir onlySomeRea-sons, e DP omitir reasons, entao defina interim reasons mask com o valorespecial all-reasons.


Ern

andes

79


(e) Verifique se interim reasons mask inclui uma ou mais razoes que nao estao incluıdasna reasons mask.

(f) Obtenha e valide o caminho de certificacao para o emissor da LCR completa. Aancora de confianca para o caminho de certificacao DEVE ser a mesma ancora deconfianca usada para validar o certificado alvo. Se a extensao key usage estiverpresente no campo issuer do certificado do emissor da LCR, verifique se o bitcRLSign esta ativado.

(g) Valide a assinatura da LCR completa usando a chave publica validada no passo(f).

(h) Se use-deltas estiver ativado, entao valide a assinatura da LCR delta usando achave publica validada no passo(f).

(i) Se use-deltas estiver ativado, procure pelo certificado na LCR delta. Se uma en-trada correspondente ao numero serial e emissor for encontrada, como descrito noitem 5.3.3, entao atribua a cert status variable a razao indicada, da seguinte forma:

(1) Se a extensao reason code da entrada da LCR estiver presente, atribua avariavel cert status o valor de reason code extensao da entrada da LCR.

(2) Se a extensao reason code da entrada da LCR nao estiver presente, atribuaa variavel cert status o valor unspecified.

(j) Se (cert status igual a UNREVOKED), entao procure pelo certificado na LCRcompleta. Se uma entrada for encontrada que corresponda ao emissor do certificadoe numero serial, como descrito na secao 5.3.3, entao atribua a variavel cert statusa razao indicada, como descrito no passo (i).

(k) Se (cert status igual a removeFromCRL), entao atribua a variavel cert status ovalor UNREVOKED.

(l) Atribua a variavel de estado reason mask a uniao dos seus valores anteriores e ovalor da variavel de estado interim reasons mask.

Se ((reasons mask igual a all-reasons) OU (cert status nao for UNREVOKED)), entao oestado de revogacao foi determinado, entao retorne cert status.

Se o estado de revogacao nao tiver sido determinado, repita o processo acima com qualquerLCR disponıvel nao especificada em distribution point, mas emitida pelo emissor do cer-tificado. Para o processamento de tal LCR, considere um DP com tanto o campo reasonscomo o campo cRLIssuer omitidos e um distribution point name igual ao campo issuer docertificado. Ou seja, a sequencia de names em fullName e criada a partir, tanto campoissuer do certificado como da extensao issuerAltName. Apos processar tais LCRs, se oestado de revogacao ainda nao tiver sido determinado, entao retorne UNDETERMINEDna variavel de estado cert status.

7 Regras de Processamento para Nomes Internacio-

nalizados

Nomes internacionalizados podem ser encontrados em campos de numerosos certificadose LCR e extensoes, incluindo nomes distintos, nome internacionalizados de domınios, en-derecos de correio eletronico, e identificadores de recursos internacionalizados (IRIs). O


Ern

andes

80


armazenamento, comparacao e apresentacao deste tipo de nome requer um cuidado espe-cial. Alguns caracteres pode ser codificados de diversas formas. O mesmo nome poderia serrepresentado em diversas codificacoes (ex: ASCII ou UTF8). Esta secao estabelece requi-sitos de conformidade para o armazenamento e comparacao para cada um desses formatosde nome. E fornecido um guia informativo de apresentacao para alguns destes formatos denome.

7.1 Nomes Internacionalizados em Distinguished Names

A representacao de nomes internacionalizados em nomes distintos (distinguished names) etratada nas secoes 4.1.2.4, Issuer Names, e 4.1.2.6, Subject Name. Atributos padrao paranomes, tais como common nem, empregam o tipo DirectoryString, que suporta nomes inter-nacionalizados atraves de uma variedade de codificacoes linguısticas. Implementacoes emconformidade DEVEM suportar UTF8String e PrintableString. A RFC 3280 requer apenascomparacoes binarias de valores de atributos codificados em UTF8String, entretanto, estaespecificacao requer um tratamento mais abrangente para comparacao. Implementacoespodem encontrar certificados e LCRs com nomes codificados usando TeletexString, BMPS-tring, ou UniversalString, mas o suporte a estas codificacoes e OPCIONAL.

Implementacoes em conformidade DEVEM usar o perfil LDAP StringPrep (incluindo otratamento de espaco insignificante), como especificado em [RFC4518], como base para acomparacao de atributos de nomes distintos codificados em PrintableString ou UTF8String.Implementacoes em conformidade DEVEM suportar comparacoes de nome usando caseIg-noreMatch. Suporte a tipos de atributo que usam outras regras de correspondencia equa-litativa e opcional.

Antes de comparar nomes usando a regra caseIgnoreMatch, implementacoes em conformi-dade DEVEM executar o algoritmo de preparacao em seis-passos do string, descrito em[RFC4518] para cada atributo do tipo DirectoryString com os seguintes esclarecimentos:

∗ No passo 2, Map, o mapeamento devera incluir caixa dobrada como especificado noAppendix B.2 de [RFC3454].

∗ No passo 6, Insignificant Character Removal, executa compressao de espaco brancocomo especificado na secao 2.6.1, Insignificant Space Handling, de [RFC4518].

Quando executar o algoritmo de preparacao de string, os atributos DEVEM ser tratadoscomo valores armazenados.

Dois atributos de nome correspondem se os tipos atributo forem os mesmos e os valoresdos atributos forem uma correspondencia exata apos o processamento com o algoritmo depreparacao de string. Dois nomes distintos relativos RDN1 e RDN2 correspondem se elestiverem o mesmo numero de atributos de nomes e para cada atributo de nome em RDN1existir um atributo de nome correspondente em RDN2. Sou nomes distintos DN1 e DN2correspondem se eles tiverem o mesmo n umero de RDNs, para cada RDN em DN1 existirum RDN correspondente em DN2, e os RDNs correspondentes aparecerem na mesma ordemem ambos DNs. Um nome distinto DN1 esta na sub-arvore definida pelo nome distintoDN2 se DN1 tiver no mınimo tantos RDNs quanto DN2, e DN1 e DN2 sao correspondentesquando RDNs a direita de DN1 sao ignorados.


Ern

andes

81


7.2 Nome de Domınio Internacionalizados em GeneralName

Nomes de Domınio Internacionalizados (IDNs) podem ser incluıdos em certificados e LCRsnas extensoes subjectAltName e issuerAltName, na extensao name constraints, na extensaoauthority information access, na extensao subject information access, nas extensoes CRLdistribution points, e extensao issuing distribution point. Cada uma dessas extensoes usamo tipo GeneralName; uma selecao em GeneralName e o campo dNSName, que e definidocomo tipo IA5String.

IA5String e limitado ao conjunto de caracteres ASCII. Para acomodar nomes de domıniointernacionalizados na estrutura atual, implementacoes em conformidade DEVEM conver-ter nomes de domınio internacionalizados para um formato de codificacao compatıvel comASCII (ACE) como especificado na secao 4 da RFC 3490 antes de incluir no campo dNS-Name. Especificamente, implementacoes em conformidade DEVEM executar a operacaode conversao especificada na secao 4 da RFC 3490, como os seguintes esclarecimentos:

∗ no passo 1, o nome de domınio DEVERA ser considerado um “stored string”. Ouseja, o rotulo AllowUnassingned NAO DEVERA ser ativado;

∗ no passo 3, ativar o rotulo chamado “UseSTD3ASCIIRules”;

∗ no passo 4, processar cada rotulo com a operacao “ToASCII”; e

∗ no passo 5, mudar todos os separadores de rotulo para U+002E (parada completa).

Quando comparar nomes DNS para igualdade, implementacoes em conformidade DEVEMexecutar uma correspondencia exata nao-sensıvel a caixa (maiuscula e minuscula) em todoo nome DNS. Quando avaliar name constraints, implementacoes em conformidade DEVEMexecutar correspondencia exata nao sensıvel a caixa em base label-by-label. Como obser-vado na secao 4.2.1.10, qualquer nome DNS que pode ser construıdo a partir da adicao derotulos ao lado esquerdo do nome de domınio dado conforme as restricoes e consideradopertencente a sub-arvore indicada.

Implementacoes em conformidade deveriam converter IDNs para Unicode antes de exibi-lo. Especificamente, implementacoes em conformidade deveriam executar a operacao deconversao especificada na secao 4 da RFC 3490, com os seguintes esclarecimentos:

∗ no passo 1, o nome de domınio DEVERA ser considerado “stored string”. Ou seja, orotulo AllowUnassigned NAO DEVE ser ativado;

∗ no passo 3, ative o rotulo chamado “UseSTD3ASCIIRules”;

∗ no passo 4, processe cada rotulo com a operacao “ToUnicode”; e

∗ pule o passo 5.

Nota: Implementacoes devem prever requisitos maiores de espaco para IDNs. Um rotuloIDN ACE comecara com quatro caracteres adicionais“xn–”e pode exigir ate cinco caracteresASCII para especificar um unico caractere internacional.


Ern

andes

82


7.3 Nomes de Domınio Internacionalizados em Distinguished Na-mes

Nome de Domınio tambem podem ser representados como nomes distintos usando compo-nentes domınio no campo subject, no campo issuer, na extensao subjectAltName, ou naextensao issuerAltName. Da mesma forma do dNSName no tipo GeneralName, o valordeste atributo e definido como um IA5String. Cada atributo domainComponent representaum rotulo unico. Para representar um rotulo de um IDN no nome distinto, a implemen-tacao DEVE executar a conversao “ToASCII” especificada na secao 4.1 da RFC 3490. Orotulo DEVERA ser considerado um“stored string”. Ou seja, o indicador AllowUnassignedNAO DEVERA ser ativado.

Implementacoes em conformidade deverao o executar correspondencia exata nao-sensıvel acaixa do caractere (maiuscula/minuscula) quando comparar atributos domainComponenteem nomes distintos, como descrito na secao 7.2.

As implementacoes deveriam converter rotulos ACE para Unicode antes de exibi-los. Espe-cificamente, implementacoes em conformidade deveriam executar a operacao de conversao“ToUnicode” especificada, como descrita na secao 7.2, em cada rotulo ACE antes de exibiro nome.

7.4 Identificadores de Recurso Internacionalizados

Identificadores de Recurso Internacionalizados (IRIs) sao os complementos internacionali-zados para Identificador de Recurso Uniforme (URI). IRIs sao sequencias de caracteres doconjunto de caracteres ASCII. [RFC3987] define o mapeamento de IRIs para URIs. En-quanto IRIs nao sao codificados diretamente em qualquer campo de certificado ou extensao,seus URIs podem mapeados sao incluıdos em certificados e LCRs. URIs podem aparecernas extensoes subjectAltName e issuerAltName, na extensao name constraints, na extensaoauthority information access, na extensao subject information access, na extensao issuingdistribution point, e na extensao de LCR distribution points. Cada uma dessas extensoesusam o tipo GeneralName; URIs sao codificadas no campo uniformResourceIdentifier emGeneralName, que e definido como um tipo IA5String.

Para comodar IRIs na estrutura atual, implementacoes em conformidade DEVEM mapearIRIs para URIs como especificado na secao 3.1 de [RFC3987], com os seguintes esclareci-mentos:

∗ no passo 1, gerar a sequencia UCS de caractere a partir do formato original da IRInormalizado de acordo com NFC como especificado em Variant b (normalizacao deacordo com NFC);

∗ Executar o passo 2 usando a saıda do passo 1.

As implementacoes NAO DEVEM converter o componente ireg-name antes de executar opasso 2.

Antes das URIs puderem ser comparadas, implementacoes em conformidade DEVEM exe-cutar uma combinacao de tecnicas de normalizacao baseada em sintaxe e baseada em es-quema descritas em [RFC3987]. Especificamente, implementacoes em conformidade DE-VEM preparar URIs para comparacao da seguinte forma:


Ern

andes

83


∗ Passo 1: Onde IRIs permitirem o uso de IDNs, aqueles nomes DEVEM ser convertidopara codificacao compatıvel ASCII como especificado na secao 7.2 acima.

∗ Passo 2: O esquema e host sao normalizados para caixa baixa, como descrito na secao5.3.2.1 de [RFC3987].

∗ Passo 3: Executar normalizacao percent-encoding, como especificado na secao 5.3.2.3de [RFC3987].

∗ Passo 4: Executar normalizacao de segmento de caminho, como especificado na secao5.3.2.4 de [RFC3987].

∗ Passo 5: Se reconhecido, a implementacao DEVE executar normalizacao baseada emesquema, como especificado na secao 5.3.3 de [RFC3987].

Implementacoes em conformidade DEVEM reconhecer e executar normalizacao baseadaem esquema para os sequintes esquemas: ldap, http, https, e ftp. Se o esquema nao forreconhecido, o passo 5 e omitido.

Quando comparar URIs para equivalencia, implementacoes em conformidade DEVERAOexecutar correspondencia exata sensıvel a caixa (maiusculas/minusculas).

As implementacoes deveriam converter URIs para Unicode ante de exibi-los. Especifi-camente, implementacoes em conformidade deveriam executar a operacao de conversaoespecificada na secao 3.2 de [RFC3987].

7.5 Enderecos de Correio Eletronico Internacionalizados

Enderecos de correio eletronico podem ser incluıdos em certificados e LCRs nas extensoessubjectAltName e issuerAltName, na extensao name constraints, na extensao authorityinformation access, na extensao subject information access, na extensao issuing distribu-tion point, ou na extensao de LCR distribution points. Cada uma dessas extensoes usa ocontrutor GeneralName; GeneralName inclui a selecao rfc822Name, que e definida comotipo IA5String. Para acomodar enderecos de correio eletronico com nomes de domınio in-ternacionalizados usando a estrutura atual, as implementacoes em conformidade DEVEMconverter os enderecos em representacoes ACSII.

Onde a parte host (o domınio da caixa postal) tiver um nome internacionalizado, o nomede domınio DEVE ser convertido de IDN para o formato de codificacao compatıvel ASCII(ACE) como especificado na secao 7.2.

Dois enderecos de email sao considerados correspondentes se:

1) a parte local de cada nome tem correspondencia exata, E

2) a parte host de cada nome correspondem usando uma comparacao ASCII naosensıvel a caixa de texto(maiuscula/minuscula).

As implementacoes devem converter a parte host dos enderecos de email internacionalizadosespecificado nessas extensoes para Unicode antes de exibi-los. Especificamente, implemen-tacoes em conformidade deveriam executar a conversao da parte host da caixa postal comodescrito na secao 7.2.


Ern

andes

84


8 Consideracoes de Seguranca

A maior parte desta especificacao e dedicada ao formato e conteudo de certificados e LCRs.Desde que os certificados e LCRs sao assinados digitalmente, nenhum servico adicional deintegridade e necessario. Nem certificados nem LCRs necessitam manter segredo, e o acessoirrestrito e anonimo aos certificados e LCRs nao tem implicacoes na seguranca.

Contudo, fatores de seguranca externos ao escopo desta especificacao afetam a garantiafornecida aos usuarios de certificados. Esta secao destaca questoes crıticas a serem consi-deradas por implementadores, administradores e usuarios.

Os procedimentos executados pelas ACs e ARs para validar a associacao da identidade dosujeito com sua chave publica afetam muito a confianca que deve ser colocada no certificado.Terceiras partes confiaveis podem querer revisar as declaracoes de praticas de certificacaodas ACs. Isto e particularmente importante quando se emite certificados para outras ACs.

O uso de um unico par de chaves tanto para assinatura quanto para outros propositos efortemente desencorajada. O uso de pares de chave separadas para assinatura e gerencia-mento de chave fornece muitos benefıcios para os usuarios. As ramificacoes associadas aperda ou comprometimento de uma chave de assinatura sao diferentes da perda ou compro-metimento de uma chave usada para gerenciamento de chaves. O uso de pares de chavesseparados permite uma resposta balanceada e flexıvel. De maneira similar, perıodos devalidade diferentes ou tamanhos de chave para cada par de chave pode ser apropriado emalguns ambientes de aplicacao. Infelizmente, alguns aplicativos legados (ex: Secure SocketsLayer (SSL)), usa um unico par de chave para assinatura e gerenciamento de chave.

A protecao conferida as chaves privadas e um fator crıtico de seguranca. Em pequenaescala, falhas de usuarios na protecao de suas chaves privadas permitira que um intrusopossa se passar por eles ou descriptografar suas informacoes pessoais. Em larga escala, ocomprometimento de uma chave privada de assinatura de AC pode ter efeitos catastrofi-cos. Se um intruso obtem a chave privada e isso passa despercebido, o intruso pode emitircertificados e LCRs falsos. A existencia de certificados e LCRs falsos prejudica a confiancano sistema. Se tal comprometimento for detectado, todos os certificados emitidos pela ACcomprometida DEVEM ser revogados, impedindo servicos entre seus usuarios e usuariosde outras ACs. A reconstrucao apos este tipo de comprometimento sera problematica, demaneira que as ACs sao alertadas a implementarem uma combinacao de medidas tecnicasfortes (ex: modulos criptograficos resistentes a violacoes) e procedimentos gerenciais apro-priados (ex: segregacao de responsabilidades) afim de evitar este tipo de incidente.

A perda de uma chave privada de assinatura de uma AC tambem pode ser problematica.A AC nao seria capaz de produzir LCRs ou executar a atualizacao normal de chave. AsACs DEVERIAM manter backup seguro das chaves de assinatura. A seguranca dos proce-dimentos de backup de chave e um fator crıtico na prevencao do seu comprometimento.

A disponibilidade e a atualizacao da informacao de revogacao afeta o grau de confianca quepode ser atribuıdo ao certificado. Embora os certificados expirem naturalmente, podemocorrer eventos durante o seu perıodo de vida util que negam a associacao entre o sujeito ea chave publica. Se a informacao de revogacao estiver desatualizada ou indisponıvel, a con-fianca atribuıda a associacao fica claramente reduzida. Terceiras partes confiaveis podemnao ter capacidade para processar toda extensao crıtica que pode aparecer em uma LCR.


Ern

andes

85


As ACs DEVERIAM tomar cuidados adicionais quando disponibilizarem informacao derevogacao unicamente atraves de LCRs que contenham extensoes crıticas, particularmente,quando o o suporte a estas extensoes nao for considerado obrigatorio neste perfil. Por exem-plo, se a informacao de revogacao for fornecida usando uma combinacao de LCRs delta eLCRs completas, e as LCRs delta forem emitidas mais frequentemente que as LCRs com-pletas, entao as terceiras partes confiaveis que nao puderem processar as extensoes crıticasrelacionadas ao processamento das LCRs delta nao serao capazes de obter a informacao derevogacao mais recente. Alternativamente, se um LCR completa for emitida sempre queuma LCR delta for emitida, entao informacao de revogacao atualizada estara disponıvelpara todas as terceiras partes. De maneira similar, as implementacoes do mecanismo devalidacao de caminho de certificacao, descrito na secao 6, que omitirem a verificacao derevogacao fornece menos confianca que aqueles que possuem esse suporte.

O algoritmo de validacao de caminho de certificacao dependem de certo conhecimento daschaves publicas (e outra informacao) sobre um ou mais ACs confiaveis. A decisao de con-fiar em uma AC e uma decisao importante, pois em ultima instancia determina a confiancaatribuıda ao certificado. A distribuicao autenticada de chaves publicas de ACs confiaveis(geralmente na forma de um certificado auto-assinado) e um processo externo crıtico paraa seguranca e que se encontra alem do escopo desta especificacao.

Alem disso, onde um comprometimento de chave ou falha de AC ocorre de uma AC con-fiavel, o usuario necessitara modificar a informacao fornecida para a rotina de validacao decaminho. A selecao de muitas ACs confiaveis torna a informacao sobre AC confiavel difıcilde manter. Por outro lado, a selecao de apenas uma AC confiavel poderia limitar os seususuarios a uma comunidade fechada de usuarios.

A qualidade das implementacoes que processam certificados tambem afeta o grau de con-fianca fornecido. O algoritmo de validacao de caminho descrito na secao 6 se baseia naintegridade da informacao da AC confiavel, e especialmente na integridade das chaves pu-blicas associadas as ACs confiaveis. Com a substituicao das chaves publicas para as quaisum intruso detenha a chave privada, um invasor poderia enganar o usuario quanto a acei-tacao de certificados falsos.

A associacao entre uma chave e o sujeito do certificado nao pode ser mais forte que aimplementacao do modulo criptografico e os algoritmos usados para gerar a assinatura.Tamanhos de chaves pequenos ou algoritmos de hash frageis limitara a utilidade de umcertificado. As ACs sao incentivadas os avancos da criptologia de forma que possam aplicartecnicas fortes de criptografia. Alem disso, as ACs DEVERIAM se recusar a emitir certifi-cados para ACs ou entidades finais que geram assinaturas fracas.

Aplicacoes inconsistentes de regras de comparacao podem resultar na aceitacao de caminhosde certificacao X.509 invalidos ou rejeicao de caminhos validos. A serie de especificacoesX.500 define regras para comparacao de nomes distintos que requerem comparacoes destrings sem considerar o tamanho do caractere, conjunto de caractere, subtracao de multi-plos caracteres brancos, ou desconsiderar caracteres brancos a esquerda ou a direita. Estaespecificacao relaxa estes requisitos, e necessario, no mınimo, suporte para comparacao bi-naria.

As ACs DEVEM codificar o nome distinto no campo subject de um certificado de AC demaneira identica ao nome distinto do campo issuer nos certificados emitidos pela AC. Se as


Ern

andes

86


ACs usarem codificacoes diferentes, as implementacoes poderao falhar no reconhecimentode cadeias de nome para os caminhos que incluırem este certificado. Como consequencia,caminhos validos poderao ser rejeitados.

Alem disso, restricoes de nome para nomes distintos DEVEM ser definidas de maneiraidentica a codificacao usada no campo subject ou na extensao subjectAltName. Casocontrario, as restricoes de nome definidas como excludedSubtrees nao corresponderao e ca-minhos invalidos serao aceitos e as restricoes de nome expressadas como permittedSubtreesnao corresponderao e caminhos validos serao rejeitados. Para evitar a aceitacao de cami-nhos invalidos, as AC DEVERIAM definir as restricoes de nome para nomes distintos comopermittedSubtrees sempre que possıvel.

Em geral, o uso da extensao nameConstraints para restringir uma forma de nome (ex: no-mes DNS) nao oferece protecao contra o uso de outras formas de nome (ex: endereco decorreio eletronico).

Enquanto o X.509 determina que nao exista ambiguidade nos nomes, existe o risco queduas autoridades nao relacionadas emitam certificados ou LCRs embaixo do mesmo nomede emissor. Como meio de reduzir problemas e questoes de seguranca relacionadas a co-lisoes de nome de emissor, nomes de AC e emissor de LCR DEVERIAM ser formados demaneira a reduzir a probabilidade de colisao de nomes. Implementadores deveriam levarem conta a possıvel existencia de multiplas ACs nao relacionadas e emissores de LCR como mesmo nome. No mınimo, as implementacoes que validam LCRs DEVEM garantir queo caminho de certificacao de um certificado e o caminho de certificacao do emissor de LCRusado para validar o certificado terminam na mesma ancora de confianca.

Enquanto a parte local de um endereco de correio eletronico diferencia maiusculas de minus-culas [RFC2821], os valores de atributo emailAddress nao fazem distincao entre maiusculase minusculas [RFC2985]. Como resultado, existe o risco de que dois enderecos de correioeletronico distintos sejam tratados como o mesmo endereco quando a regra de correspon-dencia para atributo emailAddress for usada, se o servidor de email explorar a diferenciacaode maiusculas e minusculas da parte local da caixa postal. Os implementadores nao deve-riam incluir o endereco de email no atributo emailAddress quando o servidor de email quedetem aquele endereco de email tratar a parte local do endereco de email com diferenciacaoentre maiusculas e minusculas.

Implementadores deveriam ter conhecimento dos riscos envolvidos se as extensoes CRLdistribution points ou authority information access de certificados corrompidos ou LCRstiverem links para codigos maliciosos. Os implementadores deveriam sempre tomar as me-didas de validacao de dados recuperados para garantir que o dado foi formado de maneiraapropriada.

Quando os certificados incluırem a extensao cRLDistributionPoints com uma URI httpsou esquema semelhante, pode ser introduzido uma depedencia circular. A parte confia-vel e forcada a executar uma validacao adicional de caminho para obter a LCR desejadapara completar a validacao inicial de caminho. Condicoes circulares tambem podem sercriadas com uma URI https (ou esquema simelhante) nas extensoes authorityInfoAccess ousubjectInfoAccess. Na pior das hipoteses, esta situacao pode gerar dependencias insoluveis.

As ACs NAO DEVERIAM incluir URIs que especificam https, ldaps, ou esquemas seme-


Ern

andes

87


lhantes nas extensoes. As ACs que incluem uma URI https em uma desses extensoes DEVEgarantir que o certificado do servidor pode ser validado sem a informacao que e apontadapela URI. Terceiras partes confiaveis que escolherem validar o certificado do servidor ob-tendo a informacao apontada por uma URI https nas extensoes cRLDistributionPoints,authorityInfoAccess, ou subjectInfoAccess DEVEM estar preparadas para a possibilidadedisto resultar em uma recursao infinita.

Certificados auto-emitidos fornecem as ACs um mecanismo automatizado para indicar mu-dancas nas operacoes da AC. Em particular, certificados auto-emitidos podem ser usadopara implementar uma mudanca de chaves tranquila de um par de chaves de AC nao com-prometidas para o proximo. Procedimentos detalhados para “atualizacao de chave de AC”sao especificados em [RFC4210], onde a AC protege a sua nova chave publica usando a suachave privada anterior e vice-versa, usando dois certificados auto-emitidos. Implementacoescliente em conformidade processarao o certificado auto-emitido e determinarao se o certifi-cado emitido sob a nova chave pode ser confiavel. Certificados auto-emitidos PODEM serusados para suportar outras mudancas nas operacoes da AC, como adicoes ao conjunto depolıticas da AC, usando procedimentos semelhantes.

Algumas implementacoes legadas suportam nomes codificados em ISO 8859-1 conjunto decaractere (LatinString) [ISO8859], mas marcam eles como TeletexString. TeletexString co-dificam um conjunto de caracteres maior que o definido na ISO 8859-1, mas ela codificaalguns caracteres de maneira diferente. As regras de comparacao de nome especificadasna secao 7.1 consideram que TeletexString sao codificados como o conjunto de caracteresLatinString, possibilitando falto positivos e falso negativos.

Quando strings sao mapeados de representacoes internas para representacao visual, al-gumas vezes dois strings distintos terao o mesma representacao visual, ou representacaosemelhante. Isto pode acontecer por diversas razoes, incluindo o uso de glifos semelhantese uso de caracteres compostos (como e + ´ equivalentes a U+00E9, os caracteres coreanoscompostos, e vogais acima de consoantes agrupados em certas lınguas). Como resultadodessa situacao, pessoas fazendo comparacao visual entre dois nomes diferentes pode pensarque eles sao os mesmos quando de fato eles nao sao. Tambem, as pessoas podem confundirum string com outro. Emissores de certificados e terceiras partes confiaveis necessitam terconhecimento desta situacao.

9 Consideracoes IANA

Extensoes em certificados e LCRs sao identificadas a partir de identificadores de objeto(OID). Os objetos sao definidos em um arco delegado pelo IANA ao PKIX Working Group.Nenhuma acao adicional, por parte do IANA, se faz necessario para este documento ouquaisquer atualizacoes antecipadas.

10 Agradecimento

Warwick Ford participou com os autores de algumas das reunioes do projeto da equipe quedirigiu o desenvolvimento deste documento. Os esforcos da equipe de design foram guiadospor contribuicoes de Matt Crawford, Gindin Tom, Steve Hanna, Stephen Henson, HoffmanPaulo, Ito Takashi, Pinkas Denis, e Wen-Cheng Wang.


Ern

andes

88


11 Referencias

11.1 Referencias Normativas

[RFC791] Postel, J., “Internet Protocol”, STD 5, RFC 791, September 1981.

[RFC1034] Mockapetris, P., “Domain Names - Concepts and Facilities”, STD 13, RFC1034, November 1987.

[RFC1123] Braden, R., Ed., “Requirements for Internet Hosts – Application and Sup-port”, STD 3, RFC 1123, October 1989.

[RFC2119] Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels”,BCP 14, RFC 2119, March 1997.

[RFC2460] Deering, S. and R. Hinden, “Internet Protocol, Version 6 (IPv6) Specifica-tion”, RFC 2460, December 1998.

[RFC2585] Housley, R. and P. Hoffman,“Internet X.509 Public Key Infrastructure: Ope-rational Protocols: FTP and HTTP”, RFC 2585, May 1999.

[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., andT. Berners-Lee, “Hypertext Transfer Protocol – HTTP/1.1”, RFC 2616, June1999.

[RFC2797] Myers, M., Liu, X., Schaad, J., and J. Weinstein, “Certificate ManagementMessages over CMS”, RFC 2797, April 2000.

[RFC2821] Klensin, J., Ed., “Simple Mail Transfer Protocol”, RFC 2821, April 2001.

[RFC3454] Hoffman, P. and M. Blanchet, “Preparation of Internationalized Strings(“stringprep”)”, RFC 3454, December 2002.

[RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, “Internationalizing Domain Na-mes in Applications (IDNA)”, RFC 3490, March 2003.

[RFC3629] Yergeau, F., “UTF-8, a transformation format of ISO 10646”, STD 63, RFC3629, November 2003.

[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, “Uniform Resource Identifier(URI): Generic Syntax”, STD 66, RFC 3986, January 2005.

[RFC3987] Duerst, M. and M. Suignard, “Internationalized Resource Identifiers (IRIs)”,RFC 3987, January 2005.

[RFC4516] Smith, M., Ed., and T. Howes, “Lightweight Directory Access Protocol(LDAP): Uniform Resource Locator”, RFC 4516, June 2006.

[RFC4518] Zeilenga, K., “Lightweight Directory Access Protocol (LDAP): Internationa-lized String Preparation”, RFC 4518, June 2006.

[RFC4523] Zeilenga, K., “Lightweight Directory Access Protocol (LDAP) Schema Defi-nitions for X.509 Certificates”, RFC 4523, June 2006.


Ern

andes

89


[RFC4632] Fuller, V. and T. Li, “Classless Inter-domain Routing (CIDR): The InternetAddress Assignment and Aggregation Plan”, BCP 122, RFC 4632, August2006.

[X.680] ITU-T Recommendation X.680 (2002) | ISO/IEC 8824-1:2002, Informationtechnology - Abstract Syntax Notation One (ASN.1): Specification of basicnotation.

[X.690] ITU-T Recommendation X.690 (2002) | ISO/IEC 8825-1:2002, Informationtechnology - ASN.1 encoding rules: Specification of Basic Encoding Rules(BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules(DER).

11.2 Referencias Informativas

[ISO8859] ISO/IEC 8859-1:1998. Information technology – 8-bit single-byte codedgraphic character sets – Part 1: Latin alphabet No. 1.

[ISO10646] ISO/IEC 10646:2003. Information technology – Universal Multiple-OctetCoded Character Set (UCS).

[NFC] Davis, M. and M. Duerst, “Unicode Standard Annex #15: Unicode Norma-lization Forms”, October 2006, <http://www.unicode.org/reports/tr15/>.

[RFC1422] Kent, S., “Privacy Enhancement for Internet Electronic Mail: Part II:Certificate-Based Key Management”, RFC 1422, February 1993.

[RFC2277] Alvestrand, H., “IETF Policy on Character Sets and Languages”, BCP 18,RFC 2277, January 1998.

[RFC2459] Housley, R., Ford, W., Polk, W., and D. Solo, “Internet X.509 Public KeyInfrastructure Certificate and CRL Profile”, RFC 2459, January 1999.

[RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. Adams, “X.509 In-ternet Public Key Infrastructure Online Certificate Status Protocol - OCSP”,RFC 2560, June 1999.

[RFC2985] Nystrom, M. and B. Kaliski, “PKCS #9: Selected Object Classes and Attri-bute Types Version 2.0”, RFC 2985, November 2000.

[RFC3161] Adams, C., Cain, P., Pinkas, D., and R. Zuccherato, “Internet X.509 PublicKey Infrastructure Time-Stamp Protocol (TSP)”, RFC 3161, August 2001.

[RFC3279] Bassham, L., Polk, W., and R. Housley, “Algorithms and Identifiers for theInternet X.509 Public Key Infrastructure Certificate and Certificate Revoca-tion List (CRL) Profile”, RFC 3279, April 2002.

[RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, “Internet X.509 Public Key In-frastructure Certificate and Certificate Revocation List (CRL) Profile”, RFC3280, April 2002.


Ern

andes

90


[RFC4055] Schaad, J., Kaliski, B., and R. Housley, “Additional Algorithms and Iden-tifiers for RSA Cryptography for use in the Internet X.509 Public Key In-frastructure Certificate and Certificate Revocation List (CRL) Profile”, RFC4055, June 2005.

[RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, “The Kerberos NetworkAuthentication Service (V5)”, RFC 4120, July 2005.

[RFC4210] Adams, C., Farrell, S., Kause, T., and T. Mononen, “Internet X.509 PublicKey Infrastructure Certificate Management Protocol (CMP)”, RFC 4210,September 2005.

[RFC4325] Santesson, S. and R. Housley, “Internet X.509 Public Key InfrastructureAuthority Information Access Certificate Revocation List (CRL) Extension”,RFC 4325, December 2005.

[RFC4491] Leontiev, S., Ed., and D. Shefanovski, Ed., “Using the GOST R 34.10-94,GOST R 34.10-2001, and GOST R 34.11-94 Algorithms with the InternetX.509 Public Key Infrastructure Certificate and CRL Profile”, RFC 4491,May 2006.

[RFC4510] Zeilenga, K., Ed., “Lightweight Directory Access Protocol (LDAP): TechnicalSpecification Road Map”, RFC 4510, June 2006.

[RFC4512] Zeilenga, K., Ed., “Lightweight Directory Access Protocol (LDAP): DirectoryInformation Models”, RFC 4512, June 2006.

[RFC4514] Zeilenga, K., Ed., “Lightweight Directory Access Protocol (LDAP): StringRepresentation of Distinguished Names”, RFC 4514, June 2006.

[RFC4519] Sciberras, A., Ed., “Lightweight Directory Access Protocol (LDAP): Schemafor User Applications”, RFC 4519, June 2006.

[RFC4630] Housley, R. and S. Santesson, “Update to DirectoryString Processing in theInternet X.509 Public Key Infrastructure Certificate and Certificate Revoca-tion List (CRL) Profile”, RFC 4630, August 2006.

[X.500] ITU-T Recommendation X.500 (2005) | ISO/IEC 9594-1:2005, Informationtechnology - Open Systems Interconnection - The Directory: Overview ofconcepts, models and services.

[X.501] ITU-T Recommendation X.501 (2005) | ISO/IEC 9594-2:2005, Informationtechnology - Open Systems Interconnection - The Directory: Models.

[X.509] ITU-T Recommendation X.509 (2005) | ISO/IEC 9594-8:2005, Informationtechnology - Open Systems Interconnection - The Directory: Public-key andattribute certificate frameworks.

[X.520] ITU-T Recommendation X.520 (2005) | ISO/IEC 9594-6:2005, Informationtechnology - Open Systems Interconnection - The Directory: Selected attri-bute types.


Ern

andes

91


[X.660] ITU-T Recommendation X.660 (2004) | ISO/IEC 9834-1:2005, Informationtechnology - Open Systems Interconnection - Procedures for the operation ofOSI Registration Authorities: General procedures, and top arcs of the ASN.1Object Identifier tree.

[X.683] ITU-T Recommendation X.683 (2002) | ISO/IEC 8824-4:2002, Informationtechnology - Abstract Syntax Notation One (ASN.1): Parameterization ofASN.1 specifications.

[X9.55] ANSI X9.55-1997, Public Key Cryptography for the Financial Services In-dustry: Extensions to Public Key Certificates and Certificate RevocationLists, January 1997.

Apendice A. Estruturas e OIDs em Pseudo-ASN.1

Este apendice descreve objectos de dado usados por componentes ICP em conformidade,na sintaxe “como-ANS.1”. Esta sintaxe e um hıbrido da sintaxe ASN.1 1988 e 1993. A sin-taxe ASN.1 1988 e expandida com os Tipo UNIVERSAL da versao 1993, UniversalString,BMPString e UTF8String.

A sintaxe ASN.1 nao permite a inclusao do tipo statements no modulo ASN.1, e o padraoASN.1 de 1993 nao permite o uso dos novos tipos UNIVERSAL nos modulos usando asintaxe 1988. Como resultado, este modulo nao esta de acordo com nenhuma das versoespadrao ASN.1.

Este apendice pode ser convertido em ASN.1 1988 substituindo as definicoes do Tipo UNI-VERSAL com o tipo “ANY” da versao 1988.

A.1 Modulo Explicitamente Rotulado, sintaxe 1988

PKIX1Explicit88 { iso(1) identified-organization(3) dod(6) internet(1)

security(5) mechanisms(5) pkix(7) id-mod(0) id-pkix1-explicit(18) }

DEFINITIONS EXPLICIT TAGS ::=

BEGIN

-- EXPORTE TODOS --

-- IMPORTS NENHUM --

-- Tipos UNIVERSAL definidos no ASN.1 1993 e 1998

-- necessarios a esta especificac~ao

UniversalString ::= [UNIVERSAL 28] IMPLICIT OCTET STRING

-- UniversalString e definido em ASN.1:1993


Ern

andes

92


BMPString ::= [UNIVERSAL 30] IMPLICIT OCTET STRING

-- BMPString e o subtipo de UniversalString e modela

-- o Basic Multilingual Plane da ISO/IEC 10646

UTF8String ::= [UNIVERSAL 12] IMPLICIT OCTET STRING

-- O conteudo deste tipo esta em conformidade com a RFC 3629.

-- PKIX specific OIDs

id-pkix OBJECT IDENTIFIER ::=

{ iso(1) identified-organization(3) dod(6) internet(1)

security(5) mechanisms(5) pkix(7) }

-- PKIX arcs

id-pe OBJECT IDENTIFIER ::= { id-pkix 1 }

-- arco para extens~oes privadas de certificados

id-qt OBJECT IDENTIFIER ::= { id-pkix 2 }

-- arco para tipos qualificadores de polıtica

id-kp OBJECT IDENTIFIER ::= { id-pkix 3 }

-- arco de OID para extended key purpose


-- arco para descritores de acesso

-- policyQualifierIds for Internet policy qualifiers

id-qt-cps OBJECT IDENTIFIER ::= { id-qt 1 }

-- OID para qualificadores de Declarac~ao de Praticas

-- de Certificac~ao

id-qt-unotice OBJECT IDENTIFIER ::= { id-qt 2 }

-- OID para qualificador de notificac~ao de usuario

-- definic~oes dos descritores de acesso

id-ad-ocsp OBJECT IDENTIFIER ::= { id-ad 1 }

id-ad-caIssuers OBJECT IDENTIFIER ::= { id-ad 2 }

id-ad-timeStamping OBJECT IDENTIFIER ::= { id-ad 3 }

id-ad-caRepository OBJECT IDENTIFIER ::= { id-ad 5 }

-- tipos de dado de atributo

Attribute ::= SEQUENCE {

type AttributeType,

values SET OF AttributeValue }

-- e necessario no mınimo um valor

AttributeType ::= OBJECT IDENTIFIER

AttributeValue ::= ANY -- DEFINED BY AttributeType


Ern

andes

93


AttributeTypeAndValue ::= SEQUENCE {

type AttributeType,

value AttributeValue }

-- atributos de nome sugeridos: Definicoes do seguinte

-- conjunto de objetos de informac~ao pode ser aumentada para satisfazer

-- requisitos locais. Note que apagar membros deste conjunto pode

-- impedir a interoperabilidade de implementac~oes em conformidade.

-- apresentado em pares: o AttributeType seguido pela definic~ao do

-- tipo para o AttributeValue correspondente

-- Arco para atributos de nome padr~ao

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

-- Atributos de nome do tipo X520name

id-at-name AttributeType ::= { id-at 41 }

id-at-surname AttributeType ::= { id-at 4 }

id-at-givenName AttributeType ::= { id-at 42 }

id-at-initials AttributeType ::= { id-at 43 }

id-at-generationQualifier AttributeType ::= { id-at 44 }

-- Atributos de nome do tipo X520Name:

-- X520name ::= DirectoryString (SIZE (1..ub-name))

--

-- Expandido para evitar tipo parametrizado:

X520name ::= CHOICE {

teletexString TeletexString (SIZE (1..ub-name)),

printableString PrintableString (SIZE (1..ub-name)),

universalString UniversalString (SIZE (1..ub-name)),

utf8String UTF8String (SIZE (1..ub-name)),

bmpString BMPString (SIZE (1..ub-name)) }

-- Atributos de nome do tipo X520CommonName

id-at-commonName AttributeType ::= { id-at 3 }

-- Atributos de nome do tipo X520CommonName:

-- X520CommonName ::= DirectoryName (SIZE (1..ub-common-name))

--


X520CommonName ::= CHOICE {

teletexString TeletexString (SIZE (1..ub-common-name)),

printableString PrintableString (SIZE (1..ub-common-name)),

universalString UniversalString (SIZE (1..ub-common-name)),

utf8String UTF8String (SIZE (1..ub-common-name)),

bmpString BMPString (SIZE (1..ub-common-name)) }


Ern

andes

94


-- Atributos de nome do tipo X520LocalityName

id-at-localityName AttributeType ::= { id-at 7 }

-- Atributos de nome do tipo X520LocalityName:

-- X520LocalityName ::= DirectoryName (SIZE (1..ub-locality-name))

--


X520LocalityName ::= CHOICE {

teletexString TeletexString (SIZE (1..ub-locality-name)),

printableString PrintableString (SIZE (1..ub-locality-name)),

universalString UniversalString (SIZE (1..ub-locality-name)),

utf8String UTF8String (SIZE (1..ub-locality-name)),

bmpString BMPString (SIZE (1..ub-locality-name)) }

-- Atributos de nome do tipo X520StateOrProvinceName

id-at-stateOrProvinceName AttributeType ::= { id-at 8 }

-- Atributos de nome do tipo X520StateOrProvinceName:

-- X520StateOrProvinceName ::= DirectoryName (SIZE (1..ub-state-name))

--


X520StateOrProvinceName ::= CHOICE {

teletexString TeletexString (SIZE (1..ub-state-name)),

printableString PrintableString (SIZE (1..ub-state-name)),

universalString UniversalString (SIZE (1..ub-state-name)),

utf8String UTF8String (SIZE (1..ub-state-name)),

bmpString BMPString (SIZE (1..ub-state-name)) }

-- Atributos de nome do tipo X520OrganizationName

id-at-organizationName AttributeType ::= { id-at 10 }

-- Atributos de nome do tipo X520OrganizationName:

-- X520OrganizationName ::=

-- DirectoryName (SIZE (1..ub-organization-name))

--


X520OrganizationName ::= CHOICE {

teletexString TeletexString

(SIZE (1..ub-organization-name)),

printableString PrintableString


universalString UniversalString


utf8String UTF8String


bmpString BMPString

(SIZE (1..ub-organization-name)) }


Ern

andes

95


-- Atributos de nome do tipo X520OrganizationalUnitName

id-at-organizationalUnitName AttributeType ::= { id-at 11 }

-- Atributos de nome do tipo X520OrganizationalUnitName:

-- X520OrganizationalUnitName ::=

-- DirectoryName (SIZE (1..ub-organizational-unit-name))

--


X520OrganizationalUnitName ::= CHOICE {

teletexString TeletexString

(SIZE (1..ub-organizational-unit-name)),

printableString PrintableString


universalString UniversalString


utf8String UTF8String


bmpString BMPString

(SIZE (1..ub-organizational-unit-name)) }

-- Atributos de nome do tipo X520Title

id-at-title AttributeType ::= { id-at 12 }

-- atributos de nome do tipo X520Title:

-- X520Title ::= DirectoryName (SIZE (1..ub-title))

--


X520Title ::= CHOICE {

teletexString TeletexString (SIZE (1..ub-title)),

printableString PrintableString (SIZE (1..ub-title)),

universalString UniversalString (SIZE (1..ub-title)),

utf8String UTF8String (SIZE (1..ub-title)),

bmpString BMPString (SIZE (1..ub-title)) }

-- Atributo de nome do tipo X520dnQualifier

id-at-dnQualifier AttributeType ::= { id-at 46 }

X520dnQualifier ::= PrintableString

-- Atributo de nome do tipo X520countryName (digraph do IS 3166)

id-at-countryName AttributeType ::= { id-at 6 }

X520countryName ::= PrintableString (SIZE (2))

-- Atributo de nome do tipo X520SerialNumber


Ern

andes

96


id-at-serialNumber AttributeType ::= { id-at 5 }

X520SerialNumber ::= PrintableString (SIZE (1..ub-serial-number))

-- Atributo de nome do tipo X520Pseudonym

id-at-pseudonym AttributeType ::= { id-at 65 }

-- Atributo de nome do tipo X520Pseudonym:

-- X520Pseudonym ::= DirectoryName (SIZE (1..ub-pseudonym))

--


X520Pseudonym ::= CHOICE {

teletexString TeletexString (SIZE (1..ub-pseudonym)),

printableString PrintableString (SIZE (1..ub-pseudonym)),

universalString UniversalString (SIZE (1..ub-pseudonym)),

utf8String UTF8String (SIZE (1..ub-pseudonym)),

bmpString BMPString (SIZE (1..ub-pseudonym)) }

-- Atributo de nome do tipo DomainComponent (from RFC 4519)

id-domainComponent AttributeType ::= { 0 9 2342 19200300 100 1 25 }

DomainComponent ::= IA5String

-- Atributos legados

pkcs-9 OBJECT IDENTIFIER ::=

{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 9 }

id-emailAddress AttributeType ::= { pkcs-9 1 }

EmailAddress ::= IA5String (SIZE (1..ub-emailaddress-length))

-- tipos de dado Name --

Name ::= CHOICE { -- atualmente apenas uma possibilidade --

rdnSequence RDNSequence }

RDNSequence ::= SEQUENCE OF RelativeDistinguishedName

DistinguishedName ::= RDNSequence

RelativeDistinguishedName ::= SET SIZE (1..MAX) OF AttributeTypeAndValue

-- Tipo Directory string --

DirectoryString ::= CHOICE {

teletexString TeletexString (SIZE (1..MAX)),


Ern

andes

97


printableString PrintableString (SIZE (1..MAX)),

universalString UniversalString (SIZE (1..MAX)),

utf8String UTF8String (SIZE (1..MAX)),

bmpString BMPString (SIZE (1..MAX)) }

-- a estrutura do certificado e da LCR comeca neste ponto

Certificate ::= SEQUENCE {

tbsCertificate TBSCertificate,


signature BIT STRING }

TBSCertificate ::= SEQUENCE {

version [0] Version DEFAULT v1,

serialNumber CertificateSerialNumber,


issuer Name,

validity Validity,

subject Name,

subjectPublicKeyInfo SubjectPublicKeyInfo,

issuerUniqueID [1] IMPLICIT UniqueIdentifier OPTIONAL,

-- quando presente, a vers~ao DEVE ser v2 ou v3

subjectUniqueID [2] IMPLICIT UniqueIdentifier OPTIONAL,

-- quando presente, a vers~ao DEVE ser v2 ou v3

extensions [3] Extensions OPTIONAL

-- quando presente, a vers~ao DEVE ser v3 -- }

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,


Ern

andes

98


extnValue OCTET STRING

-- Contem a codificac~ao DER de um valor ASN.1

-- correspondente ao tipo de extens~ao identificado

-- por extnID

}

-- Estruturas da LCR

CertificateList ::= SEQUENCE {

tbsCertList TBSCertList,


signature BIT STRING }

TBSCertList ::= SEQUENCE {

version Version OPTIONAL,

-- quando presente, a vers~ao DEVE ser v2


issuer Name,

thisUpdate Time,

nextUpdate Time OPTIONAL,

revokedCertificates SEQUENCE OF SEQUENCE {

userCertificate CertificateSerialNumber,

revocationDate Time,

crlEntryExtensions Extensions OPTIONAL


} OPTIONAL,

crlExtensions [0] Extensions OPTIONAL }


-- Version, Time, CertificateSerialNumber, and Extensions s~ao

-- definidos anteriormente para serem usados na estrutura do certificado

AlgorithmIdentifier ::= SEQUENCE {

algorithm OBJECT IDENTIFIER,

parameters ANY DEFINED BY algorithm OPTIONAL }

-- contem o valor de um tipo

-- registrado para uso com o algoritmo

-- de identificador de objeto com valor

-- endereco X.400, a sintaxe comeca

-- neste ponto

ORAddress ::= SEQUENCE {

built-in-standard-attributes BuiltInStandardAttributes,

built-in-domain-defined-attributes

BuiltInDomainDefinedAttributes OPTIONAL,

-- veja tambem teletex-domain-defined-attributes

extension-attributes ExtensionAttributes OPTIONAL }

-- Atributos padr~ao embutidos


Ern

andes

99


BuiltInStandardAttributes ::= SEQUENCE {

country-name CountryName OPTIONAL,

administration-domain-name AdministrationDomainName OPTIONAL,

network-address [0] IMPLICIT NetworkAddress OPTIONAL,

-- veja tambem extended-network-address

terminal-identifier [1] IMPLICIT TerminalIdentifier OPTIONAL,

private-domain-name [2] PrivateDomainName OPTIONAL,

organization-name [3] IMPLICIT OrganizationName OPTIONAL,

-- veja tambem teletex-organization-name

numeric-user-identifier [4] IMPLICIT NumericUserIdentifier

OPTIONAL,

personal-name [5] IMPLICIT PersonalName OPTIONAL,

-- veja tambem teletex-personal-name

organizational-unit-names [6] IMPLICIT OrganizationalUnitNames

OPTIONAL }

-- veja tambem teletex-organizational-unit-names

CountryName ::= [APPLICATION 1] CHOICE {

x121-dcc-code NumericString

(SIZE (ub-country-name-numeric-length)),

iso-3166-alpha2-code PrintableString

(SIZE (ub-country-name-alpha-length)) }

AdministrationDomainName ::= [APPLICATION 2] CHOICE {

numeric NumericString

(SIZE (0..ub-domain-name-length)),

printable PrintableString

(SIZE (0..ub-domain-name-length)) }

NetworkAddress ::= X121Address

-- see also extended-network-address

X121Address ::= NumericString

(SIZE (1..ub-x121-address-length))

TerminalIdentifier ::= PrintableString

(SIZE (1..ub-terminal-id-length))

PrivateDomainName ::= CHOICE {

numeric NumericString

(SIZE (1..ub-domain-name-length)),

printable PrintableString

(SIZE (1..ub-domain-name-length)) }

OrganizationName ::= PrintableString

(SIZE (1..ub-organization-name-length))

-- veja tambem teletex-organization-name

NumericUserIdentifier ::= NumericString

(SIZE (1..ub-numeric-user-id-length))


Ern

andes

100


PersonalName ::= SET {

surname [0] IMPLICIT PrintableString

(SIZE (1..ub-surname-length)),

given-name [1] IMPLICIT PrintableString

(SIZE (1..ub-given-name-length))

OPTIONAL,

initials [2] IMPLICIT PrintableString

(SIZE (1..ub-initials-length))

OPTIONAL,

generation-qualifier [3] IMPLICIT PrintableString

(SIZE

(1..ub-generation-qualifier-length))

OPTIONAL }

-- veja tambem teletex-personal-name

OrganizationalUnitNames ::= SEQUENCE SIZE (1..ub-organizational-units)

OF OrganizationalUnitName

-- veja tambem teletex-organizational-unit-names

OrganizationalUnitName ::= PrintableString (SIZE

(1..ub-organizational-unit-name-length))

-- Atributos Domain-defined embutidos

BuiltInDomainDefinedAttributes ::= SEQUENCE SIZE

(1..ub-domain-defined-attributes) OF

BuiltInDomainDefinedAttribute

BuiltInDomainDefinedAttribute ::= SEQUENCE {

type PrintableString (SIZE

(1..ub-domain-defined-attribute-type-length)),

value PrintableString (SIZE

(1..ub-domain-defined-attribute-value-length))}

-- Atributos de extens~ao

ExtensionAttributes ::= SET SIZE (1..ub-extension-attributes) OF

ExtensionAttribute

ExtensionAttribute ::= SEQUENCE {

extension-attribute-type [0] IMPLICIT INTEGER

(0..ub-extension-attributes),

extension-attribute-value [1]

ANY DEFINED BY

extension-attribute-type }

-- Tipos e valores de atributos de extens~ao

common-name INTEGER ::= 1


Ern

andes

101


CommonName ::= PrintableString (SIZE (1..ub-common-name-length))

teletex-common-name INTEGER ::= 2

TeletexCommonName ::= TeletexString (SIZE (1..ub-common-name-length))

teletex-organization-name INTEGER ::= 3

TeletexOrganizationName ::= TeletexString

(SIZE (1..ub-organization-name-length))

teletex-personal-name INTEGER ::= 4

TeletexPersonalName ::= SET {

surname [0] IMPLICIT TeletexString

(SIZE (1..ub-surname-length)),

given-name [1] IMPLICIT TeletexString

(SIZE (1..ub-given-name-length)) OPTIONAL,

initials [2] IMPLICIT TeletexString

(SIZE (1..ub-initials-length)) OPTIONAL,

generation-qualifier [3] IMPLICIT TeletexString

(SIZE (1..ub-generation-qualifier-length))

OPTIONAL }

teletex-organizational-unit-names INTEGER ::= 5

TeletexOrganizationalUnitNames ::= SEQUENCE SIZE

(1..ub-organizational-units) OF TeletexOrganizationalUnitName

TeletexOrganizationalUnitName ::= TeletexString

(SIZE (1..ub-organizational-unit-name-length))

pds-name INTEGER ::= 7

PDSName ::= PrintableString (SIZE (1..ub-pds-name-length))

physical-delivery-country-name INTEGER ::= 8

PhysicalDeliveryCountryName ::= CHOICE {

x121-dcc-code NumericString (SIZE

(ub-country-name-numeric-length)),

iso-3166-alpha2-code PrintableString

(SIZE (ub-country-name-alpha-length)) }

postal-code INTEGER ::= 9

PostalCode ::= CHOICE {

numeric-code NumericString

(SIZE (1..ub-postal-code-length)),

printable-code PrintableString


Ern

andes

102


(SIZE (1..ub-postal-code-length)) }

physical-delivery-office-name INTEGER ::= 10

PhysicalDeliveryOfficeName ::= PDSParameter

physical-delivery-office-number INTEGER ::= 11

PhysicalDeliveryOfficeNumber ::= PDSParameter

extension-OR-address-components INTEGER ::= 12

ExtensionORAddressComponents ::= PDSParameter

physical-delivery-personal-name INTEGER ::= 13

PhysicalDeliveryPersonalName ::= PDSParameter

physical-delivery-organization-name INTEGER ::= 14

PhysicalDeliveryOrganizationName ::= PDSParameter

extension-physical-delivery-address-components INTEGER ::= 15

ExtensionPhysicalDeliveryAddressComponents ::= PDSParameter

unformatted-postal-address INTEGER ::= 16

UnformattedPostalAddress ::= SET {

printable-address SEQUENCE SIZE (1..ub-pds-physical-address-lines)

OF PrintableString (SIZE (1..ub-pds-parameter-length)) OPTIONAL,

teletex-string TeletexString

(SIZE (1..ub-unformatted-address-length))

OPTIONAL }

street-address INTEGER ::= 17

StreetAddress ::= PDSParameter

post-office-box-address INTEGER ::= 18

PostOfficeBoxAddress ::= PDSParameter

poste-restante-address INTEGER ::= 19

PosteRestanteAddress ::= PDSParameter

unique-postal-name INTEGER ::= 20

UniquePostalName ::= PDSParameter


Ern

andes

103


local-postal-attributes INTEGER ::= 21

LocalPostalAttributes ::= PDSParameter

PDSParameter ::= SET {

printable-string PrintableString

(SIZE(1..ub-pds-parameter-length)) OPTIONAL,

teletex-string TeletexString

(SIZE(1..ub-pds-parameter-length)) OPTIONAL }

extended-network-address INTEGER ::= 22

ExtendedNetworkAddress ::= CHOICE {

e163-4-address SEQUENCE {

number [0] IMPLICIT NumericString

(SIZE (1..ub-e163-4-number-length)),

sub-address [1] IMPLICIT NumericString

(SIZE (1..ub-e163-4-sub-address-length))

OPTIONAL },

psap-address [0] IMPLICIT PresentationAddress }

PresentationAddress ::= SEQUENCE {

pSelector [0] EXPLICIT OCTET STRING OPTIONAL,

sSelector [1] EXPLICIT OCTET STRING OPTIONAL,

tSelector [2] EXPLICIT OCTET STRING OPTIONAL,

nAddresses [3] EXPLICIT SET SIZE (1..MAX) OF OCTET STRING }

terminal-type INTEGER ::= 23

TerminalType ::= INTEGER {

telex (3),

teletex (4),

g3-facsimile (5),

g4-facsimile (6),

ia5-terminal (7),

videotex (8) } (0..ub-integer-options)

-- Atributos de extens~ao Domain-defined

teletex-domain-defined-attributes INTEGER ::= 6

TeletexDomainDefinedAttributes ::= SEQUENCE SIZE

(1..ub-domain-defined-attributes) OF

TeletexDomainDefinedAttribute

TeletexDomainDefinedAttribute ::= SEQUENCE {

type TeletexString

(SIZE (1..ub-domain-defined-attribute-type-length)),

value TeletexString

(SIZE (1..ub-domain-defined-attribute-value-length)) }


Ern

andes

104


-- especificac~oes de Limites Superiores DEVE ser considerados mandatorios

-- do anexo B da ITU-T X.411 Reference Definition of MTS Parameter

-- Limites Superiores (Upper Bounds)

-- Upper Bounds

ub-name INTEGER ::= 32768

ub-common-name INTEGER ::= 64

ub-locality-name INTEGER ::= 128

ub-state-name INTEGER ::= 128

ub-organization-name INTEGER ::= 64

ub-organizational-unit-name INTEGER ::= 64

ub-title INTEGER ::= 64

ub-serial-number INTEGER ::= 64

ub-match INTEGER ::= 128

ub-emailaddress-length INTEGER ::= 255

ub-common-name-length INTEGER ::= 64

ub-country-name-alpha-length INTEGER ::= 2

ub-country-name-numeric-length INTEGER ::= 3

ub-domain-defined-attributes INTEGER ::= 4

ub-domain-defined-attribute-type-length INTEGER ::= 8

ub-domain-defined-attribute-value-length INTEGER ::= 128

ub-domain-name-length INTEGER ::= 16

ub-extension-attributes INTEGER ::= 256

ub-e163-4-number-length INTEGER ::= 15

ub-e163-4-sub-address-length INTEGER ::= 40

ub-generation-qualifier-length INTEGER ::= 3

ub-given-name-length INTEGER ::= 16

ub-initials-length INTEGER ::= 5

ub-integer-options INTEGER ::= 256

ub-numeric-user-id-length INTEGER ::= 32

ub-organization-name-length INTEGER ::= 64

ub-organizational-unit-name-length INTEGER ::= 32

ub-organizational-units INTEGER ::= 4

ub-pds-name-length INTEGER ::= 16

ub-pds-parameter-length INTEGER ::= 30

ub-pds-physical-address-lines INTEGER ::= 6

ub-postal-code-length INTEGER ::= 16

ub-pseudonym INTEGER ::= 128

ub-surname-length INTEGER ::= 40

ub-terminal-id-length INTEGER ::= 24

ub-unformatted-address-length INTEGER ::= 180

ub-x121-address-length INTEGER ::= 16

-- Nota - upper bounds nos tipos string, tal como TeletexString, s~ao

-- medidos em caracteres. Com excec~ao do PrintableString ou IA5String, um

-- significativamente maior de octetos ser necessario para conter tal

-- valor. Como mınimo, 16 octetos, ou duas vezes o upper bound

-- especificado, o que for maior, deve ser permitida para

-- TeletexString. Para UTF8String ou UniversalString no mınimo


Ern

andes

105


-- quatro vezes o upper bound deve ser permitido.

END

A.2 Modulo Implicitamente Rotulado, sintaxe 1988

PKIX1Implicit88 { iso(1) identified-organization(3) dod(6) internet(1)

security(5) mechanisms(5) pkix(7) id-mod(0) id-pkix1-implicit(19) }

DEFINITIONS IMPLICIT TAGS ::=

BEGIN

-- EXPORTE Todos --

IMPORTS

id-pe, id-kp, id-qt-unotice, id-qt-cps,

-- delete following line if ‘‘new’’ types are supported --

BMPString, UTF8String, -- end ‘‘new’’ types --

ORAddress, Name, RelativeDistinguishedName,

CertificateSerialNumber, Attribute, DirectoryString

FROM PKIX1Explicit88 { iso(1) identified-organization(3)

dod(6) internet(1) security(5) mechanisms(5) pkix(7)

id-mod(0) id-pkix1-explicit(18) };

-- Arco ISO para certificado e extens~oes de LCR

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

-- OID e sintaxe de authority key identifier

id-ce-authorityKeyIdentifier OBJECT IDENTIFIER ::= { id-ce 35 }

AuthorityKeyIdentifier ::= SEQUENCE {

keyIdentifier [0] KeyIdentifier OPTIONAL,

authorityCertIssuer [1] GeneralNames OPTIONAL,

authorityCertSerialNumber [2] CertificateSerialNumber OPTIONAL }

-- authorityCertIssuer e authorityCertSerialNumber MUST estar ambos

-- presente ou ambos ausente

KeyIdentifier ::= OCTET STRING

-- OID e sintaxe de subject key identifier

id-ce-subjectKeyIdentifier OBJECT IDENTIFIER ::= { id-ce 14 }

SubjectKeyIdentifier ::= KeyIdentifier


Ern

andes

106


-- OID e sintaxe da extens~ao key usage

id-ce-keyUsage OBJECT IDENTIFIER ::= { id-ce 15 }

KeyUsage ::= BIT STRING {

digitalSignature (0),

nonRepudiation (1), -- recent editions of X.509 have

-- renamed this bit to contentCommitment

keyEncipherment (2),

dataEncipherment (3),

keyAgreement (4),

keyCertSign (5),

cRLSign (6),

encipherOnly (7),

decipherOnly (8) }

-- OID e sintaxe d a extens~ao private key usage period

id-ce-privateKeyUsagePeriod OBJECT IDENTIFIER ::= { id-ce 16 }

PrivateKeyUsagePeriod ::= SEQUENCE {

notBefore [0] GeneralizedTime OPTIONAL,

notAfter [1] GeneralizedTime OPTIONAL }

-- either notBefore or notAfter MUST be present

-- OID e sintaxe da extens~ao certificate policies

id-ce-certificatePolicies OBJECT IDENTIFIER ::= { id-ce 32 }

anyPolicy OBJECT IDENTIFIER ::= { id-ce-certificatePolicies 0 }

CertificatePolicies ::= SEQUENCE SIZE (1..MAX) OF PolicyInformation

PolicyInformation ::= SEQUENCE {

policyIdentifier CertPolicyId,

policyQualifiers SEQUENCE SIZE (1..MAX) OF

PolicyQualifierInfo OPTIONAL }

CertPolicyId ::= OBJECT IDENTIFIER

PolicyQualifierInfo ::= SEQUENCE {

policyQualifierId PolicyQualifierId,

qualifier ANY DEFINED BY policyQualifierId }

-- As implementac~oes que reconhecerem additional policy qualifiers DEVEM

-- aumentar as seguintes definic~oes para PolicyQualifierId

PolicyQualifierId ::= OBJECT IDENTIFIER ( id-qt-cps | id-qt-unotice )

-- Pointer qualifier para DPC


Ern

andes

107


CPSuri ::= IA5String

-- user notice qualifier

UserNotice ::= SEQUENCE {

noticeRef NoticeReference OPTIONAL,

explicitText DisplayText OPTIONAL }

NoticeReference ::= SEQUENCE {

organization DisplayText,

noticeNumbers SEQUENCE OF INTEGER }

DisplayText ::= CHOICE {

ia5String IA5String (SIZE (1..200)),

visibleString VisibleString (SIZE (1..200)),

bmpString BMPString (SIZE (1..200)),

utf8String UTF8String (SIZE (1..200)) }

-- OID e sintaxe da extens~ao policy mapping

id-ce-policyMappings OBJECT IDENTIFIER ::= { id-ce 33 }

PolicyMappings ::= SEQUENCE SIZE (1..MAX) OF SEQUENCE {

issuerDomainPolicy CertPolicyId,

subjectDomainPolicy CertPolicyId }

-- OID e sintaxe da extens~ao subject alternative name

id-ce-subjectAltName OBJECT IDENTIFIER ::= { id-ce 17 }

SubjectAltName ::= GeneralNames

GeneralNames ::= SEQUENCE SIZE (1..MAX) OF GeneralName

GeneralName ::= CHOICE {

otherName [0] AnotherName,

rfc822Name [1] IA5String,

dNSName [2] IA5String,

x400Address [3] ORAddress,

directoryName [4] Name,

ediPartyName [5] EDIPartyName,

uniformResourceIdentifier [6] IA5String,

iPAddress [7] OCTET STRING,

registeredID [8] OBJECT IDENTIFIER }

-- AnotherName substitui OTHER-NAME ::= TYPE-IDENTIFIER, ja que

-- TYPE-IDENTIFIER n~ao e suportado na sintaxe ASN.1 de 1988

AnotherName ::= SEQUENCE {


Ern

andes

108


type-id OBJECT IDENTIFIER,

value [0] EXPLICIT ANY DEFINED BY type-id }

EDIPartyName ::= SEQUENCE {

nameAssigner [0] DirectoryString OPTIONAL,

partyName [1] DirectoryString }

-- OID e sintaxe da extens~ao issuer alternative name

id-ce-issuerAltName OBJECT IDENTIFIER ::= { id-ce 18 }

IssuerAltName ::= GeneralNames

id-ce-subjectDirectoryAttributes OBJECT IDENTIFIER ::= { id-ce 9 }

SubjectDirectoryAttributes ::= SEQUENCE SIZE (1..MAX) OF Attribute

-- OID e sintaxe da extens~ao basic constraints

id-ce-basicConstraints OBJECT IDENTIFIER ::= { id-ce 19 }

BasicConstraints ::= SEQUENCE {

cA BOOLEAN DEFAULT FALSE,

pathLenConstraint INTEGER (0..MAX) OPTIONAL }

-- OID e sintaxe de da extesn~ao name constraints

id-ce-nameConstraints OBJECT IDENTIFIER ::= { id-ce 30 }

NameConstraints ::= SEQUENCE {

permittedSubtrees [0] GeneralSubtrees OPTIONAL,

excludedSubtrees [1] GeneralSubtrees OPTIONAL }

GeneralSubtrees ::= SEQUENCE SIZE (1..MAX) OF GeneralSubtree

GeneralSubtree ::= SEQUENCE {

base GeneralName,

minimum [0] BaseDistance DEFAULT 0,

maximum [1] BaseDistance OPTIONAL }

BaseDistance ::= INTEGER (0..MAX)

-- OID e sintaxe da extens~ao policy constraints

id-ce-policyConstraints OBJECT IDENTIFIER ::= { id-ce 36 }

PolicyConstraints ::= SEQUENCE {

requireExplicitPolicy [0] SkipCerts OPTIONAL,

inhibitPolicyMapping [1] SkipCerts OPTIONAL }


Ern

andes

109



-- OID e sintaxe da extens~ao CRL distribution points

id-ce-cRLDistributionPoints OBJECT IDENTIFIER ::= {id-ce 31}

CRLDistributionPoints ::= SEQUENCE SIZE (1..MAX) OF DistributionPoint

DistributionPoint ::= SEQUENCE {


reasons [1] ReasonFlags OPTIONAL,

cRLIssuer [2] GeneralNames OPTIONAL }

DistributionPointName ::= CHOICE {

fullName [0] GeneralNames,

nameRelativeToCRLIssuer [1] RelativeDistinguishedName }

ReasonFlags ::= BIT STRING {

unused (0),

keyCompromise (1),

cACompromise (2),


superseded (4),




aACompromise (8) }

-- OID e sintaxe da extens~ao extended key usage

id-ce-extKeyUsage OBJECT IDENTIFIER ::= {id-ce 37}

ExtKeyUsageSyntax ::= SEQUENCE SIZE (1..MAX) OF KeyPurposeId

KeyPurposeId ::= OBJECT IDENTIFIER

-- uso de chave n~ao especificada

anyExtendedKeyUsage OBJECT IDENTIFIER ::= { id-ce-extKeyUsage 0 }

-- OIDs para extended key purpose

id-kp-serverAuth OBJECT IDENTIFIER ::= { id-kp 1 }

id-kp-clientAuth OBJECT IDENTIFIER ::= { id-kp 2 }

id-kp-codeSigning OBJECT IDENTIFIER ::= { id-kp 3 }

id-kp-emailProtection OBJECT IDENTIFIER ::= { id-kp 4 }

id-kp-timeStamping OBJECT IDENTIFIER ::= { id-kp 8 }

id-kp-OCSPSigning OBJECT IDENTIFIER ::= { id-kp 9 }

-- OID e sintaxe de inhibit any policy


Ern

andes

110


id-ce-inhibitAnyPolicy OBJECT IDENTIFIER ::= { id-ce 54 }

InhibitAnyPolicy ::= SkipCerts

-- OID e sintaxe da extens~ao freshest (delta)CRL



-- authority info access

id-pe-authorityInfoAccess OBJECT IDENTIFIER ::= { id-pe 1 }

AuthorityInfoAccessSyntax ::=





-- subject info access

id-pe-subjectInfoAccess OBJECT IDENTIFIER ::= { id-pe 11 }

SubjectInfoAccessSyntax ::=


-- OID e sintaxe da extens~ao CRL number

id-ce-cRLNumber OBJECT IDENTIFIER ::= { id-ce 20 }

CRLNumber ::= INTEGER (0..MAX)

-- OID e sintaxe da extens~ao issuing distribution point

id-ce-issuingDistributionPoint OBJECT IDENTIFIER ::= { id-ce 28 }

IssuingDistributionPoint ::= SEQUENCE {


onlyContainsUserCerts [1] BOOLEAN DEFAULT FALSE,

onlyContainsCACerts [2] BOOLEAN DEFAULT FALSE,

onlySomeReasons [3] ReasonFlags OPTIONAL,

indirectCRL [4] BOOLEAN DEFAULT FALSE,

onlyContainsAttributeCerts [5] BOOLEAN DEFAULT FALSE }

-- at most one of onlyContainsUserCerts, onlyContainsCACerts,

-- and onlyContainsAttributeCerts may be set to TRUE.

id-ce-deltaCRLIndicator OBJECT IDENTIFIER ::= { id-ce 27 }


Ern

andes

111


BaseCRLNumber ::= CRLNumber

-- OID e sintaxe da extens~ao reason code

id-ce-cRLReasons OBJECT IDENTIFIER ::= { id-ce 21 }

CRLReason ::= ENUMERATED {

unspecified (0),

keyCompromise (1),

cACompromise (2),


superseded (4),



removeFromCRL (8),


aACompromise (10) }

-- OID e sintaxe da extens~ao certificate issuer CRL entry

id-ce-certificateIssuer OBJECT IDENTIFIER ::= { id-ce 29 }

CertificateIssuer ::= GeneralNames

-- OID e sintaxe da extens~ao hold instruction

id-ce-holdInstructionCode OBJECT IDENTIFIER ::= { id-ce 23 }

HoldInstructionCode ::= OBJECT IDENTIFIER

-- Arco holdinstruction do ANSI x9

holdInstruction OBJECT IDENTIFIER ::=

{joint-iso-itu-t(2) member-body(2) us(840) x9cm(10040) 2}

-- holdinstructions do ANSI X9

id-holdinstruction-none OBJECT IDENTIFIER ::=

{holdInstruction 1} -- deprecated

id-holdinstruction-callissuer OBJECT IDENTIFIER ::= {holdInstruction 2}

id-holdinstruction-reject OBJECT IDENTIFIER ::= {holdInstruction 3}

-- OID e sintaxe da extens~ao invalidity date CRL entry

id-ce-invalidityDate OBJECT IDENTIFIER ::= { id-ce 24 }


Ern

andes

112


InvalidityDate ::= GeneralizedTime

END

Apendice B. Notas ASN.1

As ACs DEVEM forcar o numero serialNumber ser um numero inteiro nao-negativo, ouseja, o bit sign na codificacao DER do valor INTEGER DEVE ser zero. Isso pode serfeito um octeto lider (mais a esqueda) ‘00’H se necessario. Isso remove uma ambiguidadepotencial no mapeamento entre um string de octetos e um valor inteiro.

Como observado na secao 4.1.2.2, numeros seriais poder conter inteiros longos. Os usuariosde certificado DEVEM ser capazes de manipular valores de serialNumber de ate 20 octe-tos. Emissores de LCR em conformidade NAO DEVEM usar cRLNumber maiores que 20octetos.

O construtor “SEQUENCE SIZE (1..MAX) OF” aparece em diversos construtores ASN.1.Uma sequencia valida tera 0 ou mais entradas. O construtor SIZE (1..MAX) restringe asequencia a ter no mınimo uma entrada. MAX indica que o upper bound nao e especificado.As implementacoes ficam livres para a escolha de um limite superior apropriado aos seusambientes.

O tipo caractere string PrintableString suporta um conjunto bem basico de Latin: as letrasminusculas de ‘a’ a ‘z’, as letras miusculas de ´A’ a ‘Z’, os dıgitos de ‘0’ a ‘9’, onze caracteresespeciais ´ = ( ) + , - . / : ? e espaco.

Os implementadores devem observar que caracteres sinal ‘em’ (´@’) e underscore (‘ ’) naosao suportados pelo tipo ASN.1 PrintableString. Esses caracteres normalmente aparecemem enderecos Internet. Tais enderecos DEVEM ser codificados usando um tipo ASN.1 queos suporte. Eles sao codificados geralmente como IA5String nos atributos emailAddresscom um distinguished name ou campo rfc822Name do GeneralName. Implementacoes emconformidade NAO DEVEM codificar strings que incluem esses caracteres como Printa-bleString.

O tipo caracter string TeletexSring e um superconjunto de PrintableString. TeletexStringsuporta um padrao relativo (ASCII-afins) do conjunto de caracteres Latin: caracteres Latincom acentos nao espacados e caracteres japoneses.

Listas de bit nomeados sao do tipo BIT STRINGs onde os valores estao associados a nomes.Esta especificacao faz uso de listas de bit nomeados nas definicoes das extensoes key usage,CRL distribution points, e extensao de certificado freshest CRL, assim como nas definicoesde extensao de LCR freshest CRL e issuing distribution point. Quando o DER codifica umalista de bit nomeados, os ultimos zeros DEVEM ser omitidos. Ou seja, o valor codificadoencerra com o ultimo bit nomeado ao qual e atribuıdo o valor 1.

O tipo caractere string UniversalString suporta qualquer dos caracteres permitidos em[ISO10646]. O ISO 10646 e o conjunto o conjunto de caracteres multi-octetos Universal(UCS).


Ern

andes

113


O tipo caractere string UTF8String foi introduzido na versao 1997 do ASN.1, e UTF8Stringfoi adicionado na lista de escolhas do DirectoryString na versao 2001 de [X.520]. UTF8Stringe um tipo universal e tem sido atribuıdo o numero da etiqueta 12. O conteudo de UTF8Stringfoi definido na RFC 2044 e atualizado pela RFC 2279, que foi atualizada em [RFC3629].

Em antecipacao a estas mudancas, e em conformidade com as melhores praticas IETFcodificada em [RFC2277, IETF Policy on Character Sets and Languages, este documentoinclui UTF8String como uma das escolhas em DirectoryString e no qualificador userNoticecertificate policy.

Para muito dos tipos de atributo definidos em [X.520], o AtributeValue usa o tipo Direc-toryString. Dos atributos especificados no Apendice A, todos os atributos name, surname,givenName, initials, generationQualifier, commonName, localityName, stateOrProvince-Name, organizationName, organizationUnitName, title, e pseudonym usam tipo Direc-toryString. X.520 usa uma definicao de tipo parametrizada [X.683] de DirectoryStringpara especificar a sintaxe de cada um desses atributos. O parametro e usado para indicar otamanho do string permitido no atributo. No Apendice A, para evitar o uso de definicao detipo parametrizada, o tipo DirectoryString e escrito em sua forma expandida na definicaode cada um desses tipos de atributo. Assim, o ASN.1 no Apendice A descreve a sintaxepara cada um desses atributos como sendo uma CHOICE of TeletexString, PrintableS-tring, UniversalString, UTF8String, e BMPString, com as restricoes apropriadas para parao tamanho do string de cada um dos tipos da CHOICE, ao inves de usar o tipo ASN.1DirectoryString para descrever a sintaxe.

Os implementadores deveriam observar que a codificacao DER de valores SET OF neces-sita a ordenacao das codificacoes dos valores. Em particular, esta questao diz respeito aosnomes distintos (distinguished names).

Os implementadores deveriam observar que a codificacao DER dos componentes SET ouSEQUENCE cujo valor e DEFAULT omite o componente no certificado ou LCR codificada.Por exemplo, a extensao BasicConstraints cujo valor booleano cA e falso, omitira o valorbooleano cA do certificado codificado.

Os Identificadores de Objetos (OIDs) sao utilizados nesta especificacao para identificacaode polıticas de certificados, chave publica e algoritmos de assinatura, extensoes de certi-ficado, etc. Nao existe um numero maximo para OIDs. Esta especificacao exige suporteaos OIDs que possuem elementos de arco com valores que sao menores que 2ˆ28, ou seja,eles DEVEM estar entre 0 e 268.435,455, inclusive. Isto permite que o elemento do arcoseja representado em um palavre de 32 bits. As implementacoes DEVEM tambem suportarOIDs onde o tamanho de decimais pontuados (ver secao1.4 de [RFC4512]) representadosem string possa ser de ate 100 bytes (inclusive). As implementacoes DEVEM ser capazes detratar OIDs com ate 20 elementos (inclusive). As ACs NAO DEVERIAM emitir certifica-dos que contenham OIDs que excedam esses requisitos. De maneira semelhante, emissoresde LCR NAO DEVERIAM emitir LCRs que contenham OIDs que excedam esses requisitos.

As regras para contexto especıficdo de codificacao de valores de campo GeneralName na ex-tensao nameConstraints diferem das regras que se aplicam as outras extensoes. Em todas asoutras extensoes de certificado, LCR, e extensoes de entrada LCR, especificadas no presentedocumento, as regras de codificacao estao de acordo com as regras para o tipo subjacente.Por exemplo, valores no campo uniformResourceIdentifier devem conter um valor URI con-


Ern

andes

114


forme especificado em [RFC3986]. As regras especıficas para contexto usadas para codificarvalores na extensao nameConstraints sao especificadas na secao 4.2.1.10, e essas regras po-dem nao estar em conformidade com as regras usadas nos tipos subjecentes. Por exemplo,quando um campo uniformResourceIdentifier aparece em uma extensao nameConstraints,ele deve conter um nome DNS (ex: “host.example.com”ou“example.com”) ao inves da URI.

Os implementadores sao avisados que a comunidade de padroes X.500 desenvolveu umaserie de regras de extensibilidade. Essas regras determinam quando uma definicao ASN.1pode ser modificada sem a atribuicao de um novo Identificador de Objeto (OID). Porexemplo, no mınimo duas definicoes de extensao incluıdas em [RFC2459], o predecessordeste documento de perfil, possuem definicoes ASN.1 diferentes nesta especificacao, maso mesmo OID e utilizado. Se elementos desconhecidos aparecerem em uma extensao, ea extensao nao estiver marcada como crıtica, aqueles elementos desconhecidos podem serignorados, da seguinte forma:

(a) ignore todo bit desconhecido atribuıdo dentro de um bit string;

(b) ignore todos os numeros nomeado em um tipo ENUMERATE ou tipo INTEGERque esta sendo usado no estilo enumerado, desde que o numero ocorra como umelemento opcional de um SET ou SEQUENCE; e

(c) ignore todos os elementos desconhecidos em SETs, no final de SEQUENCEs, ou emCHOICEs onde a CHOICE e um elemento opcional de um SET ou SEQUENCE.

Se uma extensao contendo um valor nao esperado e marcada como crıtica, a implementacaoDEVE rejeitar o certificado ou LCR que contenha a extensao nao reconhecida.

Apendice C. Exemplos

Este anexo contem quatro exemplos: tres certificados e uma CRL. Os dois primeiros certi-ficados e a CRL compreendem um caminho de certificacao mınima.

O Apendice C.1 contem um hexadecimal comentado de um certificado“auto-assinado” emi-tido por uma AC cujo nome distinto e cn=Example CA, dc=example, dc=com. O certifi-cado contem uma chave RSA publica, e e assinado pela chave RSA privada correspondente.

O Apendice C.2 contem um hexadecimal comentado de um certificado de entidade final.O certificado de entidade final contem uma chave RSA publica, e e assinado pela chaveprivada correspondente ao certificado “auto-assinado” do Apendice C.1.

O Apendice C.3 contem um hexadecimal comentado de um certificado de entidade finalque contem uma chave publica DSA com parametros, e e assinado com DSA e SHA-1. Estecertificado nao e parte do caminho de certificacao mınimo.

O Apendice C.4 contem um hexadecimal comentado de uma LCR. A LCR e emitida pelaAC cujo nome distinto e cn=Example CA, dc=example, dc=com, e a lista de certificadosrevogados inclui o certificado de entidade final apresentado no Apendice C.2.

O certificado foi processado usando o utilitario dumpsan1 de Peter Gutmann para gerar asaıda. O fonte para o utilitario dumpasn1 esta disponıvel em<http://www.cs.auckland.ac.nz/˜pgut001/dumpasn1.c>. Os binarios para os certificados e LCRs estao disponıveis em


Ern

andes

115


http://csrc.nist.gov/groups/ST/crypto apps infra/documents/pkixtools.

Nos locais deste apendice onde nomes distintos sao especificados usando representacaostring, os strings sao formados usando as regras especificadas em [RFC4514].

C.1 Certificado “auto-assinado” RSA

Este apendice contem uma imagem hexadecimal comentada de um certificado de 578 bytesversao 3. O certificado contem as seguintes informacoes

(a) o numero serial e 17;

(b) o certificado e assinado com RSA e algoritmo de hash SHA-1;

(c) o nome distinto do emissor e cn=Example CA,dc=example,dc=com;

(d) o nome distinto do sujeito e cn=Example CA,dc=example,dc=com;

(e) o certificado foi emitido em 30 de abril de 2004, e expirado em 30 de abril de 2005;

(f) o certificado contem uma chave publica RSA de 1024 bit;

(g) o certificado contem uma extensao subject key identifier gerada com o metodo (1)da secao 4.2.1.2; e

(h) O certificado e um certificado de AC (como indicado atraves da extensao basicconstraints).

0 574: SEQUENCE {

4 423: SEQUENCE {

8 3: [0] {

10 1: INTEGER 2

: }

13 1: INTEGER 17

16 13: SEQUENCE {

18 9: OBJECT IDENTIFIER

: sha1withRSAEncryption (1 2 840 113549 1 1 5)

29 0: NULL

: }

31 67: SEQUENCE {

33 19: SET {

35 17: SEQUENCE {


: domainComponent (0 9 2342 19200300 100 1 25)

49 3: IA5String ‘com’

: }

: }

54 23: SET {

56 21: SEQUENCE {



70 7: IA5String ‘example’


Ern

andes

116


: }

: }

79 19: SET {

81 17: SEQUENCE {

83 3: OBJECT IDENTIFIER commonName (2 5 4 3)

88 10: PrintableString ‘Example CA’

: }

: }

: }

100 30: SEQUENCE {

102 13: UTCTime 30/04/2004 14:25:34 GMT

117 13: UTCTime 30/04/2005 14:25:34 GMT

: }

132 67: SEQUENCE {

134 19: SET {

136 17: SEQUENCE {




: }

: }

155 23: SET {

157 21: SEQUENCE {




: }

: }

180 19: SET {

182 17: SEQUENCE {



: }

: }

: }

201 159: SEQUENCE {

204 13: SEQUENCE {


: rsaEncryption (1 2 840 113549 1 1 1)

217 0: NULL

: }

219 141: BIT STRING, encapsulates {

223 137: SEQUENCE {

226 129: INTEGER

: 00 C2 D7 97 6D 28 70 AA 5B CF 23 2E 80 70 39 EE

: DB 6F D5 2D D5 6A 4F 7A 34 2D F9 22 72 47 70 1D

: EF 80 E9 CA 30 8C 00 C4 9A 6E 5B 45 B4 6E A5 E6

: 6C 94 0D FA 91 E9 40 FC 25 9D C7 B7 68 19 56 8F

: 11 70 6A D7 F1 C9 11 4F 3A 7E 3F 99 8D 6E 76 A5

: 74 5F 5E A4 55 53 E5 C7 68 36 53 C7 1D 3B 12 A6


Ern

andes

117


: 85 FE BD 6E A1 CA DF 35 50 AC 08 D7 B9 B4 7E 5C

: FE E2 A3 2C D1 23 84 AA 98 C0 9B 66 18 9A 68 47

: E9

358 3: INTEGER 65537

: }

: }

: }

363 66: [3] {

365 64: SEQUENCE {

367 29: SEQUENCE {

369 3: OBJECT IDENTIFIER subjectKeyIdentifier (2 5 29 14)

374 22: OCTET STRING, encapsulates {

376 20: OCTET STRING

: 08 68 AF 85 33 C8 39 4A 7A F8 82 93 8E 70 6A 4A

: 20 84 2C 32

: }

: }

398 14: SEQUENCE {

400 3: OBJECT IDENTIFIER keyUsage (2 5 29 15)

405 1: BOOLEAN TRUE


410 2: BIT STRING 1 unused bits

: ‘0000011’B

: }

: }

414 15: SEQUENCE {

416 3: OBJECT IDENTIFIER basicConstraints (2 5 29 19)

421 1: BOOLEAN TRUE


426 3: SEQUENCE {

428 1: BOOLEAN TRUE

: }

: }

: }

: }

: }

: }

43 1 13: SEQUENCE {



444 0: NULL

: }

446 129: BIT STRING

: 6C F8 02 74 A6 61 E2 64 04 A6 54 0C 6C 72 13 AD

: 3C 47 FB F6 65 13 A9 85 90 33 EA 76 A3 26 D9 FC

: D1 0E 15 5F 28 B7 EF 93 BF 3C F3 E2 3E 7C B9 52

: FC 16 6E 29 AA E1 F4 7A 6F D5 7F EF B3 95 CA F3

: 66 88 83 4E A1 35 45 84 CB BC 9B B8 C8 AD C5 5E

: 46 D9 0B 0E 8D 80 E1 33 2B DC BE 2B 92 7E 4A 43

: A9 6A EF 8A 63 61 B3 6E 47 38 BE E8 0D A3 67 5D


Ern

andes

118


: F3 FA 91 81 3C 92 BB C5 5F 25 25 EB 7C E7 D8 A1

: }

C.2 Certificado de Entidade Final Usando RSA



(b) o certificado e assinado com RSA e algoritmo de hash SHA-1;

(c) o nome distinto do emissor e cn=Example CA,dc=example,dc=com;

(d) o nome distinto do sujeito e cn=End Entity CA,dc=example,dc=com;

(e) o certificado era valido de 15 de setembro de 2004, ate 15 de marco de 2005;

(f) o certificado contem uma chave publica RSA de 1024 bit;

(g) o certificado e um certificado de entidade final, assim, a extensao basic constrainsnao esta presente;

(h) o certificado contem a extensao authority key identifier correspondendo ao subjectkey identifier do certificado do apendice C.1; e

(i) o certificado inclui um nome alternativo – um endereco de correio eletronico (rfc822Name)de “[email protected]”.

(j) O certificado e um certificado de AC (como indicado na extensao basic constraints).

0 625: SEQUENCE {

4 474: SEQUENCE {

8 3: [0] {

10 1: INTEGER 2

: }

13 1: INTEGER 18

16 13: SEQUENCE {



29 0: NULL

: }

31 67: SEQUENCE {

33 19: SET {

35 17: SEQUENCE {




: }

: }

54 23: SET {

56 21: SEQUENCE {


Ern

andes

119





: }

: }

79 19: SET {

81 17: SEQUENCE {



: }

: }

: }

100 30: SEQUENCE {

102 13: UTCTime 15/09/2004 11:48:21 GMT

117 13: UTCTime 15/03/2005 11:48:21 GMT

: }

132 67: SEQUENCE {

134 19: SET {

136 17: SEQUENCE {




: }

: }

155 23: SET {

157 21: SEQUENCE {




: }

: }

180 19: SET {

182 17: SEQUENCE {


189 10: PrintableString ‘End Entity’

: }

: }

: }

201 159: SEQUENCE {

204 13: SEQUENCE {


: rsaEncryption (1 2 840 113549 1 1 1)

217 0: NULL

: }


223 137: SEQUENCE {

226 129: INTEGER

: 00 E1 6A E4 03 30 97 02 3C F4 10 F3 B5 1E 4D 7F

: 14 7B F6 F5 D0 78 E9 A4 8A F0 A3 75 EC ED B6 56

: 96 7F 88 99 85 9A F2 3E 68 77 87 EB 9E D1 9F C0


Ern

andes

120


: B4 17 DC AB 89 23 A4 1D 7E 16 23 4C 4F A8 4D F5

: 31 B8 7C AA E3 1A 49 09 F4 4B 26 DB 27 67 30 82

: 12 01 4A E9 1A B6 C1 0C 53 8B 6C FC 2F 7A 43 EC

: 33 36 7E 32 B2 7B D5 AA CF 01 14 C6 12 EC 13 F2

: 2D 14 7A 8B 21 58 14 13 4C 46 A3 9A F2 16 95 FF

: 23

358 3: INTEGER 65537

: }

: }

: }

363 117: [3] {

365 115: SEQUENCE {

367 33: SEQUENCE {

369 3: OBJECT IDENTIFIER subjectAltName (2 5 29 17)


376 24: SEQUENCE {

378 22: [1] ‘[email protected]’

: }

: }

: }

402 29: SEQUENCE {




: 17 7B 92 30 FF 44 D6 66 E1 90 10 22 6C 16 4F C0

: 8E 41 DD 6D

: }

: }

433 31: SEQUENCE {


: authorityKeyIdentifier (2 5 29 35)


442 22: SEQUENCE {

444 20: [0]

: 08 68 AF 85 33 C8 39 4A 7A F8 82 93 8E 70 6A

: 4A 20 84 2C 32

: }

: }

: }

466 14: SEQUENCE {


473 1: BOOLEAN TRUE



: ‘11’B

: }

: }

: }

: }

: }


Ern

andes

121


482 13: SEQUENCE {



495 0: NULL

: }

497 129: BIT STRING

: 00 20 28 34 5B 68 32 01 BB 0A 36 0E AD 71 C5 95

: 1A E1 04 CF AE AD C7 62 14 A4 1B 36 31 C0 E2 0C

: 3D D9 1E C0 00 DC 10 A0 BA 85 6F 41 CB 62 7A B7

: 4C 63 81 26 5E D2 80 45 5E 33 E7 70 45 3B 39 3B

: 26 4A 9C 3B F2 26 36 69 08 79 BB FB 96 43 77 4B

: 61 8B A1 AB 91 64 E0 F3 37 61 3C 1A A3 A4 C9 8A

: B2 BF 73 D4 4D E4 58 E4 62 EA BC 20 74 92 86 0E

: CE 84 60 76 E9 73 BB C7 85 D3 91 45 EA 62 5D CD

: }

C.3 Certificado de Entidade Final Usando DSA



(b) o certificado e assinado com DSA e algoritmo de hash SHA-1;

(c) o nome distinto do emissor e cn=Example DSA CA,dc=example,dc=com;

(d) o nome distinto do sujeito e cn=DSA End Entity,dc=example,dc=com;

(e) o certificado foi emitido em 2 de maio de 2004, e expirado em 2 de maio de 2005;

(f) o certificado contem uma chave publica DSA de 1024 bit com parametros;

(g) o certificado e um certificado de entidade final (nao um certificado de AC);

(h) o certificado inclui um subject alternative name de“<http://www.example.com/users/DSAendentity.html>” e um alternative namede “<http://www.examplo.com>” – ambos sao URLs;

(i) O certificado inlcui uma extensao authority key identifier e uma extensao certificatepolicies especificando o OID da polıtica 2.16.840.1.101.3.2.1.48.9; e

(j) o certificado inclui uma extensao crıtica key usage especificando que a chave publicase destina a verificacao de assinaturas digitais.

0 910: SEQUENCE {

4 846: SEQUENCE {

8 3: [0] {

10 1: INTEGER 2

: }

13 2: INTEGER 256

17 9: SEQUENCE {


Ern

andes

122


19 7: OBJECT IDENTIFIER dsaWithSha1 (1 2 840 10040 4 3)

: }

28 71: SEQUENCE {

30 19: SET {

32 17: SEQUENCE {




: }

: }

51 23: SET {

53 21: SEQUENCE {




: }

: }

76 23: SET {

78 21: SEQUENCE {


85 14: PrintableString ‘Example DSA CA’

: }

: }

: }

101 30: SEQUENCE {

103 13: UTCTime 02/05/2004 16:47:38 GMT

118 13: UTCTime 02/05/2005 16:47:38 GMT

: }

133 71: SEQUENCE {

135 19: SET {

137 17: SEQUENCE {




: }

: }

156 23: SET {

158 21: SEQUENCE {




: }

: }

181 23: SET {

183 21: SEQUENCE {


190 14: PrintableString ‘DSA End Entity’

: }

: }

: }


Ern

andes

123


206 439: SEQUENCE {

210 300: SEQUENCE {

214 7: OBJECT IDENTIFIER dsa (1 2 840 10040 4 1)

223 287: SEQUENCE {

227 129: INTEGER

: 00 B6 8B 0F 94 2B 9A CE A5 25 C6 F2 ED FC FB 95

: 32 AC 01 12 33 B9 E0 1C AD 90 9B BC 48 54 9E F3

: 94 77 3C 2C 71 35 55 E6 FE 4F 22 CB D5 D8 3E 89

: 93 33 4D FC BD 4F 41 64 3E A2 98 70 EC 31 B4 50

: DE EB F1 98 28 0A C9 3E 44 B3 FD 22 97 96 83 D0

: 18 A3 E3 BD 35 5B FF EE A3 21 72 6A 7B 96 DA B9

: 3F 1E 5A 90 AF 24 D6 20 F0 0D 21 A7 D4 02 B9 1A

: FC AC 21 FB 9E 94 9E 4B 42 45 9E 6A B2 48 63 FE

: 43

359 21: INTEGER

: 00 B2 0D B0 B1 01 DF 0C 66 24 FC 13 92 BA 55 F7

: 7D 57 74 81 E5

382 129: INTEGER

: 00 9A BF 46 B1 F5 3F 44 3D C9 A5 65 FB 91 C0 8E

: 47 F1 0A C3 01 47 C2 44 42 36 A9 92 81 DE 57 C5

: E0 68 86 58 00 7B 1F F9 9B 77 A1 C5 10 A5 80 91

: 78 51 51 3C F6 FC FC CC 46 C6 81 78 92 84 3D F4

: 93 3D 0C 38 7E 1A 5B 99 4E AB 14 64 F6 0C 21 22

: 4E 28 08 9C 92 B9 66 9F 40 E8 95 F6 D5 31 2A EF

: 39 A2 62 C7 B2 6D 9E 58 C4 3A A8 11 81 84 6D AF

: F8 B4 19 B4 C2 11 AE D0 22 3B AA 20 7F EE 1E 57

: 18

: }

: }


518 128: INTEGER

: 30 B6 75 F7 7C 20 31 AE 38 BB 7E 0D 2B AB A0 9C

: 4B DF 20 D5 24 13 3C CD 98 E5 5F 6C B7 C1 BA 4A

: BA A9 95 80 53 F0 0D 72 DC 33 37 F4 01 0B F5 04

: 1F 9D 2E 1F 62 D8 84 3A 9B 25 09 5A 2D C8 46 8E

: 2B D4 F5 0D 3B C7 2D C6 6C B9 98 C1 25 3A 44 4E

: 8E CA 95 61 35 7C CE 15 31 5C 23 13 1E A2 05 D1

: 7A 24 1C CB D3 72 09 90 FF 9B 9D 28 C0 A1 0A EC

: 46 9F 0D B8 D0 DC D0 18 A6 2B 5E F9 8F B5 95 BE

: }

: }

649 202: [3] {

652 199: SEQUENCE {

655 57: SEQUENCE {

657 3: OBJECT IDENTIFIER subjectAltName (2 5 29 17)


664 48: SEQUENCE {

666 46: [6]

: ‘http://www.example.com/users/DSAendentity.’

: ‘html’


Ern

andes

124


: }

: }

: }

714 33: SEQUENCE {

716 3: OBJECT IDENTIFIER issuerAltName (2 5 29 18)


723 24: SEQUENCE {

725 22: [6] ‘http://www.example.com’

: }

: }

: }

749 29: SEQUENCE {




: DD 25 66 96 43 AB 78 11 43 44 FE 95 16 F9 D9 B6

: B7 02 66 8D

: }

: }

780 31: SEQUENCE {




789 22: SEQUENCE {

791 20: [0]

: 86 CA A5 22 81 62 EF AD 0A 89 BC AD 72 41 2C

: 29 49 F4 86 56

: }

: }

: }

813 23: SEQUENCE {

815 3: OBJECT IDENTIFIER certificatePolicies (2 5 29 32)


822 14: SEQUENCE {

824 12: SEQUENCE {

826 10: OBJECT IDENTIFIER ‘2 16 840 1 101 3 2 1 48 9’

: }

: }

: }

: }

838 14: SEQUENCE {


845 1: BOOLEAN TRUE



: ‘1’B (bit 0)

: }

: }

: }

: }


Ern

andes

125


: }

854 9: SEQUENCE {

856 7: OBJECT IDENTIFIER dsaWithSha1 (1 2 840 10040 4 3)

: }


868 44: SEQUENCE {

870 20: INTEGER

: 65 57 07 34 DD DC CA CC 5E F4 02 F4 56 42 2C 5E

: E1 B3 3B 80

892 20: INTEGER

: 60 F4 31 17 CA F4 CF FF EE F4 08 A7 D9 B2 61 BE

: B1 C3 DA BF

: }

: }

: }

C.4 Lista de Certificados Revogados

Este apendice contem uma imagem hexadecimal comentada de uma LCR versao 2 com duasextensoes (cRLNumber e authorityKeyIdentifier). A LCR foi emitida por cn=ExampleCA,dc=example,dc=com em 5 de ferereiro de 2005; a proxima emissao agendada era 6de fevereiro de 2005. A LCR inclui um certificado revogado: serial number 18, que foirevogado em 19 de novembro de 2004 devido a keyCompromise. A LCR propriamente ditatem numero 12, e foi assinada com RSA e SHA-1.

0 352: SEQUENCE {

4 202: SEQUENCE {

7 1: INTEGER 1

10 13: SEQUENCE {



23 0: NULL

: }

25 67: SEQUENCE {

27 19: SET {

29 17: SEQUENCE {




: }

: }

48 23: SET {

50 21: SEQUENCE {




: }

: }

73 19: SET {


Ern

andes

126


75 17: SEQUENCE {



: }

: }

: }

94 13: UTCTime 05/02/2005 12:00:00 GMT

109 13: UTCTime 06/02/2005 12:00:00 GMT

124 34: SEQUENCE {

126 32: SEQUENCE {

128 1: INTEGER 18

131 13: UTCTime 19/11/2004 15:57:03 GMT

146 12: SEQUENCE {

148 10: SEQUENCE {

150 3: OBJECT IDENTIFIER cRLReason (2 5 29 21)


157 1: ENUMERATED 1

: }

: }

: }

: }

: }

160 47: [0] {

162 45: SEQUENCE {

164 31: SEQUENCE {




173 22: SEQUENCE {

175 20: [0]

: 08 68 AF 85 33 C8 39 4A 7A F8 82 93 8E 70 6A

: 4A 20 84 2C 32

: }

: }

: }

197 10: SEQUENCE {

199 3: OBJECT IDENTIFIER cRLNumber (2 5 29 20)


206 1: INTEGER 12

: }

: }

: }

: }

: }

209 13: SEQUENCE {



222 0: NULL

: }

224 129: BIT STRING


Ern

andes

127


: 22 DC 18 7D F7 08 CE CC 75 D0 D0 6A 9B AD 10 F4

: 76 23 B4 81 6E B5 6D BE 0E FB 15 14 6C C8 17 6D

: 1F EE 90 17 A2 6F 60 E4 BD AA 8C 55 DE 8E 84 6F

: 92 F8 9F 10 12 27 AF 4A D4 2F 85 E2 36 44 7D AA

: A3 4C 25 38 15 FF 00 FD 3E 7E EE 3D 26 12 EB D8

: E7 2B 62 E2 2B C3 46 80 EF 78 82 D1 15 C6 D0 9C

: 72 6A CB CE 7A ED 67 99 8B 6E 70 81 7D 43 42 74

: C1 A6 AF C1 55 17 A2 33 4C D6 06 98 2B A4 FC 2E

: }

Endereco dos Autores

National Institute of Standards and Technology100 Bureau Drive, Mail Stop 8930Gaithersburg, MD 20899-8930USAEMail: [email protected]

Stefan SantessonMicrosoftOne Microsoft WayRedmond, WA 98052USAEMail: [email protected]

Stephen FarrellDistributed Systems GroupComputer Science DepartmentTrinity College DublinIrelandEMail: [email protected]

Sharon BoeyenEntrust1000 Innovation DriveOttawa, OntarioCanada K2K 3E7EMail: [email protected]

Russell HousleyVigil Security, LLC918 Spring Knoll DriveHerndon, VA 20170USAEMail: [email protected]


Ern

andes

128


Tim PolkNational Institute of Standards and Technology100 Bureau Drive, Mail Stop 8930Gaithersburg, MD 20899-8930USAEMail: [email protected]

Declaracao Plena de Propriedade Direitos Autorais

Copyright (C) The IETF Trust (2008).

Este documento esta sujeito aos direitos, licencas e restricoes contidas em BCP 78, e excetoo estabelecido no documento referenciado, os autores conservam todos os seus direitos.

Este documento e as informacoes aqui contidas sao fornecidas por uma base“COMO ESTA”e O COLABORADOR, A ORGANIZACAO QUE ELA(E) REPRESENTA OU E PATRO-CINADO (SE ALGUMA), A INTERNET SOCIETY, O IETF TRUST E O INTERNETENGINEERING TASK FORCE REJEITAM TODAS AS GARANTIAS, EXPRESSASOU IMPLICITAS, INCLUINDO, MAS NAO LIMITADO A QUALQUER GARANTIAQUE O USO DA INFORMACAO AQUI CONTIDA NAO INFRINGIRA QUAISQUERDIREITOS OU QUAISQUER GARANTIAS DE COMERCIALIZACAO OU ADEQUA-CAO PARA UM DETERMINADO PROPOSITO.

Propriedade Intelectual

O IETF nao toma posicao quanto a validade ou ambito de qualquer Direitos de PropriedadeIntelectual ou outros direitos que podem ser reclamados a figura da execucao ou utiliza-cao da tecnologia descrita nesse documento ou a medida em que qualquer licenca sob taisdireitos pode ou nao estar disponıvel; nem representa que ele tenha feito qualquer esforcoindependente para identificar quaisquer tipo de direitos. Informacoes sobre os procedimen-tos no que diz respeito aos direitos dos documentos RFC podem encontradas no BCP 78 eBCP 79.

Copias de divulgacoes IPR feitas para a Secretaria do IETF e quaisquer garantias de li-cencas a ser disponibilizado, ou o resultado de uma tentativa de obtencao de uma licencaou autorizacao geral para a utilizacao de tais direitos proprietarios pelos implementadoresou usuarios da presente especificacao, podem ser obtidas a partir do repositorio on-line doIETF em http://www.ietf.org/ipr.

O IETF convida qualquer parte interessada, para trazer ao seu conhecimento, qualquerdireitos de autor, patentes ou pedidos de patentes, ou outros direitos de propriedade que


Ern

andes

129


podem abranger tecnologia que possam ser necessarias para a implementacao desta norma.Favor enviar as informacoes para o IETF em [email protected].


network working group d. cooper request for comments: 5280 … · 2013. 3. 6. · es 2 pkix...

Documents