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
Ciência da Computação
Universidade de Brasília

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


Aula 5

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:


C2-3.1 Evolução do padrão X.509

C2-3.2 Tipos ASN.1 no formato X.509 C2-3.3 Formato X.509 para Certificados


C2-3.4 Extensões no formato de certificado X.509 v.3
 


      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

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

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 é

   id-ce-authorityKeyIdentifier OBJECT IDENTIFIER ::=  { id-ce 35 }

   AuthorityKeyIdentifier ::= SEQUENCE {
      keyIdentifier             [0] KeyIdentifier           OPTIONAL,
      authorityCertIssuer       [1] GeneralNames            OPTIONAL,
      authorityCertSerialNumber [2] CertificateSerialNumber OPTIONAL  }

   KeyIdentifier ::= OCTET STRING

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 é

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

       SubjectKeyIdentifier ::= KeyIdentifier
    .
    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 é:

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

          KeyUsage ::= BIT STRING {
               digitalSignature        (0),
               nonRepudiation          (1),
               keyEncipherment         (2),
               dataEncipherment        (3),
               keyAgreement            (4),
               keyCertSign             (5),
               cRLSign                 (6),
               encipherOnly            (7),
               decipherOnly            (8) }

      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.

       id-ce-privateKeyUsagePeriod OBJECT IDENTIFIER ::=  { id-ce 16 }

       PrivateKeyUsagePeriod ::= SEQUENCE
       {    notBefore       [0]     GeneralizedTime OPTIONAL,
            notAfter        [1]     GeneralizedTime OPTIONAL
       }

    3.4.1.5  Certificate Policies

    Esta extensão contém uma sequência não vazia de termos de informação sobre política de certificação. Cada item consiste de um identificador de objeto (OID) e, opcionalmente, qualificadores que especializam a política correspondente. Uma política de certificação mapeia a funcionalidade pretendida para o uso do certificado e da chave por ele transportada, para elementos das camadas superiores da ICP, quais sejam, o seu regime jurídico e regulativo, e seus procedimentos não computacionais. O uso da extensão é o seguinte:

  • 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 uma entidade certificadora não deseja limitar o conjunto de políticas vigentes em certificados subordinados aos que emite, pode incluir nesse certificado a extensão any-policy, cujo OID é { 2 5 29 32 0 }

    Aplicações com requisitos específicos de políticas de certificação devem operar com uma lista de identificadores e qualificadores aceitáveis, e compará-los com os OIDs da política do certificado que se tenta inserir 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.

    O CPS pointer é o qualificativo que transporta um URI (Universal Resource Identifier) apontando para um documento que define a política de certificação do emissor. Nos regimes normativos hora em uso, este documento é chamado "Declaração de Práticas de Certificação" (ou CPS, Certificate Practice Statement).

    O User Notice é um qualificativo destinado a permitir à aplicação exibir ao usuário texto informativo sobre a política de certificação do emissor do certificado. Trata-se de um objeto com dois campos opcionais, um deles -- explicitText -- para transportar texto de até 200 carcateres (limite nem sempre respeitado por emissoras). A aplicação deve exibir o explicitText de cada certificado que contenha um, numa cadeia de certificação.

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

       anyPolicy OBJECT IDENTIFIER ::= { id-ce-certificate-policies 0 }

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

       PolicyInformation ::= SEQUENCE
       {    policyIdentifier   CertPolicyId,
            policyQualifiers   SEQUENCE SIZE (1..MAX) OF PolicyQualifierInfo OPTIONAL
       }
       CertPolicyId ::= OBJECT IDENTIFIER

          PolicyQualifierInfo ::= SEQUENCE
       {    policyQualifierId  PolicyQualifierId,
            qualifier          ANY DEFINED BY policyQualifierId
       }
       -- policyQualifierIds for Internet policy qualifiers

       id-qt          OBJECT IDENTIFIER ::=  { id-pkix 2 }
       id-qt-cps      OBJECT IDENTIFIER ::=  { id-qt 1 }
       id-qt-unotice  OBJECT IDENTIFIER ::=  { id-qt 2 }

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

       Qualifier ::= CHOICE {
            cPSuri           CPSuri,
            userNotice       UserNotice }

       CPSuri ::= IA5String

       UserNotice ::= SEQUENCE {
            noticeRef        NoticeReference OPTIONAL,
            explicitText     DisplayText OPTIONAL}

       NoticeReference ::= SEQUENCE {
            organization     DisplayText,
            noticeNumbers    SEQUENCE OF INTEGER }

       DisplayText ::= CHOICE {
            ia5String        IA5String      (SIZE (1..200)),
            visibleString    VisibleString  (SIZE (1..200)),
            bmpString        BMPString      (SIZE (1..200)),
            utf8String       UTF8String     (SIZE (1..200)) }

    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.

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

       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.
    •   id-ce-subjectAltName OBJECT IDENTIFIER ::=  { id-ce 17 }

      SubjectAltName ::= GeneralNames

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

      GeneralName ::= CHOICE
      {     otherName                       [0]     OtherName,
            rfc822Name                      [1]     IA5String,
            dNSName                         [2]     IA5String,
            x400Address                     [3]     ORAddress,
            directoryName                   [4]     Name,
            ediPartyName                    [5]     EDIPartyName,
            uniformResourceIdentifier       [6]     IA5String,
            iPAddress                       [7]     OCTET STRING,
            registeredID                    [8]     OBJECT IDENTIFIER
       }

       OtherName ::= SEQUENCE
       {    type-id    OBJECT IDENTIFIER,
            value      [0] EXPLICIT ANY DEFINED BY type-id
       }

       EDIPartyName ::= SEQUENCE
       {    nameAssigner            [0]     DirectoryString OPTIONAL,
            partyName               [1]     DirectoryString
       }

    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.

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

       IssuerAltName ::= GeneralNames

    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.

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

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

    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.

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

       BasicConstraints ::= SEQUENCE {
            cA                      BOOLEAN DEFAULT FALSE,
            pathLenConstraint       INTEGER (0..MAX) OPTIONAL }

    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]

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

          NameConstraints ::= SEQUENCE
          {    permittedSubtrees       [0]     GeneralSubtrees OPTIONAL,
               excludedSubtrees        [1]     GeneralSubtrees OPTIONAL
          }

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

          GeneralSubtree ::= SEQUENCE
          {    base                    GeneralName,
               minimum         [0]     BaseDistance DEFAULT 0,
               maximum         [1]     BaseDistance OPTIONAL
          }

          BaseDistance ::= INTEGER (0..MAX)

    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.

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

       PolicyConstraints ::= SEQUENCE {
            requireExplicitPolicy           [0] SkipCerts OPTIONAL,
            inhibitPolicyMapping            [1] SkipCerts OPTIONAL }

       SkipCerts ::= INTEGER (0..MAX)

    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.

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

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

       KeyPurposeId ::= OBJECT IDENTIFIER

    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:

       anyExtendedKeyUsage OBJECT IDENTIFIER ::= { id-ce-extKeyUsage 0 }

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

       id-kp-serverAuth             OBJECT IDENTIFIER ::= { id-kp 1 }
       -- TLS WWW server authentication
       -- Key usage bits that may be consistent: digitalSignature,
       -- keyEncipherment or keyAgreement

       id-kp-clientAuth             OBJECT IDENTIFIER ::= { id-kp 2 }
       -- TLS WWW client authentication
       -- Key usage bits that may be consistent: digitalSignature
       -- and/or keyAgreement

      id-kp-codeSigning             OBJECT IDENTIFIER ::= { id-kp 3 }
       -- Signing of downloadable executable code
       -- Key usage bits that may be consistent: digitalSignature

       id-kp-emailProtection         OBJECT IDENTIFIER ::= { id-kp 4 }
       -- E-mail protection
       -- Key usage bits that may be consistent: digitalSignature,
       -- nonRepudiation, and/or (keyEncipherment or keyAgreement)

       id-kp-timeStamping            OBJECT IDENTIFIER ::= { id-kp 8 }
       -- Binding the hash of an object to a time
       -- Key usage bits that may be consistent: digitalSignature
       -- and/or nonRepudiation

       id-kp-OCSPSigning            OBJECT IDENTIFIER ::= { id-kp 9 }
       -- Signing OCSP responses
       -- Key usage bits that may be consistent: digitalSignature
       -- and/or nonRepudiation

    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.

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

       InhibitAnyPolicy ::= SkipCerts

       SkipCerts ::= INTEGER (0..MAX)
    .
    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].

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

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

       DistributionPoint ::= SEQUENCE {
            distributionPoint       [0]     DistributionPointName OPTIONAL,
            reasons                 [1]     ReasonFlags OPTIONAL,
            cRLIssuer               [2]     GeneralNames OPTIONAL }

       DistributionPointName ::= CHOICE {
            fullName                [0]     GeneralNames,
            nameRelativeToCRLIssuer [1]     RelativeDistinguishedName }

       ReasonFlags ::= BIT STRING {
            unused                  (0),
            keyCompromise           (1),
            cACompromise            (2),
            affiliationChanged      (3),
            superseded              (4),
            cessationOfOperation    (5),
            certificateHold         (6),
            privilegeWithdrawn      (7),
            aACompromise            (8) }
     

    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.

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

       FreshestCRL ::= CRLDistributionPoints
     
     

    Aula 6
     

        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.
    .
          id-pkix  OBJECT IDENTIFIER  ::=
                   { iso(1) identified-organization(3) dod(6) internet(1)
                           security(5) mechanisms(5) pkix(7)
          }

          id-pe  OBJECT IDENTIFIER  ::=  { id-pkix 1 }
    .
    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.

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

       AuthorityInfoAccessSyntax  ::=
               SEQUENCE SIZE (1..MAX) OF AccessDescription

       AccessDescription  ::=  SEQUENCE
       {       accessMethod          OBJECT IDENTIFIER,
               accessLocation        GeneralName
       }

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

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

       id-ad-ocsp OBJECT IDENTIFIER ::= { id-ad 1 }
    .
    Cada entrada 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.

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

       SubjectInfoAccessSyntax  ::=
               SEQUENCE SIZE (1..MAX) OF AccessDescription

       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 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.

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

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

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

    C2-3.5  Formato X.509 para Listas de Certificados Revogados       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

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

    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

       id-ce-authorityKeyIdentifier OBJECT IDENTIFIER ::=  { id-ce 35 }

       AuthorityKeyIdentifier ::= SEQUENCE {
          keyIdentifier             [0] KeyIdentifier           OPTIONAL,
          authorityCertIssuer       [1] GeneralNames            OPTIONAL,
          authorityCertSerialNumber [2] CertificateSerialNumber OPTIONAL  }

       KeyIdentifier ::= OCTET STRING

    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

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

       CRLNumber ::= INTEGER (0..MAX)
    .
    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.

    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].

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

       BaseCRLNumber ::= CRLNumber
    .
    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.

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

       issuingDistributionPoint ::= SEQUENCE
       {    distributionPoint          [0] DistributionPointName OPTIONAL,
            onlyContainsUserCerts      [1] BOOLEAN DEFAULT FALSE,
            onlyContainsCACerts        [2] BOOLEAN DEFAULT FALSE,
            onlySomeReasons            [3] ReasonFlags OPTIONAL,
            indirectCRL                [4] BOOLEAN DEFAULT FALSE,
            onlyContainsAttributeCerts [5] BOOLEAN DEFAULT FALSE
       }

       DistributionPointName ::= CHOICE {
            fullName                [0]     GeneralNames,
            nameRelativeToCRLIssuer [1]     RelativeDistinguishedName }

       ReasonFlags ::= BIT STRING {
            unused                  (0),
            keyCompromise           (1),
            cACompromise            (2),
            affiliationChanged      (3),
            superseded              (4),
            cessationOfOperation    (5),
            certificateHold         (6),
            privilegeWithdrawn      (7),
            aACompromise            (8)
       }

    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

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

       FreshestCRL ::= CRLDistributionPoints
    .
     

          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)

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

       -- reasonCode ::= { CRLReason }

       CRLReason ::= ENUMERATED
       {    unspecified             (0),
            keyCompromise           (1),
            cACompromise            (2),
            affiliationChanged      (3),
            superseded              (4),
            cessationOfOperation    (5),
            certificateHold         (6),
            removeFromCRL           (8),
            privilegeWithdrawn      (9),
            aACompromise           (10)
       }
    .
    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.pedro.jmrezende.com.br/trabs/SBC.htm

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

       invalidityDate ::=  GeneralizedTime
    .
    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.

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

       certificateIssuer ::=     GeneralNames
     

    Quarto Módulo
     

    Bibliografia

    Material de referência

    Texto de Referência

    Roteiros de aula


    Material de consulta

    Os textos abaixo aprofundam o material abordado no curso.


    v.0 09/03