C2 - Roteiro 3
Programa de Extensão da UnB em Criptografia e Segurança Computacional
C2- Infraestrutura de Chaves Públicas
Módulo 3 de 6 - 6 horas - pre-requisito: Curso C1, C.2 Módulos 1 a 2
Roteiro de Aulas (em construção)
copyleft - Pedro Antonio Dourado de Rezende
primeiro módulo Introdução, ASN.1, BER e DER
segundo módulo PKCS#1v2.1, PKCS#8
Roteiro Terceiro Módulo
O roteiro deste módulo seguirá o conteúdo do capítulo 7 do texto de referência do curso [0], com refinamentos do documento IETF RFC 3280 [6] (revisando o RFC 2459, citado em [0]), que discute os padrões e formatos aqui em foco para uso na Internet. Do texto de referência, merece nesse ponto a atenção do aluno o capítulo 1, que organiza a compreesão e leitora do mesmo. O material dos capítulos 2, 3 e 4 é abordado e o dos capítulos 5 e 6 é, geralmente, em parte comentado no curso C1.
Havendo que ser o escopo do curso C2 compatível com sua carga horária, priorizou-se a abordagem bottom up dos padrões e formatos das ICPs para sua parte expositiva, motivo pelo qual o material deste terceiro módulo inicia-se com o capítulo 7 do texto de referência. Uma revisão, ou leitura ligeira, do material coberto nos capítulos 5 e 6 do texto de referência propiciará ao aluno, nesso ponto, tanto uma melhor compreesão das possíveis semânticas associadas aos padrões e formatos aqui em foco, quanto uma melhor compreensão das funcionalidades disponibilizadas pelas bibliotecas de programação de aplicações, na abordagem top down que constitui o trabalho do curso (ver, em C2, "Avaliação")
C2-3 Os padrões X-509 para certificados e CRLs
Na apresentação deste curso, vimos que uma infraestrutura de chaves públicas (ICP) é um conjunto de padrões que constituem regimes normativos, procedimentos, especificações de formatos, algoritmos e protocolos, e, finalmente, de implementações de serviços que disponibilizam o uso de interoperável e escalável da criptografia assimétrica para redes abertas em conformidade com tais padrões. O estudo preliminar do tema é coberto no curso C1.
Concebe-se o projeto de uma ICP a partir de um mecanismo de transporte de chaves públicas capaz de oferecer, de forma interoperável e escalável, algum nível de confiança aos usuários acerca da titulação e validade dessas chaves. O arcabouço desse mecanismo é uma estrutura de dados padronizada, especificando o que comumente se denomina certificado de chave pública. Para examinarmos este arcabouço, começamos com alguma nomeclatura.
Textos acadêmicos em inglês, como por exemplo o texto de referência deste curso [0], referem-se a:
O usuário de uma chave pública titulada e transportada por um certificado: certificate user ou relying party (alguém que se presume confiar na titulação e possível validade de tal chave).
O titular de uma chave pública titulada e transportada por um certificado: certificate holder ou subscriber (alguém que subscreve a um tal mecanismo, e que se presume possuidor [único] da correspondente chave privada, respondendo, no regime normativo da ICP, por seu uso).
O responsável pelo serviço que agrega valor autenticatório à titulação e validade de uma chave pública em um certificado: certificate issuer (entidade certificadora, emissor de certificados). Um cliente desse serviço, agente titular ou usuário de certificados, é também chamado end entity (entidade final)
C2-3.1 Evolução do padrão X.509
C2-3.1.1- Origem
O padrão X.509 surgiu, em 1988, como arcabouço de autenticação recomendado para o padrão de diretório X.500, pelo CCITT (posteriormente ITU-T). Um diretório é uma base de dados online contendo informação arbitrária. O padrão X.500 pressupõe, como atributos de diretório, distribuição global e controle de acesso. Controle de acesso global pressupõe identificação positiva e distinguida para autorização e possível sigilo nos canais de acesso.
Esses atributos fizeram com que, ao longo do tempo, o uso do padrão X.509 migrasse do arcabouço pretendido, já que diretórios globais de informação arbitrária no padrão X.500 foram sobrepujados por padrões ao nível de aplicação sobre TCP/IP, para as ICPs, popularizadas por esses padrões de aplicação, que demandavam atributos semelhantes para seu arcabouço de transporte.
C2-3.1.2- Versões v1, v2 e v3
Devido, em boa parte, ao sucesso explosivo do padrão TCP/IP na consituição de uma rede de redes de hierarquia aberta e roteamento adaptativo (Internet), o foco da evolução do padrão X.509 procurou adaptar sua estrutura de dados original para acomodar as necessidades básicas de transporte das ICPs, demandadas pelas distintas aplicações sobre TCP/IP com requisitos de funcionalidade criptográfica.
O primeira versão do padrão X.509, mais precisamente ITU-T X.509 (v1) ou ISO/IEC 9594-8, foi publicado em 1988 juntamente com o padrão X.500, definindo um formato padrão para certificados digitais. Quando o padrão X.500 foi revisado em 1993, em decorrência da publicação dos padrões PEM (RFC 1442) para uso do X.509 no transporte de chaves públicas pela Internet, dois campos foram acrescentados ao formato X.509 (issurerUniqueID e subjectUniqueID), que passou assim à versão v2. Para uso em ICPs pela Internet, a v2 endereçou o problema da resolução de nomes como identificadores de agentes.
Mas as tentativas de se adaptar o X.509 para a padronização do uso de chaves públicas, conforme especificações no padrão PEM (RFC 1422), mostraram deficiências das versões v1 e v2. Em consequência, as três organizações que lideravam o esforço de padronização nesta área, ISO/IEC, ITU-T e ANSI X9, juntaram esforços para desenvolver a versão v3 de forma a suprir as deficiênicas até ali levantadas. A versão v3 extende a versão v2 acrescentando ao certificado os chamados campos de extensão, opcionais, cuja semântica é apontada por um identificador ASN.1 do objeto (OIDs) transportado no campo.
A especificação da versão v3 foi completada em 1996. Depois disso, ISO/IEC, ITU-T, e ANSI X9 também desenvolveram padrões minimais para certas extensões, para o transporte de dados tais como atributos da chave pública, informação adicional sobre o titular, sobre políticas de certificação e de uso, e sobre restrições aos caminhos de validação do certificado (ver [X9.55]).
Entretanto, a padronização de extensões minimais ainda é insuficiente para as necessidades de interoperabilidade para tipos específicos de aplicações, tais como serviços web, correio eletrônico, IPsec e outras aplicações sobre o suíte TCP/IP que forma a Internet. Para esses cada tipo específico de aplicação, surgiram então perfis espíficos de uso de extensões minimais do X.509 v3 na Internet, propostos pela IETF. Esses perfis são discutidos na RFC 3280 [6], publicado em abril de 2002.
C2-3.2 Tipos ASN.1 no formato X.509
C2-3.2.1- Identificadores de Objeto (Object identifiers)
O padrão de perfis IETF (também conhecido como PKIX, nome do grupo de trabalho formado no âmbito do IETF para propô-los através de RFCs) estabelece notação decimal de OIDs, alternativa à correspondente codificação DER para o tipo ASN.1, que é uma sequência de inteiros separados por pontos (à moda dos endreços IP). Cada (sub)sequência é chamada um arco (da árvore de OIDs). O padrão IETF estabelece limites de tamanho do OID (até 100 bytes de representação decimal), além daquelas da codificação DER, (que são o de 28 bits por arco a partir do terceiro arco, os valores de zero a quarenta no segundo arco e de zero a dois no primeiro).
Identificadores de objeto são alocados hierarquicamente, com cada autoridade no arco respondendo pela designação semântica dos OIDs subordinados, podendo esta responabilidade ser delegada, de forma a garantir unicidade global na designação de OIDs. Entretanto, a padronização X.500 prevê regras de extensibilidade, pelas quais objetos com designação semântica distinta podem ser identificados pelo mesmo OID. O apêndice B de [6] (pag 114) descreve regras do padrão IETF que decidem quando e como ignorar objetos de semântica desconhecida, ou quando o desconhecimento compromete a validação de um certificado.
OIDs são usados extensivamente em certificados de formato X.509, como por exemplo, para designar algoritmos criptográficos empregados, políticas de certificação e campos de extensão. Praticamente toda implementação de ICP usando este formato requer o registro de novos OIDs, em particular uma que designe a política de certificação que estabelece seu regime regulatório básico. É crucial que os OIDs sejam obtidos dos legítimos responsáveis pelos arcos, para se evitar incompatibilidades e colisões. O apêndice B do texto de referência [0] contém uma lista de várias dessas entidades responsáveis.
C2-3.2.2- Identificadores de Algoritmos (Algorithm identifiers)
Trata-se de um tipo estruturado ASN.1 para designar informação sobre algoritmos criptográficos a que se destinam chaves transportadas ou referenciadas pelo certificado. Isto é, a chave pública transportada, e a chave de verificação da assinatura da entidade emissora anexada ao certificado.
{ algorithm OBJECT IDENTIFIER,
C2-3.2.3- Cadeias para nomes de Diretório (Directory String)
Trata-se de um tipo estruturado ASN.1 para designar informação textual independentemente do conjunto de caracteres empregados na origem e no destino do transporte.
{ teletexString TeletexString (SIZE (1..MAX)),
C2-3.2.4- Nomes Unívocos (Distinguished Names)
Trata-se de um tipo estruturado ASN.1 para designar um sistema hierárquico de nomeação capaz de identificar uma entidade (no caso dos padrões IETF para o X.509, entidade final ou certificadora) de forma únívoca (sem homonimias) num diretório global.
RelativeDistinguishedName ::= SET SIZE (1 .. MAX) OF AttributeTypeAndValue
AttributeTypeAndValue ::= SEQUENCE
{ type AttributeType,
O tipo ASN.1 que designa nomes unívocos (DN) é o tipo mais complexo no formato X.509. Um DN com lista vazia de atributos é dito um DN vazio. Um DN vazio é permitido num certificado X.509 v.3 desde que algum nome genérico correspondente não seja também vezio.
C2-3.2.5- Nomes Genéricos (General Names)
Trata-se de um tipo estruturado ASN.1 para designar nomes codificáveis em qualquer forma. O tipo provê a opção de sete padrões de codificação que correspondem a tipos simples na lingugem ASN.1
{ otherName [0] OtherName,
registeredID [8] OBJECT IDENTIFIER
{ type-id OBJECT IDENTIFIER,
value [0] EXPLICIT ANY DEFINED BY type-id
EDIPartyName ::= SEQUENCE
{ nameAssigner [0] DirectoryString OPTIONAL,
partyName [1] DirectoryString
C2-3.2.6- Selos Temporais (Time)
Trata-se de um tipo estruturado ASN.1 para designar informação temporal. Contém duas opções. UTCTime codifica data e hora até segundos, omitindo os dígitos do século, eenquanto GeneralizedTime inclui os dígitos do ano
Time ::= CHOICE
{ utcTime UTCTime, --YYMMDDHHMMSS
generalTime GeneralizedTime --YYYYMMDDHHMMSS
C2-3.3 Formato X.509 para Certificados
C2-3.3.1- Estrutura dos dados
A estrutura de dados do formato X.509 para certificados digitais de chave pública corresponde ao de uma mensagem assinada. Uma sequência consistindo da parte a ser assinada, que constitui o certificado propriamente dito, do identificador do algoritmo de assinatura e da assinatura do emissor sobre o certificado.
issuer (certificadora)
subject (titular)
signatureValue (autenticador)
v.1 v.2 v.3 autenticador
___Exemplo
<- v2
<- 48
<- DSA with SHA-1
<- C=BR; O=UnB; OU=CIC; CN=Admin
<- 01021412000Z to 02021412000Z
<- C=BR; O=UnB; OU=CIC; CN=Pedro
<- RSA, 30 81 8d 01 a7 ... c0
<- (normalmente omitido)
<- 83 5e 69 3c 66 f4 5b ... 72
C2-3.3.2- Tipo ASN.1
A especificação ASN.1 da trutura de dados do formato X.509 é a seguinte
Certificate ::= SEQUENCE
{ tbsCertificate TBSCertificate,
TBSCertificate ::= SEQUENCE
{ version [0] EXPLICIT Version DEFAULT v1,
Validity ::= SEQUENCE
{ notBefore Time,
{ utcTime UTCTime,
{ algorithm AlgorithmIdentifier,
{ extnID OBJECT IDENTIFIER,
C2-3.4 Extensões no formato de certificado X.509 v.3
O objetivo das extensões é possibilitar e ampliar, em vários graus e aspectos, a interoperabilidade entre componentes de uma ICP e entre ICPs, além de flexibilizar detalhes de suas arquiteturas, como aquelas que se mostraram muito rígidas no padrão PEM de 2003.
Na v3 do X.509 o campo de extensões consiste de uma lista de objetos, cada um deles representando uma extensão, cada extensão dada por uma tripla
Bit de Criticalidade
Num primeiro nível, a semântica do campo estabelece duas regras
Não devem haver instâncias repetidas do mesmo OID nesta lista,
O sinalizador que descreve a importância de cada extensão (bit de criticalidade) indica que, durante a validação do certificado, se onde a semântica do objeto OID da extensão não puder ser estabelecida o certificado deve ser descartado se a extensão estiver sinalizada como crítica, ou ignorado caso contrário. A escolha do implementador de marcar como crítica uma extensão nos certificados que emite, pode impactar na interoperabilidade desses certificados, em proporção direta à universalidade do conhecimento da semântica desta extensão.
As entidades que se juntaram para propor a v3 do X.509 também espeficiaram, junto com a v3, várias extensões padronizadas para diversos tipos de aplicação. Também o grupo PKIX propõe extensões obrigatórias para o uso de certificados X.509 pela Internet. A especificação desses objetos estão registradas nas respectivas entidades, indicadas no prefixo no OID. No restante, examinaremos algumas dessas extensões padronizadas.
Dessas, o grupo PKIX recomenda, como conjunto mínimo de extensões para perfis na internet, as extensões key usage, extended key usage, certificate policies, inhibit any-policy, subject alternative name, basic constraints, name constraints, policy constraints. O segundo grupo de extensões que o grupo PKIX adicionalmente recomenda inclui authority e subject key identifier, e policy mapping, este quando aplicável.
3.4.1 Extensões padronizadas pelo grupo PKIX
As extensões padronizadas pelo grupo PKIX tem OID com prefixo designado pelo arco da árvore de objetos
3.4.1.1 Authority Key Identifier
Esta extensão, que não deve ser marcada como crítica, provê um meio para identificar a chave pública correspondente à chave privada que assinou o certificado. Útil quando a entidade certificadora é titular de mais de uma chave de assinatura, deve fazer referência ao certificado que contem tal chave (o próximo da cadeia de certificação), ou à chave propriamente dita. Esta referência pode ser o número de série e nome unívoco do emissor, ou um identificador.
Para se gerar o identificador, deve-se empregrar o mesmo método de gerar identificadores já escolhido para outros tipos de chave, caso um já tenha sido escolhido. Dois métodos comuns para se gerar identificadores de chaves a partir do hash da chave são descritos abaixo; outro método seria a numeração monotônica das chaves identificadas. A extesão deve ser usada para facilitar a construção de caminhos de certificação, e omitido dos certificados auto-assinados. A especificação ASN.1 da extensão é
3.4.1.2 Subject Key Identifier
Esta extensão, que não deve ser marcada como crítica, provê um meio para identificar todos os certificados que contenham uma determinada chave pública. Útil quando o titular do certificado é uma ceritificadora (o certificado inclui a extensão basic consraints com o valor CA=TRUE), facilitando a construção de caminhos de certificação. Deve ser o mesmo valor que aparce na extensão issuerKeyIdentifier nos certificados assinados pela chave identificada. Este valor pode ser o número de série e nome unívoco do emissor, ou um identificador. Para se gerar o identificador, deve-se empregrar o mesmo método de gerar identificadores já escolhido para outros tipos de chave, caso um já tenha sido escolhido.
Deve-se usar o mesmo método para se gerar identificadores unívocos empregados para outros identificadores de chaves, caso um já tenha sido escolhido. Dois métodos comuns para se gerar identificadores de chaves a partir do hash da chave são aqui descritos.
O keyIdentifier é composto do hash SHA1 de 160 bits do BIT STRING subjectPublicKey (sem a etiqueta, comprimento e número de bits não usados)
O keyIdentifier é composto do valor string de 4 bits correspondente a 0001 seguido dos 60 bits menos significativos do hash SHA1 de 160 bits do BIT STRING subjectPublicKey (sem a etiqueta de comprimento e o número de bits não usados)
Em certificados de entidades finais, este identificador deve ser derivado da chave pública. A especificação ASN.1 da extensão é
3.4.1.3 Key Usage
Esta extensão descreve o propósito ou função para o qual teria sido gerado o par de chaves do qual a chave pública é transportada no certificado. (cifragem, verificação de assinatura, etc.) Quando esta extensão ocorre em um certificado, deve ser marcada como crítica. (chaves para algoritmos comutativos, como o RSA, poderia ser usado para mais de um propósito ou função). A especificação ASN.1 é:
O uso deve ser o seguinte. Esta extensão deve aparecer em certificados que transportam chaves públicas destinadas a verificar assinaturas em documentos que não sejam certificados digitais e listas de revogação, com o bit digitalSignature ligado.
Chaves usadas para verificar assinaturas em certificados devem ter o bit 5 ligado, e para verificar listas de revogação o bit 6 ligado. O bit de não-repúdio (1) se refere à implementação de serviços que prevejam a emissão de recibos de transação, e sua relação com o regime jurídico em que se insera a ICP. (detalhes sobre a natureza desses serviços devem ser referidos através das extensões sobre Política de certificação). Se o bit keyCertSign estiver ligado, também deve estar o bit CA na extensão basic constraints.
Algumas combinações de bits ligados são inconsistentes. Por exemplo, encipherOnly e decipherOnly só fazem sentido em conjunto com keyAgreement. Se o identificador do algoritmo a que se destina a chave é o do algoritmo Diffie Hellman, o bit keyAgreement deve estar ligado, e nenhum dos bits referentes a assinatura faz sentido estar ligado. Se o algoritmo for DSA, o bit de cifragem ligado não faz sentido.
NOTA IPORTANTE: Nem toda inconsistência possível em relação à extensão keyUsage se restringe à esfera da funcionalidade de softwares especificados e implementados para interoperarem numa ICP. O bit de não-repúdio (1), que se refere a serviços para emissão de recibos de transação, não deve ser confundido com asserção jurídica homônima, e que implica, na sua hermêutica menos dura, em inversão do ônus da prova de fraude, em caso de repúdio.
Legislar esta inversão sob o pretexto de que a padronização para emissão de certificados contempla um bit com este nome, como ocorre na Medida Provisória que institui a Infraestrutura de Chaves Públicas brasileira (2200-2), é aberração megalomaníaca e esquizofrênica de legisladores que não compreendem o que sejam, como funcionam e para que servem as premissas de protocolos criptográficos (ver A. McCullagh & W. Caelli: Non-repudiation in the digital environment. F. M. Electronic journal, Dec 9, 00, http://firstmonday.org/issues/issue5_8/mccullagh/ ).
3.4.1.4 Private Key Usage Period
Esta extensão não deve ser usada em ICPs na Internet, conforme recomendação do PKIX. Serve para estabelecer uma janela temporal de validade para a datação de documentos assinados por chave privada cuja correspondente chave pública o certificado transporta. O leitor deve observar que a data que porventura conste como conteúdo de um documento assinado, a título de datação da assinatura, não diz respeito à data de verificação da assinatura, nem do prazo de validade do certificado que transporta a chave de verificação da assinatura.
PrivateKeyUsagePeriod ::= SEQUENCE
{ notBefore [0] GeneralizedTime OPTIONAL,
notAfter [1] GeneralizedTime OPTIONAL
Num certificado de entidade final, a extensão descreve o conjunto de políticas sob as quais o certificado foi emitido, inclindo o seu uso pretendido. Usuários de certificados devem conhecer as políticas aceitáveis para suas aplicações.
Num certificado de entidade certificadora, a extensão descreve as políticas que podem ser incluídas entre as políticas vigentes para certificados que lhe sejam subordinados numa cadeia de certificação.
Se esta extensão for marcada como crítica, a aplicação deve também ser capaz de, após montar a cadeia de certificação (da entidade final até a raiz) e percorrer a cadeia de verificação (a mesma cadeia em sentido contrário, da raiz até a entidade final), interpretar esta extensão à luz das limitações decorrentes das políticas que ocorrem na cadeia, e decidir pela sua adequação aos requisitos da aplicação, rejeitando o certificado, e portanto a cadeia, em caso de não adequação.
Requisitos para o processamento de qualificativos é assunto local, afeto a cada implementação: nenhuma ação é mandatória se a exetnsão for marcada como crítica. Por isso, para promover interoperabilidade, os perfis PKIX recomendam que seja usado nessa extensão apenas o OID de políticas, sem qualificativos. Se o uso de qualificativos for inevitável, recomenda-se que se restrinjam esses ao CPS pointer e ao User Notice, abaixo descritos.
3.4.1.6 Policy Mappings
Esta extensão é usada em certificados de entidades certificadoras. Constitui-se de uma lista de pares de OIDs correspondentes a políticas. O primeiro de um par se refere ao OID de uma política do emissor do certificado, e o segundo ao OID de uma política do titular da chave transportada que o emissor considera equivalente ao primeiro. Esse par tem o efeito de mapear a segunda para a primeira, na propagação das políticas em vigor através da cadeia de certificação (que vai da entidade final à raiz), e vice-versa, através da cadeia de verificação (da raiz à entidade final).
Cabe à aplicação, que reconhece políticas válidas em certificados de entidades finais, decidir sobre a transitividade dessas equivalências, segundo as regras postas por estas e outras extensões de políticas, através da cadeia. Esta extensão não deve ser crítica, qualquer política mapeada pelo emissor precisa constar da lista de suas políticas vigentes, e a política absolutamente neutra (any-policy) não deve ser mapeda por este mecanismo.
PolicyMappings ::= SEQUENCE SIZE (1..MAX) OF SEQUENCE
{ issuerDomainPolicy CertPolicyId,
subjectDomainPolicy CertPolicyId
3.4.1.7 Subject Alternative Names
Esta extensão permite que o certificado associe identidades adicionais do titular à chave transportada. Opções pré-definidas incluem nomes em formato de endereço de email, endereço DNS, endeço IP e endereço URI, e opções locais e múltiplas instâncias de um tipo de nome podem ser incluídas. Se alguma instância de algum desses tipos de nomes será vinculada à titulação de uma chave pública pelo certificado, esta extensão precisa ser usada, embora um nome DNS possa também ser representado no campo obrigatório subjectName, como caso particular de nome X.500.
Como os nomes alternativos representados nesta extensão fazem parte da titulação da chave pública, todos os nomes desta extensão precisam ser verificados como identificadores do titular da chave transportada pelo emissor e, caso distinto, pela entidade de registro que lhe forneça esse serviço de verificação. Se o único nome na titulação da chave pública for um endereço de email, o campo distinguishedName precisa estar vazio e esta extensão, onde é representado, presente. Outras restrições são as seguintes:
Endereço de email deve ser codificado como nome de tipo rfc822Name,
Endereço IP deve ser condificado em "network byte order", conforme especificado pela RFC 791 (para endereços IPv6, RFC 1883).
Endereço URI (Universal Resource Identity) deve ser codificado no campo uniformResourceIdentifier (de tipo IA5String), com sintaxe especificada em RFC 1738.
Nomes definidos para o protocolo Kerberos devem seguir a sintaxe espeficiada em RFC 1510.
Se o campo subjectField estiver vazio, esta extensão deve ser marcada como crítica. Esta extensão, se presente, não pode estar vazia.
3.4.1.8 Issuer Alternative Names
Como em 3.4.1.7, esta extensão é usada para associar identidades tipicamente usadas na Internet ao emissor do certificado. Essas identidades devem ser codificadas como em 3.4.1.7, e quando presente, não deve ser marcada como crítica.
3.4.1.9 Subject Directory Attributes
Usado para transportar identificação de atributos do titular (por exemplo, nacionalidade). Trata-se de uma sequência de um ou mais objetos atributo, e deve ser marcada como não crítica.
3.4.1.10 Basic Constraints
Esta extensão identifica se o titular do certificado é uma entidade certificadora, isto é, capaz de emitir e assinar certificados que possam integrar o interior de cadeias de certificação, e o comprimento máximo que pode ter a cauda de uma cadeia de certificação, formada a partir do certificado, excluindo raiz auto-assinada que a encerra (a cadeia de certificação é montada na ordem inversa da cadeia de verificação que propicia). Este segundo campo só faz sentido quando o bit do primeiro campo está ligado, indicando tratar-se de certificado de entidade certificadora, e o bit keyCertSign na extensão keyUsage estiver ligado (caso contrário, este bit não deve ser ligado).
Não haverá limite para o comprimento da cadeia, se o campo pathLenConstraint não ocorrer. Se a exetensão ocorrer, deve ser marcada crítica.
3.4.1.11 Name Constraints
Esta extensão deve ser usada apenas em certificados de entidades certificadoras, para restringir o espaço de nomes dentro do qual os certificados subsequentes na cadeia de verificação devem se incluir. Tais restrições se aplicam tanto ao nomes unívocos no campo obrigatório subjectName, quanto aos nomes alternativos na extensão correspondente.
As regras para o funcionamento de tais restrições são bastante complexas, e propensas a efeitos colaterais indesejáveis. Para mais detalhes, deve-se consultar os perfis PKIX na RFC 3280 [6]
NameConstraints ::= SEQUENCE
{ permittedSubtrees [0] GeneralSubtrees OPTIONAL,
excludedSubtrees [1] GeneralSubtrees OPTIONAL
GeneralSubtree ::= SEQUENCE
{ base GeneralName,
maximum [1] BaseDistance OPTIONAL
3.4.1.12 Policy Constraints
Esta extensão deve ser usada apenas em certificados de entidades certificadoras, para restringir um caminho de validação contendo o certificado. Esta restrição pode ser de duas formas. Pode proibir o mapeamento de políticas, ou exigir que cada certificado no caminho de validação (em direção ao ceritificado de entidade final) contenha o identificador de uma política aceitável.
Se o campo inhibitPolicyMapping estiver presente, seu valor indica o número de elos no caminho de verificação a partir do qual a restrição ganha efeito. Por exemplo, se um certificado contém esta extensão com inhibitPolicyMapping=1, o mapeamento de políticas pode ocorrer nos certificados emitidos pelo titular deste certificado, mas não nos certificados que lhes sejam subsequentes numa cadeia de verificação.
Se o campo requireExplicitPolicy estiver presente, seu valor indica o número de elos no caminho de verificação a partir do qual uma política específica é requerida para o restante do caminho de verificação (até o certificado da entidade final). Por exemplo, se um certificado contém esta extensão com inhibitPolicyMapping=1, uma política explícita não precisa ocorrer nos certificados emitidos pelo titular deste certificado, mas precisa ocorrer nos certificados que lhes sejam subsequentes numa cadeia de verificação. Uma tal política é qualquer política exigida pela aplicação que usa a cadeia, ou a ela mapeada como equivalente por mapeamento válido na cadeia.
A extensão não pode ser vazia, e pode ser marcada crítica ou não.
3.4.1.13 Extended Key Usage
Esta extensão indica um ou mais propósitos para os quais o certificado pode ser usado, adicionalmente ao que determina a extensão keyUsage. Em geral, esta extensão é útil para certificados de entidades finais, podendo ou não ser crítica.
Um propósito para certificação de chave pública pode ser definido por uma organização com base em necessidade, e seu identificador OID deve se enquadrar nas recomendação da IANA ou do padrão ITU-T X.660. Mais detalhes da semântica desta extensão pode ser encontrada na discussão dos perfis PKIX, na RFC 3280 [6], que descreve alguns usos pre-definidos, incluindo:
3.4.1.14 Inhibit Any-Policy
Esta extensão, que se ocorrer deve ser crítica, pode ser usada em certificados emitidos para entidades certificadoras para indicar que a política absolutamente neutra (any-policy, OID { 2 5 29 32 0 }) não seja permitida em certificados subsequentes no caminho de verificação (em direção ao certificado de entidade final). O valor do campo indica o número de certificados no caminho de verificação a partir dos quais começa a vigorar a inibição da ocorrência de política absolutamente neutra.
Por exemplo, se um certificado contém esta extensão, que deve ser marcada como crítica, e com inhibitAnyPolicy=1, o OID { 2 5 29 32 0 } pode ocorrer em extensões certificatePolicy críticas de certificados emitidos pelo titular deste certificado, mas não em certificados que lhes sejam subsequentes numa cadeia de verificação.
3.4.1.15 CRL Distribution Points
Esta extesão identifica como lista de revogação de certificados (CRL) -- nas quais poderia estar a revogação do certificado -- podem ser obtidas. A extensão não deve ser crítica, mas o perfil PKIX recomenda que esta extensão seja interpretada pelas aplicações. O assunto das listas de revogação é tratado mais adiante, em outro módulo.
A extensão cRLDistributionPoints é uma sequência de objetos distributionPoint, que consiste de três campos, cada um deles opcional (o campo reasons não deve ocorrer sozinho). Se o emissor da CRL não for o mesmo emissor do certificado, o campo cRLIssuer deve estar preenchido, e deve ser omitido com o campo distributionPoint preenchido, caso o emissor do CRL e do certificado sejam o mesmo. Se o campo distributionPoint for omitido, o campo cRLIssuer deve ser preenchido com o nome X.500 ou LDAP do emissor da CRL.
O campo distributionPoint deve ser preenchido com uma sequência de nomes genéricos um um valor único, nameRelativeToCRLIssuer. Se contiver um nome genérido de tipo URI, a seguinte semântica deve ser assumida: O URI (tipo tratado em 3.4.1.7) aponta para a atual lista de certificados que foram revogados pelas razões listadas no campo reason, emitida pela entidade identificada em cRLIssuer. Se contiver múltiplos nomes, cada um descreve um meio ou mecanismo de acesso à mesma CPL (por exemplo, LDAP e HTTP). Maiores detalhes no perfil PKIX, em [6].
3.4.1.16 Freshest CRL (a.k.a. Delta CRL Distribution Point)
Esta extensão identifica como podem ser obtidas listas de revogação para o período em curso, denominadas delta CRLs. A mesma sintaxe e as mesmas convenções sobre semântica da extensão CRL Distribution Points são empregadas. CRLs por período (delta CRLs) serão discutidas em outro módulo, adiante.
3.4.2. Extensões privadas para uso nos perfis PKIX
Extensões privadas podem ser usadas para direcionar aplicações a informações on-line sobre a entidade certificadora que emite o certificado, ou sobre o titular da chave transportada. Como as informações podem estar disponíveis em formas variadas, cada extensão deve ser uma sequência de valores IA5String, cada qual representando um URI. Cada URI implicitamente especifica o local, o formato, e o método de acesso aos dados.
O identificador de objeto (OID) associado a tais extensões privadas deve ser definido com arco (prefixo) representado nos perfis PKIX pelo identificador id-pe, que por sua vez extende o arco id-pkix. Futuras extensões privadas para uso na Internet devem também ser definidas sob o mesmo arco.
security(5) mechanisms(5) pkix(7)
Das extensões sob este arco, duas, descritas abaixo, são sugeridas pelo PKIX para uso universal.
3.4.2.1 Authority Information Access
Esta extensão indica como acessar informações e serviços prestados pela entidade que emitiu o certificado. Esses serviços podem incluir validação on-line de certificados e políticas de certificação (não inclui informação para acesso a listas de certificados revogados, que aparecem na extensão cRLDistributionPoints). Pode ser usado tanto em certificados de CA ou de entidades finais, e deve ser não-crítica.
AccessDescription ::= SEQUENCE
{ accessMethod OBJECT IDENTIFIER,
accessLocation GeneralName
Cada entrada da lista descreve um formato e localização fornecida pela entidade emissora do certificado. O tipo e formato da informação oferecida é especificado no campo acessMethod; o local de acesso no campo acessLocation, e o mecanismo de acesso em acessMethod. O perfil PKIX define dois métodos de acesso: id-ad-caIssuers e id-ad-ocsp.
O OID id-ad-caIssuers é usado para facilitar a construção de caminhos de certificação, informando sobre outras entidades hierarquicamente superiores à entidade emissora do certificado. Neste caso accessLocation descreve o servidor e o protocolo de acesso, definido em dado de tipo GeneralName. Se o acesso for via http, ftp ou ldap, acessLocation deve ser um URI (UniformResourceIdentifier). Se o acesso for via smtp, accessLocation deve ser um rfc822Name.
O OID id-ad-ocsp é usado quando o emissor do certificado disponibiliza informação sobre revogação do certificado via Online Certificate Status Protocol, - OCSP [RFC 2560]
3.4.2.2 Subject Information Access
Esta extensão indica como acessar informações e serviços oferecidos para ou pelo titular do certificado. Quando o tituar é uma entidade certificadora, tais informações e serviços podem ser da mesma natureza que na extensão anterior (3.4.2.1).
Quando o titular é um entidade final, esta extensão pode informar que tipo de serviço o titular oferece, e como acessá-los. Um exemplo seria, por exemplo, no caso do titular ser um servidor de autenticação temporal (protocolizadora), a extensão informa como acessar o serviço de protocolização. A extensão deve ser não-crítica.
Cada entrada da lista descreve um formato e localização fornecida pela entidade emissora do certificado. O tipo e formato da informação oferecida é especificado no campo acessMethod; o local de acesso no campo acessLocation, e o mecanismo de acesso em acessMethod. O perfil PKIX define um método de acesso quando o titular é uma entidade certificadora, e outro quando o titular é entidade final..
O OID id-ad-caRepository é usado quando o titular é uma entidade certificadora, e publica certificados e CRLs (caso as emitam) em um repositório. Neste caso accessLocation descreve o servidor e o protocolo de acesso, definido em dado de tipo GeneralName. Se o acesso for via http, ftp ou ldap, acessLocation deve ser um URI (UniformResourceIdentifier). Se o acesso for via smtp, accessLocation deve ser um rfc822Name.
O OID id-ad-timeStamping é usado quando o titular é uma entidade protocolizadora (emissora de autenticadores temporais), usando o protocolo TSP (definido em PKIXTSA). Se o acesso for via http ou ftp, acessLocation deve ser um URI (UniformResourceIdentifier). Se o acesso for via smtp, accessLocation deve ser um rfc822Name. Se o serviço estiver disponível via TCP/IP (protocolo NTP), nomes dNSName ou ipAddress podem ser usados. Descritores adicionais de extensões "particulares" podem vir a ser definidas em outras especificações PKIX.
C2-3.5 Formato X.509 para Listas de Certificados Revogados
O objetivo do grupo PKIX do IETF é promover o surgimento de ICPs interoperáveis e reusáveis na Internet. Para isso, perfis para o uso de extensões em CRLs de formato X.509 são detalhados em [6]. CRLs servem para informar o status de certificados que estejam em seu prazo de validade.
CRLs podem ter escopo limitado, cobrindo certificados não expirados que tenham sido emitidos para uma determinada classe de usuários (CAs ou entidades finais), que tenham sido revogados por alguma razão específica, ou que abranjam um período específico (Delta CRLs), contendo apenas certificados que tenham sido revogados após a publicação da última CRL completa, nela referenciada.
Pelo padrão PKIX, entidades certificadoras não são obrigadas a emitir CRLs se outros mecanismos de informação de status de certificados emitidos (ex.: OCSP) são disponibilizados. (entretanto, as normas em vigor na data de publicação deste módulo para a ICP-Brasil exigem a disponibilização de CRLs). Para mais detalhes, consulte a legislação em vigor no Brail no site do ITI (http://www.iti.gov.br), e os perfis PKIX na RFC 3280 [6].
C2-3.4.1- Estrutura dos dados
A estrutura de dados do formato X.509 para CRLs se parece ao de certificados. Uma sequência consistindo da parte a ser assinada, que constitui a lista de certificados revogados, do identificador do algoritmo de assinatura e da assinatura do emissor sobre a lista de revogação. A versão v.2 é a seguinte
issuer (emissora)
RevokedCertificates: Lista de triplas
<- 01021412000Z (data da emissão)
<- 02021412000Z (próxima emissão)
. (versão v.2)
<- serial number
<- 02011412000Z
A especificação ASN.1 da estrutura de dados de CRLs em formato X.509 é a seguinte
version Version OPTIONAL -- if present, MUST be v2
revokedCertificates SEQUENCE OF SEQUENCE
{ userCertificate CertificateSerialNumber,
3.6.1 Extensões PKIX para CRLs X.509 v.2
As extensões para CRL foram introduzidas na versão 2 do formato X.509 para CRLs, pelos institutos ITU-T e ANSI X.9. Essas extensões servem para representar informações pertinentes à lista inteira. O grupo PKIX recomenda o uso dos perfis descritos no RFC 3280 [6], com OIDs de extensões no prefixo designado pelo arco
3.6.1.1 Authority Key Identifier
Esta extensão, que não deve ser marcada como crítica, provê, como nos certificdos, um meio para identificar a chave pública correspondente à chave privada que assinou a CRL. Útil quando a emissora da CRL é titular de mais de uma chave de assinatura, o PKIX recomenda que seja usado o identificador da chave mesma (oposto ao certificado). A certificadora pode usar chaves diferentes para assinar certificados e CRLs
A especificação ASN.1 da extensão é a mesma da extensão homônima em certificados v.3
3.6.1.2 Número de série da CRL
Esta extensão equivale ao número de série de certificados, e deve distinguir CRLs distintas emitidas por uma entidade. Seu uso é recomendado pelo PKIX
3.6.1.3 Indicador Delta
Extensão crítica que identifica se uma CRL é do tipo Delta. Delta CRLs contêm apenas revogações registradas após a data de publicação da última CRL completa do emissor, referida como CRL-base.
Delta CRL podem reduzir o tráfego de rede, pois permitem que CRLs-base sejam armazenadas pelas aplicações, com suas informações complementadas pelas correspondentes Delta CRLs, essas acessadas com maior frequência, porém menores. Esta extensão contém um único valor, que identifica a correspondente CRL-base pelo seu número de série.
Para que uma CRL seja validada como base para uma Delta CRL, constituindo o conteúdo de ambas uma CRL completa para determinado escopo, ambas devem estar assinadas com a mesma chave. Além disso, ambas devem ser completas para este escopo, com seus respectivos intervalos temporais sobrepondo-se ou completando-se. Para isso, as seguintes quatro condições devem ser satisfeitas.
(a) A entidade emissora de ambas deve a mesma.
(b) Uma das seguintes condições determinem escopo idêntico de ambas:
(b.1) Ambas omitirem a extensão issuingDistributionPoint
(b.2) A extensão issuingDistributionPoint ocorre em ambas, campos e respectivos valores presentes na extensão de ambas coincidem.
(c) O número de série da CRL completa é igual ou maior que o número de série especificado no campo BaseCRLNumber da CRL Delta. Ou seja, ambas contem todas as revogações da base do emissor, para o escopo da CRL base.
(d) O número de série da CRL completa é menor que o número de série da CRL Delta. Ou seja, ambas contem todas as revogações da base do emissor, para o referido escopo.
Dentre os motivos para revogação previstos na extensão Reason Code está a suspensão. O status de suspensão, que não será tratado neste módulo, complica as possibilidades de combinação de CRLs base e delta para a montagem de uma CRL completa. CRLs Delta devem incluir qualquer mudança de status na base dos certificados da emissora, desde a publicação da CRL base, de forma que o escopo sendo considerado esteja contemplado em uma dessas duas CRLs. As possibilidades de combinação daí decorrentes são discutidas na RFC 3280 [6].
3.6.1.4 Ponto de distribuição de CRL
Extensão crítica que identifica os tipos de certificados ou de motivos de revogação cobertos na CRL. Uma entidade emissora de CRLs pode emitir listas de revogação de escopo diversos e complementares, assiando-as com a mesma chave. Em repositórios, uma CRL deve ser armazenada em entrada de diretório correspondente ao ponto de distribuição descrito nesta extensão.
Se a CRL contém revogações emitidas por qualquer um dos motivos previstos, o campo onlySomeReasons não deve ocorrer. Caso ocorra, o campo ReasonFlags deve também ocorrer.
Para que uma CRL seja validada como base para uma Delta CRL, com o conteúdo de ambas permitindo a montagem de uma CRL completa para determinado escopo, ambas devem estar assinadas com a mesma chave. Além disso, ambas devem ser completas para este escopo e seus respectivos intervalos temporais devem se sobrepor ou se completar. Para isso, as seguintes quatro condições devem ser satisfeitas.
Dentre os motivos para revogação previstos na extensão Reason Code está a suspensão. O status de suspensão, que não será tratado neste módulo, complica as possibilidades de combinação de CRLs base e delta para a montagem de uma CRL completa. A CRL Delta deve incluir qualquer mudança de status na base dos certificados da emissora, desde a publicação da CRL base. As possibilidades de combinação são discutidas na RFC 3280 [6], que apresenta tipo ReasonFlags distinto e mais extenso que o mesmo tipo apresentado no texto de referência [0], atualizando este.
issuingDistributionPoint ::= SEQUENCE
{ distributionPoint [0] DistributionPointName OPTIONAL,
aACompromise (8)
Quando presente, um distributionPoint com alternativa fullName deve conter um URI que aponta para a mais recente CRL. O esquema de acesso para o URI, ftp, http, mailto ou ldap são previstos para este propósito, incluindo o caminho absoluto para o servidor. Quando presente com a alaternatica nameRelativeToCRLIssuer, trata-se de endereço relativo ao nome unívoco no campo issuer, que identifica o emissor da URL.
3.6.1.5 CRL Mais recente
Esta extensão, que não deve ser crítica, informa como obter delta CRLs para a CRL base que a contem. A sintaxe é exatamente a mesma de 3.6.1.4 (ponto de distribuição), com a mesma semântica e convenções. A sintaxe é a seguinte
3.6.2 Extensões PKIX para Certificados revogados
O campo revokedCertificates contém uma lista que descreve as revogações da base da entidade emissora. O campo pode ser omitido se a lista for vazia, e na versão v.2 esta lista corresponde às revogações cobertas pelo escopo descrito nas extensões da CRL. Cada entrada da lista é uma sequência de três campos com o terceiro campo ocional. Os dois campos obrigatórios são o número de série e o selo temporal da revogação do certificado. As extensões padronizadas para perfis de uso na Internet pelo grupo PKIX para o campo opcional dessas entradas, cRLEntryExtensions, não devem ser críticas e são descritas abaixo.
3.6.2.1 Código do motivo da revogação
Os perfis PKIX recomendam ser preferível omitir a extensão, quando o motivo da revogação não é especificado, do que incluí-la com o valor unspecifiedReason ligado no sinalizador de razões, descrito abaixo conforme ocorre na RFC 3280 [6] (atualizando o texto de referência)
CRLReason ::= ENUMERATED
{ unspecified (0),
3.6.2.2 Código da instrução de suspensão (certificateHold)
Como dito antes, o status de suspensão não será tratado neste módulo. Além de complicar as possibilidades de combinação de CRLs base e delta para a montagem de uma CRL completa, seu uso não é recomendado pelo texto de referência.
3.6.2.3 Data de invalidação
Esta extensão tem o objetivo de acomodar elementos de políticas de certificação e do regime normativo a que se destina o registro da revogação de certificados representado na CRL. Refere-se à data na qual a chave privada correspondente teria sido comprometida, ou que o certificado deixou de ter validade. Pode ser anterior à data de revogação que consta do campo revocationDate, e, inclusive (diferentemente da data de revogação), à data de emissão de prévias CRLs.
Seu uso deve ser especificado, tanto em aplicações que processam CRLs quanto em regimes normativos de auditoria sobre a emissão de CRLs, com toda a cautela necessária para se evitar que venha a ser usada como instrumento de fraude, em datações retroativas destinadas a proteger, com impunidade, conluios no uso de assinatura digital pelo titular em atos ilícitos. Esta possibilidade tem sido motivo de alerta em vários artigos do autor, como por exemplo em http://www.cic.unb.br/docentes/pedro/trabs/SBC.htm
3.6.2.4 Emissor do certificado
Em CRLs indiretas, a entidade emissora da CRL não é a mesma que emitiu o certificado revogado. Tais CRLs são indicadas pela entrata indirectCRL na extensão issuingDistributionPoint da CRL (3.6.1.4). Se o sinalizador de CRL indireta estiver ligado, caso esta extensão esteja ausente de uma entrada na lista de cerificados revogados, será assumido como emissor do certificado o mesmo da última entrada anterior na lista onde a extensão ocorre. E caso não tenha antes ocorrido a extensão na lista, assume-se como emissor do certificado o mesmo emissor da CRL. Das extensões de entradas de certificados, esta é a única que deve ser marcada crítica.
[0] · Housley, R. & Polk, T.: "Planning for PKI" ,
John Willey & Sons, 2001, New York
· Rezende, P.: "Curso C2 - ICP" (módulos 1 a 6),
Os textos abaixo aprofundam o material abordado no curso.
[1] Autor anônimo?, "ASN-1, DER e BER", Univ. Federal do Rio de Janeiro - .pdf - 37 pag
[2] Curso pós em Redes de computadores - UFRGS: "O uso de ASN.1 para especificação formal de protocolos", Univ. Federal do Rio Grande do Sul - .pdf - 16 pag
[3] ITU-T X.208 "ASN-1 Specification", Melbourne, 1988 - pdf - 74 pag.
ITU-T X.209 "BER for ASN-1 Specification", Melbourne, 1988, 1993 - pdf - 26 pag.
(Obs: A especificação ASN.1 do tipo OBJECT IDENTIFIER está no documento do padrão ITU X.680)
[4] "RSA Security Inc. Public-Key Cryptography Standards (PKCS)": PKCS#1 v2.1
[5] "RSA Security Inc. Public-Key Cryptography Standards (PKCS)": PKCS#8
[6] "Internet X.509 Public Key Infrastructure, Certicicate and CRL Profiles" RFC 3280 - txt - 129 pag