Ernandes

Transcrição

Ernandes

1
PKIX Certificate and CRL Profile
RFC 5280
Maio de 2008
OBS: A presente tradução não oficial da (RFC5280) tem como finalidade
facilitar o estudo e o entendimento da Norma.
D. Cooper
NIST
S. Santesson
Microsoft
S. Farrell
Trinity College Dublin
S. Boeyen
Entrust
R. Housley
Vigil Security
W. Polk
NIST
May 2008
nd
es
Network Working Group
Request for Comments: 5280
Obsoletes: 3280, 4325, 4630
Category: Standards Track
Er
na
Tradução para o Português
Internet X.509 Public Key Infrastructure Certificate
and Certificate Revocation List (CRL) Profile
Cooper, et al.
Standards Track
Tradução para Estudo
2
RFC 5280
Maio de 2008
Estado do Documento
Este documento especifica o protocolo padrão Internet a ser seguido para a Comunidade
Internet, e solicita discussão e sugestões para sua melhoria. Consulte a edição atual do
documento “Internet Official Protocol Standards” (STD 1) para obter a situação de padronização e o estado do presente protocolo. A distribuição deste documento é ilimitado.
Resumo
Er
na
nd
es
Este documento define os perfis para o certificado X.509 v3 e a lista de certificados revogados (LCR) X.509.v2 para uso na Internet. A introdução fornece uma visão geral dessa
abordagem e modelo. O formato do certificado X.509 v3 é descrito em detalhes, com informações adicionais sobre seu formato e a semântica dos formulários de nome Internet.
São descritas as extensões padrão do certificado e duas extensões especı́ficas da Internet.
É especificado o conjunto exigido de extensões. São descritos detalhes do formato da LCR
X.509 v2, juntamente com as extensões padrão e aquelas especı́ficas da Internet. É descrito
um algoritmo para validação do caminho de certificação X.509. Nos apêndices são fornecidos um módulo ASN.1 e exemplos.
Cooper, et al.
Standards Track
3
RFC 5280
Maio de 2008
Sumário
1 Introdução
6
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
8
8
8
9
9
3 Visão Geral do Modelo
3.1 Versão 3 do Certificado X.509 . . . .
3.2 Caminhos de certificação e Confiança
3.3 Revogação . . . . . . . . . . . . . . .
3.4 Protocolos Operacionais . . . . . . .
3.5 Protocolos de Gerenciamento . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
9
10
11
13
14
15
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
16
16
17
17
17
18
18
18
19
19
19
21
22
22
22
24
24
24
24
25
25
26
27
29
32
32
35
35
35
36
38
39
41
.
.
.
.
es
2 Requisitos e Pressupostos
2.1 Comunicação e Topologia . . . .
2.2 Critério de Acessibilidade . . . .
2.3 Expectativas dos Usuários . . . .
2.4 Expectativas dos Administradores
Er
na
nd
4 Perfil do Certificado e das Extensões do Certificado
4.1 Campos Básicos do Certificado . . . . . . . . . . . .
4.1.1 Campos do Certificado . . . . . . . . . . . . .
4.1.1.1 tbsCertificate . . . . . . . . . . . . .
4.1.1.2 signatureAlgorithm . . . . . . . . . .
4.1.1.3 signatureValue . . . . . . . . . . . .
4.1.2 TBSCertificate . . . . . . . . . . . . . . . . .
4.1.2.1 Version . . . . . . . . . . . . . . . .
4.1.2.2 Serial Number . . . . . . . . . . . .
4.1.2.3 Signature . . . . . . . . . . . . . . .
4.1.2.4 Issuer . . . . . . . . . . . . . . . . .
4.1.2.5 Validity . . . . . . . . . . . . . . . .
4.1.2.5.1 UTCTime . . . . . . . . . .
4.1.2.5.2 GeneralizedTime . . . . . .
4.1.2.6 Subject . . . . . . . . . . . . . . . .
4.1.2.7 Subject Public Key Info . . . . . . .
4.1.2.8 Unique Identifiers . . . . . . . . . . .
4.1.2.9 Extensions . . . . . . . . . . . . . .
4.2 Extensões do Certificado . . . . . . . . . . . . . . . .
4.2.1 Extensões Padrão . . . . . . . . . . . . . . . .
4.2.1.1 Authority Key Identifier . . . . . . .
4.2.1.2 Subject Key Identifier . . . . . . . .
4.2.1.3 Key Usage . . . . . . . . . . . . . .
4.2.1.4 Certificate Policies . . . . . . . . . .
4.2.1.5 Policy Mappings . . . . . . . . . . .
4.2.1.6 Subject Alternative Name . . . . . .
4.2.1.7 Issuer Alternative Name . . . . . . .
4.2.1.8 Subject Directory Attributes . . . .
4.2.1.9 Basic Constraints . . . . . . . . . . .
4.2.1.10 Name Constraints . . . . . . . . . .
4.2.1.11 Policy Constraints . . . . . . . . . .
4.2.1.12 Extended Key Usage . . . . . . . . .
4.2.1.13 CRL Distribution Points . . . . . . .
Cooper, et al.
Standards Track
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
4
4.2.2
RFC 5280
Maio de 2008
4.2.1.14 Inhibit anyPolicy . . . . . . . . . . . .
4.2.1.15 Freshest CRL (Delta CRL Distribution
Extensões Privadas Internet . . . . . . . . . . .
4.2.2.1 Authority Information Access . . . . .
4.2.2.2 Subject Information Access . . . . . .
. . . .
Point)
. . . .
. . . .
. . . .
na
nd
es
5 Perfil da LCR e das Extensões da LCR
5.1 Campos da LCR . . . . . . . . . . . . . . . . . . . . . . . .
5.1.1 Campos do CertiticateList . . . . . . . . . . . . . . .
5.1.1.1 tbsCertList . . . . . . . . . . . . . . . . . .
5.1.1.2 signatureAlgorithm . . . . . . . . . . . . . .
5.1.1.3 signatureValue . . . . . . . . . . . . . . . .
5.1.2 Certificate List “A Ser Assinado” . . . . . . . . . . .
5.1.2.1 Version . . . . . . . . . . . . . . . . . . . .
5.1.2.2 Signature . . . . . . . . . . . . . . . . . . .
5.1.2.3 Issuer Name . . . . . . . . . . . . . . . . . .
5.1.2.4 This Update . . . . . . . . . . . . . . . . .
5.1.2.5 Next Update . . . . . . . . . . . . . . . . .
5.1.2.6 Revoked Certificates . . . . . . . . . . . . .
5.1.2.7 Extensões . . . . . . . . . . . . . . . . . . .
5.2 Extensões da LCR . . . . . . . . . . . . . . . . . . . . . . .
5.2.1 Authority Key Identifier . . . . . . . . . . . . . . . .
5.2.2 Issuer Alternative Name . . . . . . . . . . . . . . . .
5.2.3 CRL Number . . . . . . . . . . . . . . . . . . . . . .
5.2.4 Delta CRL Indicator . . . . . . . . . . . . . . . . . .
5.2.5 Issuing Distribution Points . . . . . . . . . . . . . . .
5.2.6 Freshest CRL (Ponto de Distribuição de LCR delta) .
5.2.7 Authority Informatioin Access . . . . . . . . . . . . .
5.3 Extensões da Entrada da LCR . . . . . . . . . . . . . . . . .
5.3.1 Reason Code . . . . . . . . . . . . . . . . . . . . . .
5.3.2 Invalidity Date . . . . . . . . . . . . . . . . . . . . .
5.3.3 Certificate Issuer . . . . . . . . . . . . . . . . . . . .
Er
6 Validação de Caminho de Certificação
6.1 Validação Básica de Caminho . . . . . . . .
6.1.1 Entradas . . . . . . . . . . . . . . . .
6.1.2 Inicialização . . . . . . . . . . . . . .
6.1.3 Processamento Básico de Certificado
6.1.4 Preparação para o Certificado i+1 . .
6.1.5 Procedimento de Encerramento . . .
6.1.6 Saı́das . . . . . . . . . . . . . . . . .
6.2 Uso do Algoritmo de Validação de Caminho
6.3 Validação de LCR . . . . . . . . . . . . . . .
6.3.1 Entradas de Revogação . . . . . . . .
6.3.2 Processamento de LCR . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
42
43
43
44
45
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
47
49
49
49
50
50
50
51
51
51
51
51
52
52
52
53
53
53
54
56
58
58
59
60
60
61
.
.
.
.
.
.
.
.
.
.
.
61
62
64
66
68
72
74
75
75
76
76
77
7 Regras de Processamento para Nomes Internacionalizados
79
7.1 Nomes Internacionalizados em Distinguished Names . . . . . . . . . . . . . . 80
7.2 Nome de Domı́nio Internacionalizados em GeneralName . . . . . . . . . . . . 81
Cooper, et al.
Standards Track
5
7.3
7.4
7.5
RFC 5280
Maio de 2008
Nomes de Domı́nio Internacionalizados em Distinguished Names . . . . . . . 82
Identificadores de Recurso Internacionalizados . . . . . . . . . . . . . . . . . 82
Endereços de Correio Eletrônico Internacionalizados . . . . . . . . . . . . . . 83
8 Considerações de Segurança
84
9 Considerações IANA
87
10 Agradecimento
87
es
11 Referências
88
11.1 Referências Normativas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
11.2 Referências Informativas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
Apêndice B. Notas ASN.1
nd
Apêndice A. Estruturas e OIDs em Pseudo-ASN.1
91
A.1 Módulo Explicitamente Rotulado, sintaxe 1988 . . . . . . . . . . . . . . . . . 91
A.2 Módulo Implicitamente Rotulado, sintaxe 1988 . . . . . . . . . . . . . . . . . 105
Apêndice C. Exemplos
C.1 Certificado “auto-assinado” RSA . . .
C.2 Certificado de Entidade Final Usando
C.3 Certificado de Entidade Final Usando
C.4 Lista de Certificados Revogados . . .
.
.
.
.
na
Endereço dos Autores
. . .
RSA
DSA
. . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
112
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
114
. 115
. 118
. 121
. 125
127
128
Propriedade Intelectual
128
Er
Declaração Plena de Direitos Autorais
Cooper, et al.
Standards Track
6
1
RFC 5280
Maio de 2008
Introdução
A presente especificação é parte do conjunto de padrões para o X.509 - Infraestrutura de
Chaves Públicas (ICP) Internet.
A especificação define perfis do formato e da semântica de certificados, e listas de certificados revogados(LCRs) para a ICP Internet. São descritos procedimentos necessários para
o processamento dos caminhos de certificação no ambiente da Internet. Finalmente, nos
apêndices, são fornecidos módulos em ASN.1 para todas as estruturas de dados definidas
ou referenciadas.
es
A seção 2 descreve os requisitos de ICP na Internet e os pressupostos que se relacionam
ao escopo deste documento. A Seção 3 apresenta o modelo da arquitetura e descreve sua
relação com a norma IETF anterior, assim como com as normas ISO/IEC/ITU-T. Em
particular, é descrita a relação existente entre esta especificação e aquelas contidas nos
documentos PEM IETF e ISO/IEC/ITU-T X.509.
nd
Seção 4 define perfis para o certificado X.509 v3, e secção 5 define perfis para a LCR X.509
v2. Os perfis incluem a identificação de extensões ISO/IEC/ITU-T e extensões ANSI que
podem ser úteis na ICP Internet. Os perfis são apresentados em Syntax Notation One
(ASN.1) de 1988, em vez da sintaxe ASN.1 de 1997, utilizada nas normas mais recentes do
ISO/IEC/ITU-T.
na
Seção 6 inclui procedimentos para validação do caminho de certificação. Estes procedimentos baseiam-se nas definições do ISO/IEC/ITU-T. É NECESSÁRIO que as implementações
obtenham os mesmos resultados, embora não seja requerido que estas utilizem os procedimentos especificados.
Er
Os procedimentos para identificação e codificação de chave pública e assinaturas são definidos em [RFC3279], [RFC4055] e [RFC4491]. Não é obrigatório que as implementações
desta especificação usem quaisquer algoritmo criptográfico. Embora, as implementações em
conformidade com esta especificação, e que usam os algoritmos identificados em [RFC3279],
[RFC4055, e [RFC4491], DEVEM identificar e codificar os materiais de chave pública e assinaturas como descrito naquelas especificações.
Finalmente, são fornecidos três apêndices para ajudar nas implementações. O Apêndice
A contém todas as estruturas ASN.1 definidas ou referenciadas nesta especificação. Como
informado acima, o material é apresentado na versão ASN.1 de 1988. O apêndice B contém notas sobre caracterı́sticas menos conhecidas da notação ASN.1 utilizadas no presente
documento. O Apêndice C contém exemplos de certificados e LCR em conformidade com
esta especificação.
Esta especificação torna obsoleta a [RFC3280]. As diferenças entre a presente especificação
e aquela contida na [RFC3280] são listadas abaixo:
∗ Seção 7 especifica o suporte avançado a nomes internacionalizados, com regras para
codificação e satisfazem os Nomes de Domı́nios Internacionalizados, os Identificadores
de Recursos Internacionalizados (IRIs), e nomes distintos. Estas regras estão alinhadas com regras de comparação estabelecidas em RFC atualizadas, incluindo entre
estas, [RFC3490], [RFC3987], e [RFC4518].
Cooper, et al.
Standards Track
RFC 5280
Maio de 2008
∗ As seções 4.1.2.4 e 4.1.2.6 incorporam as condições para a continuação de uso do legado
dos esquemas de codificação especificados na [RFC4630]. Quando utilizado por ICP já
estabelecida, a transição para UTF8String poderia causar negação de serviço baseado
em falhas na cadeia de nomes ou processamento incorreto de restrições de nomes.
∗ A seção 4.2.1.4 da [RFC3280], que especifica a extensão de certificado privateKeyUsagePeriod, mas não incentiva o uso, foi removida. O uso dessa extensão padrão
ISO nem é incentivada, nem recomendada para ser utilizada em ambientes de ICP
Internet.
es
∗ A seção 4.2.15 recomenda que a extensão policy mappigns seja marcada como crı́tica.
A [RFC3280] recomendava que esta extensão fosse marcada como não crı́tica.
∗ A seção 4.2.1.11 recomenda a marcação da extensão policy constraints como crı́tica.
A [RFC3280] permitia que esta extensão fosse marcada como crı́tica ou não crı́tica.
nd
∗ A extensão Authority Information Access (AIA) da LCR, como especificada em
[RFC4325], foi adicionada na seção 5.2.7.
∗ A seção 5.2 e 5.3 esclarece as regra para o tratamento de extensões não reconhedidas
da LCR, assim como extensões de entrada da LCR, respectivamente.
∗ A seção 5.3.2 da [RFC3280], que especificava a extensão holdInstructionCode de entrada de LCR, foi removida.
na
∗ O algoritmo de validação de caminho especificado na seção 6, não controla mais a
criticidade das extensões de polı́ticas de certificado nas cadeias de certificados. Na
[RFC3280], esta informação era retornada para um terceiro confiável.
∗ A seção de Considerações de Segurança trata dos riscos relacionados a dependências
circulares causados pelo uso de esquemas https ou similares nos pontos de distribuição de LCR, acesso a informação de autoridade (AIA), ou extensões de acesso a
informações de sujeito (SIA).
Er
∗ A seção de Considerações de Segurança trata de riscos relacionados a ambiguidade
de nomes.
∗ A seção de Considerações de Segurança referencia a [RFC4210] quanto a procedimentos para tratar mudanças de operações de AC.
Os módulos ASN.1 contidos no apêndice A não foram modificados, exceto pelo conteúdo
de ub-emailaddress-length que foi mudado de 128 para 255, para se alinhar ao PKCS #9
[RFC2985].
As palavras-chave“DEVE”,“NÃO DEVE”,“NECESSÁRIO”,“DEVERÁ”,“NÃO DEVERÁ”,
“DEVERIA”, “NÃO DEVERIA”, “RECOMENDADO”, “PODE”, e “OPCIONAL” contantes no presente documento (em letras maiúsculas, como mostrado), devem ser interpretados
como descritas em [RFC2119].
Cooper, et al.
Standards Track
7
2
RFC 5280
Maio de 2008
Requisitos e Pressupostos
O objetivo desta especificação é desenvolver um perfil para facilitar o uso de certificados
X.509 dentro de aplicações de Internet para as comunidades que pretendem fazer uso da
tecnologia X.509. Tais aplicações podem incluir WWW, correio eletrônico, WWW eletrônica, autenticação de usuário, e IPsec. A fim de aliviar alguns dos obstáculos ao uso de
certificados X.509, este documento define um perfil para promover o desenvolvimento de
sistemas de gerenciamento de certificado, o desenvolvimento de ferramentas de aplicação e
a interoperabilidade determinada pela polı́tica.
es
Algumas comunidades terão de complementar ou substituir possivelmente, este perfil, a fim
de satisfazer as exigências de domı́nios de aplicações especializadas ou em ambientes com
autorização adicional, garantia, ou requisitos operacionais. No entanto, para aplicações
básicas, representações comuns de atributos usados frequentemente são definidos para que
os desenvolvedores de aplicativos possam obter as informações necessárias sem levar em
conta o emissor de um certificado especial ou a Lista de Certificados Revogados (LCR).
nd
O usuário de certificado deveria rever a polı́tica de certificado gerado pela Autoridade Certificadora (AC) antes de confiar nos serviços de autenticação ou não-repúdio associados com
a chave pública contida em determinado certificado. Por isso, esta norma não prescreve
regras juridicamente vinculativas ou deveres.
2.1
na
Com o surgimento de ferramentas adicionais para o tratamento de autorização suplementar e gestão de atributos, tais como os certificados de atributos, pode se tornar apropriado
limitar o conjunto de atributos de autenticação inclusos no certificado. Essas ferramentas
adicionais de gestão podem fornecer métodos mais adequados para transmissão de muitos
atributos autenticados.
Comunicação e Topologia
Er
Usuários de certificados irão operar em uma ampla gama de ambientes com relação a sua
topologia de comunicação, especialmente os usuários de correio eletrônico seguro. Este
perfil suporta usuários sem banda larga, em tempo real, conectividade IP, ou alta disponibilidade de conexão. Além disso, o perfil permite a presença de firewall ou qualquer outro
tipo de filtragem de comunicação.
Este perfil não considera a implantação de um sistema de diretório X.500 [X.500] ou de um
Lightweight Directory Access Protocol (LDAP) [RFC4510]. O perfil não proı́be a utilização
do serviço de diretório X.500 ou de um diretório LDAP; desta forma, qualquer meio de
distribuição de certificados e listas de certificados revogados (LCRs) pode ser usado.
2.2
Critério de Acessibilidade
O objetivo da Infraestrutura de Chaves Pública (PKI) é atender as necessidades de funções
determinı́sticas de identificação automatizada, autenticação e controle de acesso, e autorização. O suporte para esses serviços determina os atributos contidos no certificado, bem
como a informação de controle auxiliar contidas no certificado, tais como dados de polı́ticas
e restrições quanto ao caminho de certificação.
Cooper, et al.
Standards Track
8
2.3
RFC 5280
Maio de 2008
Expectativas dos Usuários
2.4
es
Os usuários da ICP Internet são pessoas e processos que usam o software cliente e são os
sujeitos nomeados nos certificados. Estes usos incluem destinatários e remetentes de correio
eletrônico, clientes de navegadores WWW, servidores WWW, e o gerenciador de chave para
IPsec dentro de um roteador. Este perfil reconhece as limitações das plataformas usadas por
esses usuários, assim como as limitações em termos de sofisticação e cuidados implementados
pelos próprios usuários. Isso se manifesta na responsabilidade mı́nima sobre a configuração
do usuário (por exemplo, chaves confiáveis de AC, regras), as limitações explı́citas de uso
da plataforma dentro do certificado, as restrições quanto ao caminho de certificação para
proteger o usuário de ações maliciosas, e aplicativos que automatizam funções de validação
de forma sensata.
Expectativas dos Administradores
3
nd
Tal como acontece com as expectativas dos usuários, o perfil para ICP Internet é estruturado de maneira a apoiar os indivı́duos que geralmente operam as ACs. Fornecer aos
administradores opções ilimitadas aumenta as chances de um erro sutil de um administrador resulte em comprometimento amplo. Além disso, as escolhas ilimitadas aumentam
muito a complexidade do software que processa e valida os certificados criados pela AC.
Visão Geral do Modelo
na
A seguir é uma visão simplificada do modelo de arquitetura assumido pela infra-estrutura
de chave pública usando X.509 (PKIX) especificações.
Os componentes deste modelo são:
usuário de certificados da ICP e/ou sistema usuário final, representado
no campo sujeito (subject) do certificado;
AC:
autoridade certificadora;
AR:
autoridade de registro, ou seja, é um sistema opcional para o qual a AC
delega determinadas funções de gestão;
Er
Entidade final:
Emissor de LCR: sistema que gera e assina LCRs, e
Repositório:
sistema ou conjunto de sistemas distribuı́dos que armazena certificados
e LCRs e que serve como meio de distribuição dos certificados e LCRs
para as entidades finais.
As ACs são responsáveis por indicar o status de revogação dos certificados que emitem. A
informação sobre o estado de revogação pode ser fornecida através do Online Certificate
Status Protocol (OCSP) [RFC2560], através de Listas de Certificados Revogados (LCR),
ou algum outro mecanismo. Em geral, quando as informações de status de revogação são
fornecida por CRLs, a AC também é o emissor da CRL. No entanto, uma AC pode delegar
a responsabilidade pela emissão das LCRs para uma entidade diferente.
Cooper, et al.
Standards Track
9
RFC 5280
Maio de 2008
10
Note-se que uma Autoridade de Atributos (AA) também pode optar por delegar a publicação de suas LCRs para um emissor de LCR.
nd
es
+--------------------+
<-------------------> |
Entidade Final
|
Transaç~
oes
+--------------------+
operacionais
^
e transaç~
oes de
| Transaç~
oes de
gerenciamento
| Gerenciamento
Usuários
v
da ICP
=======================
+--+-------------+
======================
^
^
entidades de
|
|
gerenciamento da
v
|
ICP
+------+
|
<---------------------| AR |<----+
|
Publica certificado +------+
|
|
v
v
+------------+
<-------------------------------|
AC
|
Publica certificado
+------------+
Publica LCR
^
^
+--------------+
|
|
gerenciamento
<--------------|Emissor de LCR|<---+
|
de transaç~
oes
Publica LCR +--------------+
v
+------+
| AC |
+------+
na
+---+
| R |
| e |
| p |
| o |
| s |
| i |
| t |
| ó |
| r |
| i |
| o |
|
|
| d |
| e |
|
|
| C |
| e |
| r |
| t |
|
|
| & |
|
|
| L |
| C |
| R |
+---+
3.1
Er
Figura 1: Entidades da ICP
Versão 3 do Certificado X.509
Os usuários de uma chave pública necessitam ter confiança de que a chave privada associada é de propriedade do sujeito remoto correto (pessoa ou sistema), com a qual um
determinado mecanismo de criptografia ou assinatura digital será utilizado. Esta confiança
é obtido através da utilização de certificados de chave pública, que são estruturas de dados
que relacionam os valores de chave pública a indivı́duos. Esta relação de confiança ocorre
a partir da utilização de AC confiável que assina digitalmente cada certificado. O AC pode
basear esta afirmação em meios técnicos (por exemplo, a prova da posse através de um
protocolo de desafia e resposta), apresentação da chave privada, ou em um afirmação do
sujeito. Um certificado tem uma vida útil válida limitada, o que está indicado no seu conteúdo assinado. Pelo fato da assinatura do certificado e o seu perı́odo de validade poderem
ser verificados de maneira independente pelo sistema usuário, que faz uso da tecnologia, os
certificados podem ser distribuı́dos através de meios de comunicação e sistemas de servidores não confiáveis , e podem ser armazenados, de forma insegura, em cache nos sistemas
Cooper, et al.
Standards Track
RFC 5280
Maio de 2008
11
usuários.
O ITU-T X.509 (anteriormente CCITT X.509) ou ISO/IEC 9594-8, que foi publicado pela
primeira vez em 1988, como parte das recomendações X.500 para diretório, define o formato de certificado padrão [X.509]. O formato do certificado no padrão de 1988 é chamado
versão 1 (v1) do formato. O X.500 foi revisto em 1993, quando mais dois campos foram
adicionados, resultando na versão 2 (v2) do formato.
nd
es
A RFC do Internet Privacy Enhanced Mail (PEM), publicada em 1993, incluiu especificações para uma infraestrutura de chaves públicas baseada em certificados X.509 v1
[RFC1422]. A experiência adquirida na tentativa de implantar RFC 1422 deixou claro
que os formatos de certificado v1 e v2 eram deficientes em vários aspectos. O mais importante, mais campos foram necessários para transportar informações que o projeto do PEM
design e a experiência de implementação tinham considerado necessário. Em resposta a
estes novos requisitos, a ISO/IEC, ITU-T, e ANSI X9 desenvolveu o X.509 versão 3 (v3)
do formato do certificado. O formato v3 estende o formato v2 incluindo previsões para
campos de extensão adicionais. Tipos de extensões particulares podem vir especificados
em normas ou pode ser definido e registrado por qualquer organização ou comunidade. Em
junho de 1996, a padronização do formato v3 básica foi concluı́da [X.509].
A ISO/IEC, ITU-T, e ANSI X9 também desenvolveram extensões padrão para uso no
campo extensões v3 [X.509] [X9.55]. Estas extensões podem transmitir dados como informações adicionais para identificação do sujeito, informações de atributos-chave, informações
polı́ticas, e restrições para o caminho de certificação.
na
ISO / IEC, ITU-T, e ANSI X9 também desenvolveram extensões padrão para uso no campo
extensões v3 [X.509] [X9.55]. Estas extensões podem transmitir dados como informações
adicionais sujeito identificação, informações de atributo-chave, informações polı́ticas, e restrições de caminho de certificação.
3.2
Er
No entanto, as extensões padrãoISO/IEC, ITU-T, e ANSI X9 são muito amplas em sua
aplicabilidade. Para desenvolver implementações interoperáveis de sistemas X.509 v3 para
uso na Internet, é necessário especificar um perfil para uso das extensões X.509 v3 sob
medida para a Internet. É o objectivo deste documento, especificar um perfil para aplicações
WWW Internet, correio eletrônico, e IPsec. Ambientes com requisitos adicionais podem
implementar usando esse perfil ou pode substituı́-lo.
Caminhos de certificação e Confiança
Um usuário de serviço de segurança que exige conhecimento de uma chave pública geralmente precisa obter e validar o certificado contendo a chave pública utilizada. Se o usuário
da chave pública não é titular de uma cópia segura da chave pública da AC que assinou
o certificado, o nome da AC, e as informações relacionadas (como o perı́odo de validade
ou o nome de restrições), então ele pode precisar de um certificado adicional para obter
a chave pública. Em geral, uma cadeia de múltiplos certificados pode se tornar necessário, compreendendo o certificado do dono da chave pública (a entidade final) assinado por
uma autoridade de certificação, e zero ou mais certificados adicionais de ACs assinados por
outras ACs. Tais cadeias, chamadas de caminhos de certificação, são necessárias porque
um usuário de chave pública só é inicializado com um número limitado de chaves públicas
garantidas pela AC.
Cooper, et al.
Standards Track
RFC 5280
Maio de 2008
12
Existem diferentes formas de configuração de ACs que possibilitam aos usuários de chaves
públicas encontrarem os caminhos de certificação. Para o PEM, a RFC 1422 foi definido
uma estrutura hierárquica rı́gida para ACs. Existem três tipos de autoridade certificadora
PEM:
es
(a) Autoridade de Registro de Polı́tica de Internet(ARPI): Esta autoridade, operando
sob os auspı́cios da Internet Society, atua como a raiz da hierarquia de certificação
PEM no nı́vel 1. Emite certificados apenas para o próximo nı́vel de autoridades,
APC (Autoridade de Polı́tica de Certificação). Todos os caminhos de certificação
começam na ARPI.
nd
(b) Autoridades de polı́ticas de Certificação (APC): As APCs estão no nı́vel 2 da
hierarquia, cada APC a ser certificada pelo ARPI. A APC deve estabelecer e publicar uma declaração da sua polı́tica com relação aos usuários de certificação ou
autoridades de certificação subordinadas. APCs distintas visam satisfazer as necessidades de usuários diferentes. Por exemplo, uma APC (uma APC organizacional)
pode apoiar as necessidades gerais de correio eletrônico de organizações comerciais,
e outra APC (uma APC de alta confiança) pode ter uma polı́tica mais rigorosa,
projetada para satisfazer os requisitos legalmente vinculativos de assinatura digital.
na
(c) Autoridades Certificadoras (ACs): ACs estão no nı́vel 3 da hierarquia e podem
também estar em nı́veis mais baixos. As de nı́vel 3 são certificadas pela APC. As
ACs representam, por exemplo, organizações particulares, unidades organizacionais
particulares (por exemplo, departamentos, grupos, seções), ou áreas geográficas
especı́ficas.
Er
Além disso, a RFC 1422, tem uma regra para subordinação de nome, que exige que a AC
só possa emitir certificados para entidades cujos nomes são subordinados (na árvore de
nomeação X.500) para o nome da própria AC. A confiança associada a um caminho de certificação PEM está implı́cito no nome APC. A regra de subordinação de nome garante que
ACs abaixo da APC sejam sensivelmente restritas ao conjunto de entidades subordinadas
que podem certificar (por exemplo, uma AC para uma organização só pode certificar entidades na árvore com o nome da organização). Sistemas usuários de certificado são capazes
de verificar mecanicamente que a regra de subordinação de nome foi seguida.
A RFC 1422 utiliza o formato X.509 certificado v1. As limitações do X.509 v1 tornam
necessário a imposição de várias restrições estruturais que associam claramente as informações sobre a polı́tica ou restrições quanto a utilização dos certificados. Estas restrições
incluem:
(a) uma hierarquia top-down pura, na qual todos os caminhos de certificação começam
na ARPI;
(b) uma regra de subordinação de nomes que restringe os nomes de sujeito de AC; e
(c) uso do conceito APC, que requer o conhecimento de APCs individuais para serem
incluı́dos para verificação lógica da cadeia de certificação. O conhedimento de
APCs individuais é necessário para determinar se a cadeia pode ser aceita.
Com o X.509 v3, a maioria dos requisitos abordados na RFC 1422 podem ser resolvidos
através das extensões do certificado, sem a necessidade de restringir as estruturas das ACs
Cooper, et al.
Standards Track
RFC 5280
Maio de 2008
utilizadas. Em particular, as extensões do certificado relacionadas com as polı́ticas de
certificação evitam a necessidade de uso de APCs e as restrições contidas nas extensões
torna desnecessário o uso das regra subordinação de nome. Como resultado, esta norma
suporta uma arquitetura mais flexı́vel, incluindo:
(a) Os caminhos de certificação começam com a chave pública de uma Autoridade
Certificadora no próprio domı́nio do usuário, ou com a chave pública da árvore
superior de uma hierarquia. Começar com a chave pública de uma Autoridade de
Certificadora no domı́nio do usuário tem certas vantagens. Em certos ambientes,
o domı́nio local é o mais confiável.
es
(b) Restrições de nomes podem ser impostas através da inclusão de uma extensão para
restrição explı́cita de nomes no certificado, mas isso não é requisito.
nd
(c) Extensões de Polı́tica e mapeamentos de polı́tica substituem o conceito de APC,
permitindo um maior grau de automação. A aplicação pode determinar se o caminho de certificação é aceitável com base no conteúdo dos certificados, em vez de um
conhecimento a priori da APC. Isto permite a automatização do processamento do
caminho de certificação.
O X.509 v3 também inclui uma extensão que identifica o sujeito de um certificado como
sendo uma CA ou uma entidade final, reduzindo a dependência de informação externa exigida pelo PEM.
3.3
Er
na
Esta especificação abrange duas classes de certificados: certificados de AC e certificados de
entidade final. Os certificados de AC podem ser divididos em três classes: certificado cruzado, certificado auto-emitido e certificado auto-assinado. O certificado cruzado é aquele no
qual o emissor e o sujeito do certificado são entidades distintas. A certificação cruzada descreve uma relação de confiança entre duas ACs. O certificado auto-emitido é aquele no qual
o emissor e o sujeito do certificado são a mesma entidade. A auto-emissão de certificados
ocorre em suporte a mudanças na polı́tica ou nas operações. Certificados auto-assinados
são aqueles nos quais a assinatura de digital pode ser verificada com a chave pública relacionada contida no próprio certificado. Certificados auto-assinados são utilizados para
transmitir uma chave pública para uso como inı́cio de um caminho de certificação. Certificados de entidade final são emitidos para aquelas entidades que não estão autorizadas a
emitir certificados.
Revogação
Quando um certificado é emitido, é esperado que ele seja utilizado durante todo o seu
perı́odo de validade. No entanto, várias circunstâncias podem causar a invalidação do certificado antes da expiração do seu prazo de validade. Tais circunstâncias incluem a mudança
de nome, mudança de associação entre o sujeito e a AC (por exemplo, quando o empregado
termina deixa de prestar serviços a uma organização), comprometimento ou suspeita de
comprometimento da chave privada correspondente. Sob tais circunstâncias, o AC tem que
revogar o certificado.
O X.509 define um método para revogação de certificado. Este método envolve a emissão
periódica 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 tempo
que identifica os certificados revogados, assinada pela AC que o emitiu ou por um emissor
Cooper, et al.
Standards Track
13
RFC 5280
Maio de 2008
es
de CRL, e disponibilizada gratuitamente em um repositório público. Cada certificado revogado é identificado na LCR pelo número de série do certificado. Quando um sistema que
faz uso de certificação, usa um certificado (por exemplo, para verificar a assinatura digital
de um usuário remoto), o sistema não verifica somente a assinatura do certificado e sua
validade, mas também adquire uma LCR adequadamente recente e verifica que o número
de série do certificado não na LCR. O significado de “adequadamente recente” pode variar
de acordo com a polı́tica local, mas isso normalmente remete a LCR emitida mais recentemente. A nova lista é emitida em base regular e periódica (por exemplo, a cada hora,
diariamente ou semanalmente). Uma entrada é adicionada a LCR como parte da próxima
atualização após a notificação de revogação. Uma entrada não deve ser removido da LCR,
até que apareça em LCRs regulares emitidas após o perı́odo de validade do certificado revogado.
Uma vantagem deste método é que as CRLs podem ser distribuı́das da mesma forma que
os certificados propriamente ditos, ou seja, através de servidores e meios de comunicações
não seguros.
nd
Uma limitação do método de revogação por LCR, usando comunicações e servidores não
confiáveis, é que a granularidade do tempo de revogação é limitada ao prazo de emissão
da LCR. Por exemplo, se a revogação for relatada agora, a revogação não será confiável
ao sistema que faz uso do certificado até que todas as LCRs sejam atualizadas conforme
o agendamento de emissão - o que pode ser de até uma hora, um dia ou uma semana,
dependendo da frequência de emissão das LCRs.
3.4
Er
na
Tal como acontece com o formato de certificado X.509 v3, a fim de facilitar a interoperabilidade nas implementações de vários fornecedores, o formato de LCR X.509 v2 tem que
ter um perfil adequado ao uso na Internet. Um dos objetivos do presente documento é
a especificação deste perfil. No entanto, o perfil não define os requisitos para emissão de
LCRs. Os formatos de mensagens e protocolos de suporte on-line para notificação de revogação são definidos em outras especificações do PKIX. Métodos de notificação on-line de
revogação podem ser aplicáveis, em alguns ambientes, como alternativa para a LCR X.509.
A verificação de revogação on-line pode reduzir significativamente a latência entre a geração
do relatório de revogação e a sua distribuição aos terceiros confiáveis. Uma vez que o AC
aceite um relatório da revogação, como autêntico e confiável, qualquer consulta ao serviço
on-line, refletirá corretamente os impactos da revogação na validação do certificado. No entanto, estes métodos impõem novos requisitos de segurança: o validador certificado precisa
confiar no serviço de validação on-line, enquanto o repositório não precisa ser confiável.
Protocolos Operacionais
É necessário um conjunto de protocolos operacionais para entregar os certificados e CRLs
(ou informações de status) aos sistemas clientes que fazem uso de certificado. Torna-se
necessário provisões para uma variedade de diferentes meios de certificado e entrega de
LCR, incluindo procedimentos de distribuição baseados em LDAP, HTTP, FTP e X.500.
Os protocolos operacionais que dão suporte a estas funções são definidas em outras especificações do PKIX. Estas especificações podem incluir definições de formatos de mensagem
e procedimentos para suportar todos os ambientes operacionais acima referidos, incluindo
definições ou referências para tipos apropriados de conteúdo MIME.
Cooper, et al.
Standards Track
14
3.5
RFC 5280
Maio de 2008
Protocolos de Gerenciamento
15
Os protocolos de gerenciamento são necessários para dar suporte às interações entre os
usuários da ICP e as entidades que realizam o seu gerenciamento. Como exemplo, um
protocolo de administração pode ser utilizado entre a AC e um sistema cliente com o qual
um par de chave está associada, ou entre duas ACs que implementem certificação cruzada
entre si. O conjunto de funções que, potencialmente, têm de ser suportados por protocolos
de gestão incluem:
es
(a) registro: É o processo no qual o usuário primeiro se faz conhecido pela AC (diretamente, ou através de uma AR), ocorre antes da AC emitir o certificado ou
certificados para o usuário.
nd
(b) inicialização: Antes do sistema cliente poder operar de forma segura, é necessária
a instalação de materiais essenciais que têm a relação adequada com as chaves
armazenadas em outras partes da infra-estrutura. Por exemplo, o cliente tem de ser
inicializado de maneira segura com a chave pública e outras informação garantidas
pela AC(s), que serão utilizadas na validação dos caminhos de certificação. Além
disso, um cliente normalmente tem de ser inicializado com seu próprio par(es) de
chave(s).
(c) certificação: Este é o processo no qual a AC emite o certificado de chave pública
para o usuário, e retorna esse certificado para o sistema cliente do usuário e/ou
publica o certificado em um repositório.
na
(d) recuperação de par de chaves: Como opção, os materiais de chave do usuário cliente
(por exemplo, a chave privada de um usuário utilizado para fins de criptografia)
pode ser suportado por uma CA ou um sistema de backup de chave. Se um usuário
precisa recuperar esses materiais de backup de chave (por exemplo, como resultado
de uma senha esquecida ou perda do arquivo da cadeia da chave), um protocolo de
troca de mensagem on-line protocolo pode ser necessários para das suporte a esta
ação.
Er
(e) atualização de par de chaves: Todos os pares de chaves precisam ser atualizados
regularmente, ou seja, substituı́do por um novo par de chaves, e emissão de novos
certificados
(f) solicitação de revogação: Uma pessoa autorizada avisa uma AC sobre uma uma
situação anormal e solicita a revogação do certificado.
(g) certificação cruzada: Duas ACs trocam informações utilizadas na criação de um
certificado cruzado. Um certificado cruzado é um certificado emitido por uma AC
para outra AC que contém uma chave de assinatura de AC usada na emissão de
certificados.
Note que os protocolos on-line não são a única maneira de implementar as funções acima.
Para todas as funções, existem métodos off-line utilizados para obtenção do mesmo resultado, esta especificação não exige o uso de protocolos on-line. Por exemplo, quando são
utilizados tokens, muitas das funções podem ser realizadas no próprio token. Além disso,
algumas das funções acima descritas podem ser combinados em um protocolo de troca de
mensagens. Em particular, dois ou mais registos, inicialização e funções de certificação
podem ser combinados em uma troca de mensagens de protocolo.
Cooper, et al.
Standards Track
RFC 5280
Maio de 2008
A série de especificações PKIX define um conjunto de formatos de mensagens padrão que
suportam as funções acima. Os protocolos para transmitir estas mensagens em diferentes
ambientes (por exemplo, a transferência de ficheiros de e-mail, e WWW) encontram-se
descritos nessas especificações.
4
Perfil do Certificado e das Extensões do Certificado
es
Esta seção apresenta o perfil para certificados de chaves públicas que promovem a interoperabilidade e a utilização continuada de uma ICP. Esta seção é baseada no formato de
certificado X.509 v3 e nas extensões de certificado padrão definidas no [X.509]. Os documentos ISO/IEC e ITU-T utiliza a versão de 1997 do ASN.1, enquanto este documento
usa versão de 1988 da sintaxe ASN.1, o certificado codificado e suas extensões padrão são
equivalentes. Esta seção também define as extensões privadas necessárias para suportar
uma ICP na comunidade da Internet.
Campos Básicos do Certificado
na
4.1
nd
Os certificados podem ser utilizados numa vasta gama de aplicações e ambientes que abrangem um largo espectro de objetivos de interoperabilidade e um espectro mais amplo ainda
de requisitos operacionais e de segurança. O objetivo deste documento é estabelecer uma
base comum para aplicações genéricas que exigem ampla interoperabilidade e requisitos de
propósitos especiais limitados. Em particular, a ênfase será em apoiar o uso de certificados
X.509 v3 para uso no correio eletrônico informal da Internet, no IPsec e nas aplicações
WWW.
A sintaxe básica do certificado X.509 v3 segue abaixo. Para o cálculo da assinatura, os dados
que serão assinados é codificado usando as regras de codificação (DER) do ASN.1 [X.690].
A codificação DER do ASN.1 DER é baseada em rótulo, e um sistema de codificação desse
valor para cada elemento.
::=
Er
Certificate
tbsCertificate
signatureAlgorithm
signatureValue
TBSCertificate
::=
version
serialNumber
signature
issuer
validity
subject
subjectPublicKeyInfo
issuerUniqueID
subjectUniqueID
extensions
Cooper, et al.
SEQUENCE {
TBSCertificate,
AlgorithmIdentifier,
BIT STRING }
SEQUENCE {
[0] EXPLICIT Version DEFAULT v1,
CertificateSerialNumber,
Name,
Validity,
Name,
SubjectPublicKeyInfo,
[1] IMPLICIT UniqueIdentifier OPTIONAL,
-- If present, version MUST be v2 or v3
-- If present, version MUST be v2 or v3
[3] EXPLICIT Extensions OPTIONAL
-- If present, version MUST be v3
Standards Track
16
RFC 5280
Maio de 2008
}
17
::=
INTEGER { v1(0), v2(1), v3(2) }
CertificateSerialNumber
::=
INTEGER
Validity
notBefore Time,
notAfter Time }
::=
SEQUENCE {
Time
::=
CHOICE {
UTCTime,
GeneralizedTime }
UniqueIdentifier
::=
BIT STRING
SubjectPublicKeyInfo
algorithm
subjectPublicKey
::=
Extensions
::=
SEQUENCE SIZE (1..MAX) OF Extension
Extension
extnID
critical
extnValue
::=
SEQUENCE {
OBJECT IDENTIFIER,
BOOLEAN DEFAULT FALSE,
OCTET STRING
-- contains the DER encoding of an ASN.1
-- value corresponding to the extension
-- type identified by extnID
na
}
SEQUENCE {
BIT STRING }
nd
utcTime
generalTime
es
Version
Os itens a seguir descrevem os certificados X.509 v3 para uso na Internet.
Campos do Certificado
Er
4.1.1
O certificado é uma SEQUÊNCIA de três campos obrigatórios. Os campos são detalhadamente descritos nas subseções abaixo.
4.1.1.1
tbsCertificate
Esse campo contém os nomes do sujeito e do emissor, uma chave pública associada ao
sujeito, um perı́odo de validade, e outras informações relacionadas. Os campos são descritos
em detalhes na seção 4.1.2; o campo tbsCertificate normalmente inclui extensões, que são
descritas na seção 4.2.
4.1.1.2
signatureAlgorithm
O campo signatureAlgorithm contém o identificador do algoritmo criptográfico usado pela
AC para assinar o certificado. [RFC3279], [RFC4055], e [RFC4491] lista os algoritmos de
assinatura suportados, mas outros algoritmos também PODEM ser suportados.
Cooper, et al.
Standards Track
RFC 5280
Maio de 2008
Um identificador de algoritmo é definido pela estrutura ASN.1 a seguir:
18
AlgorithmIdentifier
algorithm
parameters
::=
SEQUENCE {
OBJECT IDENTIFIER,
ANY DEFINED BY algorithm OPTIONAL }
es
O identificador de algoritmo é utilizado para identificar o algoritmo criptográfico. O componente OBJECT IDENTIFIER identifica o algoritmo (como o DSA com SHA-1). O
conteúdo do do campo parameters variam de acordo com o algoritmo identificado.
Este campo DEVE conter os mesmos identificadores de algoritmo que o campo signature
na sequência de campos do tbsCertificate (seção 4.1.2.3).
4.1.1.3
signatureValue
nd
O campo signatureValue contém a assinatura digital calculada sobre o campo tbsCertificate codificado em DER do ASN.1. A codificação do tbsCertificate é usada como entrada
da função de assinatura. Este valor de assinatura é codificado como um BIT STRING e
incluı́do no campo de assinatura. Os detalhes deste processo são especificados para cada
algoritmo listado em [RFC3279], [RFC4055] e [RFC4491].
4.1.2
na
Para gerar a assinatura, a AC de certifica da validade da informação contida no campo
tbsCertificate. Em particular, a AC se certifica da relação existente entre o material da
chave pública e o sujeito do certificado.
TBSCertificate
4.1.2.1
Er
A sequência TBSCertificate contém informações associadas ao sujeito do certificado e a AC
que o emitiu. Todo TBSCertificate contém o nome do sujeito e o emissor, uma chave pública
associada ao sujeito, um perı́odo de validade, o número da versão e o número serial; alguns
PODEM conter campos opcionais de identificador único. O restante desta seção descreve a
sintaxe e a semântica dos três campos. O TBSCertificate geralmente inclui extensões. As
extensões para ICP na Internet são descritos na seção 4.2.
Version
Este campo descreve a versão do certificado codificado. Quando são utilizados extensões,
como esperado na definição do perfil, o valor deste campo deve ser 3 (valor igual a 2). Caso
não ocorra nenhuma extensão, mas o UniqueIdentifier esteja presente, a versão DEVERIA
ser 2 (valor igual a 1); entretanto, a versão PODE ser 3. Quando apenas os campos básicos
estiverem presentes, a versão DEVERIA ser 1 (o valor é omitido do certificado, é considerado o valor padrão); embora a versão possa ser 2 ou 3.
As implementações DEVERIAM estar preparadas para aceitar qualquer versão de certificado. No mı́nimo, as implementações que estão em conformidade DEVEM reconhecer os
certificados de versão 3.
A geração de certificados de versão 2 não é esperado pelas implementações baseadas no
presente perfil.
Cooper, et al.
Standards Track
4.1.2.2
RFC 5280
Maio de 2008
Serial Number
O serial number DEVE ser um número inteiro positivo atribuı́do pela AC para cada certificado. Ele DEVE ser único para cada certificado emitido pela respectiva AC (por exemplo,
o nome do emissor e o número serial identificam um certificado único) As ACs DEVEM
garantir que o serialNumber seja um número inteiro não negativo.
es
Dada a unicidade requerida acima, é esperado que este campo contenha números inteiros
longos. Os sistemas usuários de certificado DEVEM ser capazes de processar números
inteiros de até 20 octetos. Quando em conformidade, as ACs NÃO DEVEM utilizar serialNumber com valores maiores que 20 octetos.
Nota: ACs que não se encontram em conformidade PODEM emitir certificados com números negativos ou iguais a zero. Os sistemas usuários de certificado DEVERIAM ser
preparados para tratar adequadamente tais certificados.
Signature
nd
4.1.2.3
Este campo contém o identificador de algoritmo para o algoritmo utilizado pela AC para
assinar o certificado.
4.1.2.4
Issuer
na
Este campo DEVE conter o mesmo identificador de algoritmo do campo signatureAlgorithm
na sequência de campos do certificado (seção 4.1.1.2). O conteúdo dos parâmetros opcionais
variam de acordo com o identificador do algoritmo. [RFC3279], [RFC4055] e [RFC4491]
listam os algoritmos de assinatura suportados, mas outros algoritmos PODEM também ser
suportados.
O campo issuer identifica a entidade que assinou e emitiu o certificado. O campo issuer
DEVE conter um valor não vazio de nome distinto (DN). O campo issuer é definido com o
tipo Name do ASN.1 [X.500]. Name é definido pela estrutura ASN.1 a seguir:
::=
CHOICE {
-- only one possibility for now -RDNSequence }
::=
SEQUENCE OF RelativeDistinguishedName
Er
Name
rdnSequence
RDNSequence
RelativeDistinguishedName ::=
SET SIZE (1..MAX) OF AttributeTypeAndValue
AttributeTypeAndValue
type
value
::=
SEQUENCE {
AttributeType,
AttributeValue }
AttributeType
::=
OBJECT IDENTIFIER
AttributeValue
::=
ANY -- DEFINED BY AttributeType
DirectoryString
::=
Cooper, et al.
CHOICE {
Standards Track
19
RFC 5280
teletexString
printableString
universalString
utf8String
bmpString
Maio de 2008
TeletexString (SIZE (1..MAX)),
PrintableString (SIZE (1..MAX)),
UniversalString (SIZE (1..MAX)),
UTF8String (SIZE (1..MAX)),
BMPString (SIZE (1..MAX)) }
O tipo Name descreve um nome hierárquico composto de atributos, tais como o nome do
paı́s, e os valores correspondentes, como US. O tipo de componente AttributeValue é determinado pelo AttributeType; geralmente será um DirectoryString.
nd
es
O tipo DirectoryString é definido como uma selecão entre PrintableString, TelexString,
BMPString e UniversalString. As ACs em conformidade com este perfil DEVEM usar codificação PrintableString ou UTF8String para codificar o DirectoryString, com duas exceções.
Quando ACs tiverem emitido anteriormente certificados com campos issuer com atributos
codificados usando TelexString, BMPString ou UniversalString, a AC PODE continuar a
usar essas codificações para o DirectoryString de maneira a preservar a compatibilidade do
legado. Também no caso de novas ACs serem adicionadas a um domı́nio onde existem ACs
que emitem certificados com campos issuer com atributos codificados usando TelexString,
BMPString ou UniversalString PODEM codificar os atributos que elas trocam com as ACs
existentes usando a mesma codificação que as ACs utilizam.
na
Como notado acima, os nomes distintos são compostos por atributos. A presente espcificação não restringe o conjunto de tipos de atributos que podem aparecer nos nomes. Entretanto, as implementações em conformidade DEVEM estar preparadas para receberem
certificados com nomes contendo o conjunto de atributos listados a seguir. Esta especificação RECOMENDA o suporte a tipos adicionais de atributos.
O conjunto padrão de atributos foi definido na série de especificações do X.500 [X.520]. As
implementações deta especificação DEVEM estar preparadas para receberem os seguintes
tipos de atributos de nomes padrão nos campos issuer e subject (seção 4.1.2.6):
* paı́s,
Er
* organização,
* unidade organizacional,
* qualificador do nome distinto,
* nome do estado ou provincia,
* nome comum (por exemplo, “Susan Housley”), e
* número serial.
Além disso, as implementações desta especificação DEVERIAM estar preparadas para receberem os seguintes tipo de atributos padrão tanto no nome do emissor quanto no nome
do sujeito:
* localidade
* tı́tulo,
Cooper, et al.
Standards Track
20
RFC 5280
Maio de 2008
* sobrenome,
* nome,
* iniciais,
21
* pseudônimo, e
* qualificador de geração (por exemplo, “Jr”, “3º”, ou “IV”).
es
A sintaxe e identificadores de objeto (OIDs) para esses tipos de atributos são fornecidos
nos módulos ASN.1 do apêndice A.
nd
Adicionalmente, as implementações desta especificação DEVEM estar preparadas para receberem atributos domainComponent, como descrito em [RFC4519]. O Sistema de Nome
de Domı́nio (DNS) fornece um sistema de rótulos hierárquico. Este atributo fornece um
mecanismo adequado para organização que deseja usar DNs em paralelo aos nomes DNS.
Isso não é uma substituição para o componente dNSName das extensões alternative name.
Não é necessário que as implementações convertam estes nomes em nomes DNS. A sintaxe
associada e o OID para este tipo de atributo são fornecidos nos módulos ASN.1 do apêndice
A. Regras para a codificação de nomes de domı́nio internacionalizados para uso no atributo
domainComponent serão especificadas na seção 7.3.
4.1.2.5
Validity
na
Os sistemas usuários de certificados DEVEM ser preparados para processar campos contendo nomes distintos do emissor e do sujeito (seção 4.1.2.6) para validar a cadeia de nome
do caminho de certificação (seção 6). A cadeia de nomes é executada fazendo a correspondência entre o nome distinto do emissor no certificado com o nome do sujeito no certificado
da AC. As regras de comparação de nomes distintos estão especificadas na seção 7.1. Se
os nomes nos campos emissor e sujeito de um certificado correspondem de acordo com as
regras especificadas na seção 7.1 então o certificado é auto-emitido.
Er
O perı́odo de validade do certificado é o intervalo de tempo durante o qual a AC garante
que vai manter as informações sobre o status do certificado. O campo é representado como
uma sequência de duas datas: a data em que o perı́odo de validade do certificado começa
(notBefore) e a data na qual o perı́odo de validade do certificado termina (notAfter). Ambos notBefore e notAfter podem ser codificados como UTCTime ou GeneralizedTime.
As ACS em conformidade com esse perfil deve sempre codificar datas de validade de certificado até o ano de 2049 como UTCTime; data de validade de certificado em 2050 ou
posterior, deve ser codificada como GeneralizedTime. As aplicações em conformidade devem ser capazes de processar datas de validade que são codificados em tanto em UTCTime
quanto em GeneralizedTime.
O perı́odo de validade de um certificado é o perı́odo de tempo compreendido entre notBefore e notAfter, inclusive nestas datas.
Em algumas situações, são fornecidos aos dispositivos certificados para os quais nenhuma
data de expiração boa pode ser atribuı́da. Por exemplo, pode ser emitido um certificado
para um dispositivo que vincula o seu modelo e número de série com a sua chave pública,
Cooper, et al.
Standards Track
RFC 5280
Maio de 2008
é esperado que tal certificado seja utilizado durante toda a vida útil do dispositivo.
Para indicar que um certificado não tem data de validade bem definida, ao campo notAfter
deve ser atribuı́do o valor de GeneralizedTime igual a 99991231235959Z.
22
4.1.2.5.1
es
Quando o emissor não é capaz de manter informações de estado até a data notAfter (inclusive quando a data contida em notAfter for 99991231235959Z), o emissor DEVE assegurar
que não existirá nenhum caminho de certificação válido para o certificado após encerrada a
manutenção de informações sobre o estado do certificado. Isto pode ser conseguido através
de expiração ou revogação de todos os certificados de AC contendo a chave pública usada
para verificar a assinatura do certificado e com a interrupção do uso da chave pública
utilizada para verificar a assinatura do certificado como âncora de confiança.
UTCTime
nd
O tipo de tempo universal, UTCTime, é um tipo padrão ASN.1 usado para representação
de datas e tempo. O UTCTime especifica para ano os dois dı́gitos de mais baixa órdem e
o tempo é especificado com a precisão de um minuto ou um segundo. O UTCTime inclui
tanto Z (para Zulu, ou Greenwich Mean Time) ou um tempo diferencial de tempo.
na
Para os propósitos deste perfil, os valores UTCTime DEVEM ser expressos em Greenwich
Mean Time (Zulu) e DEVEM incluir os segundos (por exemplo, tempos são representados
por YYMMDDHHMMSSZ), mesmo onde o número relacionado aos segundos seja zero. Os
sistemas em conformidade DEVEM interpretar o campo ano (YY) como:
Quando YY for maior que ou igual a 50, o ano DEVERÁ ser interepretado como
19YY; e
Quando YY for menor que 50, o ano DEVERÁ ser interpretado como 20YY.
4.1.2.5.2
GeneralizedTime
Er
O tipo tempo generalizado, GeneralizedTime, é um tipo padrão ASN.1 para representação
precisa de tempo variável. Opcionalmente, o campo GeneralizedTime pode incluir a representação do diferencial do tempo entre o tempo local e o Greenwich Mean Time.
Para os propósitos deste perfil, os valores de GeneralizedTime DEVEM ser expressos em
Greenwich Mean Time (Zulu) e DEVEM incluir segundos (por exemplo, tempos são representados por YYYYMMDDHHMMMSSZ), mesmo quando o número de segundos for igual
a zero. Os valores de GeneralizedTime NÃO DEVEM incluir frações de segundos.
4.1.2.6
Subject
O campo subject identifica a entidade associada com a chave pública armazenada no campo
subject public key. O nome do sujeito PODE ocorrer no campo subject e/ou na extensão
subjectAltName. Se o sujeito é uma AC (por exemplo, a extensão basic constraints, a ser
discutida na seção 4.2.1.9, ocorre e o valor do campo cA será TRUE), então o campo subject DEVE ser preenchido com um nome distinto não vazio correspondente ao conteúdo do
campo issuer (seção 4.1.2.4) em todos os certificados emitidos com o sujeito AC. Quando
o sujeito for um emissor de LCR (por exemplo, na extensão key usage, discutida na seção
Cooper, et al.
Standards Track
RFC 5280
Maio de 2008
4.2.1.3, estará presente e o valor de cRLSign será TRUE), então o campo subject DEVE ser
preenchido com um nome distinto não vazio correspondente ao conteúdo do campo issuer
(seção 5.1.2.3) em todas as LCRs emitidas pelo emissor de LCR. Quando a informação de
nome do sujeito estiver presente apenas na extensão subjectAltName (por exemplo, uma
chave relacionada apenas a um endereço de email ou URI), então o nome do sujeito DEVE
ser uma sequência vazia e a extensão subjectAltName DEVE ser marcada como crı́tica.
es
Quando o campo subject não for vazio, DEVE conter um nome distinto (DN) X.500. O
DN DEVE ser único para cada entidade sujeito certificado por uma AC como definido no
campo issuer. Uma AC PODE emitir mais que um certificado com o mesmo DN para a
mesma entidade sujeito.
na
nd
O campo subject é definido como um nome tipo X.501. Os requisitos de implementação
para este campo são aqueles definidos para o campo issuer (seção 4.1.2.4). As implementações desta especificação DEVEM se preparadas para receberem nomes de sujeito contendo
os tipos de atributos necessários para o campo issuer. As implementações desta especificação DEVERIAM ser preparadas para receber nomes de sujeito contendo os tipos de
atributos recomendados para o campo issuer. A sintaxe e os identificadores de objetos
(OIDs) associados a estes tipos de atributos são fornecidos nos módulos ASN.1 do apêndice
A. As implementações desta especificação DEVEM usar as regras de comparação contidas
na seção 7.1 para processar os tipos de atributos não comuns (por exemplo, para come
de cadeia) cujos valores de atributos usam uma das opções de codificação definidas como
DirectoryString. Comparações binárias deveriam ser utilizadas quando tipos de atributos incomuns incluirem valores de atributos com opções de codificação diferentes daquelas
encontradas no DirectoryString. Isso permite às implementações processarem certificados
com atributos incomuns presentes no nome de sujeito.
Na codificação dos valores de atributos do tipo DirectoryString, as ACs em conformidade
DEVEM usar codificação PrintableString ou UTF8String, com as seguintes exceções:
Er
(a) Quando o sujeito de um certificado for uma AC, o campo subject DEVE ser codificado da mesma forma que ele foi codificado no campo issuer (seção 4.1.2.4) em
todos os certificados emitidos pelo sujeito AC. Assim, se o sujeito AC codificar
atributos nos campos issuer do certificado dos certificados que ela emite usando
codificação TeletexSting, BMPString, ou UniversalString, o campo subject dos
certificados emitidos para aquela AC DEVEM usar a mesma codificação.
(b) Quando o sujeito de um certificado é um emissor de LCR, o campo subject DEVE
ser codificado da mesma forma que foi codificado no campo issuer (seção 5.1.2.3)
em todas as LCRs emitidas pelo sujeito emissor da LCR.
(c) TeletexString, BMPString e UniversalString são incluı́dos para compatibilidade
com o legado, e NÃO DEVERIAM ser usados em certificados para novos sujeitos. Entretanto, estes tipos PODEM ser usados em certificados onde o nome foi
previamente estabelecido, incluindo os casos nos quais um novo certificado esta
sendo emitido para um novo sujeito onde os atributos sendo codificados foram
previamente estabelecidos no certificado emitido para outros sujeitos. Os usuários
do certificado DEVERIAM ser preparados para receberem certificados com esses
tipos.
Implementações do legado existem onde um endereço de email está incorporado no nome
distinto do sujeito como um atributo emailAddress [RFC2985]. O valor do atributo para
Cooper, et al.
Standards Track
23
RFC 5280
Maio de 2008
emailAddress é do tipo IA5String para permitir inclusão do caractere “@”, que não é parte
do conjunto de caracteres PrintableString. Valores de atributo emailAddress não são sensı́veis quanto a maiúsculas e minúsculas (por exemplo, “[email protected]” é o mesmo
que “[email protected]”).
4.1.2.7
Subject Public Key Info
es
As implementações em conformidade quando da geração de novos certificados com endereços
de email PODEM usar o rfc822Name na extensão de nome de sujeito alternativo (seção
4.2.1.6) para descrever tal identidade. Inclusões simultâneas do atributo emailAddress
no nome distinto do sujeito para suportar implementações do legado não é uma prática
incentivada, embora seja permitida.
4.1.2.8
Unique Identifiers
nd
Este campo é utilizado para incluir a chave pública e o identificar o algoritmo com o qual
a chave é usada (por exemplo, RSA, DSA ou Diffie-Hellman). O algoritmo é identificado
usando a estrutura AlgorithmIdentifier especificada na seção 4.1.1.2. O identificador de
objeto para o algoritmo suportado e o método de codificação do material da chave pública (chave pública e os seus parâmetros) são especificados em [RFC3279], [RFC4055] e
[RFC4491].
Extensions
Er
4.1.2.9
na
Esses campos somente DEVEM estar presentes quando a versão for 2 ou 3 (seção 4.1.2.1).
Esses campos NÃO DEVEM aparecer quando a versão for 1. O subject e issuer unique
identifiers estão presentes no certificado para possibilitar a reutilização do nome do sujeito
e/ou emissor no decorrer do tempo. Este perfil RECOMENDA que os nomes não sejam
reutilizados para entidades diferentes. ACs em conformidade com este perfil NÃO DEVEM
gerar certificados com unique identifiers. As aplicações em conformidade com este perfil
DEVERIAM ser capazes de analisar certificados que incluem unique identifiers, mas não
há nenhum requisito de processamento associado ao unique identifiers.
Este campo DEVE aparecer apenas quando a versão for 3 (seção 4.1.2.1). Quando presente,
o campo é uma SEQUENCE de um ou mais extensões de certificado. O formato e o
conteúdo das extensões de certificado da ICP de Internet estão definidos na seção 4.2.
4.2
Extensões do Certificado
As extensões definidas para certificados X.509 v3 fornecem métodos para associar atributos adicionais aos usuários ou chaves públicas, e também para a gestão das relações entre
ACs. O formato do certificado X.509 v3 também permite que comunidades definam extensões privadas que levam informações exclusivas a essas comunidades. Cada uma das
extensões do certificado é designada como crı́tica ou não crı́tica. O sistema que utiliza certificado deve rejeitar o certificado quando encontrar uma extensão crı́tica não reconhecida
ou uma extensão crı́tica que contenha informações que não podem ser processadas. A extensão não-crı́tica PODE ser ignorada quando não reconhecida, mas DEVE ser processada
quando reconhecido. As seções seguintes apresentam extensões recomendadas usadas nos
certificados Internet Internet e os localização padrão para a informação. As comunidades
Cooper, et al.
Standards Track
24
RFC 5280
Maio de 2008
podem optar por usar extensões adicionais, no entanto, todo cuidado deve ser tomado na
adoção de qualquer extensão crı́tica que possam inviabilizar o seu uso em um contexto geral.
nd
es
Cada extensão inclui um OID e uma estrutura ASN.1. Quando uma extensão aparece em
um certificado, o respectivo OID ocorre como um campo extnID e a estrutura codificada
em DER do ASN.1 é o valor do string de octetos contido no extnValue. O certificado
NÃO DEVE incluir mais que uma instância de uma determinada extensão. Por exemplo, o
certificado pode conter apenas uma extensão authority key identifier (seção 4.2.1.1). Uma
extensão inclui a opção de criticidade como um valor booleano, com valor padrão FALSE.
O texto relacionado a cada das extensões, especifica os valores aceitáveis para campo crı́tico
para ACs em conformidade com este perfil.
As ACs em conformidade DEVEM suportar as extensões key identifiers (seção 4.2.1.1 e
4.2.1.2), basic constraints (seção 4.2.1.9), key usage (seção 4.2.1.3), e certificate policies
(seção 4.2.1.4). Quando uma AC emite certificados com uma sequência vazia para o campo
subject, a AC DEVE suportar a extensão subject alternative name (seção 4.2.1.6). O
suporte às extensões restantes permanece opcional. As ACs em conformidade PODEM suportar extensões que não são identificadas nesta especificação; os emissores de certificados
com estas extensões que as marcarem como crı́ticas podem dificultar a interoperabilidade.
No mı́nimo, as aplicações em conformidade com este perfil DEVEM reconhecer as seguintes
extensões: key usage (seção 4.2.1.3), certificate policies (seção 4.2.1.4), subject alternative
name (seção 4.2.1.6), basic constraints (seção 4.2.1.9), name constraints (seção 4.2.1.10),
policy constraints (seção 4.2.1.11), extended key usage (seção 4.2.1.12), e inhibir anyPolicy
(seção 4.2.1.14).
4.2.1
na
Adicionalmente, as aplicações em conformidade com este perfil DEVERIAM reconhecer as
extensões authority and subject key identifier (seção 4.2.1.1 e 4.2.1.2) e policy mappings
(seção 4.2.1.5).
Extensões Padrão
id-ce
4.2.1.1
Er
Esta seção identifica as extensões padrão de certificado no [X.509] para uso na ICP Internet.
Cada extensão é associada a um OID definido em [X.509]. Esses OIDs são membros do
arco de OID id-ce-arc, que é definido da seguinte forma:
OBJECT IDENTIFIER
::=
{ joint-iso-ccitt(2) ds(5) 29 }
Authority Key Identifier
A extensão authority key identifier fornece um meio de identificação da chave pública correspondente a chave privada usada para assinar o certificado. Esta extensão é utilizada
quando um emissor tem múltiplas chaves de assinatura (também d devido a ocorrência de
vários pares de chaves simultâneos ou devido à mudança do par de chaves). A identificação
PODE ser baseada tanto no key identifier (identificador da chave do sujeito no certificado
do emissor) como no nome do emissor e número serial.
O campo keyIdentifier da extensão authorityKeyIdentifier DEVE ser incluı́do em todos os
certificados gerados por ACs em conformidade para facilitar a construção do caminho de
certificação. Existe uma exceção; quando uma AC distribui sua chave pública na forma
de certificado “auto-assinado”, o identificador de chave da autoridade PODE ser omitido.
Cooper, et al.
Standards Track
25
RFC 5280
Maio de 2008
A assinatura em um certificado auto-assinado é gerada com a chave privada associada a
chave pública do sujeiro do certificado. (Isso prova que o emissor tem a posse tanto da
chave pública quanto da privada). Neste caso, o sujeito e o identificador de chave de autoridade devem ser idênticos, mas apenas o identificador de chave do sujeito é necessário
para a construção do caminho de certificação.
es
O valor do campo keyIdentifier DEVERIA ser derivado a partir da chave pública utilizada
para verificar a assinatura do certificado ou do método que gera valores únicos. Dois métodos comuns para geração de identificadores para chave pública são descritos na seção
4.2.1.2. Quando o identificador de chave não tiver sido previamente definido, esta especificação RECOMENDA o uso de um desses métodos para a geração do keyIdentifiers ou o uso
de um método similar que usa um algoritmo de hash diferente. Quando um identificador
de chave tiver sido previamente definido, a AC DEVERIA usar o identificador previamente
definido.
nd
Este perfil RECOMENDA suporte ao método de identificão de chave a todos os usuários
de certificado.
As ACs em conformidade DEVEM marcar esta extensão como não crı́tica.
id-ce-authorityKeyIdentifier OBJECT IDENTIFIER ::= { id-ce 35 }
SEQUENCE {
[0] KeyIdentifier OPTIONAL,
[1] GeneralNames OPTIONAL,
[2] CertificateSerialNumber OPTIONAL }
na
AuthorityKeyIdentifier
::=
keyIdentifier
authorityCertIssuer
authorityCertSerialNumber
KeyIdentifier ::= OCTET STRING
4.2.1.2
Subject Key Identifier
Er
A extensão subject key identifier fornece meios para identificação de certificados que contém uma determinada chave pública.
Para facilitar a construção do caminho de certificação, esta extensão DEVE aparecer em
todos os certificados de AC, ou seja, todos os certificados que incluem a extensão basic
constraints (seção 4.2.1.9) nos quais o valor de cA é TRUE. Nos certificados de AC em
conformidade, o valor do subject key identifier DEVE ser o valor colocado no campo key
identifier da extensão authority key identifier (seção 4.2.1.1) dos certificados emitidos pelo
sujeito deste certificado. As aplicações não precisam verificar que os identificadores de
chave corresponde quando realizam a validação do caminho de certificação.
Para certificados de AC, os identificadores de chave de sujeito DEVERIAM ser derivados
da chave pública ou a partir de um método que gera valores únicos. Dois métodos comuns
para geração de identificadores de chave a partir da chave pública são:
(1) o keyIdentifier é composto por um hash de 160 bits SHA-1 do valor do BIT STRING
subjectPublicKey (excluı́dos o rótulo, o tamanho e o número de bits não utilizados).
Cooper, et al.
Standards Track
26
RFC 5280
Maio de 2008
(2) o keyIdentifier é composto por um campo de quatro bit com o valor 0100 seguido
dos 60 bits menos significativos do hash SHA-1 calculado sobre o valor em BIT
STRING do subjectPublicKey (excluı́dos o rótulo, tamanho, e número de bits não
utilizados).
Também são aceitos outros métodos de geração de números únicos.
27
es
Para certificados de entidades finais, a extensão de identificação de chave de sujeito fornece
um meio de identificação de certificados contendo uma chave pública especı́fica utilizada
em uma aplicação. Quando uma entidade tiver obtido múltiplos certificados, especialmente
de múltiplas ACs, o identificador de chave de sujeito fornece meios de identificação rápida
do conjunto de certificados que contêm uma chave pública especı́fica. Para auxiliar as aplicações na identificação do certificado de entidade final apropriado, a extensão DEVERIA
ser incluı́da em todos os certificados de entidade final.
nd
Para certificados de entidade final, os identificadores de chave de sujeito DEVERIAM ser
derivados da chave pública. Abaixo são identificados dois métodos para geração de identificadores de chave a partir da chave pública.
Quando o identificador de chave não tiver sido previamente definido, esta especificação RECOMENDA o uso de um dos métodos para geração de keyIdentifiers ou usar um método
similar que utilize um algoritmo de hash diferente. Quando um identificador de chave tiver
sido previamente definido a AC DEVERIA usar o identificador já definido.
na
As ACs em conformidade DEVEM marcar esta extensão como não crı́tica.
id-ce-subjectKeyIdentifier
SubjectKeyIdentifier
4.2.1.3
OBJECT IDENTIFIER ::= { id-ce 14 }
::=
KeyIdentifier
Key Usage
Er
A extensão key usage define o propósito (por exemplo, codificação, assinatura, assinatura
de certificado) da chave contida no certificado. A restrição de uso pode ser empregada
quando uma chave que poderia ser usada para mais de uma operação deve ter seu escopo
de uso restrito. Por exemplo, quando uma chave RSA deve ser utilizada somente para a
verificação de assinatura em objetos diferentes de certificados de chave pública e LCRs, os
bits digitalSignature e/ou nonRepudiation estariam ativados. Da mesma forma, quando
uma chave RSA for utilizada somente para gerenciamento de chave, o bit keyEncipherment
estaria ativado.
As ACs em conformidade DEVEM incluir esta extensão nos certificados que contém chaves
públicas que são usados para validar assinaturas digitais em outros certificados de chave
pública ou LCRs. Quando presente, as ACs em conformidade DEVERIAM marcar esta
extensão como crı́tica.
id-ce-keyUsage
KeyUsage
digitalSignature
nonRepudiation
Cooper, et al.
::=
BIT STRING {
(0),
(1),
Standards Track
keyEncipherment
dataEncipherment
keyAgreement
keyCertSign
cRLSign
encipherOnly
decipherOnly
RFC 5280
Maio de 2008
-- recent editions of X.509 have
-- renamed this bit to contentCommitment
(2),
(3),
(4),
(5),
(6),
(7),
(8) }
es
Os bits para definição do tipo de uso, contidos na extensão KeyUsage, são utilizados da
seguinte forma:
O bit digitalSignature é ativado quando a chave pública do sujeito é utilizada para
verificar as assinaturas digitais, exceto assinaturas em certificados (bit 5) e LCR (bit
6), tais como os utilizados em um serviço de autenticação de uma entidade, um serviço
de dados de autenticação de origem, e/ou um serviço de integridade.
nd
O bit nonRepudiation é ativado quando a chave pública do sujeito é usada para
verificar as assinaturas digitais, diferentes das assinaturas de certificados (bit 5) e
de CRL (bit 6), usado para fornecer um serviço não-repúdio que protege contra uma
negação falsa por parte da entidade que assinou negando alguma ação realizada. Neste
caso de conflito, uma terceira parte confiável pode determinar a autenticidade do dado
assinado. (Note que as edições recentes do X.509 ter renomeado o bit nonRepudiation
para contentCommitment.)
na
O bit keyEncipherment é ativado quando a chave pública do sujeito é utilizada para
codificar chaves privadas ou secretas, ou seja, para o transporte de chaves. Por exemplo, este bit será ativado quando uma chave pública RSA é usada para criptografar
uma chave de decodificação de conteúdo simétrica ou uma chave assimétrica privada.
Er
O bit dataEncipherment é ativado quando a chave pública do sujeito é utilizada para
cifrar dados, sem a utilização de um algoritmo intermediário de cifra simétrica. Note
que a utilização deste bit é extremamente raro; quase todos os aplicativos usam o
transporte de chave ou acordo de chave para estabelecer uma chave simétrica.
O bit keyAgreement é ativado quando a chave pública do sujeito é usada para acordo
de chave. Por exemplo, quando uma chave Diffie-Hellman é para ser utilizado para o
gerenciamento de chaves, então esse bit é ativado.
O bit keyCertSign é ativado quando a chave pública do sujeito é usada para verificação
de assinaturas em certificados de chaves públicas. Se o bit keyCertSign é ativado,
então o bit de cA na extensão basic constraints (Seção 4.2.1.9) também DEVE ser
ativado.
O bit cRLSign é ativado quando a chave pública do sujeito é usada para verificação
de assinaturas na listas de certificados revogados (por exemplo, LCRs, delta LCRs
ou CRLs, CRLs delta, ou LARs).
A função do bit encipherOnly fica indefinida na ausência do bit keyAgreement.
Quando o bit encipherOnly é ativado e o bit keyAgreement também é ativado, nesse
caso, a chave pública do sujeito só pode ser utilizado para cifragem de dados durante
a execução de acordo de chave.
Cooper, et al.
Standards Track
28
RFC 5280
Maio de 2008
A função do bit decipherOnly fica indefinida na ausência do bit keyAgreement.
Quando o bit decipherOnly é ativado e o bit keyAgreement também é ativado, a
chave pública do sujeito só pode ser utilizado para decifrar dados durante a execução
de acordo de chave.
es
Se a extensão keyUsage estiver presente, então a chave pública do sujeito NÃO DEVE ser
usada para verificação assinaturas em certificados ou LCRs a menos que o bit keyCertSign ou cRLSign correspondente esteja ativado. Se a chave pública do sujeito deve ser
utilizado somente para verificação de assinaturas em certificados e/ou LCRs, então os bits
DigitalSignature e nonRepudiation NÃO DEVERIAM ser ativados. No entanto, os bits digitalSignature e/ou nonRepudiation PODEM ser ativados além dos bits keyCertSign e/ou
cRLSign se a chave pública do sujeito é para ser utilizada na verificação de assinaturas em
certificados e/ou LCRs, bem como em outros objetos.
nd
A combinação do bit nonRepudiation na extensão keyUsage do certificado com outros bits
dessa extensão pode ter implicações na segurança, dependendo do contexto no qual o certificado seja utilizado. Outras distinções entre os bits digitalSignature e nonRepudiation
podem ser fornecidas em polı́ticas especı́ficas de certificados.
Este perfil não restringe as combinações de bits que podem ser ativados em uma instância da extensão keyUsage. No entanto, valores apropriados para as extensões KeyUsage,
para determinados algoritmos, são especificados em [RFC3279], [RFC4055] e [RFC4491].
Quando a extensão keyUsage aparece no certificado, pelo menos um dos bits DEVE ser
definido como 1 (ativado).
Certificate Policies
na
4.2.1.4
A extensão polı́ticas de certificado contém uma sequência de um ou mais termos de informação da polı́tica, cada um desses consistindo de um identificador de objeto (OID) e
qualificadores opcionais. Os qualificadores opcionais, que PODEM estar presentes, não são
previstos para alterar a definição da polı́tica. Um OID de polı́tica de certificado, NÃO
DEVE aparecer mais que uma vez como extensão polı́ticas de certificado.
Er
Em um certificado de entidade final, esses termos de informação sobre polı́tica indicam a
polı́tica sob a qual o certificado foi emitido e os fins para os quais o certificado pode ser
usado. Em um certificado de AC, esses termos de informação sobre polı́tica limitam o
conjunto de polı́ticas utilizadas para obtenção dos caminhos de certificação que incluem o
certificado. Quando uma AC não deseja limitar o conjunto de polı́ticas para caminhos de
certificação que incluem o seu certificado, PODE atribuir uma polı́tica especial, anyPolicy,
com um valor de 2 5 29 32 0.
Para aplicações com requisitos de polı́ticas especı́ficas é esperado que implementem uma
lista daquelas polı́ticas que serão aceitas e possam comparar OIDs contidos nos certificados
com aqueles constantes na lista. Quando essa extensão for crı́tica, o software de validação
de caminho DEVE ser capaz de interpretar essa extensão (incluindo o qualificador opcional), ou DEVE rejeitar o certificado.
Para promover a interoperabilidade, este perfil RECOMENDA que os termos de informação sobre polı́tica consistam de apenas um OID. Quando um único OID é insuficiente, este
perfil recomenda que o uso de qualificadores seja limitado àqueles identificados nesta seção.
Cooper, et al.
Standards Track
29
RFC 5280
Maio de 2008
Quando qualificadores são utilizados com a polı́tica especial anyPolicy, eles DEVEM ser
limitados aos qualificadores identificados nesta seção. Apenas os qualificadores retornados
como resultado da validação do caminho são considerados.
Esta especificação define dois tipos de qualificadores de polı́tica para serem por criadores de
polı́tica de certificados e emissores de certificado. Os tipos de qualificação são CPS Pointers
e User Notice.
30
es
O qualificador CPS Pointers contém um ponteiro para uma Declaração de Práticas de Certificação (DPC), publicado pela AC. O ponteiro está na forma de uma URI. Os requisitos
de processamento para esse qualificador é tratado localmente. Nenhuma ação é definida
por esta especificação, independentemente da criticidade atribuı́da a extensão.
nd
O qualificador do tipo User Notice é indicado para a exposição a uma terceira parte confiável quando um certificado é utilizado. Apenas User Notice, retornado como um resultado
da validação de caminho, é destinado a exibição para o usuário. Se esse aviso estiver repetido, apenas uma cópia precisa ser exibida. Para evitar essa duplicação, esse qualificador
apenas DEVERIA estar em presente em certificados de entidade final e certificados de CA
emitidos para outras organizações.
O qualificador User Notice possui dois campos opcionais: o campo noticeRef e o campo
explicitText. As ACs em conformidade com este perfil NÃO DEVERIAM utilizar a opção
noticeRef.
Er
na
O campo noticeRef, quando utilizado, nomeia uma organização e identifica, por número, uma declaração textual especı́fica preparada pela organização. Por exemplo,
ele pode identificar a organização “CertsRUs” e anunciar o número 1. Em uma implementação tı́pica, o software aplicativo terá um arquivo de aviso contendo o conjunto
atual de avisos para CertsRUs, o aplicativo irá extrair o texto de aviso a partir do
arquivo e exibi-lo. As mensagens podem ocorrer em várias lı́nguas, permitindo ao
software selecionar uma linguagem particular para de mensagem para o seu próprio
ambiente.
O campo explicitText inclui uma declaração textual diretamente no certificado. O
campo explicitText é uma string com um tamanho máximo de 200 caracteres. As ACs
em conformidade DEVERIAM usar codificação UTF8String para explicitText, mas
PODEM usar IA5String. As ACs em conformidade NÃO DEVEM codificar explicitText como VisibleString ou BMPString. A seqüência de explicitText NÃO DEVERIA
incluir qualquer caractere de controle (por exemplo, U+0000 até U+001F e U+007F
até U+009F). Quando a codificação UTF8String for utilizada, todas as sequências
de caracteres DEVERIAM ser normalizados de acordo com Unicode Normatization
Form C (NFC) [NFC].
Se tanto a opção noticeRef quanto explicitText forem incluı́das no qualificador um e se o
software aplicativo for capaz de localizar o texto de aviso indicado pela opção noticeRef,
então o texto DEVERIA ser apresentado; caso contrário, a sequência contida em explicitText DEVERIA ser exibida.
Cooper, et al.
Standards Track
RFC 5280
Maio de 2008
Nota: Enquanto o explicitText tem um tamanho máximo de 200 caracteres, algumas ACs
que não se encontram em conformidade excedem este limite. Portanto, os usuários certificado DEVERIAM ser capazes de processar campos explicitText contendo mais de 200
caracteres.
id-ce-certificatePolicies
anyPolicy
OBJECT IDENTIFIER ::= { id-ce-certificatePolicies 0 }
31
::= SEQUENCE SIZE (1..MAX) OF PolicyInformation
PolicyInformation
policyIdentifier
policyQualifiers
PolicyQualifierInfo
::= SEQUENCE {
CertPolicyId,
SEQUENCE SIZE (1..MAX) OF
OPTIONAL }
CertPolicyId
::= OBJECT IDENTIFIER
PolicyQualifierInfo
policyQualifierId
::= SEQUENCE {
PolicyQualifierId,
qualifier ANY DEFINED BY policyQualifierId }
-- policyQualifierIds for Internet
-- policy qualifiers
PolicyQualifierId
CPSuri
nd
::= OBJECT IDENTIFIER ( id-qt-cps | id-qt-unotice )
::= CHOICE {
CPSuri,
UserNotice }
Er
Qualifier
cPSuri
userNotice
OBJECT IDENTIFIER ::= { id-pkix 2 }
OBJECT IDENTIFIER ::= { id-qt 1 }
OBJECT IDENTIFIER ::= { id-qt 2 }
na
id-qt
id-qt-cps
id-qt-unotice
es
certificatePolicies
UserNotice
noticeRef
explicitText
::= IA5String
::= SEQUENCE {
NoticeReference OPTIONAL,
DisplayText OPTIONAL }
NoticeReference
organization
noticeNumbers
::= SEQUENCE {
DisplayText,
SEQUENCE OF INTEGER }
DisplayText
ia5String
visibleString
bmpString
utf8String
::= CHOICE {
IA5String (SIZE (1..200)),
VisibleString (SIZE (1..200)),
BMPString (SIZE (1..200)),
UTF8String (SIZE (1..200)) }
Cooper, et al.
Standards Track
4.2.1.5
RFC 5280
Maio de 2008
Policy Mappings
Esta extensão é usada em certificados de AC. Ele lista de um ou mais pares de OIDs; cada
par inclui um campo issuerDomainPolicy e um campo subjectDomainPolicy. O par indica
a AC emissora, considerando o seu equivalente issuerDomainPolicy para o sujeito da AC
contida em subjectDomainPolicy.
Usuários da AC emissora podem aceitar uma issuerDomainPolicy para determinadas aplicações. O mapeamento polı́tica define a lista de polı́ticas associadas ao sujeito da AC que
podem ser aceitas como comparável ao issuerDomainPolicy.
es
Cada issuerDomainPolicy nomeado na extensão policy mappings também DEVERIA estar
indicada na extensão de polı́ticas de certificado no mesmo certificado. Polı́ticas NÃO DEVEM ser mapeados para ou a partir do valor especial anyPolicy (Seção 4.2.1.4).
na
nd
Em geral, as polı́ticas de certificados que aparecem no campo issuerDomainPolicy da extensão mapeamentos policy mappings não são consideradas aceitáveis para inclusão em
certificados posteriores do caminho de certificação. Em algumas circunstâncias, uma AC
pode querer mapear uma polı́tica (p1) para uma outra (p2), mas ainda quer que o issuerDomainPolicy (p1), seja considerado aceitável para a inclusão em certificados subsequentes.
Isto pode ocorrer, por exemplo, se a AC está em processo de transição a partir do uso
da polı́tica p1 para a utilização de uma polı́tica p2 e tem certificados válidos que foram
emitidos em cada uma das polı́ticas. A AC pode indicar isso, incluindo duas extensões
policy mappings nos certificados de AC que ela emitir. Cada policy mapping teria um issuerDomainPolicy de p1, um policy mapping teria um subjectDomainPolicy de p1; o outro
teria o subjectDomainPolicy de p2.
Esta extensão pode ser suportado por CAs e/ou aplicações. As ACs em conformidade
DEVERIAM marcar esta extensão como crı́tica.
id-ce-policyMappings
4.2.1.6
::= SEQUENCE SIZE (1..MAX) OF SEQUENCE {
CertPolicyId,
CertPolicyId }
Er
PolicyMappings
issuerDomainPolicy
subjectDomainPolicy
Subject Alternative Name
A extensão Subject Alternative Name permite que outras identidades sejam relacionadas ao
sujeito do certificado. Estas identidades podem ser incluı́das em adição ou no lugar da identidade no campo de sujeito do certificado. Opções previamente definidas incluem endereço
de correio eletrônico da Internet, um nome de DNS, um endereço IP, e um Uniform Resource Identifier (URI). Existem outras opções, incluindo definições completamente locais.
Formas múltiplas de nome, e várias instâncias de cada forma de nome, podem ser incluı́das.
Sempre que essas identidades tiverem que ser relacionadas em um, a extensão subject alternative name (ou issuer alternative name) DEVEM ser usadas. No entanto, um nome de
DNS também PODE ser representado no campo subject, usando o atributo DomainComponent como descrito na Seção 4.1.2.4. Observe que onde tais nomes forem representados nas
implementações do campo subject não é requerido a conversão dos mesmos em nomes DNS.
Cooper, et al.
Standards Track
32
RFC 5280
Maio de 2008
Pelo motivo do subject alternative name ser considerado definitivamente ligada à chave
pública, todas as sua partes devem ser verificadas pela AC.
es
Além disso, se a única identidade de sujeito incluı́da no certificado for uma forma de nome
alternativo (por exemplo, um endereço de correio eletrônico), então, o nome distinto do
sujeito deve permanecer vazio (uma sequência vazia), e a extensão subjectAltName devem
estar presentes. Se o campo subject tiver uma seqüência vazia, então a AC que emissora
DEVE incluir uma extensão subjectAltName que é marcada como crı́tica. Quando incluı́da
a extensão subjectAltName em um certificado que tem um campo subject distinguished
name não-vazio, as ACs em conformidade DEVERIAM marcar a extensão subjectAltName
como não-crı́tica.
nd
Quando a extensão subjectAltName tiver um endereço de correio da Internet, o endereço
DEVE ser armazenado em rfc822Name. O formato de um nome rfc822Name é uma “caixa
de correio”, como definido na Seção 4.1.2 da [RFC2821]. Uma caixa de correio tem o
formato “Parte-Local@Domı́nio”. Note que uma caixa de correio não possui nenhuma expressão (tal como um nome comum), antes dele, não contém observações (texto limitado por
parênteses) após ele, e não é limitado por “<” e “>”. As regras para codificação de endereços
de e-mail que incluem nomes de domı́nio internacionalizados são especificados na secção 7.5.
na
Quando a extensão subjectAltName tiver um IPAddress, o endereço deve ser armazenado
em string de octeto de “ordem de byte da rede”, conforme especificado no [RFC791]. O bit
menos significativo (LSB) de cada octeto é o bit menos significativo do byte correspondente
do endereço de rede. Para o IP versão 4, conforme especificado em [RFC791], o string de
octeto deve conter exatamente quatro octetos. Para o IP versão 6, conforme especificado
em [RFC2460], o string de octeto deve conter exatamente 16 octetos.
Er
Quando a extensão subjectAltName tiver um rótulo de sistema de nome de domı́nio, o
nome de domı́nio DEVE ser armazenado no dNSName (um IA5String). O nome DEVE
estar na “prefered name syntax”, conforme especificado pela Seção de 3.5 da [RFC1034] e
como modificado pela Secção de 2.1 da [RFC1123]. Observe que, embora letras maiúsculas e minúsculas sejam permitidas para nomes de domı́nio, nenhum significado existe em
relação ao tamanho de caractere. Além disso, apesar do string “” ser um nome de domı́nio
legal, extensões subjectAltName com dNSName de “” NÃO DEVE ser usado. Finalmente,
o uso da representação DNS para endereços de correio da Internet (em vez de [email protected] usar subscriber.example.com) NÃO DEVE ser usado; essas identidades
são codificados como rfc822Name. As regras para codificação de nomes de domı́nio internacionalizados são especificados na secção 7.2.
Quando a extensão subjectAltName tiver uma URI, o nome deve ser armazenado no uniformResourceIdentifier (um IA5String). O nome não deve ser um nome URI relativo, e
ele deve seguir a sintaxe de URI e as regras de codificação especificado em [RFC3986]. O
nome deve incluir tanto o esquema (por exemplo, “http” ou “ftp”) e um esquema da parte
especı́fica. URIs que incluem uma autoridade ([RFC3986], Seção 3.2) DEVE conter um
nome de domı́nio totalmente qualificado ou endereço IP do host. Regras para codificação
de identificadores de recurso internacionalizados (IRIS) são especificadas na secção 7.4.
Conforme especificado em [RFC3986], o nome do esquema não diferencia maiúsculas de
minúsculas (por exemplo, “http” é equivalente a “HTTP”). A parte do host, se estiver presente, também não é sensı́vel a maiúsculas e minúsculas, mas outros componentes da parte
Cooper, et al.
Standards Track
33
RFC 5280
Maio de 2008
especı́fica do esquema podem ser sensı́veis ao tamanho do caractere. Regras para comparar
URIs são especificados na secção 7.4.
Quando a extensão subjectAltName tiver um DN no directoryName, as regras de codificação são as mesmas especificadas para o campo emissor na Secção 4.1.2.4. O DN deve ser
único para cada entidade de sujeita certificada por uma AC, tal como definido pelo campo
issuer. A AC pode emitir mais de um certificado com o mesmo DN para a mesma entidade
sujeito.
es
O subjectAltName PODE conter tipos de nome adicionais através da utilização do campo
Othername. O formato e a semântica do nome são indicados através do identificador do
objeto no campo type-id. O próprio 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 sequência de realM e PrincipalName.
nd
Nomes alternativos de sujeito PODEM ser limitados da mesma forma que nomes distintos
de sujeitos usando a extensão name constraints como descrito na Seção 4.2.1.10.
na
Se a extensão subjectAltName estiver presente, a sequência DEVE ter pelo menos uma
entrada. Ao contrário do campo subject, as AC em conformidade NÃO DEVEM emitir
certificados com subjectAltNames contendo campos GeneralName vazios. Por exemplo, um
rfc822Name é representado como um IA5String. Enquanto um string vazio é um IA5String
válido, tal rfc822Name não é permitido por este perfil. O comportamento dos clientes que
encontrarem esse tipo de certificado, ao processar um caminho de certificação, não é definido neste perfil.
Finalmente, a semântica de nomes alternativos de sujeito que incluem caracteres curinga
(por exemplo, como um espaço reservado para um conjunto de nomes) não são abordados
por esta especificação. Aplicações com requisitos especı́ficos podem usar tais nomes, mas
eles devem definir a semântica.
id-ce-subjectAltName
::= GeneralNames
Er
SubjectAltName
GeneralNames
::= SEQUENCE SIZE (1..MAX) OF GeneralName
GeneralName
::=
otherName
rfc822Name
dNSName
x400Address
directoryName
ediPartyName
uniformResourceIdentifier
iPAddress
registeredID
CHOICE {
[0] OtherName,
[1] IA5String,
[2] IA5String,
[3] ORAddress,
[4] Name,
[5] EDIPartyName,
[6] IA5String,
[7] OCTET STRING,
[8] OBJECT IDENTIFIER }
OtherName
type-id
::= SEQUENCE {
OBJECT IDENTIFIER,
Cooper, et al.
Standards Track
34
value
Maio de 2008
[0] EXPLICIT ANY DEFINED BY type-id }
EDIPartyName
nameAssigner
partyName
4.2.1.7
RFC 5280
::= SEQUENCE {
[0] DirectoryString OPTIONAL,
[1] DirectoryString }
Issuer Alternative Name
es
Da mesma forma da seção 4.2.1.6, esta extensão é usada para associar identidades que seguem forma Internet, ao emissor do certificado. A extensão Issuer Alternative Name DEVE
ser codificada com definido em 4.2.1.6. Estas extensões não são processadas como parte
do algoritmo de validação de caminho de certificação conforme seção 6. (ou seja, os nomes
alternativos de emissor, não são usados em name chaining e nem o seu uso é incentivado
em name constraints.)
id-ce-issuerAltName
IssuerAltName
4.2.1.8
nd
Quando presente, as ACs em conformidade DEVERIAM marcar esta extensão como não
crı́tica.
::= GeneralNames
Subject Directory Attributes
na
A extensão subject directory attributes é utilizada para transmitir atributos de identificação
(por exemplo, a nacionalidade) do sujeito. A extensão é definida como uma sequência de
um ou mais atributos. As ACs em conformidade DEVEM marcar esta extensão como não
crı́tica.
id-ce-subjectDirectoryAttributes OBJECT IDENTIFIER ::= { id-ce 9 }
SubjectDirectoryAttributes
Basic Constraints
Er
4.2.1.9
::= SEQUENCE SIZE (1..MAX) OF Attribute
A extensão basic constraints identifica se o sujeito de um certificado é uma AC e a profundidade máxima dos caminhos de certicação válidos que incluem o certificado.
O campo booleano cA indica a chave pública do certificado pode ser utilizada para verificar
assinaturas de certificados. Se o booleano cA não for ativado, então o bit keyCertSign na
extensão key usage NÃO DEVE ser ativado. Se a extensão basic constraints não estiver
presente em um certificado X.509v3, ou se a extensão estiver presente, mas o campo booleano cA não tiver nenhum valor atribuı́do, então o certificado de chave pública NÃO DEVE
ser usado para verificação de assinatura de certificado.
O campo pathLenConstraints tem significância apenas quando o campo booleano cA for
ativado e a extensão key usage, quando presente, tiver o bit keyCertSign ativado (seção
4.2.1.3). Neste caso, ela fornece o número máximo de certificados intermediários não autoassinados que podem seguir o certificado em um caminho de certificação válido. (Nota: o
último certificado em um caminho de certificação não é um certificado intermediário, e nem
está incluı́do neste limite. Normalmente, o último certificado é um certificado de entidade
Cooper, et al.
Standards Track
35
RFC 5280
Maio de 2008
final, mas ele também pode ser um certificado de AC.) Um campo pathLenConstraints com
valor zero indica que nenhum certificado intermediário de AC não auto assinado pode seguir
em um caminho de certificação válido. Quando ele aparecer, o campo pathLenConstraints
DEVE ser maior ou igual a zero. Quando pathLenConstraings não aparecer, nenhum limite
é imposto.
es
As ACs em conformidade DEVEM incluir esta extensão em todos os certificados de AC
que contenham chaves públicas usadas para validar assinaturas digitais de certificados e
DEVEM marcar esta extensão como crı́tica neste tipo de certificado. Esta extensão PODE
aparecer como crı́tica ou não crı́tica em certificados de AC que contenham chaves públicas usadas exclusivamente para propósitos diferentes daquele da validação de assinatura
de certificados. Tais certificados incluem aqueles cujas chaves públicas são utilizadas exclusivamente para validação de assinaturas digitais de LCRs e aqueles que contêm chaves
públicas de gerenciamento de chaves usados em protocolos de negociação de chaves. Esta
extensão pode aparecer como crı́tica ou não crı́tica em certificados de entidades finais.
id-ce-basicConstraints
BasicConstraints
cA
pathLenConstraint
Name Constraints
::= SEQUENCE {
INTEGER (0..MAX) OPTIONAL }
na
4.2.1.10
nd
As ACs NÃO DEVEM incluir o campo pathLenConstraints a menos que o campo booleano
cA seja ativado e que o bit keyCertSign da extensão key usage também seja ativado.
Er
A extensão name constraints, que DEVE ser usada apenas em certificado de AC, indica o
espaço de nome dentro do qual todos os nomes de sujeito em certificados subsequentes do
caminho de certificação DEVEM estar contidos. As restrições se aplicam ao nome distinto
de sujeito e nomes alternativos de sujeito. As restrições são aplicáveis apenas quando a
forma de nome especificado estiver presente. Se nenhum nome do tipo estiver no certificado,
o certificado é aceitável.
Name constraints não são aplicados em certificados auto-assinados (a menos que o certificado seja o certificado final no caminho). (Isso poderia impedir que AC que usam name
constraints em certificados auto-assinados, implementem substituição de chave.)
As restrições são definidas em termos de subárvores de nomes permitidas ou excluı́das.
Qualquer nome correspondente em um campo excludedSubtrees é inválido independentemente da informação contida na permittedSubtrees. As ACs em conformidade DEVEM
marcar esta extensão como crı́tica e NÃO DEVERIAM impor restrições de nomes as formas x400address, ediPartyName ou formas de nome registeredID. As ACs em conformidade
NÃO DEVEM emitir certificados onde name constraints é uma sequência vazia. Ou seja,
tanto o permittedSubtree quanto o excludedSubtree DEVEM estar presentes.
As aplicações em conformidade com este perfil DEVEM ser capazes de processar restrições
de nome que são impostas em formas de nome directoryName e DEVERIAM ser capazes
de processar restrições de nome que são impostas nas formas rfc822Name, uniformResourceIdentifier, dNSName, e iPAddress. Se a extensão name constraints que é marcada como
Cooper, et al.
Standards Track
36
RFC 5280
Maio de 2008
crı́tica impor restrições a uma forma especı́fica, e uma instância daquelas formas de nome
aparecerem em um campo subject ou extensão subjectAltName de um certificado subsequente, então a aplicação DEVE processar a restrição ou rejeitar o certificado.
Dentro deste perfil, os campos mı́nimo e máximo não são utilizados nas formas any name,
assim, o mı́nimo DEVE ser zero, e o máximo DEVE estar ausente. Entretanto, se uma
aplicação encontra uma extensão name constraints crı́tica que especifica outros valores para
mı́nimo ou máximo para uma forma de nome que aparece em um certificado subsequente,
a aplicação DEVE processar estes campos ou rejeitar o certificado.
nd
es
Para URIs, a restrição é aplicada a parte host do nome. A restrição DEVE ser especificada
como um nome de domı́nio totalmente qualificado e PODE especificar um host ou um domı́nio. Seriam exemplos “host.example.com” e “.example.com”. Quando a restrição começa
com um ponto, ela PODE ser expandida com um ou mais rótulos. Ou seja, a restrição
“.example.com” é satisfeita por tanto host.example.com quanto por my.host.example.com.
Entretanto, a restrição “.example.com” não é satisfeita por “example.com”. Quando a restrição não começar com um ponto, ela especifica um host. Se uma restrição é aplicada a
forma de nome uniformResourceIdentifier e um certificado subsequente inclui uma extensão subjectAltName com um uniformResourceIdentifier que não inclui uma componente
autoridade 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 componente
autoridade no qual o nome do host é especificado como um endereço IP), então a aplicação
DEVE rejeitar o certificado.
Er
na
Uma restrição de nome para endereço de correio eletrônico Internet PODE especificar uma
caixa de correio particular, todos os endereços de um host em particular, ou todas as caixas
postais de um domı́nio. Para indicar uma caixa de correio particular, a restrição é o endereço completo de correio eletrônico. Por exemplo, “[email protected]” indica a caixa postal
root no host “example.com”, a restrição “example.com” é satisfeita por qualquer endereço
de correio eletrônico no host “example.com”. Para especificar qualquer endereço dentro
de um domı́nio, a restrição é especificada com ponto na frente (como ocorre com URIs).
Por exemplo, “.example.com” indica todos os endereços de correio eletrônico no domı́nio
“example.com”, mas não todos os endereços de correio eletrônico no host “example.com”.
As restrições a nomes DNS são expressas como host.example.com. Qualquer nome DNS
que possa ser construı́do simplesmente adicionando zero ou mais rótulos ao lado mais a
esquerda do nome satisfará a restrição de nome. Por exemplo, www.host.example.com satisfaria a restrição, mas host1.example.com não satisfaria.
Existem implementações no legado nas quais um endereço de correio eletrônico foi incorporado no nome distinto de sujeito em um atributo do tipo emailAddress (seção 4.1.2.6).
Quando são impostas restrições na forma de nome rfc822Name, mas o certificado não
inclui um nome alternativo de sujeito, a limitação rfc822Name DEVE ser aplicada ao atributo do tipo emailAddress no campo subject distinguished name. A sintaxe ASN.1 para
emailAddress e o seu OID correspondente é fornecida no Apêndice A.
Restrições da forma directoryName DEVEM ser aplicadas ao campo subject do certificado (quando o certificado incluir um campo subject não vazio) e a qualquer nome do tipo
directoryName da extensão subjectAltName. Restrições da forma x400Address DEVEM
ser aplicadas a qualquer nome do tipo x400Address na extensão subjectAltName.
Cooper, et al.
Standards Track
37
RFC 5280
Maio de 2008
Quando aplicar restrições da forma directoryName, a aplicação DEVE comparar os atributos DN. No mı́nimo, as aplicações DEVEM executar as regras de comparação para DN
especificadas na seção 7.1. As ACs que emitem certificados com uma restrição da forma
directoryName NÃO DEVERIAM confiar em implementações do algoritmo de comparação
de nome ISO DN completo. Isso implica que as restrições de nome DEVEM ser definidas de maneira idêntica para a codificação usada no campo subject ou para a extensão
subjectAltName.
id-ce-nameConstraints
nd
es
A sintaxe de iPAddress DEVE ser aquela descrita na seção 4.2.1.6 com as adições seguintes especificamente para restrições de nomes. Para endereços IPv4, o campo endereço de
GeneralName DEVE conter oito (8) octetos, condificados no estilo da RFC 4632 (CIDR)
para representar o escopo de endereçamento [RFC4632]. Para endereços IPv6, o campo
iPAddress DEVE conter 32 octetos codificados de maneira similar. Por exemplo, uma
restrição de nome para subrede “classe C” 192.0.2.0 é representado é representada pelos
octetos C0 00 02 00 FF FF FF 00, representando a notação CIDR 192.0.2.0/24 (máscara
255.255.255.0).
NameConstraints
permittedSubtrees
excludedSubtrees
::= SEQUENCE {
[0] GeneralSubtrees OPTIONAL,
[1] GeneralSubtrees OPTIONAL }
GeneralSubtrees
::= SEQUENCE SIZE (1..MAX) OF GeneralSubtree
Regras adicionais para codificação e processamento de restrições de nome são especificadas
na seção 7.
A sintaxe e a semântica para restrições de nome para otherName, ediPartyName, e registeredID não são definidas nesta especificação, entretanto, a sintaxe e a semântica para
restrições de nome para formas other name podem ser especificadas em outros documentos.
na
Er
GeneralSubtree
base
minimum
maximum
BaseDistance
4.2.1.11
::= SEQUENCE {
GeneralName,
[0] BaseDistance DEFAULT 0,
[1] BaseDistance OPTIONAL }
::= INTEGER (0..MAX)
Policy Constraints
A extensão policy constraints pode ser usada em certificados emitidos para ACs. A extensão restringe validação de caminho de certificação de duas formas. Pode ser utilizada
para impedir o mapeamento de polı́tica ou requerer que todo certificado de um caminho
contenha um identificador de polı́tica aceitável.
Se o campo inhibitPolicyMapping estiver presente, o valor indica o número de certificados
adicionais 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
Cooper, et al.
Standards Track
38
RFC 5280
Maio de 2008
emitidos pelo sujeito do certificado, mas não em certificados adicionais do caminho.
Se o campo requireExplicitPolicy estiver presente, o valor de requireExplicitPolicy indica
o número de certificados adicionais que podem aparecer no camiinho ante de uma explicit
policy ser requerido para o caminho inteiro. Quando uma polı́tica explı́cita for requerida,
é necessário que todos os certificados do caminho contenham um identificador de polı́tica
aceitável na extensão certificate policy. Um indentificador de polı́tica aceitável é o identificador de uma polı́tica requerida pelo usuário do caminha de certificação ou o identificador
de uma polı́tica que for declarada como equivalente através da extensão policy mapping.
es
Aplicações em conformidade DEVEM ser capazes de processar o campo requireExplicitPolicy e DEVERIAM ser capazes de processar o campo inhibitPolicyMapping. Aplicações
que suportarem o campo inhibitPolicyMapping DEVEM também implementar suporte a
extensão policyMappings. Se a estensão policyConstraints estiver marcada como crı́tica
e o campo inhibitPolicyMapping estiver presente, as aplicações que não implementarem
suporte ao campo inhibitPolicyMapping DEVEM rejeitar o certificado.
nd
As ACs em conformidade NÃO DEVEM emitir certificados onde policy constraints é uma
sequência vazia. Ou seja, tanto o campo inhibitPolicyMapping ou o campo requireExplicitPolicy DEVE estar presente. O comportamento do cliente que encontra um campo policy
constraints vazio não é tratado neste perfil.
As ACs em conformidade DEVEM marcar esta extensão como crı́tica.
na
id-ce-policyConstraints
PolicyConstraints
requireExplicitPolicy
inhibitPolicyMapping
::= SEQUENCE {
[0] SkipCerts OPTIONAL,
[1] SkipCerts OPTIONAL }
SkipCerts
Extended Key Usage
Er
4.2.1.12
Esta extensão indica um ou mais propósitos para os quais o certificado de chave pública
pode ser usado, em adição a ou em substituição ao indicado no campo basic purpose na
extensão key usage.
id-ce-extKeyUsage
ExtKeyUsageSyntax
::= SEQUENCE SIZE (1..MAX) OF KeyPurposeId
KeyPurposeId
O propósito da chave pode ser definido por qualquer organização com esta demanda. Identificadores de objeto utilizados para identificar os propósitos da chave DEVEM ser atribuı́dos
em conformidade com o IANA ou a recomendação ITU-T X.660 [X.660].
Esta extensão PODE, dependendo da opção do emissor do certificado, ser marcada como
crı́tica ou não-crı́tica.
Cooper, et al.
Standards Track
39
RFC 5280
Maio de 2008
Se a extensão estiver presente, então o certificado DEVE apenas ser utilizado para um dos
propósitos indicados. Se múltiplos propósitos forem indicados, a aplicação não necessita
reconhecer todos eles, desde que o propósito pretendido esteja presente. Aplicações que
usam certificados PODEM requerer que a extensão extended key usage estejam presente
e que seja indicado um propósito particular para que o certificado seja aceito pela aplicação.
es
Se uma AC inclui a extensão extended key usage para satisfazer tais aplicações, mas não
querem restringir o uso da chave, a AC pode incluir o valor especial anyExtendedKeyUsage
ao campo KeyPurposeID em adição ao propósito especı́fico requerido pelas aplicações. ACs
em conformidade NÃO DEVERIAM marcar esta extensão como crı́tica anyExtendedKeyUsage no campo KeyPurposeId estiver presente. Aplicações que necessitarem a presença de
um propósito particular PODEM rejeitar certificados que tiverem incluı́do o OID anyExtendedKeyUsage, mas não o OID especı́fico aguardado pela aplicação.
nd
Se um certificado tiver tanto a extensão key usage e uma extensão extended key usage, então ambas as extensões DEVEM ser processadas independentemente e o certificado DEVE
ser utilizado apenas para o propósito consistente com ambas as extensões. Se não existir
nenhum propósito consistente em ambas as extensões, então o certificado NÃO DEVE ser
usado para nenhum dos propósitos.
São definidos propósitos de uso para chave:
id-kp
na
id-kp-serverAuth
OBJECT IDENTIFIER ::= { id-kp 1 }
-- TLS WWW server authentication
-- Key usage bits that may be consistent: digitalSignature,
-- keyEncipherment or keyAgreement
Er
id-kp-clientAuth
-- TLS WWW client authentication
-- Key usage bits that may be consistent: digitalSignature
-- and/or keyAgreement
id-kp-codeSigning
-- Signing of downloadable executable code
id-kp-emailProtection
-- Email protection
-- Key usage bits that may be consistent: digitalSignature,
-- nonRepudiation, and/or (keyEncipherment or keyAgreement)
id-kp-timeStamping
-- Binding the hash of an object to a time
-- and/or nonRepudiation
id-kp-OCSPSigning
-- Signing OCSP responses
Cooper, et al.
Standards Track
40
RFC 5280
Maio de 2008
-- and/or nonRepudiation
4.2.1.13
CRL Distribution Points
A extensão CRL Distribution Points identifica como a informação da LCR é obtida. A
extensão DEVERIA ser marcada como não-crı́tica, mas este perfil RECOMENDA suporte
a esta extensão, tanto nas ACS quanto nas aplicações. Uma discussão adicional sobre o
gerenciamento de LCR está incluı́da na seção 5.
nd
es
A extensão cRLDistributionPoints é uma sequência de DistributionPont. Um DistributionPoint é formado por três campos, cada um deles opcional: distributionPoint, reasons,
e cRLIssuer. Embora cada um desses campos seja opcional, um DistributionPoint NÃO
DEVE consistir de apenas do campo reasons, o distributionPoint ou cRLIssuer DEVE estar
presente. Se o emissor do certificado não for o emissor da LCR, então o campo cRLIssuer
DEVE estar presente, e conter o nome do emissor da LCR. Se o emissor do certificado também for o emissor da LCR, as ACs em conformidade DEVEM omitir o campo cRLIssuer e
DEVEM incluir o campo distributioinPoint.
Quando o distributionPoint estiver presente, ele pode conter tanto uma SEQUENCE de
general names como um valor único, nameRelativeToCRLIssuer. Se o DistributionPointsName tiver múltiplos valores, cada nome descreve um mecanismo distinto para obtenção
da mesma LCR. Por exemplo, a mesma LCR poderia estar disponı́vel para recuperação
tanto através do LDAP quanto do HTTP.
na
Se o campo distributionPoints tiver um directoryName, a entrada para aquele directoryName contem a LCR atual para as razões relacionadas e a LCR é emitida pelo cRLIssuer associado. A LCR pode estar armazenada tanto no atributo certificateRevocationList
quanto no atributo authotityRevocationList. A LCR a ser obtida pela aplicação a partir
de qualquer servidor de diretório é configurada localmente. O protocolo utilizado pela aplicação para acessar o diretório (por exemplo, DAP ou LDAP) é uma questão local.
Er
Se o DistributionPointName tiver um general name do tipo URI, a seguinte semântica
DEVE ser considerada: A URI é um apontador para a LCR atual para as razões relacionadas e será emitida pelo cRLIssuer associado. Quando o forem utilizados os esquemas HTTP ou FTP URI, a URI deve apontar para uma única LCR codificada em DER,
conforme especificado em [RFC2585]. Implementações de servidor HTTP acessado via
URI DEVERIAM especificar o tipo de meio application/pkix-crl no campo de cabeçalho
content-type na resposta. Quando o esquema LDAP URI [RFC4516] for utilizado, a URI
DEVE incluir um campo <dn> contendo o nome distinto da entrada da LCR, DEVE
incluir um único <attrdesc> que contém uma descrição de atributo apropriado para o
atributo que mantém a LCR [RFC4523], e DEVERIA incluir um <host> (por exemplo,
<ldap://ldap.example.com/cn=example%20CA,dc=example, dc=com?certificateRevocationList;binary>). Omitir o <host> (por exemplo, <ldap://cn=CA,dc=examplo,dc=?authorityRevocationList,binary>) tem o efeito de confiar em qualquer conhecimento, que o
cliente detenha a priori, para contactar o servidor apropriado. Quando presente, DistributionPointName DEVERIA incluir no mı́nimo uma URI LDAP ou HTTP.
Se o DistributionPointName tiver o valor único nameRelativeToCRLIssuer, o valor fornece
um fragmento do distinguished name. O fragmento é acrescentado ao distinguished name
Cooper, et al.
Standards Track
41
RFC 5280
Maio de 2008
X.500, do emissor da LCR, para obter o nome do ponto de distribuição. Se o campo cRLIssuer no DistributionPoint estiver presente, então o fragmento do nome é adicionado ao
disntinguished name que ele contém; de outra forma, o fragmento de nome é adicionado
ao distinguished name do emissor do certificado. ACs em conformidade NÃO DEVERIAM
usar nameRalativeToCRLIssuer para indicação de nomes de ponto de distribuição. O DistributionPointName NÃO DEVE usar o nameRelativeToCRLIssuer alternativo quando o
cRLIssuer tiver mais que um distinguished name.
es
Se o DistributionPoint omitir o campo reasons, a CRL DEVE incluir informações de revogação para todas as razões. Este perfil RECOMENDA evitar a segmentação de LCRs pelos
codigos contidos em reason. Quando um AC em conformidade incluir a extensão cRLDistributionPoints em um certificado, ela DEVE incluir no mı́nimo um DistributionPoint que
aponta para uma LCR que cobre o certificado para todas as razões.
id-ce-cRLDistributionPoints
::= SEQUENCE SIZE (1..MAX) OF DistributionPoint
na
CRLDistributionPoints
nd
O cRLIssuer identifica a entrada que assina e emite a LCR, Se presente, a cRLIssuer DEVE
conter apenas o nome distinto (DN) do campo issuer da LCR para a qual o DistributionPoint está apontando. A codificação do nome no campo cRLissuer DEVE ser exatamente
o mesmo que a codificação no campo issuer da LCR. Se o campo sRLIssuer estiver incluı́do e o DN naquele campo não corresponder a uma entrada de diretório X.500 ou LDAP
na qual a LCR esta localizada, então as ACs em conformidade DEVEM incluir o campo
distributionPoint.
::= SEQUENCE {
[0] DistributionPointName OPTIONAL,
[1] ReasonFlags OPTIONAL,
[2] GeneralNames OPTIONAL }
DistributionPointName
fullName
nameRelativeToCRLIssuer
ReasonFlags
unused
keyCompromise
cACompromise
affiliationChanged
superseded
cessationOfOperation
certificateHold
privilegeWithdrawn
aACompromise
::= CHOICE {
[0] GeneralNames,
[1] RelativeDistinguishedName }
::= BIT STRING {
(0),
(1),
(2),
(3),
(4),
(5),
(6),
(7),
(8) }
Er
DistributionPoint
distributionPoint
reasons
cRLIssuer
4.2.1.14
Inhibit anyPolicy
A extensão inhibit anyPolicy pode ser utilizada em certificados emitidos para ACs. A extensão inhibit anyPolicy indica que o OID especial anyPolicy, com o valor 2 5 29 32 0 ,
Cooper, et al.
Standards Track
42
RFC 5280
Maio de 2008
não é considerado uma correspondência explicita para outras polı́ticas de certificado exceto
quanto aparecerem em um certificado intermediário de AC auto-assinado. O valor indica o
número de certificados adicionais não-auto-assinados que pode aparecer no caminho antes
de anyPolicy não mais ser permitido. Por exemplo, o valor um idica que anyPolicy pode
ser processado em certificados emitidos pelo sujeito do certificado, mas não em certificados
adicionais no caminho.
As ACs em conformidade DEVEM marcar esta extensão como crı́tica.
es
id-ce-inhibitAnyPolicy
InhibitAnyPolicy
::= SkipCerts
SkipCerts
4.2.1.15
Freshest CRL (Delta CRL Distribution Point)
nd
A extensão freshest CRL identifica como a informação de LCR delta é obtida. A extensão
DEVE ser marcada como não-crı́tica nas ACs em conformidade. A seção 5 contém uma
discussão adicional sobre o gerenciamento.
A mesma sintaxe é usada para esta extensão, e a extensão cRLDistributionPoints, é descrita
na seção 4.2.1.13. A mesma convenção é aplicada às duas extensões.
FreshestCRL
4.2.2
na
id-ce-freshestCRL
::= CRLDistributionPoints
Extensões Privadas Internet
Er
Esta seção define duas extensões em Infraestruturas de Chave Pública Internet. Estas extensões podem ser utilizadas para direcionar aplicações para informações on-line sobre o
emissor ou sobre o sujeito do certificado. Cada extensão contém uma sequência de métodos
de acesso e locais de acesso. O método de acesso é um identificador de objeto que indica o
tipo de informação que está disponı́vel. O local de acesso é um GeneralName que implicitamente especifica o local e o formato da informação, e o método para obtenção da informação.
Identificadores de objeto são definidos para as extensões privadas. Os identificadores de
objeto associado a extensões privadas são devinidos sob o arco is-pe dentro do arco id-pkix.
Quaisquer extensões futuras definidas para a ICP Internet também é esperando que sejam
definidas sob o arco id-pe.
id-pkix
id-pe
Cooper, et al.
OBJECT IDENTIFIER ::=
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) }
Standards Track
43
4.2.2.1
RFC 5280
Maio de 2008
Authority Information Access
A extensão authority information access (acesso a informação de autoridade) indica como
acessar informação e serviços para o emissor do certificado no qual a extensão ocorre.
Informação e serviços podem incluir serviços de validação on-line e dado de polı́tica de
AC. (A localização de LCRs não é especificada nesta extensão; essa informação é fornecida
pela extensão cRLDistributionPoints.) Esta extensão pode ser incluı́da em certificados
de entidade final ou de AC. ACs em conformidade DEVEM marcar esta extensão como
não-crı́tica.
AccessDescription
accessMethod
accessLocation
id-ad
id-ad-caIssuers
id-ad-ocsp
::=
es
AuthorityInfoAccessSyntax
OBJECT IDENTIFIER ::= { id-pe 1 }
SEQUENCE SIZE (1..MAX) OF AccessDescription
::= SEQUENCE {
OBJECT IDENTIFIER,
GeneralName }
OBJECT IDENTIFIER ::= { id-ad 2 }
nd
id-pe-authorityInfoAccess
na
Cada entrada na sequência AuthorityInformationAccessSyntax descreve o formato e a localização da informação adicional fornecida pelo emissor do certificado no qual a extensão
ocorre. O tipo e o formato da informação são especificados pelo campo accessMethod; o
campo accessLocation especifica o local da informação. O mecanismo de recuperação pode
estar implı́cito no accessMethod ou estar ser especificado no accessLocation.
Este perfil define dois OIDs para accessMethod: id-ad-caIssuers e id-ad-ocsp.
Er
No certificado de chave pública, o OID id-ad-caIssuers é usado quando a informação adicional lista certificados que foram emitidos para a AC que emitiu o certificado que tem a
extensão. A descrição de AC emissoras referenciada tem como finalidade ajudar os usuários
de certificado na seleção de um caminho de certificação que termina em um ponto que é
considerado confiável pelo usuário do certificado.
Quando id-ad-caIssuers aparece como accessMethod, o campo accessLocation descreve o
servidor da descrição referenciada e o protocolo de acesso para obtenção da descrição referenciada. O campo accessLocation é definido como GeneralName, que pode ter várias
formas.
Quando o accessLocation é um directoryName, a informação a ser obtida pela aplicação a
partir de qualquer servidor de diretório é localmente configurada. A entrada para o directoryName contem certificados de AC em crossCertificatePair e/ou atributos cACertificate
como especificado em [RFC4523]. O protocolo que as aplicações utilizaram para acessor o
diretório (ex, DAP ou LDAP) é uma questão local.
Onde a informação estiver disponı́vel através do LDAP, o accessLocation DEVERIA ser
um uniformResourceIdentifier. A URI LDAP [RFC4516] DEVE incluir um campo <dn>
contendo o nome distinto do entrada com o certificado, DEVE incluir um campo <attributes> que lista a descrições apropriadas ao atributo para os atributos que detêm certificados
Cooper, et al.
Standards Track
44
RFC 5280
Maio de 2008
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;binary,crossCertificatePair,binary>). Omitindo o <host> (ex, <ldap:///cn=exampleCA,dc=example,dc=com?cACertificate;binary>) tem o efeito de confiar em qualquer conhecimento
que o cliente possa ter, a priori, para contactar um servidor apropriado.
es
Onde a informação estiver disponı́vel através de HTTP ou FTP, accessLocation DEVE ser
um uniformResourceIdentifier e a URI DEVE apontar tanto para um único certificado, codificado em DER como especificado em [RFC2585] como para uma coleção de certificados
em uma mensagem CMS tipo “certs-only” codificada em BER ou DER , conforme especificado em RFC2797].
Aplicações em conformidade que suportam HTTP ou FTP para acessar certificados DEVEM ser capazes de aceitar certificados individuais codificados em DER e DEVERIAM ser
capazes de aceitar mensagens CMS “certs-only”.
nd
Implementações de servidores HTTP acessados via URI DEVERIAM especificar o tipo
de mı́dia aplication/pkix-cert [RFC2585] no campo de cabeçalho content-type da resposta
para mensagens CMS “certs-only”. Para FTP, o nome do arquivo que contém um certificado único codificado em DER DEVERIA possuir um sufixo “.cer” [RFC2585] e o nome
do arquivo que contem uma mensagem CMS “certs-only” DEVERIA ter o sufixo “.p7c”
[RFC2797]. Clientes consumidores podem usar o tipo de mı́dia ou extensão de arquivo
como uma dica para o conteúdo, mas não deve depender apenas da presença do tipo de
mı́dia correto ou extensão de arquivo na resposta do servidor.
na
A semântica de outras formas de nome id-ad-caIssuers accessLocation não são definidas.
Uma extensão authorityInfoAccess pode incluir múltiplas instancias de id-ad-caIssuers accessMethod. As diferentes instâncias podem especificar diferentes métodos para acessar a
mesma informação ou podem apontar para informação diferente. Quando o id-ad-caIssuers
accessMethod é usado, no mı́nimo uma instância DEVERIA especificar uma accessLocation
que é uma URI HTTP [RFC2616] ou LDAP [RFC4516].
Er
O OID id-ad-ocsp é usado quando informação de revogação para o certificado contendo
esta extensão 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 respondedor OCSP, usando as convenções definidas em [RFC2560].
Descritores adicionais de acesso podem ser definidos em outras especificações PKIX.
4.2.2.2
Subject Information Access
A extensão subject information access indica como acessar informação e serviços para o
sujeito do certificado no qual a extensão ocorre. Quando o sujeito é uma AC, informações
e serviços podem incluir serviços de validação de certificado e dados dé polı́tica de AC.
Quando o sujeito é uma entidade final, a informação descreve o tipo de serviços oferecidos
e como acessá-los. Neste caro, o conteúdo desta extensão é definido na especificação do
protocolo para os serviços suportados. Esta extensão pode ser incluı́da em certificados de
Cooper, et al.
Standards Track
45
RFC 5280
Maio de 2008
entidade final ou de AC. ACs em conformidade DEVEM marcar esta extensão como nãocrı́tica.
id-pe-subjectInfoAccess
SubjectInfoAccessSyntax
OBJECT IDENTIFIER ::= { id-pe 11 }
::=
::= SEQUENCE {
OBJECT IDENTIFIER,
GeneralName }
es
AccessDescription
accessMethod
accessLocation
nd
Cada entrada na sequÊncia SubjectInfoAccessSyntax descreve o formato e a localização da
informação adicional fornecida pelo sujeito do certificado no qual a extensão ocorre. O tipo
e o formato da informação são especificados no campo accessMethod; o campo accessLocation especifica o local da informação. O mecanismo de recuperação pode estar implı́cito
no accessMethod ou ser especificado por accessLocation.
Este perfil define um método de acesso para ser usado quando o sujeito é uma AC e um
método de acesso para ser usado quando o sujeito é uma entidade final. Métodos de acesso
adicionais podem ser definidos no futuro em especificações de protocolos para outros serviços.
na
O OID id-ad-caRepository é usado quando o sujeito é uma AC que publica certificados que
ela emite em um repositório. O campo accessLocation é como um GeneralName, que pode
ter diversas formas.
Er
Quando o accessLocation é um directoryName, a informação é para ser obtida pela aplicação de qualquer diretório localmente configurado. Quando a extensão é usada para apontar
para certificados de AC, a entrada para o directoryName contém certificados de AC no
crossCertificatePair e/ou atributos cACertificate como especificado em [RFC4523]. O protocolo que a aplicação usa para acessar o diretório (ex: DAP ou LDAP) é uma questão local.
Onde a informação for disponibilizada através do LDAP, o accessLocation DEVERIA ser
um uniformResourceIdentifier. A URI LDAP [RFC4516] DEVE incluir um campo <dn>
contendo o nome distinto da entrada que detém os certificados, DEVE incluir um campo
<attributes> que lista os descritores de atributo apropriados para o atributo que detém os
certificados codificados em DER ou pares cross-certificate [RFC4523], e DEVERIA incluir
um <host> (ex: <ldap://ldap.example.com/cn=AC,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 em qualquer conhecimento, a priori, o cliente poderia ter para
contactar um servidor apropriado.
Onde a informação estiver disponı́vel via HTTP ou FTP, accessLocation DEVE ser um
uniformResourceIdentifier e a URI DEVE apontar para um único certificado codificado em
DER como especificado em [RFC2585] ou uma coleção de certificados codificados em BER
Cooper, et al.
Standards Track
46
RFC 5280
Maio de 2008
ou DER de uma mensagem CMS “certs-only” como especificado em [RFC2797].
Aplicações em conformidade que suportam HTTP ou FTP para acessar certificados DEVEM ser capazes de aceitar certificados individuais codificados em DER e DEVEM ser
es
Implementações de servidores HTTP acessados via URI DEVERIAM especificar a tipo de
mı́dia application/pkix-cert [RFC2585] no campo content-type do cabeçalho da resposta
para um único certificado codificado em DER e DEVERIA especificar o tipo de mı́dia
application/pkcs7-mime [RFC2797] no campo content-type do cabeçalho da resposta para
mensagens CMS “certs-only”. Para FTP, o nome do arquivo que contem um único certificado codificado em DER DEVERIA ter sufixo “.cer” [RFC2585] e o nome do arquivo
contendo uma mensagem “certs-only” DEVERIA ter um sufixo “.p7c” [RFC2797]. Clientes
consumidores podem usar o campo media type ou file extension como uma sugestão para
o conteúdo, mas não deveria depender somente da presença do tipo correto de mı́dia ou da
extensão arquivo na resposta do servidor.
nd
A semântica de outra forma id-ad-caRepository para nome accessLocation não é definida.
Uma extensão subjectAccess pode incluir múltiplas instâncias de id-ad-caRepository accessMethod. As diferentes instâncias podem especificar diferentes métodos para acessar a
mesma informação ou apontar para informação diferente. Quando o id-ad-caRepository
accessMethod é usado, no mı́nimo uma instância DEVERIA especificar um accessLocation
que seja URI HTTP [RFC2616] ou LDAP [RFC4516].
Er
na
O OID id-ad-timeStamping é usado quando o sujeito oferece serviços de timestamping
usando o Time Stamp Protocol definido em [RFC3161]. Onde os serviços de timestamping
estiveres disponı́veis via HTTP ou FTP, accessLocation DEVE ser um uniformResourceIdentifier. Onde os serviços de timestamping estiverem disponı́veis via correio eletrônico,
accessLocation DEVE ser um rfc822name. Onde serviços de timestamping estiverem disponı́veis usando TCP/IP, o dNSName ou formas de nome tipo iPAddress podem ser utilizadas.
As semânticas de outras formas de nome de accessLocation (quando accessMethod é id-adtimeStamping) não são definidas nesta especificação.
Outros descritores de acesso adicionais podem ser definidos em outras especificações PKIX.
id-ad
id-ad-caRepository
id-ad-timeStamping
5
Perfil da LCR e das Extensões da LCR
Como discutido acima, um objetivo deste perfil para LCR X.509 v2 é fomentar a criação de
uma ICP Internet interoperável e reutilizável. Para atingir este objetivo, são especificadas
diretrizes para o uso de extensões, e são feitas considerações sobre a natureza da informação
contida na LCR.
Cooper, et al.
Standards Track
47
RFC 5280
Maio de 2008
As LCRs podem ser utilizadas numa vasta gama de aplicações e ambientes que abrangem um largo espectro de objetivos de interoperabilidade e um espectro ainda mais amplo
de requisitos operacionais e de segurança. Este perfil estabelece uma base comum para
aplicações genéricas que exigem ampla interoperabilidade. O perfil define um conjunto
de informações que podem ser esperadas em cada LCR. Além disso, o perfil define locais
comuns dentro do LCR para atributos usados com freqüência, assim como representações
comuns para esses atributos.
es
Os emissores de LCR emitem LCRs. O emissor da LCR pode ser tanto a AC quanto uma
entidade que foi autorizada pelo AC para emitir LCRs. ACs publicam LCRs para fornecer
informações de estado de revogação dos certificados por ela emitidos. No entanto, uma AC
pode delegar esta responsabilidade a uma outra autoridade confiável.
nd
Cada LCR possui um escopo especı́fico. O escopo da LCR é o conjunto de certificados que
podem aparecer em uma dada LCR. Por exemplo, o escopo pode ser “todos os certificados
emitidos pela AC X”, “todos os certificados de AC emitidos pela AC X”, “todos os certificados emitidos pela AC X que foram revogados por razões de comprometimento da chave e
comprometimento da AC”, ou um conjunto de certificados com base em informações locais
arbitrárias, como “todos os certificados emitidos aos funcionários do NIST localizados em
Boulder”.
na
Uma LCR completa lista todos os certificados em curso, dentro do seu âmbito, que foram
revogados por um dos motivos de revogação abrangidos pelo escopo da LCR. Uma LCR
inteira e completa lista todos os certificados ainda não vencidos emitidos por uma CA que
foram revogados por qualquer motivo. (Note que, as ACs e emissores de LCR são identificados pelo nome, o escopo de uma LCR não é afetado pela chave usada para assinar a
LCR ou a(s) chave(s) usada(s) para assinar certificados.)
Er
Se o escopo da LCR inclui um ou mais certificados emitidos por uma entidade distinta do
emitente da LCR, então ela é um LCR indireta. O escopo de uma LCR indireta pode ser
limitada aos certificados emitidos por uma única CA ou pode incluir certificados emitidos
por múltiplas ACs. Se o emitente da LCR indireta é uma AC, então, o escopo da LCR
indireta também pode incluir certificados emitidos pelo emissor da LCR.
O emissor da LCR também PODE gerar LCRs delta. Um LCR delta lista apenas os certificados, no seu escopo, cuja estado de revogação mudou desde a emissão da CRL completa
referenciada. A LCR completa referenciada é indicada como uma LCR base. O escopo de
uma LCR delta deve ser a mesma que a LCR base a qual faz referência.
Este perfil define uma extensão privada para LCR Internet, mas não define qualquer extensão privada para entrada da LCR.
Ambientes com requisito adicional ou especial podem implementar esse perfil ou pode
substituı́-lo.
As ACs em conformidade não são obrigadas a emitir LCRs quando são fornecidos outros
mecanismos para consulta do estado de revogação de certificados. Quando as LCRs são
emitidas, as LCRs DEVEM ser LCRs versão 2, incluir a data em que a próxima LCR será
emitida no campo nextUpdate (Seção 5.1.2.5), incluir a extensão number da LCR (Seção
5.2.3), e incluir a autoridade extensão authority key identifier (Seção 5.2.1). As aplicações
Cooper, et al.
Standards Track
48
RFC 5280
Maio de 2008
em conformidade que suportarem LCRs são REQUERIDAS fazer o processamento tanto
da versão 1 quanto da versão 2 das LCRs completas que fornecem informações de revogação sobre todos os certificados emitidos por uma AC. Aplicações em conformidade não são
obrigadas a suportar o processamento de LCRs delta, LCRs indiretas, ou LCRs com um
escopo diferente daquele utilizado para todos os certificados emitidos por uma AC.
5.1
Campos da LCR
::= SEQUENCE {
TBSCertList,
BIT STRING }
::= SEQUENCE {
Version OPTIONAL,
-- if present, MUST be v2
signature
issuer
Name,
thisUpdate
Time,
nextUpdate
Time OPTIONAL,
revokedCertificates
SEQUENCE OF SEQUENCE {
userCertificate
revocationDate
Time,
crlEntryExtensions
Extensions OPTIONAL
-- if present, version MUST be v2
} OPTIONAL,
crlExtensions
[0] EXPLICIT Extensions OPTIONAL
-- if present, version MUST be v2
Er
na
TBSCertList
version
nd
CertificateList
tbsCertList
signatureAlgorithm
signatureValue
es
A sintaxe da LCR X.509 v2 é a seguinte. Para o cálculo da assinatura o dado deve ser
assinado é aquele codificado em DER do ASN.1. A codificação DER do ASN.1 é formado
por um rótulo, tamanho, e um sistema de codificação de valor para cada elemento. id-pesubjectInfoAccess OBJECT IDENTIFIER ::= id-pe 11
SubjectInfoAccessSyntax ::= SEQUENCE SIZE (1..MAX) OF AccessDescription
}
-- 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 sequência de três campos obrigatórios. Os campos são
descritos em detalhes nas subseções seguintes.
5.1.1.1
tbsCertList
O primeiro campo na sequeência é o tbsCertList. O campo é por si, uma sequência contendo o nome do emissor, a data de emissão, a data da emissão da próxima lista, a lista
Cooper, et al.
Standards Track
49
RFC 5280
Maio de 2008
opcional de certificados revogados, e extensões opcionais da LCR. Quando não existirem
certificados revogados, a lista de certificados revogados não estará presente. Quando um
ou mais certificados tiverem sido revogados, cada entrada da lista de certificados revogados é definida como uma sequência de números seriais de certificados de usuário, data da
revogação e entradas para extensões opcionais da LCR.
5.1.1.2
signatureAlgorithm
es
O campo signatureAlgorithm contem o identificador de algoritmo para o algoritmo usado
pelo emissor da LCR para assinar o CertificateList. O campo é do tipo AlgorithmIdentifier,
que é definido na seção 4.1.1.2. [RFC4055], [RFC4055], e [RFC4491] lista os algoritmos suportados por esta especificação, mas outros algoritmos de assinatura também PODEM ser
suportados.
5.1.1.3
signatureValue
nd
Este campo DEVE conter o mesmo identificador de algoritmo que o indicado no campo
signature da sequência tbsCertList (seção 5.1.2.2).
O campo signatureValue contem uma assinatura digital calculada sobre o campo tbsCertList codificado em DER do ASN.1. O tbsCertList codificado é usado como entrada para a
função de assinatura. Esse valor de assinatura é codificado como um string de bit e incluı́do
no campo signatureValue da LCR. Os detalhes desse processo são especificados para cada
um dos algoritmos suportados em [RFC3279], [RFC4055], e [RFC4491].
Er
na
As ACs que também são emissoras de LCR PODEM usar uma chave privada para assinar
digitalmente certificados e LCRs, ou PODEM usar chaves privadas separadas para assinar digitalmente certificados e LCRs. Quando empregadas chaves separadas, cada uma das
chaves públicas relacionadas com essas chaves privadas é incluı́da em certificados separados,
um com o bit cRLSign ativado na extensão key usage (seção 4.2.1.3). Quando forem empregadas chaves privadas separadas, os certificados emitidos pela AC contêm um authority
key identifier, e as LCRs correspondentes, contêm um authority key identifier diferente. O
uso de certificados de AC separados para validação de assinaturas de certificado e assinaturas de LCR, podem oferecer uma melhor caracterı́stica de segurança; no entanto, impõem
um fardo a mais para as aplicações, e pode limitar a interoperabilidade. Muitas aplicações
constroem um caminho de certificação, e então validam o caminho de certificação (seção
6). A validação da LCR, por sua vez, requer um caminho de certificação separado, a ser
construı́do e validado para a validação do certificado de assinatura da LCR usado pela AC.
As aplicações que executam validação de LCR DEVEM suportar validação de caminho de
certificação quando os certificados e LCRs são assinados digitalmente pela mesma chave
privada. Estas aplicações também DEVERIAM suportar validação de caminho de certificação quando forem utilizadas chaves privadas distintas para assinatura de certificados e
LCRs.
5.1.2
Certificate List “A Ser Assinado”
O campo certificate list a ser assinado, ou TBSCertList, é uma sequência de campos obrigatórios e opcionais. Os campos obrigatórios identificam o emissor da LCR, o algoritmo
Cooper, et al.
Standards Track
50
RFC 5280
Maio de 2008
utilizado para assinar a LCR, e a data e o tempo da emissão da LCR.
Campos adicionais incluem a data e o tempo no qual o emissor da CLR emitirá a próxima
LCR, a lista de certificados revogados, e extensões da LCR. A lista de certificados revogados
é opcional, para suportar o caso no qual a AC não possui nenhum certificado, por ela
emitido, revogado dentro do perı́odo de validade. Este perfil requer que os emissores de
LCR em conformidade incluam o campo nextUpdate e o número da LCR, e a extensão
authority key identifier em todas as LCRs emitidas.
Version
es
5.1.2.1
Este campo opcional descreve a versão da LCR codificada. Quando as extensões forem usadas, como obrigatório para este perfil, este campo DEVE estar presente e DEVE especificar
a versão 2 (o valor inteiro utilizado é 1).
5.1.2.2
Signature
nd
Este campo contém o identificador do algoritmo para o algoritmo utilizado para assinar a
LCR. [RFC3279], [RFC4055], e [RFC4491] lista os OIDs para os algoritmos de assinatura
mais comuns usados na ICP Internet.
Este campo DEVE conter o mesmo identificador de algoritmo que o campo signatureAlgorithm na sequência CertificateList (seção 5.1.1.2).
5.1.2.3
Issuer Name
This Update
Er
5.1.2.4
na
O campo issuer name identifica a entidade que assinou e emitiu a LCR. A identidade
do emissor é informada no campo issuer. Formas alternativas de nome também podem
aparecer na extensão issuerAltName (seção 5.2.2). O campo issuer DEVE conter um nome
distinto (DN) X.500 não vazio. O campo issuer é definido como um tipo Name do X.501,
e DEVE seguir as regras de codificação para o campo issuer name do certificado (seção
4.1.2.4).
Este campo indica a data de emissão da LCR. thisUpdate pode ser codificado como UTCTime ou GeneralizedTime.
Emissores de LCR em conformidade com este perfil DEVEM codificar thisUpdate como
UTCTime para datas até o ano 2049. Emissores de LCR em conformidade com este perfil
DEVEM codificar thisUpdate como GeneralizedTime para datas no ano 2050 para frente.
Aplicações em conformidade DEVEM ser capazes de processar datas que estejam codificadas tanto em UTCTime como em GeneralizedTime.
Quando codificada como UTCTime, thisUpdate DEVE ser especificada e interpretada como
definido na seção 4.1.2.5.1. Quando codificadas como GenerelizedTime, thisUpdate DEVE
ser especificada e interpretada como definido na seção 4.1.2.5.2.
5.1.2.5
Next Update
Cooper, et al.
Standards Track
51
RFC 5280
Maio de 2008
Este campo indica a data na qual a próxima LCR será emitida. A próxima LCR pode ser
emitida antes da data indicada. Emissores de LCR DEVERIAM emitir LCRs com o tempo
nextUpdate iqual ou maior que todas as LCRs enteriores. nextUpdate pode ser codificado
como UTCTime ou GeneralizedTime.
Os emissores de LCR em conformidade DEVEM incluir o campo nextUpdate em todas
as 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 clientes que processam LCRs que omitem o campo nextUpdate não é especificado neste perfil.
es
Emissores de LCR em conformidade com este perfil DEVEM codificar nextUpdate como
UTCTime para datas até o ano de 2049. Emissores de LCR em conformidade com este
perfil DEVEM codificar nextUpdate como GeneralizedTime para datas no ano 2050 e posteriores. Aplicações em conformidade DEVEM ser capazes de processar datas que estejam
codificadas tanto em UTCTime quanto em GeneralizedTime.
5.1.2.6
Revoked Certificates
nd
Quando codificadas como UTCTime, nextUpdate DEVE ser especificado e interpretado
como definido na seção 4.1.2.5.1. Quando codificada como GeneralizedTime, nextUpdate
DEVE ser especificado e interpretado como definido na seção 4.1.2.5.2.
5.1.2.7
Extensões
na
Quando não existirem certificados revogados, a lista de certificados revogados DEVE estar
ausente. De outra forma, os certificados revogados são listados pelos seus números seriais.
Certificados revogados pela AC são identificados unicamente pelo número serial do certificado. A data na qual a revogação ocorreu é especificada. O tempo para revocationDate
DEVE ser expresso conforme descrito na seção 5.1.2.4. Informação adicional pode ser fornecida nas extensões das entradas da LCR; extensões de entrada da LCR serão discutidas
na seção 5.3.
5.2
Er
Este campo apenas ocorre se a versão for 2 (seção 5.1.2.1). Se presente, este campo é uma
sequência de um ou mais extensões de LCR. As extensões de LCR são serão discutidas na
seção 5.2.
Extensões da LCR
As extensões para LCRs X.509 v2 definidas nos padrões ANSI X.9, ISO/IEC e ITU-T
[X.509] [X9.55] fornecem métodos para associação de atributos adicionais às LCRs. O formato X.509 para LCR também permite que comunidades definam extensões privadas para
transferir informações particulares àquelas comunidades. Cada extensão da LCR pode ser
designada como crı́tica ou não-crı́tica. Se um LCR tiver uma extensão crı́tica que a aplicação não possa processar, então a aplicação NÃO DEVE usar a LCR para determinar o
estado de revogação dos certificados. Entretanto, as aplicações podem ignorar as extensões
não-crı́ticas. As subseções seguintes apresentam aquelas extensões usadas com LCRs Internet. As comunidades podem decidir incluir extensões na LCR que não estão definidas nesta
especificação. No entanto, devem ter cuidado na adoção de quaisquer extensões crı́tica nas
LCRs que podem ser utilizadas em contexto geral.
Cooper, et al.
Standards Track
52
RFC 5280
Maio de 2008
Os emissores de LCR em conformidade NECESSITAM incluir a extensões authority Key
Identifier (seção 5.2.1) e CRL number (seção 5.2.3) em todas as LCRs emitidas.
5.2.1
Authority Key Identifier
es
A extensão authority key identifier fornece um meio para identificar a chave pública correspondente a chave privada usada para assinar a LCR. A identificação pode ser baseada tanto
no identificador da chave (campo subject key identifier do certificado usado para assinar a
LCR) ou no campo issuer name e serial number. Esta extensão é especialmente útil quando
um emissor tem mais de uma chave para assinatura, por questões de múltiplos pares de
chaves concorrentes ou devido a troca de chave.
Emissores de LCR em conformidade DEVEM usar o método key identifier, e DEVEM incluir esta extensão em todas as LCRs emitidas.
A sintaxe para esta extensão da LCR é definida na seção 4.2.1.1.
Issuer Alternative Name
nd
5.2.2
53
A extensão issuer alternative name permite que identidades adicionais sejam associadas ao
emissor da LCR. Opções definidas incluem endereço de e-mail (ref822Name), nome DNS,
endereço IP, e URI. Múltiplas instâncias de uma forma de nome e múltiplas formas de
nome podem ser incluı́das. Sempre que tais identidades forem utilizadas, a extensão issuer
alternative name DEVE ser utilizada; no entanto, um nome DNS PODE ser representado
no campo issuer usando o atributo domainComponent conforme descrito na seção 4.1.2.4.
na
Emissores de LCR em conformidade DEVERIAM marcar a extensão issuerAltName como
não-crı́tica.
O OID e a sintaxe para este extensão de LCR estão definidos na seção 4.2.1.7.
5.2.3
CRL Number
Er
A extensão CRL number é uma extensão não-crı́tica que contém uma sequência monotonicamente crescente de números para um dado escopo de LCR e emissor de LCR. Esta
extensão permite que os usuários facilmente determinem quando uma LCR em particular sucede uma outra LCR. Números de LCR também suportam identificação para LCRs
complementares inteiras e para LCRs delta. Emissores de LCR em conformidade com este
perfil DEVEM incluir esta extensão em todas as LCRs e DEVEM marcá-la como não-crı́tica.
Se um emissor de LCR gerar LCRs delta em complemento a LCRs completas para um
dado escopo, as LCRs completas e as LCRs delta devem compartilhar uma única sequência
numérica. Se uma LCR delta e uma LCR completa que cobrem o mesmo escopo forem
emitidas no mesmo tempo, elas DEVEM possuir o mesmo número de LCR e fornecerem a
mesma informação de revogação. Ou seja, a combinação da LCR delta e uma LCR completa aceitável DEVE fornecer a mesma informação sobre revogação que a LCR completa
simultaneamente emitida.
Se o emissor de LCR gera duas LCRs (duas LCRs completas, duas LCRs delta, ou uma
LCR completa e uma delta) para o mesmo escopo em momentos diferentes do tempo, as
Cooper, et al.
Standards Track
RFC 5280
Maio de 2008
duas LCRs NÃO DEVEM possuir o mesmo número de LCR. Isto é, se o campo this update (seção 5.1.2.4) nas duas LCRs não forem idênticos, os números das LCRs DEVEM ser
diferentes.
Considerando os requisitos acima, números de LCR podem aguardados como inteiros longos. Os verificadores de LCR DEVEM ser capazes de processar valores contidos no CRLNumber de até 20 octetos. Emissores de LCR em conformidade NÃO DEVEM usar valores
maiores que 20 octetos para CRLNumber.
CRLNumber
5.2.4
es
id-ce-cRLNumber
Delta CRL Indicator
nd
A extensão delta CRL indicator é crı́tica e identifica que uma LCR é delta. As LCRs delta
contêm atualizações de informação de revogação previamente distribuı́das, ao invés de conter todas as informações constantes de uma LCR completa. O uso de LCRs delta pode
significativamente reduzir o carregamento da rede e o tempo de processamento em determinados ambientes. LCRs delta são geralmente menores que as LCRs que elas atualizam,
assim, as aplicações que obtêm LCRs delta consomem menos banda da rede que aplicações
que obtêm as LCRs completas correspondentes. Aplicações que armazenam informação de
revogação em formato diferente da estrutura da LCR podem adicionar nova informação de
revogação à base de dados local sem a necessidade de reprocessar toda informação.
na
A extensão delta CRL indicator contém um valor único do tipo BaseCRLNumber. O CRL
number identifica a LCR, completa para um dado escopo, que foi utilizada como ponto de
referência para a geração da presente LCR delta. Um emissor de LCR em conformidade
DEVE publicar a LCR base referenciada como uma LCR completa. A LCR delta contém
todas as atualizações de estado de revogação para um mesmo escopo. A combinação de
uma LCR delta mais a LCR base referenciada é equivalente a uma LCR completa, para o
escopo considerado, no tempo da publicação da LCR delta.
Er
Quando um emissor de LCR gera uma LCR delta, a LCR delta DEVE incluir a extensão
crı́tica delta CRL indicator.
Quando uma LCR delta é emitida, ela DEVE cobrir o mesmo conjunto de razões e o mesmo
conjunto de certificados que foram cobertos pela LCR base que ela referencia. Isto é, o escopo da LCR delta DEVE ser o mesmo escopo da LCR completa referenciada como LCR
base. A LCR base referenciada e a LCR delta DEVEM omitir a extensão issuing ditribution
point ou conter extensões issuing distribution point iguais. Além disso, o emissor de LCR
DEVE usar a mesma chave privada para assinar a LCR delta e qualquer LCR completa
que a LCR delta atualiza.
A aplicação que suporta LCRs delta pode construir uma LCR completa para um dado
escopo, combinando a LCR delta para aquele escopo com, tanto uma LCR emitida para
aquele escopo que seja completa ou uma LCR localmente construı́da que seja completa
para aquele escopo.
Cooper, et al.
Standards Track
54
RFC 5280
Maio de 2008
Quando um LCR delta é combinada com uma LCR completa ou uma LCR localmente
construı́da, a LCR resultante, localmente construı́da, tem como CRL number aquele especificado na extensão CRL number encontrada na LCR delta, utilizada para a sua construção. Adicionalmente, a LCR resultante, localmente construı́da, tem os tempos thisUpdate
e nextUpdate especificados nos campos correspondentes da LCR delta utilizada na sua
construção. Além disso, a LCR localmente construı́da herda os calores contidos em issuing
distribution point da LCR delta.
es
Uma LCR completa e uma LCR delta PODEM ser combinadas quando as quatro condições
à 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 possuem
o mesmo escopo se ocorrer uma das seguintes condições:
nd
(1) A extensão issuingDistributionPoint é omitida tanto na LCR completa
quanto na LCR delta.
(2) A extensão issuingDistributionPoint estiver presente tanto na LCR completa quanto na LCR delta, e o valor desses campos for o mesmo nas duas
LCRs.
(c) O CRL number da LCR completa é iqual ou maior que o BaseCRLNumber especificado na LCR delta. Isto é, a LCR completa contém (no mı́nimo) toda a
informação de revogação tratada pela LCR base referenciada.
na
(d) O CRL number da LCR completa é menor que o número da LCR delta. Isto é, a
LCR delta seque a LCR completa na sequência de numeração.
Os emissores de LCR DEVEM garantir que a combinação de uma LCR delta e qualquer
LCR completa apropriada refletirá exatamente a estado de revogação atual. O emissor de
LCR DEVE incluir uma entrada na LCR delta para cada certificado dentro do escopo da
LCR delta cujo estado tiver mudado desde a geração da LCR base referenciada:
Er
(a) Se o certificado está revogado por uma razão incluı́da no escopo da LCR, listar o
certificado como revogado.
(b) Se o certificado estiver válido e estiver listado na LCR base referenciada ou qualquer LCR subsequente, com o código razão certificateHold, e o código da razão
certificateHold estiver incluı́do no escopo da LCR, listar o certificado com o código
razão removeFromLCR.
(c) Se o certificado estiver revogado por uma razão externa ao escopo da LCR, mas o
certificado for listado na LCR base referenciada ou qualquer LCR subsequente com
o código razão incluso no escopo desta LCR, listar o certificado como revogado,
mas omitir o código razão.
(d) Se o certificado estiver revogado por uma razão externa ao escopo da LCR e o certificado nao se encontrar listado na LCR base referenciada, nem em qualquer LCR
subsequente com a razão existente no escopo desta LCR, não listar o certificado
nesta LCR.
Cooper, et al.
Standards Track
55
RFC 5280
Maio de 2008
O estado de um certificado é considerado modificado se ele estiver revogado (por qualquer
razão, incluindo certificateHold), se ele estiver liberado da suspensão, ou se as razões de
sua revogação mudarem.
É apropriado listar um certificado com código razão removeFromCRL na LCR delta mesmo
se o certificado não estiver suspenso na LCR base referenciada. Se o certificado foi colocado
em suspensão em qualquer LCR emitida após a LCR base, mas antes desta LCR delta e
então liberado da suspensão, ele DEVE ser listado na LCR delta com código de revogação
removeFromCRL.
es
O emissor de LCR DEVE opcionalmente listar um certificado na LCR delta com código
razão removeFromCRL se o tempo notAfter especificado no certificado preceder o tempo
thisUpdate especificado na LCR delta e o certificado for listado na LCR base referenciada
ou em qualquer LCR emitida após a base, mas antes desta LCR delta.
nd
Se um aviso de revogação de certificado aparecer primeiro na LCR delta, então é possı́vel
que o perı́odo de validade do certificado expire antes da próxima LCR completa, para o
mesmo escopo, ser emitida. Neste caso, o aviso de revogação é incluı́do em, no mı́nimo,
uma LCR completa emitida explicitamente para este escopo.
56
na
Uma aplicação que suporte LCR delta DEVE ser capaz de construir uma LCR completa
atualizada, combinando a LCR completa emitida previamente e a LCR delta mais atual.
Uma aplicação que suporte LCR delta PODE também ser capaz de construir uma LCR
completa atual pela combinação de uma LCR completa construı́da localmente e a LCR
delta atual. Uma LCR delta é considerada ser a atual se o tempo no momento estiver entre
os tempos contidos nos campos thisUpdate e nextUpdate. Sob certas circunstâncias, o
emissor de LCR pode publicar uma ou mais LCRs delta antes do tempo indicado no campo
nextUpdate. Se mais de uma LCR delta atual para um mesmo escopo for encontrada, a
aplicação DEVERIA considerar aquela com o último valor em thisUpdate como sendo a
mais atualizada.
id-ce-deltaCRLIndicator OBJECT IDENTIFIER ::= { id-ce 27 }
5.2.5
::= CRLNumber
Er
BaseCRLNumber
Issuing Distribution Points
A issuing distribution point é uma extensão crı́tica de LCR que identifica os pontos de
distribuição da LCR e o escopo para uma LCR especı́fica, e indica se se a LCR cobre revogação apenas para certificados de entidade final, apenas para certificados de AS, apenas
certificados de atributo, ou um conjunto limitado de códigos razão. Embora a extensão
seja crı́tica, implementações em conformidade não são obrigadas a suportar esta extensão.
Entretanto, as implementações que não suportarem esta extensão DEVEM tanto tratar o
estado de revogação de qualquer certificado não listado nesta LCR como desconhecido ou
localizar uma outra LCR que não contenha qualquer extensão crı́tica não reconhecida.
A LCR é assinada usando a chave privada do emissor da LCR. Os pontos de distribuição de
LCR não possuem seus próprios pares de chave. Se a LCR for armazenada em um diretório
X.500, ela é gravada em uma entrada do diretório correspondendo ao ponto de distribuição
da LCR, que pode ser diferente da entrada de diretório do emissor da LCR.
Cooper, et al.
Standards Track
RFC 5280
Maio de 2008
Os códigos razão associados com um ponto de distribuição DEVE ser especificado em onlySomeReasons. Se onlySomeReasons não aparece, o ponto de distribuição DEVE conter
revogações para todos os códigos razão. ACs podem usar os pontos de distribuição para
particionar a LCR com base nos compromissos e rotinas de revogação. Neste caso, as revogações com códigos razão keyCompromise (1), cACompromise (2), e aACompromise (8)
aparecem em um ponto de distribuição, e as revogações com outros códigos razão aparecem
em outro ponto de distribuição.
es
Se uma LCR incluir uma extensão issuingDistributionPoint com onlySomeReasons presente, então todo certificado no escopo da LCR que estiver revogado DEVE ter uma razão
de revogação associada, diferente de não especificado. A razão de revogação associada é
usada para determinar em qual LCR(s) listar o certificado revogado, embora, não exista
requisito para incluir a extensão de entrada na LCR reasonCode na entrada LCR correspondente.
nd
A sintaxe e a semântica para o campo distributionPoint são as mesmas utilizadas para o
campo distributionPoint na extensão cRLDistributionPoints (seção 4.2.1.13). Se o campo
distributionPoint estiver presente, então ele DEVE incluir no mı́nimo um dos nomes para
o campo distributionPoint correspondente a extensão cRLDistributionPoints de todo certificado que esteja dentro do escopo desta LCR. Uma codificação idêntica DEVE ser usada
nos campos distributionPoint do certificado e da LCR.
na
Se o escopo da LCR incluir apenas certificados emitidos pelo emissor da LCR, então ao
campo booleano de indirectCRL, DEVE ser atribuı́do o valor FALSE. De outra forma, se
o escopo da LCR incluir certificados emitidos por uma ou mais autoridades distintas do
emissor da LCR, ao campo booleano indirectCRL deve ser atribuı́do o valor TRUE. a autoridade responsável por cada entrada é indicada pelo emissor do certificado na entrada da
extensão na LCR (seção 5.3.3).
Er
Se o escopo da LCR incluir apenas certificados de chave pública de entidade final, então,
onlyContainsUserCerts DEVE ter o valor TRUE. Se o escopo da LCR incluir apenas certificados de AC, então deve ser atribuı́do o valor TRUE ao campo onlyContaisCACerts. Se
tanto onlyContainsUserCerts ou onlyContainsCACerts tiverem o valor TRUE, então o escopo da LCR NÃO DEVE incluir qualquer certificado com versão 1 ou versão 2. Emissores
de LCR em conformidade DEVEM atribuir o valor FALSE ao campo onlyContainsAttributeCerts.
Emissores de LCR em conformidade NÃO DEVEM emitir LCRs onde a codificação DER
da extensão issuing distribution point é uma sequência vazia. Ou seja, se onlyContainsUserCerts, onlyContainsCACerts indirectCRL, e onlyContainsAttributeCerts tiverem todos
o valor FALSE, então ou o campo distributionPoint ou onlySomeReasons DEVE estar
presente.
id-ce-issuingDistributionPoint OBJECT IDENTIFIER ::= { id-ce 28 }
IssuingDistributionPoint ::= SEQUENCE {
distributionPoint
onlyContainsUserCerts
[1] BOOLEAN DEFAULT FALSE,
onlyContainsCACerts
onlySomeReasons
Cooper, et al.
Standards Track
57
RFC 5280
indirectCRL
onlyContainsAttributeCerts
Maio de 2008
[5] BOOLEAN DEFAULT FALSE }
-- at most one of onlyContainsUserCerts, onlyContainsCACerts,
-- and onlyContainsAttributeCerts may be set to TRUE.
5.2.6
Freshest CRL (Ponto de Distribuição de LCR delta)
es
A extensão freshest CRL identifica como a informação da LCR delta para a LCR completa
é obtida. Emissores de LCR em conformidade DEVEM marcar esta extensão como nãocrı́tica. Esta extensão NÃO DEVE aparecer em LCRs delta.
A mesma sintaxe utilizada para a extensão de certificado cRLDistributionPoints é utilizada
nesta extensão, e está descrita na seção 4.2.1.13. Embora, apenas o campo distribution
point é significativo neste contexto. Os campos reasons e cRLIssuer DEVEM ser omitidos
nesta extensão de LCR.
nd
Cada nome de ponto de distribuição fornece a localização na qual a LCR delta para a LCR
completa pode ser encontrada. O escopo dessas LCRs delta DEVE ser o mesmo escopo da
LCR completa. Os conteúdos desta extensão de LCR são usados apenas para localização
de LCRs delta, os conteúdos não são usados para validar a LCR ou para referenciar LCRs
delta. As convenções de codificação definidas para distribution points na seção 4.2.1.13
também se aplicam a esta extensão.
FreshestCRL
5.2.7
na
id-ce-freshestCRL OBJECT IDENTIFIER ::= { id-ce 46 }
Authority Informatioin Access
Er
Esta seção define o uso da extensão Authority Information Access na LCR. A sintaxe e a
semântica definidas na seção 4.2.2.1 para a extensão em certificado também são utilizadas
para esta extensão na LCR.
Esta extensão de LCR DEVE ser marcada como não-crı́tica.
Quando presente em um LCR, esta extensão DEVE incluir no mı́nimo um AccessDescription especificando id-ad-caIssuers como o accessMethod. O OID id-ad-caIssuers é usado
quando a informação disponı́vel lista certificados que podem ser utilizados para verificar a
assinatura na LCR (ex: certificados cujo nome do sujeito correspondem ao nome do emissor na LCR e que um chave pública do sujeito correspondente a chave privada utilizada
para assinar a LCR). Tipos de método de acesso diferente de id-ad-caIssuers NÃO DEVEM
ser incluı́dos. No mı́nimo uma instância de AccessDescription DEVERIA especificar um
accessLocation para URI HTTP [RFC2616] ou LDAP [RFC4516].
Quando a informação estiver disponı́vel via HTTP ou FTP, o accessLocation DEVE ser
um uniformResourceIdentifier e a URI DEVE apontar para um único certificado codificado
em DER como especificado em [RFC2585] ou uma coleção de certificados codificados em
BER ou DER de uma mensagem CMS “certs-only” como especificado em [RFC2797].
Cooper, et al.
Standards Track
58
RFC 5280
Maio de 2008
Aplicações em conformidade que suportam HTTP ou FTP para acessar certificados DEVEM ser capazes de aceitar certificados individuais codificados em DER e DEVERIAM ser
es
Implementações de servidor HTTP acessados via URI DEVERIAM especificar o tipo de
meio application/pki-cert [RFC2585] no campo content-type do cabeçalho de mensagens
de resposta para um único certificado codificado em DER e DEVERIA especificar o tipo
de meio application/pkcs7-mime [RFC2797] no campo content-type do cabeçalho da mensagens de resposta CMS “certs-only”. Pra FTP, o nome do arquivo que contém um único
certificado codificado em DER DEVERIA ter o sufixo “.cer” [RFC2585] e o nome de um
arquivo que contenha o sufixo “.p7c” para arquivos que contenham mensagem CMS “certsonly” [RFC2797]. Cliente consumidores podem usar o tipo meio ou extensão de arquivo
como um indicador para o conteúdo, mas não deveriam depender somente da presença de
um tipo de meio correto ou extensão de arquivo constante na resposta do servidor.
na
nd
Quando o accessLocation é um directoryName, a informação pode ser obtida pela aplicação à partir de qualquer servidor de diretório, é uma configuração local. Quando uma
chave pública de AC é usada para validar assinaturas em certificados e LCRs, o respectivo
certificado de AC é guardado nos atributos crossCertificatePair e/ou cACerttificate como
especificado em [RFC4523]. Quando chaves públicas distintas forem utilizadas para validar
assinaturas em certificados e LCRs, o respectivo certificado é guardado no atributo userCertificate como especificado em [RFC4523]. Assim, implementações que suportem a forma
directoryName de accessLocation DEVEM ser preparadas para encontrar o certificado necessário em algum desses três atributos. O protocolo que a aplicação usa para acessar o
diretório (ex: DAP ou LDAP) é definido localmente.
5.3
Er
Quando a informação estiver disponı́vel através de LDAP, o accessLocation DEVERIA
ser um uniformResourceIdentifier. A URI LDAP [RFC4516] DEVE incluir um campo
<dn> contendo o nome distinto da entrada que contém o certificado, DEVE incluir um
campo <attributes> que lista descritores apropriados de atributo para os atributos que
contém 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 em
qualquer conhecimento prévio que o cliente possa ter para contactar o servidor apropriado.
Extensões da Entrada da LCR
As extensões das entradas da LCR definidas para LCRs X.509 v2 pela ISO/IEC, ITU-T e
ANSI-X9 fornece métodos para associação de atributos adicionais com as entradas da LCR
[X.509] [X9.55]. O formato da LCR X.509 v2 também permite que comunidades especı́ficas
definam extensõ0es privadas para entradas da LCR para transmitir informações relevantes
àquelas comunidades. Cada extensão na entrada da LCR pode designada como crı́tica ou
não-crı́tica. Se uma LCR tiver uma extensão de entrada da LCR crı́tica que a aplicação não
possa processar, então a aplicação NÃO DEVE usar esta LCR para determinar o estado de
revogação de qualquer certificado. Entretanto, as aplicações podem ignorar extensões das
entradas de LCR marcadas como não-crı́ticas.
As subseções seguintes apresentam as extensões recomendadas para serem utilizadas nas entradas de LCR Internet e os locais padrão para informação. Comunidades especı́ficas podem
Cooper, et al.
Standards Track
59
RFC 5280
Maio de 2008
usar extensões das entradas da LCR adicionais; entretanto, isso deve ser feito com muito
cuidado quando se tratar de extensões crı́ticas que podem ser usadas em um contexto geral.
O suporte as extensões das entradas da LCR definidas nesta especificação é opcional para
emissores de LCR e aplicações em conformidade. No entanto, os emissores de LCR DEVERIAM incluir códigos razão (reason code) (seção 5.3.1) e datas de invelidez (seção 5.3.2)
sempre que esta informação estiver disponı́vel.
Reason Code
es
5.3.1
A extensão reasonCode é uma extensão não-crı́tica para entrada da LCR que identifica a
razão para a revogação do certificado. Os emissores de LCR são incentivados a incluı́rem
códigos razão significativos na entradas da LCR; no entanto, o código razão da extensão
da entrada da LCR DEVERIA estar ausente ao invés do uso do valor unspecified (0) para
reasonCode.
nd
O valor de reasonCode igual a removeFromCRL (8) apenas pode ocorrer em LCRs delta e
indica que um certificado esta para ser removido da LCR devido ou a expiração do certificado ou que não está mais suspenso. Todos os outros códigos razão podem aparecer em
qualquer LCR e indica que o certificado especificado deveria ser considerado revogado.
id-ce-cRLReasons
60
na
-- reasonCode ::= { CRLReason }
5.3.2
Er
CRLReason
::= ENUMERATED {
unspecified
(0),
keyCompromise
(1),
cACompromise
(2),
affiliationChanged
(3),
superseded
(4),
(5),
certificateHold
(6),
-- value 7 is not used
removeFromCRL
(8),
privilegeWithdrawn
(9),
aACompromise
(10) }
Invalidity Date
A extensão invalidity date, da entrada da CLR, é uma extensão não-crı́tica que fornece
a data na qual a chave privada foi considerada comprometida ou considerada suspeita de
estar comprometida, ou caso contrário, que ele se tornou inválida. Esta é a data pode ser
anterior à data de revogação na entrada da LCR, que é a data na qual a AC processou a
revogação. Quando uma revogação é publicada primeiro pelo emissor de LCR, na LCR, a
data de invalidez do certificado pode preceder a data da emissão das LCRs mais recentes,
mas a data de revogação NÃO DEVERIA preceder a data da emissão das últimas LCRs.
Sempre que esta informação estiver disponı́vel, é fortemente sugerido aos emissores de LCR
Cooper, et al.
Standards Track
RFC 5280
Maio de 2008
que compartilhem a informação com os usuários de LCR.
Os valores GeneralizedTime incluı́dos neste campo DEVEM ser expressos em Greenwich
Mean Time (Zulu), e DEVEM ser especificado e interpretados como definido na seção
4.1.2.5.2.
id-ce-invalidityDate OBJECT IDENTIFIER ::= { id-ce 24 }
InvalidityDate
Certificate Issuer
es
5.3.3
::= GeneralizedTime
nd
Esta extensão de entrada da LCR identifica o emissor do certificado associado com a entrada
em uma LCR indireta, ou seja, a LCR que tem o indicador indirectCRL ativado na extensão
issuing distribution point. Quando presente, a extensão da entrada certificate issuer da LCR
inclui um ou mais nomes da extensão issuer e/ou issuer alternative name do certificado que
corresponde a entrada LCR. Se esta extensão não estiver presente na primeira entrada
de uma entrada LCR, o emissor padrão para certificate issuer é o emissor da LCR. Nas
entradas subsequentes da LCR indireta, se esta extensão não estiver presente, o emissor do
certificado para a entrada, é o mesmo da entrada precedente. Este campo é definido da
seguinte forma:
id-ce-certificateIssuer OBJECT IDENTIFIER ::= { id-ce 29 }
CertificateIssuer
::= GeneralNames
na
Emissores de LCR em conformidade DEVEM incluir nesta extensão o nome distinto (DN)
do campo issuer do certificado correspondente a esta entrada da LCR. A codificação do DN
DEVE ser igual àquela usada no certificado.
6
Er
Os emissores de LCR DEVEM marcar esta extensão como crı́tica desde que implementações que ignoram esta extensão poderiam não atribuir corretamente entradas da LCR
a certificados. Este especificação RECOMENDA que as implementações reconheçam esta
extensão.
Validação de Caminho de Certificação
Os procedimentos de validação de caminho para ICP Internet são baseados no algoritmo
fornecido em [X.509]. O processamento do caminho de certificação verifica a associação
entre o nome distinto ou nome alternativo do sujeito e a chave pública do sujeito. A associação é limitada pelas restrições especificadas nos certificados que compõem o caminho e
insumos especificados pela terceira parte confiável. As extensões basic constraints e policy
constraints permitem à lógica de processamento de caminho de certificação automatizar o
processo de tomada de decisão.
Esta seção descreve um algoritmo para validação de caminhos de certificação. Não é solicitado às implementações em conformidade desta especificação implementarem este algoritmo, mas DEVEM fornecer funcionalidade equivalente para o comportamento externo
resultante deste procedimento. Qualquer algoritmo pode ser usado por uma implementação
Cooper, et al.
Standards Track
61
RFC 5280
Maio de 2008
em particular, desde que derivem o resultado correto.
Na seção 6.1, o texto descreve a validação básica de caminho. Os caminhos básicos começam com certificados emitidos por uma âncora confiável. O algoritmo requer a chave
pública da AC, o nome da CA, e qualquer restrição sobre o conjunto de caminhos que
podem ser validados usando esta chave.
es
A seleção de uma âncora de confiança é uma questão de polı́tica: pode ser a AC que se
encontra no topo de uma ICP hierárquica, a AC que emitiu o(s) próprio(s) certificado(s),
ou qualquer AC em uma rede de ICP. O procedimento de validação de caminho é o mesmo
independente da escolha da âncora de confiança. Adicionalmente, aplicações diferentes podem confiar em diferentes âncoras de confiança, ou podem aceitar caminhos que comecem
com qualquer uma em um conjunto de âncoras de confiança.
A seção 6.2 descreve métodos para utilização do algoritmo de validação de caminho em
implementações especı́ficas.
6.1
nd
A seção 6.3 descreve os passos necessários para determinar se um certificado esta revogado
quando LCRs são o mecanismo de revogação usado pelo emissor do certificado.
Validação Básica de Caminho
na
Este texto descreve um algoritmo para o processamento de caminhos X.509. Um implementação em conformidade DEVE incluir um procedimento de processamento de caminho
que seja funcionalmente equivalente ao comportamento externo deste algoritmo. No entanto, o suporte para algumas extensões processadas por este algoritmo seja OPCIONAL
para implementações em conformidade. Os clientes que não suportarem essas extensões
PODEM omitir os passos correspondentes no algoritmo de validação de caminho.
Er
Por exemplo, não é requerido que os clientes suportem a extensão policy mappings. Os
clientes que não tiverem suporte a esta extensão PODEM omitir os passos da validação
de caminho nos quais esta extensão é processada. Note que os clientes DEVEM rejeitar o
certificado se ele tiver uma extensão crı́tica não suportada.
Enquanto o perfil para certificado e LCR especificados nas seções 4 e 5 deste documento
especificam valores para campos de certificados e LCRs e para extensões que são consideradas apropriadas para ICP Internet, o algoritmo apresentado nesta seção não é limitado
está limitado a aceitação de certificados e LCRs que estão em conformidade com este perfil.
Portanto, o algoritmo apenas inclui a checagem para verificação da validade do caminho
de certificação de acordo com o X.509 e não inclui checagem para verificação da conformidade dos certificados e LCRs com o perfil. Embora o algoritmo pudesse ser estendido
para incluir checagem de conformidade com os perfis definidos nas seções 4 e 5, este perfil
RECOMENDA que não sejam incluı́dos tais verificações.
O algoritmo apresentado nesta seção valida o certificado no que diz respeito a data e hora
atual. Uma implementação em conformidade PODE também suportar validação com respeito a algum momento no passado. Note que os mecanismos não são disponibilizados para
a validação de um certificado no que diz respeito ao tempo fora do perı́odo de validade do
certificado.
Cooper, et al.
Standards Track
62
RFC 5280
Maio de 2008
A âncora de confiança é uma entrada para o algoritmo. Não há requisito para que a mesma
âncora de confiança seja utilizada para validar todos os caminhos de certificação. Âncoras
de confiança distintas PODEM ser utilizadas para validar diferentes caminhos, como discutido adiante na seção 6.2.
es
A primeira meta da validação de caminho é verificar a associação entre o nome distinto de
um sujeito ou o seu nome alternativo e a chave pública do sujeito, como representado no
certificado alvo, baseado na chave pública de uma âncora de confiança. Na maioria dos
casos, o certificado alvo será um certificado de entidade final, mas o certificado alvo pode
ser um certificado de AC contanto que a chave pública ocorra para ser utilizada para um
propósito diferente da verificação de assinatura em um certificado de chave pública. A verificação da associação entre o nome e a chave pública do sujeito requer a obtenção de uma
sequência de certificados que dão suporte a esta associação. O procedimento executado
para obter esta sequência de certificados está fora do escopo desta especificação.
nd
Para satisfazer esta meta, o processo de validação de caminho verifica, entre outras coisas,
que um caminho de certificação prospectivo (uma sequência de n certificados) satisfaz às
seguintes condições:
(a) para todo x em {1, ..., n-1}, o sujeito do certificado x seja o emissor do certificado
x+1;
(b) o certificado 1 seja emitido pela âncora de confiança;
63
(c) o certificado n seja o certificado a ser validado (ex: o certificado alvo); e
na
(d) para todo x em {1, ..., n} o certificado era válido no tempo em questão.
Um certificado NÃO DEVE aparecer mais que uma vez em um caminho de certificação
prospectivo.
Er
Quando uma âncora de confiança for provida na forma de um certificado auto-assinado, este
certificado auto-assinado não é incluı́do como parte do caminho prospectivo de certificação.
Informação sobre âncoras de confiança são fornecidas como entrada para o algoritmo de
validação de caminho de certificação (seção 6.1.1).
Um caminho de certificação particular não deve, contudo, ser apropriado para todas as
aplicações. Portanto, uma aplicação PODE aumentar este algoritmo para um limite superior àquele estabelecido para o conjunto de caminhos válidos. O processo de validação do
caminho também determina o conjunto de polı́ticas de certificado que são válidas para este
caminho, baseado na extensão certificate policies, na extensão policy mappings, na extensão policy constraints e na extensão inhibit anyPolicy. Para alcançar isso, o algoritmo de
caminho de validação constrói uma árvore de polı́tica válida. Se o conjunto de polı́ticas de
certificado que são válidas para este caminho não estiver vazio, então o resultado será uma
árvore de polı́tica válida de profundidade n, de outra forma o resultado será uma árvore de
polı́tica válida nula.
Um certificado é auto-assinado se o mesmo DN aparecer tanto no campo subject como no
camo issuer (os dois DNs são os mesmos se eles corresponderem de acordo com as regras
especificadas na seção 7.1). Em geral, o emissor e o sujeito do certificado que formam o
caminho são diferentes para cada certificado. Embora, uma AC possa emitir um certificado
Cooper, et al.
Standards Track
RFC 5280
Maio de 2008
para ela mesma para suportar a atualização de chave ou modificação nas polı́ticas de certificado. Esses certificados auto-assinados não são contados na avaliação do comprimento
do caminho ou para restrições de nome.
Esta seção apresenta o algoritmo em quatro passos básicos: (1) inicialização, (2) processamento básico de certificado, (3) preparação para o próximo certificado, e (4) encerramento.
Os passos (1) e (4) são executados exatamente uma vez. O passo (2) é executado para
todos os certificados no caminho. O passo (3) é executado para todos os certificados no
caminho exceto para o certificado final. A figura 2 fornece um fluxograma deste algoritmo.
Er
na
nd
es
+--------+
| INÍCIO |
+--------+
|
V
+-----------------+
| Inicializaç~
ao |
+-----------------+
|
+<---------------------------+
|
|
V
|
+-------------------------+
|
| Processar Certificado |
|
+-------------------------+
|
|
|
V
|
+========================+
|
| SE Último Certificado |
|
|
no Caminho
|
|
+========================+
|
|
|
|
ENT~
AO |
| SEN~
AO
|
V
V
|
+--------------+ +---------------------+ |
| Encerramento | |
Preparar para
| |
+--------------+ | Próximo Certificado | |
|
+---------------------+ |
V
|
|
+------+
+-------------+
| PARE |
+------+
Figura 2: Fluxograma do Processamento do Caminho de Certificação
6.1.1
Entradas
Este algoritmo considera que as seguintes nove entradas são fornecidas para a lógica de
processamento do caminho:
Cooper, et al.
Standards Track
64
RFC 5280
Maio de 2008
(a) um caminho de certificação prospectivo de comprimento n.
(b) a data/tempo atual.
(c) user-initial-policy-set: um conjunto de identificadores de polı́tica de certificado que
dá nome as polı́ticas aceitáveis para o usuário do certificado. O user-initial-policyset contém o valor especial any-policy quando o usuário não faz referência a polı́tica
de certificado.
(1) o nome confiável do emissor,
es
(d) informação sobre a âncora de confiança, descrevendo uma AC que serve como
âncora de confiança para o caminho de certificação. A informação sobre a âncora
de confiança inclui:
(2) o algoritmo confiável de chave pública,
(3) a chave pública confiável, e
nd
(4) opcionalmente, os parâmetros confiáveis de chave pública associados à
chave pública.
na
A informação da âncora confiável pode ser fornecida ao procedimento de processamento do caminho na forma de um certificado auto-assinado. Quando a informação
da âncora de confiança for fornecida na forma de um certificado, o nome no campo
subject é usado como o nome confiável do emissor e o conteúdo do campo subjectPublicKeyInfo é usado como fonte para o algoritmo confiável de chave pública
e a chave pública confiável. A informação confiável da âncora é confiável porque
foi entregue ao procedimento de processamento por algum procedimento externo
confiável. Se o algoritmo de chave pública confiável requerer parâmetros, então os
parâmetros serão fornecidos juntamente com a chave pública confiável.
(e) initial-policy-mapping-inhibit, que indica se a o mapeamento de polı́tica é permitido no caminho de certificação.
(f) initial-explicit-policy, que indica se o caminho deve ser válido para no mı́nimo uma
das polı́ticas de certificado contidas em user-initial-policy-set.
Er
(g) initial-any-policy-inhibit, que indica se o OID anyPolicy deveria ser processado
quando incluı́do no certificado.
(h) initial-permitted-subtrees, que indica para cada tipo de nome (ex: nomes distintos
X.500, endereços de email, ou endereços IP) um conjunto de sub-árvores no qual
todos os nomes de sujeito em todos os certificados do caminho DEVEM corresponder. A entrada initial-permitted-subtree inclui um conjunto para cada tipo de
nome. Para cada tipo de nome, o conjunto pode consistir de uma única sub-árvore
que inclui todos os nome de um tipo name ou uma ou mais sub-árvores nas quais
especifica um sub-conjunto de nomes do tipo name, ou o conjunto pode ser vazio.
Se o o conjunto para um tipo name for vazio, então o caminho de certificação será
considerado inválido se qualquer certificado no caminho de certificação incluir um
nome daquel tipo name.
(i) initial-excluded-subtrees, que indica para cada tipo name (ex: nomes distintos
X.500, endereços de email, ou endereços IP) um conjunto de sub-árvores dentro do
Cooper, et al.
Standards Track
65
RFC 5280
Maio de 2008
qual cada nenhum nome de sujeito de qualquer certificado no caminho de certificação pode pertencer. A entrada initial-excluded-subtrees inclui um conjunto para
cada tipo nome. Para cada tipo nome, o conjunto pode ser vazio ou pode consistir
de uma ou mais sub-árvores onde, cada uma delas especifica um sub-conjunto de
nomes daquele tipo nome. Se o conjunto para o tipo nome for vazio, então nenhum
nome daquele tipo nome é excluı́do.
6.1.2
es
Não é demandado às implementações em conformidade suportarem o conjunto de todas
essas entradas. Por exemplo, uma implementação em conformidade pode ser designada
para validar todos os caminhos de certificação usando um valor FALSE para initial-anypolicy-inhibit.
Inicialização
A fase de inicialização estabelece onze estados variáveis baseados nas nove entradas:
nd
(a) valid policy tree: Uma árvore de polı́ticas de certificado com seus qualificadores
opcionais; cada uma das folhas da árvore representam uma polı́tica válida nesta
faze da validação do caminho de certificação. Se uma polı́tica válida existe nessa
fase da validação do caminho de certificação, a profundidade da árvore é igual
ao número de certificados na cadeia que está sendo processada. Se não existirem
polı́ticas válidas nesta fase da validação do caminho de certificação, a árvore é
definida como NULL (nula). Uma vez que a árvore seja definida como NULL, o
processamento de polı́tica é encerrado.
na
Cada nodo na valid policy tree inclui três objetos de dados: a polı́tica válida, um
conjunto de qualificadores associados à polı́tica, e um conjunto de um ou mais valores esperados para a polı́tica. Se o nodo possui a profundidade x, os componentes
do nodo têm a seguinte semântica:
(1) A valid policy é um OID único de polı́tica que representa uma polı́tica
válida para o caminho de comprimento x.
(2) O qualifier set é um conjunto de qualificadores de polı́tica associados com
a polı́tica válida do certificado x.
Er
(3) O expected policy set contém um ou mais OIDs de polı́tica que satisfaria
esta polı́tica no certificado x+1.
O valor inicial de valid policy tree é um nodo único com valid policy anypolicy,
um conjunto vazio de qualifier set, e um expected policy set com o valor anyPolicy
único. A profundidade deste nodo é considerada como zero.
A figura 3 é uma representação gráfica do estado inicial da valid policy tree. Figuras adicionais usarão este formato para descrever mudanças na valid policy tree
durante o processamento do caminho.
(b) permitted subtree: um conjunto de nomes raiz para cada tipo de nome (ex: nomes
distintos X.500, endereços de email, ou endereços IP) que definem um conjunto de
sub-árvores nas quais todos os nomes de sujeito nos certificados subsequentes no
caminho de certificação DEVEM ocorrer. Esta variável inclui um conjunto para
cada tipo de nome, e o valor inicial é initial-permitted-subtrees.
Cooper, et al.
Standards Track
66
RFC 5280
+--------------+
|
anyPolicy |
+--------------+
|
{}
|
+--------------+
| {anyPolicy} |
+--------------+
Maio de 2008
<------ valid_policy
<------ qualifier_set
<------ expected_policy_set
Figura 3: Valor Inicial da Variável de Estado valid policy tree
nd
es
(c) excluded subtrees: um inteiro que indica se é necessário uma valid policy tree nonNULL (não nula). O inteiro indica o número de certificados não-auto-assinados a
serem processados antes deste requisito ser imposto. Uma vez estabelecida, esta
variável pode ser decrementada, mas não pode ser incrementada. Ou seja, se um
certificado no caminho requer uma valid policy tree não nula, um certificado posterior não pode remover este requisito. Se a initial-explicit-policy estiver definida,
então o valor inicial é 0, de outra forma o valor inicial é n+1.
na
(d) inhibit anyPolicy: um inteiro que indica se o identificador de polı́tica anyPolicy
é considerado na correspondência. O inteiro indica o número de certificados nãoauto-assinados a serem processados antes do OID anyPolicy, se atribuı́do em um
certificado diferente de um certificado intermediário auto-assinado, é ignorado.
Uma vez definida, esta variável pode ser decrementada, mas não pode ser incrementada. Ou seja, se um certificado no caminho inibir o processamento de
anyPolicy, um certificado posterior não poderá permiti-lo. Se a initial-any-policyinhibit estiver definida, então o valor inicial é 0, de outra forma, o valor inicial é
n+1.
Er
(e) policy mapping: um inteiro que indica se o mapeamento de polı́tica é permitido.
O inteiro indica o número de certificados não-auto-assinados a serem processado
antes do mapeamento de polı́tica ser inibido. Um vez definida, esta variável pode
ser decrementada, mas não pode ser incrementada. Ou seja, se um certificado no
caminho especificar que o mapeamento de polı́tica não é permitido, esta definição
não poderá ser substituı́da por um certificado posterior da cadeia. Se a variável
initial-policy-mapping-inhibit for definida, então o valor inicial é 0, de outra forma
o valor inicial é n+1.
(f) working public key algorithm: é o algoritmo de assinatura digital utilizado para
verificar a assinatura do certificado. A variável working public key algorithm é
inicializada a partir do algoritmo de chave pública confiável fornecido na informação
da âncora de confiança.
(g) working public key: a chave pública usada para verificar a assinatura de um certificado. A variável working public key é inicializada com a chave pública confiável
fornecida na informação da âncora de confiança.
(h) working public key parameters: parâmetros associados à chave pública atual que
pode ser requerido para verificar uma assinatura (dependendo do algoritmo). A
variável working public key parameters é inicializada a partir dos parâmetros de
chave pública confiável fornecidos pela informação da âncora confiável.
Cooper, et al.
Standards Track
67
RFC 5280
Maio de 2008
(i) working issuer name: o nome distinto de emissor esperado no próximo certificado
da cadeia. A variável working issuer name é inicializada com o nome de emissor
confiável fornecido na informação da âncora confiável.
(j) max path length: este inteiro é inicializado com n, é decrementado para cada
certificado não-auto-assinado do caminho, e pode ser reduzido ao valor constante
do campo path length constraint da extensão basic constraints de um certificado
de AC.
6.1.3
es
Após a conclusão das etapas de inicialização, execute as etapas básicas de processamento
de certificados especificadas em 6.1.3.
Processamento Básico de Certificado
As ações de processamento básico de caminho a serem executadas para certificado i (para
todo i em [1..n]) são listadas abaixo:
nd
(a) Verificar a informação básica do certificado. O certificado DEVE satisfazer a cada
uma das seguintes condições:
(1) A assinatura no certificado pode ser verificada usando as variáveis working public key algorithm, working public key, e working public key parameters.
(2) O perı́odo da validade do certificado inclui a data atual.
na
(3) No tempo atual, o certificado não estar revogado. Isto pode ser determinado pela obtenção da LCR apropriada (seção 6.3), pela informação de
estado, ou por outro mecanismo externo.
(4) O nome do emissor do certificado é o working issuer name.
Er
(b) Se o certificado i é auto-emitido e ele não é certificado final no caminho, pule este
passo para o certificado i. De outra forma, verifique se o nome do sujeito não se encontra dentro de qualquer nome constante na variável excluded subtree para nomes
distintos X.500, e verifique que cada um dos nomes alternativos na extensão subjectAltName (crı́tica ou não-crı́tica) não esteja em qualquer dos excluded subtrees
para este tipo nome.
(c) Se a extensão certificate policies estiver presente no certificado e a variável valid policy tree não tiver o valor Null, processe a informação de polı́tica executando
os seguintes passos, na ordem a seguir:
(1) Para cada polı́tica P não igual a anyPolicy na extensão certificate policies, tenha P-OID denotando a polı́tica P e P-Q denotando o conjunto
qualificado para a polı́tica P. Execute os seguintes passos, na ordem de
apresenta ção:
(i) Para cada nodo de profundidade i-1 na valid policy tree onde POID está no expected policy set, crie um nodo filho da seguinte
forma: defina o valid policy para P-OID, defina o conjunto qualificado para P-Q e defina o expected policy set para {P-OID}.
Cooper, et al.
Standards Track
68
RFC 5280
Maio de 2008
Por exemplo, considere uma valid policy tree com um nodo de
profundidade i-1 onde expected policy set seja {Gold,White}. Considere que as polı́ticas de certificado Gold e Silver apareçam na
extensão certificate policies do certificado i. A polı́tica Gold corresponde, mas a polı́tica Silve não. Esta regra criará um nodo
filho, de profundidade i, para a polı́tica Gold. O resultado é mostrado na figura 4.
es
+---------------+
|
Red
|
+---------------+
|
{}
|
+---------------+
| {Gold, White} |
+---------------+
|
|
|
V
+---------------+
|
Gold
|
+---------------+
|
{}
|
+---------------+
|
{Gold}
|
+---------------+
nd
nodo de profundidade i-1
nodo de profundidade i
na
69
Figura 4: Processamento de uma Correspondência Exata
Er
(ii) Se não ocorreu nenhuma correspondência no passo (i) e a valid policy tree inclui um nodo de profundidade i-1 com a valid policy igual a anyPolicy, crie um nodo filho com os seguintes valores:
defina a variável valid policy para P-OID, o conjunto qualificado
para P-Q, e o expected policy set para {P-OID}.
Por exemplo, considere uma valid policy tree com um nodo de
profunidade i-1 onde o valor de valid policy seja anyPolicy. Considere que as polı́ticas de certificado Gold e Silver aparecem na
extensão certificate policies do certificado i. A polı́tica Gold não
tem um qualificador, mas a polı́tica Silver possui o qualificador
Q-Silver. Se Gold e Silver corresponderem em (i) acima, eta regra
criará dois nodos filhos de profundidade i, um para cada polı́tica.
O resultado é mostrado na figura 5.
(2) Se a extensão certificate policies incluir a polı́tica anyPolicy com o qualificador definido AP-Q e ou (a) inhibit anyPolicy é maior que 0 ou (b) i<n
e o certificado for auto-emitido, então:
Para cada nodo no valid policy tree de profundidade i-1, para cada valor
na expectec policy set (incluindo anyPolicy) que não apareça em um nodo
filho, crie um nodo filho com os seguintes valorres: defina valid policy com
Cooper, et al.
Standards Track
RFC 5280
Maio de 2008
nd
es
+---------------+
|
anyPolicy
|
+---------------+
|
{}
|
+---------------+ nodo de profundidade i-1
| {anyPolicy} |
+---------------+
/
\
/
\
/
\
/
\
+---------------+
+---------------+
|
Gold
|
|
Silver
|
+---------------+
+---------------+
|
{}
|
|
{Q-Silver} |
+---------------+ nodo de
+---------------+
|
{Gold}
| profundidade i |
{Silver}
|
+---------------+
+---------------+
Figura 5: Processamento Polı́ticas Não-Correspondentes Quado um Nodo Folha Especifica
anyPolicy
o valor de expected policy set no nodo pai, defina qualifier set para APQ, e defina expected policy set para o valor de valid policy para este nodo.
na
Por exemplo, considere uma valid policy tree com um nodo de profundidade i-1 onde expected policy ser é {Gold, Silver}. Considere que anyPolicy aparece na extensão certificate policies do certificado i sem qualificadores de polı́tica, mas Gold e Silver não aparecem. Esta regra criará
dois nodos filhos de profundidade i, um para cada polı́tica. O resultado é
mostrado abaixo, na figura 6.
Er
(3) Se existir um nodo na valid policy tree de profundidade i-1 ou menor se
qualquer nodo filho, apague este nodo. Repita este passo até que não
existe 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 estão marcados com um “X” não
têm filhos, e eles são apagados. Aplicando esta regra à árvore resultante
causará que os nodos na profundidade i-2 que estão marcados com “Y”
sejam apagados. Na árvore resultante, não ocorre nodos de profundidade
i-1 ou menor sem filhos, e este passo é finalizado.
(4) Se a extensão certificate policies não estiver presente, defina a variável
valid policy tree como NULL.
(5) verifique que ou explicit policy seja maior que o ou que valid policy tree
não seja igual a NULL.
Se qualquer dos passos (a), (b), (c), ou (f) falhar, o procedimento terminará, retornando um indicador de falha e uma razão apropriada.
Cooper, et al.
Standards Track
70
RFC 5280
Maio de 2008
nd
es
+----------------+
|
anyPolicy
|
+----------------+
|
{}
|
+----------------+ nodo de profundidade i-1
| {Gold, Silver} |
+----------------+
/
\
/
\
/
\
/
\
+---------------+
+---------------+
|
Gold
|
|
Silver
|
+---------------+
+---------------+
|
{}
|
|
{}
|
+---------------+ nodo de
+---------------+
|
{Gold}
| profundidade i |
{Silver}
|
+---------------+
+---------------+
Figura 6: Processamento Polı́ticas Não-Correspondentes Quando a Extensão Certificate
Policies Especifica anyPolicy
Se i não for igual a n, continue executando os passos preparatórios listados na seção
6.1.4. Se i for igual a n, execute o passo de encerramento listado na seção 6.1.5.
Er
na
+----------------+
|
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
Cooper, et al.
Standards Track
71
6.1.4
RFC 5280
Maio de 2008
Preparação para o Certificado i+1
Para preparar o processamento do certificado i+1, execute os seguintes passos para o certificado i:
(a) Se a extensão policy mappings estiver presente, verifique que o valor especial anyPolicy não apareça como um issuerDomainPolicy ou um subjectDomainPolicy.
(b) Se a extensão policy mappings estiver presente, então para cada issuerDomainPolicy ID-P na extensão policy mappings:
es
(1) Se a variável policy mapping for maior que 0, para cada nodo na valid policy tree de profundidade i onde ID-P é valid policy, defina expected policy set com o conjunto dos valores subjectDomainPolicy que sejam
especificados como equivalente ao ID-P pela extensão policy mappings.
nd
Se nehum nodo de profundidade i na valid policy tree tiver uma valid policy
de ID-P mas existir um nodo de profundidade i com uma valid policy com
valor anyPolicy, então crie um nodo filho de um nodo de profundidade i-1
que tenha o valid policy com valor anyPolicy seguindo:
na
(i) defina a valid policy para ID-P;
(ii) defina o qualifier set para o conjunto de qualificadores da polı́tica
anyPolicy na extensão polı́ticas de certificado i, e
(iii) defina a expect policy set com o conjunto de valores subjectDomainPoliciy que são especificados como equivalentes a ID-P pela
extensão policy-mappings.
(2) se a variável policy mapping for igual a 0:
72
Er
(i) apague cada nodo de profundidade i na valid policy tree onde IDP seja a valid policy.
(ii) Se existir um nodo na valid policy tree de profundidade i-1 ou
menor sem nenhum nodo filho, apague este nodo. Repita este
passo até que não existam nodos de profundidade i-1 ou menor
sem 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 com
parâmetros null ou os parâmetros forem omitidos, atribua os parâmetros à variável
working public key parameters.
Se o campo subjectPublicKeyInfo do certificado tiver um campo algorithm com
parâmetros null ou os parâmetros forem omitidos, compare o campo subjectPublicKey algorithm ao working public key algorithm. Se o campo subjectPublicKey
algorithm do certificado e o working public key algorithm forem diferentes, defina
working public key parameters como null.
(f) Atribua o algorithm subjectPublicKey do certificado à variável
working public key algorithm.
Cooper, et al.
Standards Track
RFC 5280
Maio de 2008
(g) Se a extensão 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 variável de
estado permitted subtrees a intersecção do seu valor prévio e o valor indicado no campo extensão. Se permittedSubtrees não incluir um tipo
nome particular, a variáveis de estado permitted subtrees não é modificada para este tipo de nome. Por exemplo, a intersecção de example.com
e foo.example é foo.example.com. E a intersecção de example.com e example.net é um conjunto vazio..
nd
es
(2) Se excludedSubtrees estiver presente no certificado, defina a variável de
estado excluded subtrees como a união do seu valor prévio e o valor indicado no campo extensão. Se excludedSubtrees não inclui um tipo nome
particular, a variável de estado excluded subtrees não é modificada para
este tipo nome. Por exemplo, a união dos espaços de nome example.com e
foo.example.com é example.com. E a união de example.com e example.net
seria os dois espaços de nome.
(h) Se o certificado i não for auto-emitido:
(1) Se explicit policy não for 0, decremente explicit policy de 1.
(2) Se policy mapping não for 0, decremente policy mapping de 1.
(3) Se inhibit anyPolicy não for 0, decremente inhibit anyPolicy de 1.
na
(i) Se a extensão 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.
Er
(j) Se a extensão inhibitAnyPolicy estiver incluı́da no certificado e for menor que
inhibit anyPolicy, defina inhibit anyPolicy com o valor de inhibitAnyPolicy.
(k) Se o certificado i tiver a versão 3 de certificado, verifique se a extensão basicConstraints está presente e que cA tem valor TRUE. (Se o certificado i for versão 1
ou versão 2, então a aplicação DEVE ou verificar se o certificado i é um certificado de AC através de meios externos ou rejeitar o certificado. Implementações
em conformidade podem escolher rejeitar todas as versões 1 e 2 em certificados
intermediários.)
(l) Se o certificado não tiver sido auto-emitido, verificar se max path lenght é maior
que 0 e decrementar max path length de 1.
(m) Se pathLenConstraints estiver presente no certificado e for menor que max path length, defina max path lenght com o valor de pathLenConstraint.
(n) Se a extensão key usage estiver presente, verifique se o bit keyCertSign está ativado.
(o) Reconhecer e processar qualquer outra extensão crı́tica presente no certificado.
Processar qualquer outra extensão não-crı́tica presente no certificado, que seja
relevante ao processamento do caminho.
Cooper, et al.
Standards Track
73
RFC 5280
Maio de 2008
Se as verificações (1), (k), (l), (n) ou (o) falharem, o procedimento é finalizado, retornando
uma indicação de falha e uma razão apropriada.
Se (a), (k), (l), (n), e (o) forem completadas com sucesso, incremente i e execute o processamento básico de certificado especificado na seção 6.1.3.
6.1.5
Procedimento de Encerramento
Para completar o processamento do certificado alvo, execute os passos para o certificado n:
es
(a) Se explicit policy não for 0, decremente explicit policy de 1.
(b) Se a extensão policy contraints estiver incluı́da no certificado e requireExplicitPolicy estiver presente e tiver o valor de 0, defina a variável de estado explicit policy
com o valor 0.
(c) Atribua o campo subjectPublicKey do certificado à variável working public key.
nd
(d) Se o campo subjectPublicKeyInfo do certificado tiver um campo algorithm com parâmetros null (nulos) ou os parâmetros forem omitidos, compare subjectPublicKey
algorithm do certificado com a variável working public key algorithm. Se o campo
subjectPublicKey algorithm do certificado e a variável working public key algorithm
forem diferentes, defina a variável working public key parameters como null.
(e) Atribua o valor de subjectPublicKey algorithm do certificado à variável working public key algorithm.
na
(f) Reconheça e processe qualquer outra extensão crı́tica presente no certificado n.
Processe qualquer outra extensão não-crı́tica presente no certificado n, que seja
relevante ao processamento do caminho.
(g) Calcule a intersecção de valid policy tree e user-initial-policy-set, da seguinte forma:
(i) Se a valid policy tree for NULL, a intersecção é NULL.
Er
(ii) Se a valid policy não for NULL e a user-initial-policy-set for any-policy, a
intersecção será a valid policy tree completa.
(iii) Se a valid policy tree não for NULL e a user-initial-policy-set não for anypolicy, calcule a intersecção de valid policy tree e user-initial-policy-set
conforme:
1. Determine o conjunto de polı́ticas de nodos cujos nodos pais tenham uma variável valid policy do tipo anyPolicy. Este é o valid policy node set.
2. Se o valid policy de qualquer nodo no valid policy node set não
estiver em user-initial-policy-ser e não for anyPolicy, apague este
nodo e todos os nodos filhos.
3. Se valid policy tree inclui um nodo de profundidade n com o valid policy com valor anyPolicy e user-initial-policy-ser não for anypolicy, execute os seguintes passos:
a. Defina P-Q para o qualifier set no nodo de profundidade
n com valid policy igual a anyPolicy.
Cooper, et al.
Standards Track
74
RFC 5280
Maio de 2008
es
b. Para cada P-OID no user-initial-policy-set que não for
o valid policy de um nodo no valid policy node set, crie
um nodo filho cujo parente seja o nodo de profundidade
n-1 com valid policy igual a anyPolicy. Defina os valores
no nodo filho como a seguir: defina o valid policy para
P-OID, defina o qualifier set para P-Q, e defina a expected policy ser para P-OID.
c. Apague o nodo de profundidade n com valid policy igual
a anyPolicy.
4. Se existir um nodo na valid policy tree de profundidade n-1 ou
menor sem qualquer nodo filho, apague este nodo. Repetir este
passo ate que não existam nodos de profundidade n-1 ou menor
sem filhos.
6.1.6
nd
Se (1) o valor da variável explicit policy é maior que zero ou (2) o valor da variável valid policy tree não é NULL, então o processamento do caminho obteve sucesso.
Saı́das
Se o processamento do caminho obteve sucesso, o procedimento termina, retornando um indicador de sucesso junto com o valor final das variáveis valid policy tree, working public key,
working public key algorithm, e working public key parameters.
6.2
Uso do Algoritmo de Validação de Caminho
Er
na
O algoritmo de validação de caminho descreve o processo de validação de um único caminho
de certificação. Embora cada caminho de certificação começe com uma âncora de confiança
especı́fica, não há exigência de que todos os caminhos de certificação validados por um
sistema particular compartilhem a mesma âncora de confiança. A seleção de uma ou mais
ACs confiáveis é uma decisão local. Um sistema pode fornecer qualquer uma das suas ACs
confiáveis como a âncora de confiança para um caminho particular. As entradas para o
algoritmo de validação de caminho podem ser diferente para cada caminho. As entradas
utilizadas para processar um caminho podem refletir requisitos especı́ficos da aplicação ou
limitações na confiança atribuı́da uma âncora de confiança particular. Por exemplo, uma
AC confiável pode ser confiável apenas para um determinada polı́tica de certificado. Esta
restrição pode ser expressa através das entradas para o procedimento de validação de caminho.
Uma implementação PODE aumentar o algoritmo apresentado na seção 6.1 para limitar
ainda mais o conjunto de caminhos de certificação válidos que comecem com uma determinada âncora de confiança. Por exemplo, uma implementação PODE modificar o algoritmo
para aplicar uma restrição de comprimento de caminho a uma determinada âncora durante a fase de inicialização, ou a aplicação PODE ter como requisito a presença de uma
determinada forma de nome alternativo no certificado alvo, ou a aplicação PODE impor
como requisitos, extensões especı́ficas para a aplicação. Assim, o algoritmo de validação
de caminho apresentado na seção 6.1 define as condições mı́nimas para um caminho ser
considerado válido.
Quando uma AC distribuir certificados auto-assinados para especificar informação da âncora de confiança, as extensões do certificado podem ser usadas para especificar as entradas
Cooper, et al.
Standards Track
75
RFC 5280
Maio de 2008
6.3
es
recomendadas para a validação de caminho. Por exemplo, uma extensão policy constraints
poderia ser incluı́da no certificado auto-assinado para indicar que os caminhos que começarem com esta âncora de confiança deveria ser confiável apenas para polı́ticas especı́ficas.
De maneira similar, uma extensão name constraints poderia ser incluı́da para indicar que
os caminhos começando com esta âncora de confiança deveriam ser confiáveis apenas para
determinados espaços de nome. O algoritmo de validação de caminho apresentado na seção 6.1 não assume que a informação da âncora de confiança é fornecida em certificados
auto-assinados e não especifica regras de processamento para informação adicionais incluı́das em tais certificados. As implementações que usarem certificados auto-assinados para
especificar informação sobre âncora de confiança estão livres para processar ou ignorar esta
informação.
Validação de LCR
nd
Esta seção descreve os passos necessários para determinar se um certificado está revogado
quando LCRs são o mecanismo de revogação utilizado pelo emissor do certificado. As implementações em conformidade que suportarem LCRs não obrigadas a implementarem este
algoritmo, mas elas DEVEM ser funcionalmente equivalentes ao comportamento externo resultante deste procedimento, quando processarem LCRs que são emitidas em conformidade
com este perfil. Qualquer algoritmo pode ser utilizado por determinada implementação,
desde que derivem o resultado correto.
na
Esta algoritmo considera que todas as LCRs necessárias estarão disponı́veis em uma cache
local. Além disso, se o tempo da próxima atualização de LCR tiver passado, o algoritmo
assume 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 variáveis de estado, e
passos de processamento que são executados para cada certificado do caminho. A saı́da do
algoritmo é o estado de revogação do certificado.
6.3.1
Entradas de Revogação
Para dar suporte ao processo de revogação, o algoritmo precisa de duas entradas:
Er
(a) certificado: O algoritmo precisa do número serial do certificado e do nome do emissor para determinar se o certificado está em uma determinada LCR. A extensão
basicConstraints é utilizada para determinar se o certificado fornecido está associado a uma AC ou a uma entidade final. Se presente, o algoritmo usa as extensões
cRLDistributionPoints e freshestCRL para determinar o estado de revogação.
(b) use-deltas: entrada booleana que determina se serão aplicadas LCRs delta à LCR.
Para suportar o processamento de LCR, o algoritmo requer as seguintes variáveis de estado:
(a) reasons mask: Esta variável contém o conjunto de razões de revogação suportas
pelas LCRs e LCRs delta processadas até o agora. Os membros legais do conjunto
são as possı́veis razões de revogação menos aqueles não especificados: keyCompromise, cACompromise, affiliationChanged, superseded, cessationOfOperation, certificateHold, privilegeWithdrawn, and aACompromise. O valor especial all-reasons
é usado para denotar o conjunto de todos os membros integrantes. Esta variável é
inicializada com um conjunto vazio.
Cooper, et al.
Standards Track
76
RFC 5280
Maio de 2008
(b) cert status: Esta variável contém o estado do certificado. A esta variável pode
ser atribuı́do um dos seguintes valores: unspecified, keyCompromise, cACompromise, affiliationChanged, superseded, cessationOfOperation, certificateHold, removeFromCRL, privilegeWithdrawn, aACompromise, o valor especial UNREVOKED,
ou o valor especial UNDETERMINED. Esta variável é inicializada com o valor especial UNREVOKED.
(c) interim reasons mask: Esta contém o conjunto de razões de revogação suportado
pela LCR ou LCR delta que está sendo processada no momento atual.
6.3.2
es
Nota: Em alguns ambientes, não é necessário verificar todos os códigos razão. Por exemplo, alguns ambientes estão relacionados apenas ao cACompromid e keyCompromise para
certificados de AC. Este algoritmo verifica todos os códigos razão. Processamento adicional
e variáveis de estado podem ser necessário para limitar a verificação a um subconjunto dos
códigos razão.
Processamento de LCR
nd
Este algoritmo começa assumindo que o certificado não está revogado. O algoritmo verifica
um ou mais LCRs até que o estado do certificado seja determinado como revogado ou que
um número suficiente de LCRs tenham sido verificadas para cobrir todos os códigos razão.
Para cada ponto de distribuição (DP) na extensão CRL distribution points do certificado,
para cada LCR correspondente na cache local, enquento ((reasons mask não for all-reasons)
e (cert status for UNREVOKED)) execute o seguinte:
na
(a) Atualize a cache de LCR local obtendo uma LCR completa, uma LCR delta, conforme necessário:
(1) Se o tempo atual é após o valor do campo next update da LCR, então faça
uma das seguintes opções:
Er
(i) Se use-delta estiver ativado e o certificado ou a LCR tiver a extensão freshest CRL, obtenha a LCR delta com o valor next update
que seja após a data atual e possa ser utilizado para atualizar a
LCR armazenada no cache local, como especificado na seção 5.2.4.
(ii) Atualize a cache de LCR local com a LCR completa atual, verifique se o tempo atual é anterior ao valor de next update da nova
LCR, e continue o processamento com a nova LCR. Se use-deltas
estiver ativado e o certificado ou a LCR tiver a extensão freshest
CRL, então obtenha a LCR delta atual que pode ser usada para
atualizar a nova LCR completa gravada na cache local, como especificado na seção 5.2.4.
(2) Se o tempo atual é anterior ao valor do campo next update, use-deltas
estiver ativado, e o certificado ou a LCR tiver a extensão freshest CLR,
então obtenha a LCR delta atual que pode ser usada para atualizar a LCR
completa gravada na cache local, como especificado na seção 5.2.4.
(b) Verifique o emissor e o escopo da LCR completa da seguinte forma:
(1) Se o DP inclui cRLIssuer, então verifique se o campo issuer na LCR completa corresponde ao cRLIssuer do DP e que a LCR completa contém uma
Cooper, et al.
Standards Track
77
RFC 5280
Maio de 2008
extensão issuig distribution point com o campo booleano indirectCRL ativado. Se outra forma, verifique que o campo CRL issuer corresponde ao
ao campo certificate issuer.
(2) Se a LCR completa tiver a extensão de LCR issuing distribution point
(IDP), verifique o seguinte:
nd
es
(i) Se distribution point name estiver presente na extensão IDP da
LCR e o campo distribution estiver presente na DP, então verifique
que um dos nomes da IDP corresponde a um dos nomes da DP.
Se o distribution point name estiver presente na extensão IDP da
LCR e o campo distribution for omitido na DP, então verifique
que um dos nomes na IDP corresponde a um dos nomes no campo
cRLIssuer da DP.
(ii) Se o campo booleano onlyContainsUserCerts estiver atribuı́do na
extensão IDP da LCR, verifique se o certificado não inclui a extensão basic contraints como o campo booleano cA ativado.
(iii) Se o campo booleano onlyContainsCACerts estiver atribuı́do na
estensão IDP da LCR, verifique se o certificado inclui a extensão
basic constraints com o campo booleano cA ativado.
(iv) Verifique que o campo booleano onlyContainsAttributeCerts não
está ativado.
(c) Se use-deltas estiver ativado, verifique o usuário e o escopo da LCR delta da seguinte forma:
na
(1) Verifique se delta CRL issuer corresponde a complete CRL issuer.
(2) Se a LCR completa inclui a extensão de LCR issuing distribution point
(IDP), verifique se a LCR delta contém uma extensão de LCR IDP. Se a
LCR completa omite a extensão IDP da LCR, verifique se a LCR delta
também omite a extensão IDP da LCR .
(3) Verifique se a extensão authority key identifier da LCR delta corresponde
à extensão authority key identifier da LCR completa.
Er
(d) Processe a variável interim reasons mask para esta LCR da seguinte forma:
(1) Se a extensão issuing distribution point da LCR estiver presente e incluir
onlySomeReasons e a DP incluir reasons, então defina interim reasons mask
com a intersecção de reasons da DP e onlySomeReasons da extensão IDP
da LCR.
(2) Se a extensão IDP da LCR incluir onlySomeReasons, mas a DP omitir reasons, então defina interim reasons mask com o valor de onlySomeReasons
da extesnão IDP da LCR.
(3) Se a estensão IDP da LCR não estiver presente ou omitir onlySomeReasons, mas a DP incluir reasons, então defina interim reasons mask com o
valor de reasons da DP.
(4) Se a extensão IDP da LCR não estiver presente ou omitir onlySomeReasons, e DP omitir reasons, então defina interim reasons mask com o valor
especial all-reasons.
Cooper, et al.
Standards Track
78
RFC 5280
Maio de 2008
(e) Verifique se interim reasons mask inclui uma ou mais razões que não estão incluı́das
na reasons mask.
(f) Obtenha e valide o caminho de certificação para o emissor da LCR completa. A
âncora de confiança para o caminho de certificação DEVE ser a mesma âncora de
confiança usada para validar o certificado alvo. Se a extensão key usage estiver
presente no campo issuer do certificado do emissor da LCR, verifique se o bit
cRLSign está ativado.
(g) Valide a assinatura da LCR completa usando a chave pública validada no passo
(f).
es
(h) Se use-deltas estiver ativado, então valide a assinatura da LCR delta usando a
chave pública validada no passo(f).
(i) Se use-deltas estiver ativado, procure pelo certificado na LCR delta. Se uma entrada correspondente ao número serial e emissor for encontrada, como descrito no
item 5.3.3, então atribua a cert status variable a razão indicada, da seguinte forma:
nd
(1) Se a extensão reason code da entrada da LCR estiver presente, atribua à
variável cert status o valor de reason code extensão da entrada da LCR.
(2) Se a extensão reason code da entrada da LCR não estiver presente, atribua
à variável cert status o valor unspecified.
na
(j) Se (cert status igual a UNREVOKED), então procure pelo certificado na LCR
completa. Se uma entrada for encontrada que corresponda ao emissor do certificado
e número serial, como descrito na seção 5.3.3, então atribua à variável cert status
a razão indicada, como descrito no passo (i).
(k) Se (cert status igual a removeFromCRL), então atribua à variável cert status o
valor UNREVOKED.
(l) Atribua à variável de estado reason mask a união dos seus valores anteriores e o
valor da variável de estado interim reasons mask.
Er
Se ((reasons mask igual a all-reasons) OU (cert status não for UNREVOKED)), então o
estado de revogação foi determinado, então retorne cert status.
Se o estado de revogação não tiver sido determinado, repita o processo acima com qualquer
LCR disponı́vel não especificada em distribution point, mas emitida pelo emissor do certificado. Para o processamento de tal LCR, considere um DP com tanto o campo reasons
como o campo cRLIssuer omitidos e um distribution point name igual ao campo issuer do
certificado. Ou seja, a sequência de names em fullName é criada a partir, tanto campo
issuer do certificado como da extensão issuerAltName. Após processar tais LCRs, se o
estado de revogação ainda não tiver sido determinado, então retorne UNDETERMINED
na variável de estado cert status.
7
Regras de Processamento para Nomes Internacionalizados
Nomes internacionalizados podem ser encontrados em campos de númerosos certificados
e LCR e extensões, incluindo nomes distintos, nome internacionalizados de domı́nios, endereços de correio eletrônico, e identificadores de recursos internacionalizados (IRIs). O
Cooper, et al.
Standards Track
79
RFC 5280
Maio de 2008
armazenamento, comparação e apresentação deste tipo de nome requer um cuidado especial. Alguns caracteres pode ser codificados de diversas formas. O mesmo nome poderia ser
representado em diversas codificações (ex: ASCII ou UTF8). Esta seção estabelece requisitos de conformidade para o armazenamento e comparação para cada um desses formatos
de nome. É fornecido um guia informativo de apresentação para alguns destes formatos de
nome.
7.1
Nomes Internacionalizados em Distinguished Names
nd
es
A representação de nomes internacionalizados em nomes distintos (distinguished names) é
tratada nas seções 4.1.2.4, Issuer Names, e 4.1.2.6, Subject Name. Atributos padrão para
nomes, tais como common nem, empregam o tipo DirectoryString, que suporta nomes internacionalizados através de uma variedade de codificações linguı́sticas. Implementações em
conformidade DEVEM suportar UTF8String e PrintableString. A RFC 3280 requer apenas
comparações binárias de valores de atributos codificados em UTF8String, entretanto, esta
especificação requer um tratamento mais abrangente para comparação. Implementações
podem encontrar certificados e LCRs com nomes codificados usando TeletexString, BMPString, ou UniversalString, mas o suporte a estas codificações é OPCIONAL.
na
Implementações em conformidade DEVEM usar o perfil LDAP StringPrep (incluindo o
tratamento de espaço insignificante), como especificado em [RFC4518], como base para a
comparação de atributos de nomes distintos codificados em PrintableString ou UTF8String.
Implementações em conformidade DEVEM suportar comparações de nome usando caseIgnoreMatch. Suporte a tipos de atributo que usam outras regras de correspondência equalitativa é opcional.
Antes de comparar nomes usando a regra caseIgnoreMatch, implementações em conformidade DEVEM executar o algoritmo de preparação 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 no
Appendix B.2 de [RFC3454].
Er
∗ No passo 6, Insignificant Character Removal, executa compressão de espaço branco
como especificado na seção 2.6.1, Insignificant Space Handling, de [RFC4518].
Quando executar o algoritmo de preparação de string, os atributos DEVEM ser tratados
como valores armazenados.
Dois atributos de nome correspondem se os tipos atributo forem os mesmos e os valores
dos atributos forem uma correspondência exata após o processamento com o algoritmo de
preparação de string. Dois nomes distintos relativos RDN1 e RDN2 correspondem se eles
tiverem o mesmo número de atributos de nomes e para cada atributo de nome em RDN1
existir um atributo de nome correspondente em RDN2. Sou nomes distintos DN1 e DN2
correspondem se eles tiverem o mesmo n umero de RDNs, para cada RDN em DN1 existir
um RDN correspondente em DN2, e os RDNs correspondentes aparecerem na mesma ordem
em ambos DNs. Um nome distinto DN1 está na sub-árvore definida pelo nome distinto
DN2 se DN1 tiver no mı́nimo tantos RDNs quanto DN2, e DN1 e DN2 são correspondentes
quando RDNs à direita de DN1 são ignorados.
Cooper, et al.
Standards Track
80
7.2
RFC 5280
Maio de 2008
Nome de Domı́nio Internacionalizados em GeneralName
Nomes de Domı́nio Internacionalizados (IDNs) podem ser incluı́dos em certificados e LCRs
nas extensões subjectAltName e issuerAltName, na extensão name constraints, na extensão
authority information access, na extensão subject information access, nas extensões CRL
distribution points, e extensão issuing distribution point. Cada uma dessas extensões usam
o tipo GeneralName; uma seleção em GeneralName é o campo dNSName, que é definido
como tipo IA5String.
es
IA5String é limitado ao conjunto de caracteres ASCII. Para acomodar nomes de domı́nio
internacionalizados na estrutura atual, implementações em conformidade DEVEM converter nomes de domı́nio internacionalizados para um formato de codificação compatı́vel com
ASCII (ACE) como especificado na seção 4 da RFC 3490 antes de incluir no campo dNSName. Especificamente, implementações em conformidade DEVEM executar a operação
de conversão especificada na seção 4 da RFC 3490, como os seguintes esclarecimentos:
nd
∗ no passo 1, o nome de domı́nio DEVERÁ ser considerado um “stored string”. Ou
seja, o rótulo AllowUnassingned NÃO DEVERÁ ser ativado;
∗ no passo 3, ativar o rótulo chamado “UseSTD3ASCIIRules”;
∗ no passo 4, processar cada rótulo com a operação “ToASCII”; e
∗ no passo 5, mudar todos os separadores de rótulo para U+002E (parada completa).
na
Quando comparar nomes DNS para igualdade, implementações em conformidade DEVEM
executar uma correspondência exata não-sensı́vel a caixa (maiúscula e minúscula) em todo
o nome DNS. Quando avaliar name constraints, implementações em conformidade DEVEM
executar correspondência exata não sensı́vel a caixa em base label-by-label. Como observado na seção 4.2.1.10, qualquer nome DNS que pode ser construı́do a partir da adição de
rótulos ao lado esquerdo do nome de domı́nio dado conforme as restrições é considerado
pertencente a sub-árvore indicada.
81
Er
Implementações em conformidade deveriam converter IDNs para Unicode antes de exibilo. Especificamente, implementações em conformidade deveriam executar a operação de
conversão especificada na seção 4 da RFC 3490, com os seguintes esclarecimentos:
∗ no passo 1, o nome de domı́nio DEVERÁ ser considerado “stored string”. Ou seja, o
rótulo AllowUnassigned NÃO DEVE ser ativado;
∗ no passo 3, ative o rótulo chamado “UseSTD3ASCIIRules”;
∗ no passo 4, processe cada rótulo com a operação “ToUnicode”; e
∗ pule o passo 5.
Nota: Implementações devem prever requisitos maiores de espaço para IDNs. Um rótulo
IDN ACE começará com quatro caracteres adicionais“xn–”e pode exigir até cinco caracteres
ASCII para especificar um único caractere internacional.
Cooper, et al.
Standards Track
7.3
RFC 5280
Maio de 2008
Nomes de Domı́nio Internacionalizados em Distinguished Names
es
Nome de Domı́nio também podem ser representados como nomes distintos usando componentes domı́nio no campo subject, no campo issuer, na extensão subjectAltName, ou na
extensão issuerAltName. Da mesma forma do dNSName no tipo GeneralName, o valor
deste atributo é definido como um IA5String. Cada atributo domainComponent representa
um rótulo único. Para representar um rótulo de um IDN no nome distinto, a implementação DEVE executar a conversão “ToASCII” especificada na seção 4.1 da RFC 3490. O
rótulo DEVERÁ ser considerado um “stored string”. Ou seja, o indicador AllowUnassigned
NÃO DEVERÁ ser ativado.
Implementações em conformidade deverão o executar correspondência exata não-sensı́vel a
caixa do caractere (maiúscula/minúscula) quando comparar atributos domainComponente
em nomes distintos, como descrito na seção 7.2.
7.4
nd
As implementações deveriam converter rótulos ACE para Unicode antes de exibi-los. Especificamente, implementações em conformidade deveriam executar a operação de conversão
“ToUnicode” especificada, como descrita na seção 7.2, em cada rótulo ACE antes de exibir
o nome.
Identificadores de Recurso Internacionalizados
Er
na
Identificadores de Recurso Internacionalizados (IRIs) são os complementos internacionalizados para Identificador de Recurso Uniforme (URI). IRIs são sequências de caracteres do
conjunto de caracteres ASCII. [RFC3987] define o mapeamento de IRIs para URIs. Enquanto IRIs não são codificados diretamente em qualquer campo de certificado ou extensão,
seus URIs podem mapeados são incluı́dos em certificados e LCRs. URIs podem aparecer
nas extensões subjectAltName e issuerAltName, na extensão name constraints, na extensão
authority information access, na extensão subject information access, na extensão issuing
distribution point, e na extensão de LCR distribution points. Cada uma dessas extensões
usam o tipo GeneralName; URIs são codificadas no campo uniformResourceIdentifier em
GeneralName, que é definido como um tipo IA5String.
Para comodar IRIs na estrutura atual, implementações em conformidade DEVEM mapear
IRIs para URIs como especificado na seção 3.1 de [RFC3987], com os seguintes esclarecimentos:
∗ no passo 1, gerar a sequência UCS de caractere à partir do formato original da IRI
normalizado de acordo com NFC como especificado em Variant b (normalização de
acordo com NFC);
∗ Executar o passo 2 usando a saı́da do passo 1.
As implementações NÃO DEVEM converter o componente ireg-name antes de executar o
passo 2.
Antes das URIs puderem ser comparadas, implementações em conformidade DEVEM executar uma combinação de técnicas de normalização baseada em sintaxe e baseada em esquema descritas em [RFC3987]. Especificamente, implementações em conformidade DEVEM preparar URIs para comparação da seguinte forma:
Cooper, et al.
Standards Track
82
RFC 5280
Maio de 2008
∗ Passo 1: Onde IRIs permitirem o uso de IDNs, aqueles nomes DEVEM ser convertido
para codificação compatı́vel ASCII como especificado na seção 7.2 acima.
∗ Passo 2: O esquema e host são normalizados para caixa baixa, como descrito na seção
5.3.2.1 de [RFC3987].
∗ Passo 3: Executar normalização percent-encoding, como especificado na seção 5.3.2.3
de [RFC3987].
es
∗ Passo 4: Executar normalização de segmento de caminho, como especificado na seção
5.3.2.4 de [RFC3987].
∗ Passo 5: Se reconhecido, a implementação DEVE executar normalização baseada em
esquema, como especificado na seção 5.3.3 de [RFC3987].
nd
Implementações em conformidade DEVEM reconhecer e executar normalização baseada
em esquema para os sequintes esquemas: ldap, http, https, e ftp. Se o esquema não for
reconhecido, o passo 5 é omitido.
Quando comparar URIs para equivalência, implementações em conformidade DEVERÃO
executar correspondência exata sensı́vel a caixa (maiúsculas/minúsculas).
As implementações deveriam converter URIs para Unicode ante de exibi-los. Especificamente, implementações em conformidade deveriam executar a operação de conversão
especificada na seção 3.2 de [RFC3987].
Endereços de Correio Eletrônico Internacionalizados
na
7.5
Er
Endereços de correio eletrônico podem ser incluı́dos em certificados e LCRs nas extensões
subjectAltName e issuerAltName, na extensão name constraints, na extensão authority
information access, na extensão subject information access, na extensão issuing distribution point, ou na extensão de LCR distribution points. Cada uma dessas extensões usa o
contrutor GeneralName; GeneralName inclui a seleção rfc822Name, que é definida como
tipo IA5String. Para acomodar endereços de correio eletrônico com nomes de domı́nio internacionalizados usando a estrutura atual, as implementações em conformidade DEVEM
converter os endereços em representações ACSII.
Onde a parte host (o domı́nio da caixa postal) tiver um nome internacionalizado, o nome
de domı́nio DEVE ser convertido de IDN para o formato de codificação compatı́vel ASCII
(ACE) como especificado na seção 7.2.
Dois endereços de email são considerados correspondentes se:
1) a parte local de cada nome tem correspondência exata, E
2) a parte host de cada nome correspondem usando uma comparação ASCII não
sensı́vel a caixa de texto(maiúscula/minúscula).
As implementações devem converter a parte host dos endereços de email internacionalizados
especificado nessas extensões para Unicode antes de exibi-los. Especificamente, implementações em conformidade deveriam executar a conversão da parte host da caixa postal como
descrito na seção 7.2.
Cooper, et al.
Standards Track
83
8
RFC 5280
Maio de 2008
Considerações de Segurança
A maior parte desta especificação é dedicada ao formato e conteúdo de certificados e LCRs.
Desde que os certificados e LCRs são assinados digitalmente, nenhum serviço adicional de
integridade é necessário. Nem certificados nem LCRs necessitam manter segredo, e o acesso
irrestrito e anonimo aos certificados e LCRs não tem implicações na segurança.
es
Contudo, fatores de segurança externos ao escopo desta especificação afetam a garantia
fornecida aos usuários de certificados. Esta seção destaca questões crı́ticas a serem consideradas por implementadores, administradores e usuários.
Os procedimentos executados pelas ACs e ARs para validar a associação da identidade do
sujeito com sua chave pública afetam muito a confiança que deve ser colocada no certificado.
Terceiras partes confiáveis podem querer revisar as declarações de práticas de certificação
das ACs. Isto é particularmente importante quando se emite certificados para outras ACs.
na
nd
O uso de um único par de chaves tanto para assinatura quanto para outros propósitos é
fortemente desencorajada. O uso de pares de chave separadas para assinatura e gerenciamento de chave fornece muitos benefı́cios para os usuários. As ramificações associadas a
perda ou comprometimento de uma chave de assinatura são diferentes da perda ou comprometimento de uma chave usada para gerenciamento de chaves. O uso de pares de chaves
separados permite uma resposta balanceada e flexı́vel. De maneira similar, perı́odos de
validade diferentes ou tamanhos de chave para cada par de chave pode ser apropriado em
alguns ambientes de aplicação. Infelizmente, alguns aplicativos legados (ex: Secure Sockets
Layer (SSL)), usa um único par de chave para assinatura e gerenciamento de chave.
Er
A proteção conferida às chaves privadas é um fator crı́tico de segurança. Em pequena
escala, falhas de usuários na proteção de suas chaves privadas permitira que um intruso
possa se passar por eles ou descriptografar suas informações pessoais. Em larga escala, o
comprometimento de uma chave privada de assinatura de AC pode ter efeitos catastróficos. Se um intruso obtém a chave privada e isso passa despercebido, o intruso pode emitir
certificados e LCRs falsos. A existência de certificados e LCRs falsos prejudica a confiança
no sistema. Se tal comprometimento for detectado, todos os certificados emitidos pela AC
comprometida DEVEM ser revogados, impedindo serviços entre seus usuários e usuários
de outras ACs. A reconstrução após este tipo de comprometimento será problemática, de
maneira que as ACs são alertadas a implementarem uma combinação de medidas técnicas
fortes (ex: módulos criptográficos resistentes a violaçoes) e procedimentos gerenciais apropriados (ex: segregação de responsabilidades) afim de evitar este tipo de incidente.
A perda de uma chave privada de assinatura de uma AC também pode ser problemática.
A AC não seria capaz de produzir LCRs ou executar a atualização normal de chave. As
ACs DEVERIAM manter backup seguro das chaves de assinatura. A segurança dos procedimentos de backup de chave é um fator crı́tico na prevenção do seu comprometimento.
A disponibilidade e a atualização da informação de revogação afeta o grau de confiança que
pode ser atribuı́do ao certificado. Embora os certificados expirem naturalmente, podem
ocorrer eventos durante o seu perı́odo de vida útil que negam a associação entre o sujeito e
a chave pública. Se a informação de revogação estiver desatualizada ou indisponı́vel, a confiança atribuı́da a associação fica claramente reduzida. Terceiras partes confiáveis podem
não ter capacidade para processar toda extensão crı́tica que pode aparecer em uma LCR.
Cooper, et al.
Standards Track
84
RFC 5280
Maio de 2008
es
As ACs DEVERIAM tomar cuidados adicionais quando disponibilizarem informação de
revogação unicamente através de LCRs que contenham extensões crı́ticas, particularmente,
quando o o suporte a estas extensões não for considerado obrigatório neste perfil. Por exemplo, se a informação de revogação for fornecida usando uma combinação de LCRs delta e
LCRs completas, e as LCRs delta forem emitidas mais frequentemente que as LCRs completas, então as terceiras partes confiáveis que não puderem processar as extensões crı́ticas
relacionadas ao processamento das LCRs delta não serão capazes de obter a informação de
revogação mais recente. Alternativamente, se um LCR completa for emitida sempre que
uma LCR delta for emitida, então informação de revogação atualizada estará disponı́vel
para todas as terceiras partes. De maneira similar, as implementações do mecanismo de
validação de caminho de certificação, descrito na seção 6, que omitirem a verificação de
revogação fornece menos confiança que aqueles que possuem esse suporte.
nd
O algoritmo de validação de caminho de certificação dependem de certo conhecimento das
chaves públicas (e outra informação) sobre um ou mais ACs confiáveis. A decisão de confiar em uma AC é uma decisão importante, pois em última instância determina a confiança
atribuı́da ao certificado. A distribuição autenticada de chaves públicas de ACs confiáveis
(geralmente na forma de um certificado auto-assinado) é um processo externo crı́tico para
a segurança e que se encontra além do escopo desta especificação.
na
Além disso, onde um comprometimento de chave ou falha de AC ocorre de uma AC confiável, o usuário necessitará modificar a informação fornecida para a rotina de validação de
caminho. A seleção de muitas ACs confiáveis torna a informação sobre AC confiável difı́cil
de manter. Por outro lado, a seleção de apenas uma AC confiável poderia limitar os seus
usuários a uma comunidade fechada de usuários.
A qualidade das implementações que processam certificados também afeta o grau de confiança fornecido. O algoritmo de validação de caminho descrito na seção 6 se baseia na
integridade da informação da AC confiável, e especialmente na integridade das chaves públicas associadas às ACs confiáveis. Com a substituição das chaves públicas para as quais
um intruso detenha a chave privada, um invasor poderia enganar o usuário quanto a aceitação de certificados falsos.
85
Er
A associação entre uma chave e o sujeito do certificado não pode ser mais forte que a
implementação do módulo criptográfico e os algoritmos usados para gerar a assinatura.
Tamanhos de chaves pequenos ou algoritmos de hash frágeis limitará a utilidade de um
certificado. As ACs são incentivadas os avanços da criptologia de forma que possam aplicar
técnicas fortes de criptografia. Além disso, as ACs DEVERIAM se recusar a emitir certificados para ACs ou entidades finais que geram assinaturas fracas.
Aplicações inconsistentes de regras de comparação podem resultar na aceitação de caminhos
de certificação X.509 inválidos ou rejeição de caminhos válidos. A série de especificações
X.500 define regras para comparação de nomes distintos que requerem comparações de
strings sem considerar o tamanho do caractere, conjunto de caractere, subtração de múltiplos caracteres brancos, ou desconsiderar caracteres brancos à esquerda ou à direita. Esta
especificação relaxa estes requisitos, é necessário, no mı́nimo, suporte para comparação binária.
As ACs DEVEM codificar o nome distinto no campo subject de um certificado de AC de
maneira idêntica ao nome distinto do campo issuer nos certificados emitidos pela AC. Se as
Cooper, et al.
Standards Track
RFC 5280
Maio de 2008
ACs usarem codificações diferentes, as implementações poderão falhar no reconhecimento
de cadeias de nome para os caminhos que incluı́rem este certificado. Como consequência,
caminhos válidos poderão ser rejeitados.
es
Além disso, restrições de nome para nomes distintos DEVEM ser definidas de maneira
idêntica à codificação usada no campo subject ou na extensão subjectAltName. Caso
contrário, as restrições de nome definidas como excludedSubtrees não corresponderão e caminhos inválidos serão aceitos e as restrições de nome expressadas como permittedSubtrees
não corresponderão e caminhos válidos serão rejeitados. Para evitar a aceitação de caminhos inválidos, as AC DEVERIAM definir as restrições de nome para nomes distintos como
permittedSubtrees sempre que possı́vel.
Em geral, o uso da extensão nameConstraints para restringir uma forma de nome (ex: nomes DNS) não oferece proteção contra o uso de outras formas de nome (ex: endereço de
correio eletrônico).
na
nd
Enquanto o X.509 determina que não exista ambiguidade nos nomes, existe o risco que
duas autoridades não relacionadas emitam certificados ou LCRs embaixo do mesmo nome
de emissor. Como meio de reduzir problemas e questões de segurança relacionadas a colisões de nome de emissor, nomes de AC e emissor de LCR DEVERIAM ser formados de
maneira a reduzir a probabilidade de colisão de nomes. Implementadores deveriam levar
em conta a possı́vel existência de múltiplas ACs não relacionadas e emissores de LCR com
o mesmo nome. No mı́nimo, as implementações que validam LCRs DEVEM garantir que
o caminho de certificação de um certificado e o caminho de certificação do emissor de LCR
usado para validar o certificado terminam na mesma âncora de confiança.
Er
Enquanto a parte local de um endereço de correio eletrônico diferencia maiúsculas de minúsculas [RFC2821], os valores de atributo emailAddress não fazem distinção entre maiúsculas
e minúsculas [RFC2985]. Como resultado, existe o risco de que dois endereços de correio
eletrônico distintos sejam tratados como o mesmo endereço quando a regra de correspondência para atributo emailAddress for usada, se o servidor de email explorar a diferenciação
de maiúsculas e minúsculas da parte local da caixa postal. Os implementadores não deveriam incluir o endereço de email no atributo emailAddress quando o servidor de email que
detém aquele endereço de email tratar a parte local do endereço de email com diferenciação
entre maiúsculas e minúsculas.
Implementadores deveriam ter conhecimento dos riscos envolvidos se as extensões CRL
distribution points ou authority information access de certificados corrompidos ou LCRs
tiverem links para códigos maliciosos. Os implementadores deveriam sempre tomar as medidas de validação de dados recuperados para garantir que o dado foi formado de maneira
apropriada.
Quando os certificados incluı́rem a extensão cRLDistributionPoints com uma URI https
ou esquema semelhante, pode ser introduzido uma depedência circular. A parte confiável é forçada a executar uma validação adicional de caminho para obter a LCR desejada
para completar a validação inicial de caminho. Condições circulares também podem ser
criadas com uma URI https (ou esquema simelhante) nas extensões authorityInfoAccess ou
subjectInfoAccess. Na pior das hipóteses, esta situação pode gerar dependências insolúveis.
As ACs NÃO DEVERIAM incluir URIs que especificam https, ldaps, ou esquemas semeCooper, et al.
Standards Track
86
RFC 5280
Maio de 2008
lhantes nas extensões. As ACs que incluem uma URI https em uma desses extensões DEVE
garantir que o certificado do servidor pode ser validado sem a informação que é apontada
pela URI. Terceiras partes confiáveis que escolherem validar o certificado do servidor obtendo a informação apontada por uma URI https nas extensões cRLDistributionPoints,
authorityInfoAccess, ou subjectInfoAccess DEVEM estar preparadas para a possibilidade
disto resultar em uma recursão infinita.
nd
es
Certificados auto-emitidos fornecem às ACs um mecanismo automatizado para indicar mudanças nas operações da AC. Em particular, certificados auto-emitidos podem ser usado
para implementar uma mudança de chaves tranquila de um par de chaves de AC não comprometidas para o próximo. Procedimentos detalhados para “atualização de chave de AC”
são especificados em [RFC4210], onde a AC protege a sua nova chave pública usando a sua
chave privada anterior e vice-versa, usando dois certificados auto-emitidos. Implementações
cliente em conformidade processarão o certificado auto-emitido e determinarão se o certificado emitido sob a nova chave pode ser confiável. Certificados auto-emitidos PODEM ser
usados para suportar outras mudanças nas operações da AC, como adições ao conjunto de
polı́ticas da AC, usando procedimentos semelhantes.
Algumas implementações legadas suportam nomes codificados em ISO 8859-1 conjunto de
caractere (LatinString) [ISO8859], mas marcam eles como TeletexString. TeletexString codificam um conjunto de caracteres maior que o definido na ISO 8859-1, mas ela codifica
alguns caracteres de maneira diferente. As regras de comparação de nome especificadas
na seção 7.1 consideram que TeletexString são codificados como o conjunto de caracteres
LatinString, possibilitando falto positivos e falso negativos.
9
Er
na
Quando strings são mapeados de representações internas para representação visual, algumas vezes dois strings distintos terão o mesma representação visual, ou representação
semelhante. Isto pode acontecer por diversas razões, incluindo o uso de glifos semelhantes
e uso de caracteres compostos (como e + ´ equivalentes a U+00E9, os caracteres coreanos
compostos, e vogais acima de consoantes agrupados em certas lı́nguas). Como resultado
dessa situação, pessoas fazendo comparação visual entre dois nomes diferentes pode pensar
que eles são os mesmos quando de fato eles não são. Também, as pessoas podem confundir
um string com outro. Emissores de certificados e terceiras partes confiáveis necessitam ter
conhecimento desta situação.
Considerações IANA
Extensões em certificados e LCRs são identificadas à partir de identificadores de objeto
(OID). Os objetos são definidos em um arco delegado pelo IANA ao PKIX Working Group.
Nenhuma ação adicional, por parte do IANA, se faz necessário para este documento ou
quaisquer atualizações antecipadas.
10
Agradecimento
Warwick Ford participou com os autores de algumas das reuniões do projeto da equipe que
dirigiu o desenvolvimento deste documento. Os esforços da equipe de design foram guiados
por contribuições de Matt Crawford, Gindin Tom, Steve Hanna, Stephen Henson, Hoffman
Paulo, Ito Takashi, Pinkas Denis, e Wen-Cheng Wang.
Cooper, et al.
Standards Track
87
11
11.1
RFC 5280
Maio de 2008
Referências
Referências Normativas
[RFC791]
Postel, J., “Internet Protocol”, STD 5, RFC 791, September 1981.
[RFC1034] Mockapetris, P., “Domain Names - Concepts and Facilities”, STD 13, RFC
1034, November 1987.
es
[RFC1123] Braden, R., Ed., “Requirements for Internet Hosts – Application and Support”, 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) Specification”, RFC 2460, December 1998.
nd
[RFC2585] Housley, R. and P. Hoffman, “Internet X.509 Public Key Infrastructure: Operational Protocols: FTP and HTTP”, RFC 2585, May 1999.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and
T. Berners-Lee, “Hypertext Transfer Protocol – HTTP/1.1”, RFC 2616, June
1999.
[RFC2797] Myers, M., Liu, X., Schaad, J., and J. Weinstein, “Certificate Management
Messages over CMS”, RFC 2797, April 2000.
na
[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 Names in Applications (IDNA)”, RFC 3490, March 2003.
Er
[RFC3629] Yergeau, F., “UTF-8, a transformation format of ISO 10646”, STD 63, RFC
3629, November 2003.
88
[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): Internationalized String Preparation”, RFC 4518, June 2006.
[RFC4523] Zeilenga, K., “Lightweight Directory Access Protocol (LDAP) Schema Definitions for X.509 Certificates”, RFC 4523, June 2006.
Cooper, et al.
Standards Track
RFC 5280
Maio de 2008
[RFC4632] Fuller, V. and T. Li, “Classless Inter-domain Routing (CIDR): The Internet
Address Assignment and Aggregation Plan”, BCP 122, RFC 4632, August
2006.
ITU-T Recommendation X.680 (2002) | ISO/IEC 8824-1:2002, Information
technology - Abstract Syntax Notation One (ASN.1): Specification of basic
notation.
[X.690]
technology - ASN.1 encoding rules: Specification of Basic Encoding Rules
(BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules
(DER).
11.2
Referências Informativas
[ISO8859]
es
[X.680]
ISO/IEC 8859-1:1998. Information technology – 8-bit single-byte coded
graphic character sets – Part 1: Latin alphabet No. 1.
nd
[ISO10646] ISO/IEC 10646:2003. Information technology – Universal Multiple-Octet
Coded Character Set (UCS).
Davis, M. and M. Duerst, “Unicode Standard Annex #15: Unicode Normalization 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 Key
Infrastructure Certificate and CRL Profile”, RFC 2459, January 1999.
[RFC2560]
Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. Adams, “X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP”,
RFC 2560, June 1999.
Er
na
[NFC]
[RFC2985]
Nystrom, M. and B. Kaliski, “PKCS #9: Selected Object Classes and Attribute Types Version 2.0”, RFC 2985, November 2000.
[RFC3161]
Adams, C., Cain, P., Pinkas, D., and R. Zuccherato, “Internet X.509 Public
Key Infrastructure Time-Stamp Protocol (TSP)”, RFC 3161, August 2001.
[RFC3279]
Bassham, L., Polk, W., and R. Housley, “Algorithms and Identifiers for the
Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile”, RFC 3279, April 2002.
[RFC3280]
Housley, R., Polk, W., Ford, W., and D. Solo, “Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile”, RFC
3280, April 2002.
Cooper, et al.
Standards Track
89
RFC 5280
Maio de 2008
[RFC4055] Schaad, J., Kaliski, B., and R. Housley, “Additional Algorithms and Identifiers for RSA Cryptography for use in the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile”, RFC
4055, June 2005.
[RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, “The Kerberos Network
Authentication Service (V5)”, RFC 4120, July 2005.
[RFC4210] Adams, C., Farrell, S., Kause, T., and T. Mononen, “Internet X.509 Public
Key Infrastructure Certificate Management Protocol (CMP)”, RFC 4210,
September 2005.
es
[RFC4325] Santesson, S. and R. Housley, “Internet X.509 Public Key Infrastructure
Authority Information Access Certificate Revocation List (CRL) Extension”,
RFC 4325, December 2005.
nd
[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 Internet
X.509 Public Key Infrastructure Certificate and CRL Profile”, RFC 4491,
May 2006.
[RFC4510] Zeilenga, K., Ed., “Lightweight Directory Access Protocol (LDAP): Technical
Specification Road Map”, RFC 4510, June 2006.
[RFC4512] Zeilenga, K., Ed., “Lightweight Directory Access Protocol (LDAP): Directory
Information Models”, RFC 4512, June 2006.
na
[RFC4514] Zeilenga, K., Ed., “Lightweight Directory Access Protocol (LDAP): String
Representation of Distinguished Names”, RFC 4514, June 2006.
[RFC4519] Sciberras, A., Ed., “Lightweight Directory Access Protocol (LDAP): Schema
for User Applications”, RFC 4519, June 2006.
[RFC4630] Housley, R. and S. Santesson, “Update to DirectoryString Processing in the
Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile”, RFC 4630, August 2006.
[X.501]
[X.509]
technology - Open Systems Interconnection - The Directory: Overview of
concepts, models and services.
Er
[X.500]
[X.520]
Cooper, et al.
technology - Open Systems Interconnection - The Directory: Models.
technology - Open Systems Interconnection - The Directory: Public-key and
attribute certificate frameworks.
technology - Open Systems Interconnection - The Directory: Selected attribute types.
Standards Track
90
RFC 5280
Maio de 2008
[X.660] ITU-T Recommendation X.660 (2004) | ISO/IEC 9834-1:2005, Information
technology - Open Systems Interconnection - Procedures for the operation of
OSI Registration Authorities: General procedures, and top arcs of the ASN.1
Object Identifier tree.
[X.683] ITU-T Recommendation X.683 (2002) | ISO/IEC 8824-4:2002, Information
technology - Abstract Syntax Notation One (ASN.1): Parameterization of
ASN.1 specifications.
es
[X9.55] ANSI X9.55-1997, Public Key Cryptography for the Financial Services Industry: Extensions to Public Key Certificates and Certificate Revocation
Lists, January 1997.
nd
Apêndice A. Estruturas e OIDs em Pseudo-ASN.1
Este apêndice 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 sintaxe ASN.1 1988 é expandida com os Tipo UNIVERSAL da versão 1993, UniversalString,
BMPString e UTF8String.
na
A sintaxe ASN.1 não permite a inclusão do tipo statements no módulo ASN.1, e o padrão
ASN.1 de 1993 não permite o uso dos novos tipos UNIVERSAL nos módulos usando a
sintaxe 1988. Como resultado, este módulo não está de acordo com nenhuma das versões
padrão ASN.1.
Este apêndice pode ser convertido em ASN.1 1988 substituindo as definições do Tipo UNIVERSAL com o tipo “ANY” da versão 1988.
Er
A.1 Módulo 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
-- necessários a esta especificaç~
ao
UniversalString ::= [UNIVERSAL 28] IMPLICIT OCTET STRING
-- UniversalString é definido em ASN.1:1993
Cooper, et al.
Standards Track
91
RFC 5280
Maio de 2008
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 conteúdo deste tipo está em conformidade com a RFC 3629.
-- PKIX specific OIDs
es
id-pkix OBJECT IDENTIFIER ::=
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) }
-- PKIX arcs
id-qt
id-kp
id-ad
-- arco para extens~
oes privadas de certificados
-- arco para tipos qualificadores de polı́tica
-- arco de OID para extended key purpose
-- arco para descritores de acesso
nd
id-pe
na
-- policyQualifierIds for Internet policy qualifiers
id-qt-cps OBJECT IDENTIFIER ::= { id-qt 1 }
-- OID para qualificadores de Declaraç~
ao de Práticas
-- de Certificaç~
ao
id-qt-unotice OBJECT IDENTIFIER ::= { id-qt 2 }
-- OID para qualificador de notificaç~
ao de usuário
Er
-- definiç~
oes dos descritores de acesso
id-ad-ocsp
id-ad-caIssuers
id-ad-timeStamping
id-ad-caRepository
OBJECT
OBJECT
OBJECT
OBJECT
IDENTIFIER
IDENTIFIER
IDENTIFIER
IDENTIFIER
::=
::=
::=
::=
{
{
{
{
id-ad
id-ad
id-ad
id-ad
1
2
3
5
}
}
}
}
92
-- tipos de dado de atributo
Attribute
type
values
::= SEQUENCE {
AttributeType,
SET OF AttributeValue }
-- é necessário no mı́nimo um valor
AttributeType
AttributeValue
::= ANY -- DEFINED BY AttributeType
Cooper, et al.
Standards Track
RFC 5280
Maio de 2008
AttributeTypeAndValue ::= SEQUENCE {
type
AttributeType,
value
AttributeValue }
-- Arco para atributos de nome padr~
ao
id-at
es
-- atributos de nome sugeridos: Definiçoes 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
OBJECT IDENTIFIER ::= { joint-iso-ccitt(2) ds(5) 4 }
id-at-name
id-at-surname
id-at-givenName
id-at-initials
id-at-generationQualifier
nd
-- Atributos de nome do tipo X520name
AttributeType
AttributeType
AttributeType
AttributeType
AttributeType
::=
::=
::=
::=
::=
{
{
{
{
{
id-at
id-at
id-at
id-at
id-at
41 }
4 }
42 }
43 }
44 }
Er
na
-- 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
93
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)) }
Cooper, et al.
Standards Track
RFC 5280
Maio de 2008
-- Atributos de nome do tipo X520LocalityName
id-at-localityName
es
-- 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
nd
id-at-stateOrProvinceName
na
-- 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
Er
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)) }
Cooper, et al.
Standards Track
94
RFC 5280
Maio de 2008
-- Atributos de nome do tipo X520OrganizationalUnitName
id-at-organizationalUnitName AttributeType ::= { id-at 11 }
nd
es
-- 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
na
id-at-title AttributeType ::= { id-at 12 }
Er
-- 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)) }
95
-- Atributo de nome do tipo X520dnQualifier
id-at-dnQualifier
X520dnQualifier
::= PrintableString
-- Atributo de nome do tipo X520countryName (digraph do IS 3166)
id-at-countryName
X520countryName
::= PrintableString (SIZE (2))
-- Atributo de nome do tipo X520SerialNumber
Cooper, et al.
Standards Track
id-at-serialNumber
X520SerialNumber
RFC 5280
Maio de 2008
::= PrintableString (SIZE (1..ub-serial-number))
-- Atributo de nome do tipo X520Pseudonym
id-at-pseudonym AttributeType ::= { id-at 65 }
nd
es
-- 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
::= IA5String
na
DomainComponent
AttributeType ::= { 0 9 2342 19200300 100 1 25 }
-- Atributos legados
pkcs-9 OBJECT IDENTIFIER ::=
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 9 }
id-emailAddress
::= IA5String (SIZE (1..ub-emailaddress-length))
Er
EmailAddress
AttributeType ::= { pkcs-9 1 }
-- 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
Cooper, et al.
(SIZE (1..MAX)),
Standards Track
96
printableString
universalString
utf8String
bmpString
RFC 5280
PrintableString
UniversalString
UTF8String
BMPString
(SIZE
(SIZE
(SIZE
(SIZE
Maio de 2008
(1..MAX)),
(1..MAX)),
(1..MAX)),
(1..MAX)) }
-- a estrutura do certificado e da LCR começa neste ponto
extensions
Version
na
subjectUniqueID
SEQUENCE {
[0] Version DEFAULT v1,
Name,
Validity,
Name,
SubjectPublicKeyInfo,
-- quando presente, a vers~
ao DEVE ser v2 ou v3
ao DEVE ser v2 ou v3
[3] Extensions OPTIONAL
ao DEVE ser v3 -- }
nd
TBSCertificate
::=
version
serialNumber
signature
issuer
validity
subject
subjectPublicKeyInfo
issuerUniqueID
es
Certificate
::= SEQUENCE {
tbsCertificate
TBSCertificate,
signatureAlgorithm AlgorithmIdentifier,
signature
BIT STRING }
::= INTEGER { v1(0), v2(1), v3(2) }
CertificateSerialNumber ::= INTEGER
Time
::= SEQUENCE {
Time,
Time }
Er
Validity
notBefore
notAfter
utcTime
generalTime
UniqueIdentifier
::= CHOICE {
UTCTime,
GeneralizedTime }
97
::= BIT STRING
SubjectPublicKeyInfo ::= SEQUENCE {
algorithm
subjectPublicKey
BIT STRING }
Extensions
::= SEQUENCE SIZE (1..MAX) OF Extension
Extension
extnID
critical
::= SEQUENCE {
OBJECT IDENTIFIER,
Cooper, et al.
Standards Track
extnValue
RFC 5280
Maio de 2008
OCTET STRING
-- Contém a codificaç~
ao DER de um valor ASN.1
-- correspondente ao tipo de extens~
ao identificado
-- por extnID
}
-- Estruturas da LCR
SEQUENCE {
TBSCertList,
BIT STRING }
es
CertificateList
::=
tbsCertList
signatureAlgorithm
signature
na
nd
TBSCertList ::= SEQUENCE {
version
Version OPTIONAL,
ao DEVE ser v2
signature
issuer
Name,
thisUpdate
Time,
nextUpdate
Time OPTIONAL,
revokedCertificates SEQUENCE OF SEQUENCE {
userCertificate
revocationDate
Time,
crlEntryExtensions
Extensions OPTIONAL
ao DEVE ser v2
} OPTIONAL,
crlExtensions
[0] Extensions OPTIONAL }
ao DEVE ser v2
-- Version, Time, CertificateSerialNumber, and Extensions s~
ao
-- definidos anteriormente para serem usados na estrutura do certificado
::= SEQUENCE {
OBJECT IDENTIFIER,
ANY DEFINED BY algorithm OPTIONAL }
-- contém o valor de um tipo
-- registrado para uso com o algoritmo
-- de identificador de objeto com valor
-- endereço X.400, a sintaxe começa
-- neste ponto
Er
AlgorithmIdentifier
algorithm
parameters
ORAddress ::= SEQUENCE {
built-in-standard-attributes BuiltInStandardAttributes,
built-in-domain-defined-attributes
BuiltInDomainDefinedAttributes OPTIONAL,
-- veja também teletex-domain-defined-attributes
extension-attributes
ExtensionAttributes OPTIONAL }
-- Atributos padr~
ao embutidos
Cooper, et al.
Standards Track
98
RFC 5280
Maio de 2008
es
BuiltInStandardAttributes
::= SEQUENCE {
country-name
CountryName OPTIONAL,
administration-domain-name
AdministrationDomainName OPTIONAL,
network-address
[0] IMPLICIT NetworkAddress OPTIONAL,
-- veja também extended-network-address
terminal-identifier
[1] IMPLICIT TerminalIdentifier OPTIONAL,
private-domain-name
[2] PrivateDomainName OPTIONAL,
organization-name
[3] IMPLICIT OrganizationName OPTIONAL,
-- veja também teletex-organization-name
numeric-user-identifier [4] IMPLICIT NumericUserIdentifier
OPTIONAL,
personal-name
[5] IMPLICIT PersonalName OPTIONAL,
-- veja também teletex-personal-name
organizational-unit-names [6] IMPLICIT OrganizationalUnitNames
OPTIONAL }
-- veja também teletex-organizational-unit-names
iso-3166-alpha2-code
printable
NetworkAddress
::= X121Address
-- see also extended-network-address
::= NumericString
(SIZE (1..ub-x121-address-length))
Er
X121Address
::= [APPLICATION 2] CHOICE {
NumericString
(SIZE (0..ub-domain-name-length)),
PrintableString
(SIZE
(0..ub-domain-name-length)) }
na
AdministrationDomainName
numeric
::= [APPLICATION 1] CHOICE {
NumericString
(SIZE (ub-country-name-numeric-length)),
PrintableString
(SIZE (ub-country-name-alpha-length)) }
nd
CountryName
x121-dcc-code
TerminalIdentifier
::= PrintableString
(SIZE (1..ub-terminal-id-length))
PrivateDomainName
numeric
::= CHOICE {
NumericString
(SIZE (1..ub-domain-name-length)),
PrintableString
(SIZE (1..ub-domain-name-length)) }
printable
OrganizationName
::= PrintableString
(SIZE (1..ub-organization-name-length))
-- veja também teletex-organization-name
NumericUserIdentifier
Cooper, et al.
::= NumericString
(SIZE (1..ub-numeric-user-id-length))
Standards Track
99
RFC 5280
Maio de 2008
::= SET {
[0] IMPLICIT PrintableString
(SIZE (1..ub-surname-length)),
given-name
(SIZE (1..ub-given-name-length))
OPTIONAL,
initials
(SIZE (1..ub-initials-length))
OPTIONAL,
generation-qualifier
(SIZE
(1..ub-generation-qualifier-length))
OPTIONAL }
-- veja também teletex-personal-name
es
PersonalName
surname
::= SEQUENCE SIZE (1..ub-organizational-units)
OF OrganizationalUnitName
-- veja também teletex-organizational-unit-names
OrganizationalUnitName
nd
OrganizationalUnitNames
::= PrintableString (SIZE
(1..ub-organizational-unit-name-length))
-- Atributos Domain-defined embutidos
na
BuiltInDomainDefinedAttributes ::= SEQUENCE SIZE
(1..ub-domain-defined-attributes) OF
BuiltInDomainDefinedAttribute
Er
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
100
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
Cooper, et al.
INTEGER ::= 1
Standards Track
CommonName
RFC 5280
Maio de 2008
::= 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
teletex-personal-name
es
TeletexOrganizationName ::= TeletexString
(SIZE (1..ub-organization-name-length))
INTEGER ::= 4
nd
TeletexPersonalName ::= SET {
surname
[0] IMPLICIT TeletexString
(SIZE (1..ub-surname-length)),
given-name
(SIZE (1..ub-given-name-length)) OPTIONAL,
initials
(SIZE (1..ub-initials-length)) OPTIONAL,
generation-qualifier [3] IMPLICIT TeletexString
(SIZE (1..ub-generation-qualifier-length))
OPTIONAL }
na
teletex-organizational-unit-names INTEGER ::= 5
TeletexOrganizationalUnitNames ::= SEQUENCE SIZE
(1..ub-organizational-units) OF TeletexOrganizationalUnitName
TeletexOrganizationalUnitName ::= TeletexString
(SIZE (1..ub-organizational-unit-name-length))
INTEGER ::= 7
Er
pds-name
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
printable-code
Cooper, et al.
NumericString
(SIZE (1..ub-postal-code-length)),
PrintableString
Standards Track
101
RFC 5280
Maio de 2008
(SIZE (1..ub-postal-code-length)) }
physical-delivery-office-name INTEGER ::= 10
PhysicalDeliveryOfficeName
::= PDSParameter
physical-delivery-office-number
INTEGER ::= 11
PhysicalDeliveryOfficeNumber ::= PDSParameter
INTEGER ::= 12
es
extension-OR-address-components
ExtensionORAddressComponents ::= PDSParameter
physical-delivery-personal-name
INTEGER ::= 13
PhysicalDeliveryPersonalName ::= PDSParameter
nd
physical-delivery-organization-name INTEGER ::= 14
PhysicalDeliveryOrganizationName ::= PDSParameter
extension-physical-delivery-address-components INTEGER ::= 15
ExtensionPhysicalDeliveryAddressComponents ::= PDSParameter
na
unformatted-postal-address INTEGER ::= 16
Er
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
StreetAddress
INTEGER ::= 17
::= PDSParameter
post-office-box-address
INTEGER ::= 18
102
PostOfficeBoxAddress ::= PDSParameter
poste-restante-address
INTEGER ::= 19
PosteRestanteAddress ::= PDSParameter
unique-postal-name
UniquePostalName
Cooper, et al.
INTEGER ::= 20
::= PDSParameter
Standards Track
local-postal-attributes
RFC 5280
Maio de 2008
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 }
INTEGER ::= 22
es
extended-network-address
nd
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 }
terminal-type
OCTET STRING OPTIONAL,
SET SIZE (1..MAX) OF OCTET STRING }
na
PresentationAddress ::= SEQUENCE {
pSelector
[0] EXPLICIT
sSelector
[1] EXPLICIT
tSelector
[2] EXPLICIT
nAddresses
[3] EXPLICIT
INTEGER ::= 23
Er
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
103
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)) }
Cooper, et al.
Standards Track
especificaç~
oes de Limites Superiores DEVE ser considerados mandatórios
do anexo B da ITU-T X.411 Reference Definition of MTS Parameter
Limites Superiores (Upper Bounds)
Upper Bounds
INTEGER
INTEGER
INTEGER
INTEGER
INTEGER
INTEGER
INTEGER
INTEGER
INTEGER
INTEGER
INTEGER
INTEGER
INTEGER
INTEGER
INTEGER
INTEGER
INTEGER
INTEGER
INTEGER
INTEGER
INTEGER
INTEGER
INTEGER
INTEGER
INTEGER
INTEGER
INTEGER
INTEGER
INTEGER
INTEGER
INTEGER
INTEGER
INTEGER
INTEGER
INTEGER
INTEGER
INTEGER
Er
na
nd
ub-name
ub-common-name
ub-locality-name
ub-state-name
ub-organization-name
ub-organizational-unit-name
ub-title
ub-serial-number
ub-match
ub-emailaddress-length
ub-common-name-length
ub-country-name-alpha-length
ub-country-name-numeric-length
ub-domain-defined-attributes
ub-domain-defined-attribute-type-length
ub-domain-defined-attribute-value-length
ub-domain-name-length
ub-extension-attributes
ub-e163-4-number-length
ub-e163-4-sub-address-length
ub-generation-qualifier-length
ub-given-name-length
ub-initials-length
ub-integer-options
ub-numeric-user-id-length
ub-organization-name-length
ub-organizational-unit-name-length
ub-organizational-units
ub-pds-name-length
ub-pds-parameter-length
ub-pds-physical-address-lines
ub-postal-code-length
ub-pseudonym
ub-surname-length
ub-terminal-id-length
ub-unformatted-address-length
ub-x121-address-length
-------
Maio de 2008
::=
::=
::=
::=
::=
::=
::=
::=
::=
::=
::=
::=
::=
::=
::=
::=
::=
::=
::=
::=
::=
::=
::=
::=
::=
::=
::=
::=
::=
::=
::=
::=
::=
::=
::=
::=
::=
32768
64
128
128
64
64
64
64
128
255
64
2
3
4
8
128
16
256
15
40
3
16
5
256
32
64
32
4
16
30
6
16
128
40
24
180
16
es
-----
RFC 5280
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 necessário 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
Cooper, et al.
Standards Track
104
RFC 5280
Maio de 2008
-- quatro vezes o upper bound deve ser permitido.
END
A.2 Módulo Implicitamente Rotulado, sintaxe 1988
es
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 --
na
nd
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
Er
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
105
KeyIdentifier
::= OCTET STRING
-- OID e sintaxe de subject key identifier
id-ce-subjectKeyIdentifier OBJECT IDENTIFIER ::= { id-ce 14 }
SubjectKeyIdentifier
Cooper, et al.
::= KeyIdentifier
Standards Track
RFC 5280
Maio de 2008
-- OID e sintaxe da extens~
ao key usage
id-ce-keyUsage OBJECT IDENTIFIER
::= { id-ce 15 }
es
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) }
nd
-- 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
na
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
Er
PolicyInformation
::= SEQUENCE {
policyIdentifier CertPolicyId,
policyQualifiers SEQUENCE SIZE (1..MAX) OF
PolicyQualifierInfo OPTIONAL }
CertPolicyId
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
Cooper, et al.
Standards Track
106
CPSuri
RFC 5280
Maio de 2008
::= IA5String
-- user notice qualifier
NoticeReference
::= SEQUENCE {
organization DisplayText,
noticeNumbers SEQUENCE OF INTEGER }
CHOICE {
IA5String
VisibleString
BMPString
UTF8String
(SIZE
(SIZE
(SIZE
(SIZE
(1..200)),
(1..200)),
(1..200)),
(1..200)) }
nd
DisplayText
::=
ia5String
visibleString
bmpString
utf8String
es
UserNotice
::= SEQUENCE {
noticeRef
NoticeReference OPTIONAL,
explicitText
DisplayText
OPTIONAL }
ao policy mapping
id-ce-policyMappings OBJECT IDENTIFIER
::= { id-ce 33 }
na
PolicyMappings
::= SEQUENCE SIZE (1..MAX) OF SEQUENCE {
issuerDomainPolicy CertPolicyId,
subjectDomainPolicy CertPolicyId }
ao subject alternative name
id-ce-subjectAltName OBJECT IDENTIFIER
::= { id-ce 17 }
SubjectAltName ::= GeneralNames
::= SEQUENCE SIZE (1..MAX) OF GeneralName
Er
GeneralNames
GeneralName
::= CHOICE {
otherName
rfc822Name
dNSName
x400Address
directoryName
ediPartyName
uniformResourceIdentifier
iPAddress
registeredID
[0]
[1]
[2]
[3]
[4]
[5]
[6]
[7]
[8]
AnotherName,
IA5String,
IA5String,
ORAddress,
Name,
EDIPartyName,
IA5String,
OCTET STRING,
OBJECT IDENTIFIER }
107
-- AnotherName substitui OTHER-NAME ::= TYPE-IDENTIFIER, já que
-- TYPE-IDENTIFIER n~
ao é suportado na sintaxe ASN.1 de 1988
AnotherName
Cooper, et al.
::= SEQUENCE {
Standards Track
RFC 5280
Maio de 2008
type-id OBJECT IDENTIFIER,
value
[0] EXPLICIT ANY DEFINED BY type-id }
EDIPartyName ::= SEQUENCE {
nameAssigner [0] DirectoryString OPTIONAL,
partyName
[1] DirectoryString }
ao issuer alternative name
::= { id-ce 18 }
es
id-ce-issuerAltName OBJECT IDENTIFIER
IssuerAltName ::= GeneralNames
id-ce-subjectDirectoryAttributes OBJECT IDENTIFIER ::= { id-ce 9 }
SubjectDirectoryAttributes ::= SEQUENCE SIZE (1..MAX) OF Attribute
nd
ao basic constraints
id-ce-basicConstraints OBJECT IDENTIFIER
::= { id-ce 19 }
BasicConstraints ::= SEQUENCE {
cA
pathLenConstraint INTEGER (0..MAX) OPTIONAL }
na
-- 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 }
Er
GeneralSubtrees ::= SEQUENCE SIZE (1..MAX) OF GeneralSubtree
GeneralSubtree ::= SEQUENCE {
base
GeneralName,
minimum
[0] BaseDistance DEFAULT 0,
maximum
[1] BaseDistance OPTIONAL }
BaseDistance ::= INTEGER (0..MAX)
ao policy constraints
id-ce-policyConstraints OBJECT IDENTIFIER
108
::= { id-ce 36 }
PolicyConstraints ::= SEQUENCE {
requireExplicitPolicy [0] SkipCerts OPTIONAL,
inhibitPolicyMapping [1] SkipCerts OPTIONAL }
Cooper, et al.
Standards Track
RFC 5280
Maio de 2008
SkipCerts ::= INTEGER (0..MAX)
ao CRL distribution points
id-ce-cRLDistributionPoints OBJECT IDENTIFIER ::= {id-ce 31}
CRLDistributionPoints ::= SEQUENCE SIZE (1..MAX) OF DistributionPoint
es
DistributionPoint
::= SEQUENCE {
distributionPoint
reasons
cRLIssuer
[2] GeneralNames OPTIONAL }
DistributionPointName ::= CHOICE {
fullName
[0] GeneralNames,
nameRelativeToCRLIssuer [1] RelativeDistinguishedName }
na
nd
ReasonFlags ::= BIT STRING {
unused
(0),
keyCompromise
(1),
cACompromise
(2),
affiliationChanged
(3),
superseded
(4),
(5),
certificateHold
(6),
privilegeWithdrawn
(7),
aACompromise
(8) }
ao extended key usage
id-ce-extKeyUsage OBJECT IDENTIFIER
::= {id-ce 37}
Er
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
id-kp-clientAuth
id-kp-codeSigning
id-kp-emailProtection
id-kp-timeStamping
id-kp-OCSPSigning
OBJECT
OBJECT
OBJECT
OBJECT
OBJECT
OBJECT
IDENTIFIER
IDENTIFIER
IDENTIFIER
IDENTIFIER
IDENTIFIER
IDENTIFIER
::=
::=
::=
::=
::=
::=
{
{
{
{
{
{
id-kp
id-kp
id-kp
id-kp
id-kp
id-kp
1
2
3
4
8
9
}
}
}
}
}
}
-- OID e sintaxe de inhibit any policy
Cooper, et al.
Standards Track
109
RFC 5280
id-ce-inhibitAnyPolicy OBJECT IDENTIFIER
InhibitAnyPolicy
Maio de 2008
::= { id-ce 54 }
::= SkipCerts
ao freshest (delta)CRL
id-ce-freshestCRL
::= { id-ce 46 }
es
FreshestCRL
OBJECT IDENTIFIER
-- authority info access
id-pe-authorityInfoAccess OBJECT IDENTIFIER ::= { id-pe 1 }
nd
AuthorityInfoAccessSyntax ::=
AccessDescription ::= SEQUENCE {
accessMethod
OBJECT IDENTIFIER,
accessLocation GeneralName }
-- subject info access
na
id-pe-subjectInfoAccess OBJECT IDENTIFIER
::= { id-pe 11 }
SubjectInfoAccessSyntax ::=
ao CRL number
id-ce-cRLNumber
::= { id-ce 20 }
Er
CRLNumber
OBJECT IDENTIFIER
ao issuing distribution point
id-ce-issuingDistributionPoint OBJECT IDENTIFIER ::= { id-ce 28 }
IssuingDistributionPoint ::= SEQUENCE {
distributionPoint
onlyContainsUserCerts
onlyContainsCACerts
onlySomeReasons
indirectCRL
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 }
Cooper, et al.
Standards Track
110
RFC 5280
Maio de 2008
BaseCRLNumber ::= CRLNumber
ao reason code
nd
CRLReason ::= ENUMERATED {
unspecified
(0),
keyCompromise
(1),
cACompromise
(2),
affiliationChanged
(3),
superseded
(4),
cessationOfOperation (5),
certificateHold
(6),
removeFromCRL
(8),
privilegeWithdrawn
(9),
aACompromise
(10) }
::= { id-ce 21 }
es
id-ce-cRLReasons OBJECT IDENTIFIER
ao certificate issuer CRL entry
id-ce-certificateIssuer OBJECT IDENTIFIER
::= { id-ce 29 }
CertificateIssuer ::= GeneralNames
na
ao hold instruction
id-ce-holdInstructionCode OBJECT IDENTIFIER ::= { id-ce 23 }
HoldInstructionCode ::= OBJECT IDENTIFIER
-- Arco
holdinstruction do ANSI x9
Er
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}
ao invalidity date CRL entry
id-ce-invalidityDate OBJECT IDENTIFIER
Cooper, et al.
::= { id-ce 24 }
Standards Track
111
RFC 5280
Maio de 2008
InvalidityDate ::= GeneralizedTime
END
Apêndice B. Notas ASN.1
es
As ACs DEVEM forçar o número serialNumber ser um número inteiro não-negativo, ou
seja, o bit sign na codificação DER do valor INTEGER DEVE ser zero. Isso pode ser
feito um octeto lider (mais a esqueda) ‘00’H se necessário. Isso remove uma ambiguidade
potencial no mapeamento entre um string de octetos e um valor inteiro.
Como observado na seção 4.1.2.2, números seriais poder conter inteiros longos. Os usuários
de certificado DEVEM ser capazes de manipular valores de serialNumber de até 20 octetos. Emissores de LCR em conformidade NÃO DEVEM usar cRLNumber maiores que 20
octetos.
nd
O construtor “SEQUENCE SIZE (1..MAX) OF” aparece em diversos construtores ASN.1.
Uma sequência válida terá 0 ou mais entradas. O construtor SIZE (1..MAX) restringe a
sequência a ter no mı́nimo uma entrada. MAX indica que o upper bound não é especificado.
As implementações ficam livres para a escolha de um limite superior apropriado aos seus
ambientes.
na
O tipo caractere string PrintableString suporta um conjunto bem básico de Latin: as letras
minúsculas de ‘a’ a ‘z’, as letras miúsculas de ´A’ a ‘Z’, os dı́gitos de ‘0’ a ‘9’, onze caracteres
especiais ´ = ( ) + , - . / : ? e espaço.
Er
Os implementadores devem observar que caracteres sinal ‘em’ (´@’) e underscore (‘ ’) não
são suportados pelo tipo ASN.1 PrintableString. Esses caracteres normalmente aparecem
em endereços Internet. Tais endereços DEVEM ser codificados usando um tipo ASN.1 que
os suporte. Eles são codificados geralmente como IA5String nos atributos emailAddress
com um distinguished name ou campo rfc822Name do GeneralName. Implementações em
conformidade NÃO DEVEM codificar strings que incluem esses caracteres como PrintableString.
O tipo caracter string TeletexSring é um superconjunto de PrintableString. TeletexString
suporta um padrão relativo (ASCII-afins) do conjunto de caracteres Latin: caracteres Latin
com acentos não espaçados e caracteres japoneses.
Listas de bit nomeados são do tipo BIT STRINGs onde os valores estão associados a nomes.
Esta especificação faz uso de listas de bit nomeados nas definições das extensões key usage,
CRL distribution points, e extensão de certificado freshest CRL, assim como nas definições
de extensão de LCR freshest CRL e issuing distribution point. Quando o DER codifica uma
lista de bit nomeados, os últimos zeros DEVEM ser omitidos. Ou seja, o valor codificado
encerra com o último 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).
Cooper, et al.
Standards Track
112
RFC 5280
Maio de 2008
O tipo caractere string UTF8String foi introduzido na versão 1997 do ASN.1, e UTF8String
foi adicionado na lista de escolhas do DirectoryString na versão 2001 de [X.520]. UTF8String
é um tipo universal e tem sido atribuı́do o número da etiqueta 12. O conteúdo de UTF8String
foi definido na RFC 2044 e atualizado pela RFC 2279, que foi atualizada em [RFC3629].
Em antecipação a estas mudanças, e em conformidade com as melhores práticas IETF
codificada em [RFC2277, IETF Policy on Character Sets and Languages, este documento
inclui UTF8String como uma das escolhas em DirectoryString e no qualificador userNotice
certificate policy.
nd
es
Para muito dos tipos de atributo definidos em [X.520], o AtributeValue usa o tipo DirectoryString. Dos atributos especificados no Apêndice A, todos os atributos name, surname,
givenName, initials, generationQualifier, commonName, localityName, stateOrProvinceName, organizationName, organizationUnitName, title, e pseudonym usam tipo DirectoryString. X.520 usa uma definição de tipo parametrizada [X.683] de DirectoryString
para especificar a sintaxe de cada um desses atributos. O parâmetro é usado para indicar o
tamanho do string permitido no atributo. No Apêndice A, para evitar o uso de definição de
tipo parametrizada, o tipo DirectoryString é escrito em sua forma expandida na definição
de cada um desses tipos de atributo. Assim, o ASN.1 no Apêndice A descreve a sintaxe
para cada um desses atributos como sendo uma CHOICE of TeletexString, PrintableString, UniversalString, UTF8String, e BMPString, com as restrições apropriadas para para
o tamanho do string de cada um dos tipos da CHOICE, ao invés de usar o tipo ASN.1
DirectoryString para descrever a sintaxe.
na
Os implementadores deveriam observar que a codificação DER de valores SET OF necessita a ordenação das codificações dos valores. Em particular, esta questão diz respeito aos
nomes distintos (distinguished names).
Os implementadores deveriam observar que a codificação DER dos componentes SET ou
SEQUENCE cujo valor é DEFAULT omite o componente no certificado ou LCR codificada.
Por exemplo, a extensão BasicConstraints cujo valor booleano cA é falso, omitira o valor
booleano cA do certificado codificado.
Er
Os Identificadores de Objetos (OIDs) são utilizados nesta especificação para identificação
de polı́ticas de certificados, chave pública e algoritmos de assinatura, extensões de certificado, etc. Não existe um número máximo para OIDs. Esta especificação exige suporte
aos OIDs que possuem elementos de arco com valores que são menores que 2ˆ28, ou seja,
eles DEVEM estar entre 0 e 268.435,455, inclusive. Isto permite que o elemento do arco
seja representado em um palavre de 32 bits. As implementações DEVEM também suportar
OIDs onde o tamanho de decimais pontuados (ver seção1.4 de [RFC4512]) representados
em string possa ser de até 100 bytes (inclusive). As implementações DEVEM ser capazes de
tratar OIDs com até 20 elementos (inclusive). As ACs NÃO DEVERIAM emitir certificados que contenham OIDs que excedam esses requisitos. De maneira semelhante, emissores
de LCR NÃO DEVERIAM emitir LCRs que contenham OIDs que excedam esses requisitos.
As regras para contexto especı́ficdo de codificação de valores de campo GeneralName na extensão nameConstraints diferem das regras que se aplicam às outras extensões. Em todas as
outras extensões de certificado, LCR, e extensões de entrada LCR, especificadas no presente
documento, as regras de codificação estão de acordo com as regras para o tipo subjacente.
Por exemplo, valores no campo uniformResourceIdentifier devem conter um valor URI conCooper, et al.
Standards Track
113
RFC 5280
Maio de 2008
forme especificado em [RFC3986]. As regras especı́ficas para contexto usadas para codificar
valores na extensão nameConstraints são especificadas na seção 4.2.1.10, e essas regras podem não estar em conformidade com as regras usadas nos tipos subjecentes. Por exemplo,
quando um campo uniformResourceIdentifier aparece em uma extensão nameConstraints,
ele deve conter um nome DNS (ex: “host.example.com” ou “example.com”) ao invés da URI.
es
Os implementadores são avisados que a comunidade de padrões X.500 desenvolveu uma
série de regras de extensibilidade. Essas regras determinam quando uma definição ASN.1
pode ser modificada sem a atribuição de um novo Identificador de Objeto (OID). Por
exemplo, no mı́nimo duas definições de extensão incluı́das em [RFC2459], o predecessor
deste documento de perfil, possuem definições ASN.1 diferentes nesta especificação, mas
o mesmo OID é utilizado. Se elementos desconhecidos aparecerem em uma extensão, e
a extensão não estiver marcada como crı́tica, aqueles elementos desconhecidos podem ser
ignorados, da seguinte forma:
(a) ignore todo bit desconhecido atribuı́do dentro de um bit string;
nd
(b) ignore todos os números nomeado em um tipo ENUMERATE ou tipo INTEGER
que esta sendo usado no estilo enumerado, desde que o número ocorra como um
elemento opcional de um SET ou SEQUENCE; e
(c) ignore todos os elementos desconhecidos em SETs, no final de SEQUENCEs, ou em
CHOICEs onde a CHOICE é um elemento opcional de um SET ou SEQUENCE.
na
Se uma extensão contendo um valor não esperado é marcada como crı́tica, a implementação
DEVE rejeitar o certificado ou LCR que contenha a extensão não reconhecida.
Apêndice C. Exemplos
Este anexo contém quatro exemplos: três certificados e uma CRL. Os dois primeiros certificados e a CRL compreendem um caminho de certificação mı́nima.
Er
O Apêndice C.1 contém um hexadecimal comentado de um certificado “auto-assinado” emitido por uma AC cujo nome distinto é cn=Example CA, dc=example, dc=com. O certificado contém uma chave RSA pública, e é assinado pela chave RSA privada correspondente.
O Apêndice C.2 contém um hexadecimal comentado de um certificado de entidade final.
O certificado de entidade final contém uma chave RSA pública, e é assinado pela chave
privada correspondente ao certificado “auto-assinado” do Apêndice C.1.
O Apêndice C.3 contém um hexadecimal comentado de um certificado de entidade final
que contém uma chave pública DSA com parâmetros, e é assinado com DSA e SHA-1. Este
certificado não é parte do caminho de certificação mı́nimo.
O Apêndice C.4 contém um hexadecimal comentado de uma LCR. A LCR é emitida pela
AC cujo nome distinto é cn=Example CA, dc=example, dc=com, e a lista de certificados
revogados inclui o certificado de entidade final apresentado no Apêndice C.2.
O certificado foi processado usando o utilitário dumpsan1 de Peter Gutmann para gerar a
saı́da. O fonte para o utilitário dumpasn1 está disponı́vel em <http://www.cs.auckland.ac.nz/
˜pgut001/dumpasn1.c>. Os binários para os certificados e LCRs estão disponı́veis em
Cooper, et al.
Standards Track
114
RFC 5280
Maio de 2008
http://csrc.nist.gov/groups/ST/crypto apps infra/documents/pkixtools.
Nos locais deste apêndice onde nomes distintos são especificados usando representação
string, os strings são formados usando as regras especificadas em [RFC4514].
C.1 Certificado “auto-assinado” RSA
Este apêndice contem uma imagem hexadecimal comentada de um certificado de 578 bytes
versão 3. O certificado contém as seguintes informações
es
(a) o número 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;
nd
(e) o certificado foi emitido em 30 de abril de 2004, e expirado em 30 de abril de 2005;
(f) o certificado contém uma chave pública RSA de 1024 bit;
(g) o certificado contém uma extensão subject key identifier gerada com o método (1)
da seção 4.2.1.2; e
13
16
18
29
31
33
35
37
49
54
56
58
70
574: SEQUENCE {
423:
SEQUENCE {
3:
[0] {
1:
INTEGER 2
:
}
1:
INTEGER 17
13:
SEQUENCE {
9:
OBJECT IDENTIFIER
:
sha1withRSAEncryption (1 2 840 113549 1 1 5)
0:
NULL
:
}
67:
SEQUENCE {
19:
SET {
17:
SEQUENCE {
10:
OBJECT IDENTIFIER
:
domainComponent (0 9 2342 19200300 100 1 25)
3:
IA5String ‘com’
:
}
:
}
23:
SET {
21:
SEQUENCE {
10:
OBJECT IDENTIFIER
:
7:
IA5String ‘example’
Er
0
4
8
10
na
(h) O certificado é um certificado de AC (como indicado através da extensão basic
constraints).
Cooper, et al.
Standards Track
115
150
155
157
159
171
180
182
184
189
201
204
206
217
219
223
226
es
}
SET {
SEQUENCE {
OBJECT IDENTIFIER commonName (2 5 4 3)
PrintableString ‘Example CA’
}
}
}
SEQUENCE {
UTCTime 30/04/2004 14:25:34 GMT
UTCTime 30/04/2005 14:25:34 GMT
}
SEQUENCE {
SET {
SEQUENCE {
OBJECT IDENTIFIER
domainComponent (0 9 2342 19200300 100
IA5String ‘com’
}
}
SET {
SEQUENCE {
OBJECT IDENTIFIER
}
}
SET {
SEQUENCE {
}
}
}
SEQUENCE {
SEQUENCE {
OBJECT IDENTIFIER
rsaEncryption (1 2 840 113549 1 1 1)
NULL
}
BIT STRING, encapsulates {
SEQUENCE {
INTEGER
00 C2 D7 97 6D 28 70 AA 5B CF 23 2E 80
DB 6F D5 2D D5 6A 4F 7A 34 2D F9 22 72
EF 80 E9 CA 30 8C 00 C4 9A 6E 5B 45 B4
6C 94 0D FA 91 E9 40 FC 25 9D C7 B7 68
11 70 6A D7 F1 C9 11 4F 3A 7E 3F 99 8D
74 5F 5E A4 55 53 E5 C7 68 36 53 C7 1D
nd
132
134
136
138
}
1 25)
1 25)
na
100
102
117
Maio de 2008
Er
79
81
83
88
:
:
19:
17:
3:
10:
:
:
:
30:
13:
13:
:
67:
19:
17:
10:
:
3:
:
:
23:
21:
10:
:
7:
:
:
19:
17:
3:
10:
:
:
:
159:
13:
9:
:
0:
:
141:
137:
129:
:
:
:
:
:
:
RFC 5280
Cooper, et al.
Standards Track
70
47
6E
19
6E
3B
39
70
A5
56
76
12
EE
1D
E6
8F
A5
A6
116
Maio de 2008
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
INTEGER 65537
}
}
na
nd
es
}
[3] {
SEQUENCE {
SEQUENCE {
OBJECT IDENTIFIER subjectKeyIdentifier (2 5 29 14)
OCTET STRING, encapsulates {
OCTET STRING
08 68 AF 85 33 C8 39 4A 7A F8 82 93 8E 70 6A 4A
20 84 2C 32
}
}
SEQUENCE {
OBJECT IDENTIFIER keyUsage (2 5 29 15)
BOOLEAN TRUE
BIT STRING 1 unused bits
‘0000011’B
}
}
SEQUENCE {
OBJECT IDENTIFIER basicConstraints (2 5 29 19)
BOOLEAN TRUE
SEQUENCE {
BOOLEAN TRUE
}
}
}
}
}
}
SEQUENCE {
OBJECT IDENTIFIER
NULL
}
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
Er
:
:
:
358
3:
:
:
:
363
66:
365
64:
367
29:
369
3:
374
22:
376
20:
:
:
:
:
398
14:
400
3:
405
1:
408
4:
410
2:
:
:
:
414
15:
416
3:
421
1:
424
5:
426
3:
428
1:
:
:
:
:
:
:
43 1 13:
433
9:
:
444
0:
:
446 129:
:
:
:
:
:
:
:
RFC 5280
Cooper, et al.
Standards Track
117
:
:
RFC 5280
Maio de 2008
F3 FA 91 81 3C 92 BB C5 5F 25 25 EB 7C E7 D8 A1
}
C.2 Certificado de Entidade Final Usando RSA
es
(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 válido de 15 de setembro de 2004, até 15 de março de 2005;
nd
(f) o certificado contém uma chave pública RSA de 1024 bit;
(g) o certificado é um certificado de entidade final, assim, a extensão basic constrains
não está presente;
(h) o certificado contém a extensão authority key identifier correspondendo ao subject
key identifier do certificado do apêndice C.1; e
na
(i) o certificado inclui um nome alternativo – um endereço de correio eletrônico (rfc822Name)
de “[email protected]”.
(j) O certificado é um certificado de AC (como indicado na extensão basic constraints).
13
16
18
29
31
33
35
37
49
54
56
625: SEQUENCE {
474:
SEQUENCE {
3:
[0] {
1:
INTEGER 2
:
}
1:
INTEGER 18
13:
SEQUENCE {
9:
OBJECT IDENTIFIER
:
0:
NULL
:
}
67:
SEQUENCE {
19:
SET {
17:
SEQUENCE {
10:
OBJECT IDENTIFIER
:
3:
IA5String ‘com’
:
}
:
}
23:
SET {
21:
SEQUENCE {
Er
0
4
8
10
Cooper, et al.
Standards Track
118
132
134
136
138
150
155
157
159
171
180
182
184
189
201
204
206
217
219
223
226
es
100
102
117
}
SET {
SEQUENCE {
}
}
}
SEQUENCE {
UTCTime 15/09/2004 11:48:21 GMT
UTCTime 15/03/2005 11:48:21 GMT
}
SEQUENCE {
SET {
SEQUENCE {
OBJECT IDENTIFIER
IA5String ‘com’
}
}
SET {
SEQUENCE {
OBJECT IDENTIFIER
}
}
SET {
SEQUENCE {
PrintableString ‘End Entity’
}
}
}
SEQUENCE {
SEQUENCE {
OBJECT IDENTIFIER
rsaEncryption (1 2 840 113549 1 1 1)
NULL
}
SEQUENCE {
INTEGER
00 E1 6A E4 03 30 97 02 3C F4 10 F3 B5
14 7B F6 F5 D0 78 E9 A4 8A F0 A3 75 EC
96 7F 88 99 85 9A F2 3E 68 77 87 EB 9E
nd
79
81
83
88
OBJECT IDENTIFIER
}
na
70
10:
:
7:
:
:
19:
17:
3:
10:
:
:
:
30:
13:
13:
:
67:
19:
17:
10:
:
3:
:
:
23:
21:
10:
:
7:
:
:
19:
17:
3:
10:
:
:
:
159:
13:
9:
:
0:
:
141:
137:
129:
:
:
:
Maio de 2008
1 25)
1 25)
Er
58
RFC 5280
Cooper, et al.
Standards Track
1E 4D 7F
ED B6 56
D1 9F C0
119
433
435
440
442
444
466
468
473
476
478
AB
AA
E9
32
8B
89
E3
1A
B2
21
23
1A
B6
7B
58
A4
49
C1
D5
14
1D
09
0C
AA
13
7E
F4
53
CF
4C
16
4B
8B
01
46
23
26
6C
14
A3
4C
DB
FC
C6
9A
4F
27
2F
12
F2
A8
67
7A
EC
16
4D
30
43
13
95
F5
82
EC
F2
FF
65537
}
es
}
[3] {
SEQUENCE {
SEQUENCE {
OBJECT IDENTIFIER subjectAltName (2 5 29 17)
SEQUENCE {
[1] ‘[email protected]’
}
}
}
SEQUENCE {
OCTET STRING
17 7B 92 30 FF 44 D6 66 E1 90 10 22 6C 16 4F C0
8E 41 DD 6D
}
}
SEQUENCE {
OBJECT IDENTIFIER
authorityKeyIdentifier (2 5 29 35)
SEQUENCE {
[0]
08 68 AF 85 33 C8 39 4A 7A F8 82 93 8E 70 6A
4A 20 84 2C 32
}
}
}
SEQUENCE {
BOOLEAN TRUE
‘11’B
}
}
}
}
}
nd
402
404
409
411
DC
7C
4A
7E
7A
na
363
365
367
369
374
376
378
B4 17
31 B8
12 01
33 36
2D 14
23
INTEGER
}
Maio de 2008
Er
358
:
:
:
:
:
:
3:
:
:
:
117:
115:
33:
3:
26:
24:
22:
:
:
:
29:
3:
22:
20:
:
:
:
:
31:
3:
:
24:
22:
20:
:
:
:
:
:
14:
3:
1:
4:
2:
:
:
:
:
:
:
RFC 5280
Cooper, et al.
Standards Track
120
482
484
495
497
13:
9:
:
0:
:
129:
:
:
:
:
:
:
:
:
:
RFC 5280
SEQUENCE {
OBJECT IDENTIFIER
sha1withRSAEncryption
NULL
}
BIT STRING
00 20 28 34 5B 68 32 01
1A E1 04 CF AE AD C7 62
3D D9 1E C0 00 DC 10 A0
4C 63 81 26 5E D2 80 45
26 4A 9C 3B F2 26 36 69
61 8B A1 AB 91 64 E0 F3
B2 BF 73 D4 4D E4 58 E4
CE 84 60 76 E9 73 BB C7
}
Maio de 2008
(1 2 840 113549 1 1 5)
BB
14
BA
5E
08
37
62
85
0A
A4
85
33
79
61
EA
D3
36
1B
6F
E7
BB
3C
BC
91
0E
36
41
70
FB
1A
20
45
AD
31
CB
45
96
A3
74
EA
71
C0
62
3B
43
A4
92
62
C5
E2
7A
39
77
C9
86
5D
es
95
0C
B7
3B
4B
8A
0E
CD
nd
C.3 Certificado de Entidade Final Usando DSA
(b) o certificado é assinado com DSA e algoritmo de hash SHA-1;
na
(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 contém uma chave pública DSA de 1024 bit com parâmetros;
Er
(g) o certificado é um certificado de entidade final (não um certificado de AC);
(h) o certificado inclui um subject alternative name de
“<http://www.example.com/users/DSAendentity.html>” e um alternative name
de “<http://www.examplo.com>” – ambos são URLs;
(i) O certificado inlcui uma extensão authority key identifier e uma extensão certificate
policies especificando o OID da polı́tica 2.16.840.1.101.3.2.1.48.9; e
(j) o certificado inclui uma extensão crı́tica key usage especificando que a chave pública
se destina a verificação de assinaturas digitais.
0
4
8
10
13
17
910: SEQUENCE {
846:
SEQUENCE {
3:
[0] {
1:
INTEGER 2
:
}
2:
INTEGER 256
9:
SEQUENCE {
Cooper, et al.
121
Standards Track
67
76
78
80
85
101
103
118
133
135
137
139
151
156
158
160
172
181
183
185
190
es
51
53
55
Cooper, et al.
4 3)
1 25)
1 25)
nd
46
Maio de 2008
OBJECT IDENTIFIER dsaWithSha1 (1 2 840 10040
}
SEQUENCE {
SET {
SEQUENCE {
OBJECT IDENTIFIER
IA5String ‘com’
}
}
SET {
SEQUENCE {
OBJECT IDENTIFIER
}
}
SET {
SEQUENCE {
PrintableString ‘Example DSA CA’
}
}
}
SEQUENCE {
UTCTime 02/05/2004 16:47:38 GMT
UTCTime 02/05/2005 16:47:38 GMT
}
SEQUENCE {
SET {
SEQUENCE {
OBJECT IDENTIFIER
IA5String ‘com’
}
}
SET {
SEQUENCE {
OBJECT IDENTIFIER
}
}
SET {
SEQUENCE {
PrintableString ‘DSA End Entity’
}
}
}
na
28
30
32
34
7:
:
71:
19:
17:
10:
:
3:
:
:
23:
21:
10:
:
7:
:
:
23:
21:
3:
14:
:
:
:
30:
13:
13:
:
71:
19:
17:
10:
:
3:
:
:
23:
21:
10:
:
7:
:
:
23:
21:
3:
14:
:
:
:
Er
19
RFC 5280
Standards Track
1 25)
1 25)
122
Er
514
518
es
382
SEQUENCE {
SEQUENCE {
OBJECT IDENTIFIER dsa (1 2 840 10040 4 1)
SEQUENCE {
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
INTEGER
00 B2 0D B0 B1 01 DF 0C 66 24 FC 13 92 BA 55 F7
7D 57 74 81 E5
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
}
}
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
}
}
[3] {
SEQUENCE {
SEQUENCE {
OBJECT IDENTIFIER subjectAltName (2 5 29 17)
SEQUENCE {
[6]
‘http://www.example.com/users/DSAendentity.’
‘html’
nd
359
439:
300:
7:
287:
129:
:
:
:
:
:
:
:
:
:
21:
:
:
129:
:
:
:
:
:
:
:
:
:
:
:
132:
128:
:
:
:
:
:
:
:
:
:
:
202:
199:
57:
3:
50:
48:
46:
:
:
Maio de 2008
na
206
210
214
223
227
RFC 5280
649
652
655
657
662
664
666
Cooper, et al.
Standards Track
123
787
789
791
813
815
820
822
824
826
838
840
845
848
850
}
es
}
SEQUENCE {
OBJECT IDENTIFIER issuerAltName (2 5 29 18)
SEQUENCE {
[6] ‘http://www.example.com’
}
}
}
SEQUENCE {
OCTET STRING
DD 25 66 96 43 AB 78 11 43 44 FE 95 16 F9 D9 B6
B7 02 66 8D
}
}
SEQUENCE {
OBJECT IDENTIFIER
SEQUENCE {
[0]
86 CA A5 22 81 62 EF AD 0A 89 BC AD 72 41 2C
29 49 F4 86 56
}
}
}
SEQUENCE {
OBJECT IDENTIFIER certificatePolicies (2 5 29 32)
SEQUENCE {
SEQUENCE {
OBJECT IDENTIFIER ‘2 16 840 1 101 3 2 1 48 9’
}
}
}
}
SEQUENCE {
BOOLEAN TRUE
‘1’B (bit 0)
}
}
}
nd
780
782
}
na
749
751
756
758
Maio de 2008
Er
714
716
721
723
725
:
:
:
33:
3:
26:
24:
22:
:
:
:
29:
3:
22:
20:
:
:
:
:
31:
3:
:
24:
22:
20:
:
:
:
:
:
23:
3:
16:
14:
12:
10:
:
:
:
:
14:
3:
1:
4:
2:
:
:
:
:
:
RFC 5280
Cooper, et al.
}
124
Standards Track
865
868
870
892
Maio de 2008
:
}
9: SEQUENCE {
7:
OBJECT IDENTIFIER dsaWithSha1 (1 2 840 10040 4 3)
:
}
47: BIT STRING, encapsulates {
44:
SEQUENCE {
20:
INTEGER
:
65 57 07 34 DD DC CA CC 5E F4 02 F4 56 42 2C 5E
:
E1 B3 3B 80
20:
INTEGER
:
60 F4 31 17 CA F4 CF FF EE F4 08 A7 D9 B2 61 BE
:
B1 C3 DA BF
:
}
:
}
: }
nd
C.4 Lista de Certificados Revogados
es
854
856
RFC 5280
23
25
27
29
31
43
48
50
52
64
73
352: SEQUENCE {
202:
SEQUENCE {
1:
INTEGER 1
13:
SEQUENCE {
9:
OBJECT IDENTIFIER
:
0:
NULL
:
}
67:
SEQUENCE {
19:
SET {
17:
SEQUENCE {
10:
OBJECT IDENTIFIER
:
3:
IA5String ‘com’
:
}
:
}
23:
SET {
21:
SEQUENCE {
10:
OBJECT IDENTIFIER
:
7:
:
}
:
}
19:
SET {
Er
0
4
7
10
12
na
Este apêndice contém uma imagem hexadecimal comentada de uma LCR versão 2 com duas
extensões (cRLNumber e authorityKeyIdentifier). A LCR foi emitida por cn=Example
CA,dc=example,dc=com em 5 de ferereiro de 2005; a próxima emissão agendada era 6
de fevereiro de 2005. A LCR inclui um certificado revogado: serial number 18, que foi
revogado em 19 de novembro de 2004 devido a keyCompromise. A LCR propriamente dita
tem número 12, e foi assinada com RSA e SHA-1.
125
Cooper, et al.
Standards Track
171
173
175
197
199
204
206
209
211
222
224
es
}
UTCTime 05/02/2005 12:00:00 GMT
UTCTime 06/02/2005 12:00:00 GMT
SEQUENCE {
SEQUENCE {
INTEGER 18
UTCTime 19/11/2004 15:57:03 GMT
SEQUENCE {
SEQUENCE {
OBJECT IDENTIFIER cRLReason (2 5 29 21)
ENUMERATED 1
}
}
}
}
}
[0] {
SEQUENCE {
SEQUENCE {
OBJECT IDENTIFIER
SEQUENCE {
[0]
08 68 AF 85 33 C8 39 4A 7A F8 82 93 8E 70 6A
4A 20 84 2C 32
}
}
}
SEQUENCE {
OBJECT IDENTIFIER cRLNumber (2 5 29 20)
INTEGER 12
}
}
}
}
}
SEQUENCE {
OBJECT IDENTIFIER
NULL
}
BIT STRING
nd
160
162
164
166
SEQUENCE {
}
}
na
94
109
124
126
128
131
146
148
150
155
157
17:
3:
10:
:
:
:
13:
13:
34:
32:
1:
13:
12:
10:
3:
3:
1:
:
:
:
:
:
47:
45:
31:
3:
:
24:
22:
20:
:
:
:
:
:
10:
3:
3:
1:
:
:
:
:
:
13:
9:
:
0:
:
129:
Maio de 2008
Er
75
77
82
RFC 5280
126
Cooper, et al.
Standards Track
22
76
1F
92
A3
E7
72
C1
DC
23
EE
F8
4C
2B
6A
A6
18
B4
90
9F
25
62
CB
AF
7D
81
17
10
38
E2
CE
C1
F7
6E
A2
12
15
2B
7A
55
08
B5
6F
27
FF
C3
ED
17
CE
6D
60
AF
00
46
67
A2
CC
BE
E4
4A
FD
80
99
33
75
0E
BD
D4
3E
EF
8B
4C
Maio de 2008
D0
FB
AA
2F
7E
78
6E
D6
D0
15
8C
85
EE
82
70
06
6A
14
55
E2
3D
D1
81
98
9B
6C
DE
36
26
15
7D
2B
AD
C8
8E
44
12
C6
43
A4
10
17
84
7D
EB
D0
42
FC
F4
6D
6F
AA
D8
9C
74
2E
}
es
:
:
:
:
:
:
:
:
:
RFC 5280
Endereço dos Autores
na
Stefan Santesson
Microsoft
One Microsoft Way
Redmond, WA 98052
USA
EMail: [email protected]
nd
National Institute of Standards and Technology
100 Bureau Drive, Mail Stop 8930
Gaithersburg, MD 20899-8930
USA
Er
Stephen Farrell
Distributed Systems Group
Computer Science Department
Trinity College Dublin
Ireland
Sharon Boeyen
Entrust
1000 Innovation Drive
Ottawa, Ontario
Canada K2K 3E7
Russell Housley
Vigil Security, LLC
918 Spring Knoll Drive
Herndon, VA 20170
USA
Cooper, et al.
Standards Track
127
RFC 5280
Maio de 2008
es
Tim Polk
National Institute of Standards and Technology
100 Bureau Drive, Mail Stop 8930
Gaithersburg, MD 20899-8930
USA
Declaração Plena de Propriedade Direitos Autorais
Copyright (C) The IETF Trust (2008).
nd
Este documento está sujeito aos direitos, licenças e restrições contidas em BCP 78, e exceto
o estabelecido no documento referenciado, os autores conservam todos os seus direitos.
na
Este documento e as informações aqui contidas são fornecidas por uma base “COMO ESTÁ”
e O COLABORADOR, A ORGANIZAÇÃO QUE ELA(E) REPRESENTA OU É PATROCINADO (SE ALGUMA), A INTERNET SOCIETY, O IETF TRUST E O INTERNET
ENGINEERING TASK FORCE REJEITAM TODAS AS GARANTIAS, EXPRESSAS
OU IMPLÍCITAS, INCLUINDO, MAS NÃO LIMITADO A QUALQUER GARANTIA
QUE O USO DA INFORMAÇÃO AQUI CONTIDA NÃO INFRINGIRÁ QUAISQUER
DIREITOS OU QUAISQUER GARANTIAS DE COMERCIALIZAÇÃO OU ADEQUAÇÃO PARA UM DETERMINADO PROPÓSITO.
Propriedade Intelectual
Er
O IETF não toma posição quanto à validade ou âmbito de qualquer Direitos de Propriedade
Intelectual ou outros direitos que podem ser reclamados à figura da execução ou utilização da tecnologia descrita nesse documento ou à medida em que qualquer licença sob tais
direitos pode ou não estar disponı́vel; nem representa que ele tenha feito qualquer esforço
independente para identificar quaisquer tipo de direitos. Informações sobre os procedimentos no que diz respeito aos direitos dos documentos RFC podem encontradas no BCP 78 e
BCP 79.
Cópias de divulgações IPR feitas para a Secretaria do IETF e quaisquer garantias de licenças a ser disponibilizado, ou o resultado de uma tentativa de obtenção de uma licença
ou autorização geral para a utilização de tais direitos proprietários pelos implementadores
ou usuários da presente especificação, podem ser obtidas a partir do repositório on-line do
IETF em http://www.ietf.org/ipr.
O IETF convida qualquer parte interessada, para trazer ao seu conhecimento, qualquer
direitos de autor, patentes ou pedidos de patentes, ou outros direitos de propriedade que
Cooper, et al.
Standards Track
128
RFC 5280
Maio de 2008
Er
na
nd
es
podem abranger tecnologia que possam ser necessárias para a implementação desta norma.
Favor enviar as informações para o IETF em [email protected].
Cooper, et al.
Standards Track
129

Ernandes

Transcrição

Documentos relacionados

Empresas do Simples com mais de cinco funcionários devem usar

EUROTRONICS QM 201 - Português INMETRO

Extensão de garantia para nobreaks e estabiliz... http://www.sms

PROCURAÇÃO PARA O CERTIFICADO DE NFE Cidade, data

Instituto Brasileiro do Meio Ambiente e dos Recursos Naturais

Eduardo Pedro Krupa

Ramos Treuhanddienste

Instituto Brasileiro do Meio Ambiente e dos Recursos

Janine Schneiders - PET Computação

Certificado - VI MEPT - Instituto Federal Farroupilha