primeiro módulo
Introdução, ASN.1, BER e DER
segundo módulo
PKCS#1v2.1, PKCS#8
terceiro módulo
Certificados e CRLs X.509
quarto módulo
PKCS#7 e PKCS#12
C2-5 Propostas PKIX para Gerência:
CMP
O roteiro deste módulo seguirá, em sua essência, o conteúdo do capítulo 11 do texto de referência do curso [0], com referêncais ao documento IETF RFC 2510 (apresentado como "proposed standard" em março de 1999, e com último draft -- bis07 -- em novembro de 2002) [9], que discute os protocolos aqui em foco para uso na Internet (PKIX). Do texto de referência, merece nesse ponto a atenção do aluno o capítulo anterior (10), que descreve a influência da arquitetura de certificação de uma ICP (hierárquico, malha ou roteado) no algoritmo de construção de caminho de certificação para aplicações, superficialmente comentado no curso C1, que por sua vez determinam escolhas de e nos protocolos de gerenciamento de certificados, foco deste módulo.
C2-5.1 Introdução ao
Gerenciamento de ICPs
Uma ICP deve ser estruturada de forma consistente com os tipos de indivíduos que irão administrá-la. Permitir escolhas ilimitadas a esses administradores não apenas torna complexa a especificação dos softwares requeridos, mas também aumentam as chances de que sutis falhas administrativas ou de desenvolvimento de software utilizado na ICP descambem em consequências mais graves. Doutra parte, restringir demasiadamente a margem de manobra dos administradores pode redundar em falta de estímulo ou motivação para se aderir à ICPProtocolos de gerenciamento são necessários para dar suporte a transações on-line entre componentes da ICP. Por exemplo, um protocolo de gerenciamento entre uma entidade certificadora (AC) e uma plataforma de cliente à qual um par de chaves é associado, ou entre duas ACs que emitem certificados cruzados uma para a outra. No mais, protocolos de gerenciamento de ICP precisam obter informação confiável de participantes para emitir certificados e CRLs.
Um modelo gerencial de ICP deve começar pela identificação dos agentes que a compõem. Abaixo, completamos a nomeclatura iniciada no módulo 3
Subjects and End Entities (Agentes Titulares ou Entidades Finais)
O termo "subject" é usado em documentação e especificações sobre ICP para se referir a titulares de certificados. Muitas vezes o termo é mal traduzido ao português, como por exemplo, na interface do navegador web mais usado hoje, que traduz subject por "assunto", na sua interface de gerenciamento de certificados. . Quando se referenciar software ou hardware que intermedia a ação da entidade final, deve ser falar de "equipamento da entidade"
Certification Authority (Autoridade ou Entidade Certificadora - AC)
O termo se refere à entidade nomeada no certificado como emissora do mesmo. A autoridade certificadora pode ou não ser uma "terceira parte" do ponto de vista de uma entidade final. Com frequência a AC pertencerá à mesma organização que as entidades a que serve. Quando se referenciar software ou hardware que intermedia a ação da certificadora, deve ser falar de "equipamento da AC". O equipamento de uma AC pode envolver componentes em tempo real (on line) ou não (off line).
Registration Authority (Autoridade ou Entidade de Registro - AR)
Algumas implementações e modelos de ICP preveem a entidade de registro, para cumprir algumas das funções de administrativas e registrais que doutra forma se acumulariam com a AC. Tais funções podem incluir a de autenticar dados pessoais de um cliente de certificado, distribuição de token, divulgação de revogações, atribuição de nomes unívocos, geração ou arquivamento de pares de chaves, etc. Um modelo de gerenciamento deve portanto, contemplar as ARs como opcionais, e separadas das ACs.
C2-5.1.2 Classificação de operações de ICP
Protocolos de gerência precisam atender basicamente dois tipos de requisição: emissão e revogação de certificados. Mas outras premissas influirão sobremaneira na lógica e no desenho de um protocolo destinado a atendê-las, com nível de confiabilidade desejado, de forma que esta primeira classificação pode ser ampliada para os seguintes tipos de requisição
Protocolos criptográficos podem ser classificados, como explicado no curso C1, como auto-verificados (dois agentes), arbitrados (tres ou mais agentes) e ajuizados (terceiro agente off-line). Protocolos de gerenciamento para requisição ou revogação de certificados podem, em princípio serem auto-verificados no caso do protocolo propor-se a atender requisições básicas, isto é, de revogação ou emissão de certificado de cliente da AC com certificado por expirar, por parte do próprio titular.
Two-party
Se o certificado do requerente permite assinatura e cifragem, o protocolo pode, inclusive, dispensar o canal confiável externo ao protocolo, para autenticar a resposta à requisição. Quando o canal externo é usado para completar a transação, como por exemplo, para o envio de senha necessária ao requerente para decriptar/autenticar/acessar o novo certificado emitido, o modelo do protocolo é chamadono texto de referência [0], extended two-party. Esse modelo é hoje bastante usado, devido à sua simplicidade.
Todavia, para os outros casos (certificados iniciais, certificados de certificadoras e revogações indiretas), o protocolo será mais completo com a participação de um terceiro agente, que normalmente vem a ser a AR.
Three-party
Com a participação de AR, protocolos para trasações
gerenciais podem apresentar uma variação considerável
de lógica e desenho. Os modelos variam basicamente acerca das vias
de contacto do requerente inicial com a ICP. As principais opções
são:
Os protocolos de grenciamento mais simples em uso hoje são baseados no padrão PKCS#10, Certificate Request Sintax Standard.
PKCS#10
Esse padrão, que descreve uma sintaxe para requisição, que teve sua origem no padrão PEM, consitui o núcleo dos protocolos mais simples de gerenciamento de certificados. Trata-se de certificado auto-assinado, com o nome unívoco do titular formado pelo requerente e algumas extensões necessárias ao processamento da requisição. A chave pública transportada é aquela cujo certificado se requer, e a assinatura no certificado é produzida pelo par privado desta chave, o que limita seu uso à requisição de ceritificados para chaves de assinatura.
C2-5.1.5 Protocolos em uso
Há cinco protocolos de gerenciamento de certificados comumente usados hoje. Além dos dois mais simples, baseados no formato PKCS#10, existem os protocolos mais completos, que são o CMP (Certificate Management Protocol), CMC (Certificate Management using CMS), e o SCEP (Simple Certificate Enrollment Protocol). Os dois primeiros estão sendo desenvolvidos no âmbito do grupo PKIX, e o segundo, específico para agentes finais que sejam aplicativos, é promovido pela empresa CISCO.
PKCS#10 sobre SSL
Com o protocolo SSL tendo se tornado padrão de fato para autenticação de servidores na web, navegadores podem fazer uso do mesmo para enviar requisições de certificados a partir de páginas web visitadas pelo usuário. Uma AC que receba uma tal requisição, todavia, não poderá validar a identidade do requerente. A implementação mais comum neste caso é do modelo extended two-party, que se vale de um canal externo off line para validar a identificação do requisitante. O autenticador -- uma senha para autenticação ou decriptação do certificado enviado, ou para acesso ao certificado no repositório da certificadora, é enviado por correio comum ou por e-mail..
Quando a implementação é de tres partes, comumente se usa o terceiro agente (RA) para verificar off-line a identidade do requerente, com o certificado emitido pela CA apenas após a resposta da RA (trhee party modelo 3).
CMP
Este é o mais completo e abrangente protocolo de gerenciamento de certificados já proposto, documentado nas RFCs 2510 e 2511. Vem sendo desenvolvido pelo PKIX, sendo a primeira versão do padrão de 1999 [9]. O CMP procura se desviar dos padrões PKCS#7 e #10, devido a questões de direitos autorais que ainda não estavam claras na ocasião.
CMC
O protocolo CMP mostrou-se bastante complexo, e, alem disso, distanciava-se dos padrões de fato em uso, que integravam o formato PKCS#10 a formatos e protocolos mais gerais, já em uso, como o PKCS#7 e o SSL. A indústria envolvida resolveu então propor um padrão alternativo, mais simples e mais compatível com os padrões de fato em uso.
Quando a RSA cedeu os direitos de trabalhos derivativos sobre os PKCS ao IETF S/MIME, foram superados os obstáculos para que o padrão CMC -- Certificate Management using CMS -- também se desenvolvesse sob os auspícios do PKIX. Firmou-se então um acordo entre os dois grupos (CMP e CMC) para que os dois padrões usassem o mesmo formato de mensagem de requisição de certificados, e o padrão CMC foi acolhido como Proposed Standard no RFC 2797.
SCEP
Simple Certificate Enrollment Protocol foi desenvolvido pela empresa Cisco Systems, "para dar suporte à emissão segura de certificados a seus dispositivos de rede de maneira escalável". É um protocolo específico para aplicações (agentes finais que são softwares), para emissão de certificados para dispositivos de rede, e acesso a CRLs e certificados em repositórios. Nada mais.
Material de referência
Texto de Referência
Os textos abaixo aprofundam o material abordado no curso.