Debate sobre Certificação Digital

Debate com o acadêmico do Direito Caio César,
sobre questões pertinentes à certificação digital

Prof. Pedro Antonio Dourado de Rezende
Depto. Ciência da Computação - Universidade de Brasília
Fevereiro de 2004

---

Em fevereiro de 2004 Caio César e o autor travaram, numa troca de email, o seguinte debate.

email 1
 

1. No processo de revogação dos certificados digitais podem ser feitos por listas de revogação e de forma on-line. Quais são as vantagens e desvantagens de cada um? Por que  nas listas de revogação não precisam estar em ambientes confiáveis e na on-line existe essa necessidade?

Precisamos acurar o uso de dois termos em sua pergunta. Creio que sua pergunta esteja empregando "processo de revogação" como sinonimo de processo de validação (validação quanto à possível revogação do certificado, anterior ao prazo final de sua validade), e "confiável" como sinonimo de "sigiloso".

O processo de revogação é aquele em que o titular de uma par de chaves assimétricas, ou autoridade competente, solicita a revogação de um certificado digital de chave pública, devido a algum motivo considerado válido pela política de certificação de quem emitiu tal certificado.

Este processo não é feito por CRL (lista de revogação), mas por protocolo e documentos próprios. Gera, outrossim, como desfecho positivo uma entrada na base de dados dos certificados emitidos/revogados/expirados e, conforme o caso, em CRLs. Dependendo do nível de segurança do certificado a ser revogado, a revogação propriamente dita não deve ser feita on-line, mas com rito semelhante ao do registro.

Já a validação do certificado (verificação de sua possivel revogação, independente da verificação de sua integridade), esta sim, requer um de dosi métodos: ou o método CRLs (em processo off-line relativo à certificadora), ou o protocolo OCSP (em processo on-line com a certificadora), dentro do escopo da padronização PKIX.

"Confiável", por sua vez, só pode ser considerado sinonimo de sigiloso -- que se aplicaria no caso do OCSP e não das CRLs -- em cenários de risco bastante restritos ou simplistas, o que não é o caso.

CRLs (ou LRCs, listas de revogação de certificados) não precisam, como vc lembra, serem armazenadas ou transportadas em sigilo, mas isto não significa dizer que não requeiram ambiente confiável para uso devido, qual seja, ambiente onde se possa fazer a verificação de sua integridade. Doutra feita, não existe processo criptográfico sem premissa de confiança: no caso as CRLs, que são documentos digitalmente assinados, como tal necessitam ter sua integridade verificada através da checagem, imediatamente antes do seu uso, da assinatura nela aposta pelo suposto emissor. Nisso, ou seja, quanto a essa necessidade, as CRL são idênticas aos certificados x-509.

Quais são as premissas de confiança dessa verificação de integridade? A verificação de qualquer assinatura digital com base em certificados digitais de chave pública circulando em rede aberta desencadeia um processo recursivo de verificações (de assinaturas em certificados) que, para terminar, precisa necessariamente terminar num ponto cego de confiança do processo. No padrão x-509, este ponto será um certificado auto-assinado.

Tais certificados terminais são chamados auto-assinados porque a chave para verificar sua integridade é a mesma cuja integridade se quer verificar: a chave nele transportada. Esses certificados precisam, por tal motivo, ter sido transportados em um canal "out-of-band" confiável, confiável em relação à integridade no transporte e identificação do emissor. Como essa confiança não pode ser provida pelo protocolo que usa o certificado auto-assinado, este uso é ponto cego de confiança do protocolo, pois dele o protocolo precisa presumir confiança prévia.

No ambiente computacional onde se verifica assinaturas utilizando-se certificados x-509, o ponto de confiança de tal processo será, assim, um certificado auto-assinado, previamente instalado nesse ambiente, que possa encerrar uma cadeia de certificação iniciada no certificado que se quer utilizar para verificação de uma dada assinatura. No modelo de raiz única, este certificado auto-assinado terminal terá sempre um mesmo e único agente como titular, por isso chamado certificado-raiz. Resumindo: neste caso, a integridade deste certificado-raiz, ali instalado, é presumida por meios externos aos protocolos criptográficos sendo executados.

Portanto, não só a verificação da assinatura num certificado, mas também a verificação da assinatura numa CRL que poderia invalidar este certificado, iniciam e determinam cadeias de certificação, cadeias que precisam ser verificadas e que terminam em algum certificado auto-assinado, cujo uso pressupõe confiança extra-protocolo. Se a cadeia iniciada por tal certificado terminar no mesmo ponto que a cadeia iniciada por tal CRL, como  no caso do modelo de raiz única, as premissas de confiança para verificação da integridade do dito certificado serão as mesmas premissas de confiança para validação deste certificado (quanto à sua possivel revogação, via CRL).

Caso tais cadeias não terminem no mesmo ponto, apesar de não serem as mesmas, essas premissas de confiança serão equivalentes, já que ambas se assentam na confiança que se pressupõe que o usuário deposite no ambiente computacional onde mantém, e num canal out-of-band onde identifica, e através do qual recebe, certificados auto-assinados.

No modelo de raiz única, as premissas de confiança para essas duas cadeias são as mesmas, já que ambas terminam no mesmo certificado-raiz. E se, nesse modelo, cada certificadora for responsável pela emissão das CRLs dos certificados por ela emitidos (como parece ser a norma na ICP-Br), não só as premissas de confiança, mas também toda a cadeia de certificação serão as mesmas (para o certificado e para a CRL).

Já o protocolo OCSP (On-line Certificate Status Protocol) requer, por razões que se farão óbivas, um pouco mais, tanto em termos de protocolos criptográficos quanto de premissas de confiança. O resultado da consulta sobre o status de um certificado (se revogado ou não) é enviado em mensagem assinada e cifrada. Portanto, as premissas de confiança para verificação dessa assinatura (na resposta à consulta) são equivalentes (e no modelo de raiz única são idênticas) às da verificação de integridade de CRLs.

Além da verificação de integridade do resultado da consulta do status do certificado, enviada ao software consultante pelo responsável pela possível revogação do mesmo (normalmente a propria entidade que o emitiui) através de rede aberta, há também a necessidade de sigilo na comunicação entre ambos. O motivo para o sigilo é simples, mas talvez ainda obscuro em uma primeira análise.

De qualquer forma resta observar que, no OCSP, tanto o estabelecimento do sigilo entre usuário do certificado e entidade consultada, quanto a verificação da integridade da resposta à consulta sobre o status desse certificado, farão uso de uma cadeia de certificação que terá, no modelo de raiz única e sob a perspectiva do usuário do certificado, as mesmas premissas de confiança para verificação de integridade deste certificado ou da respectiva CRL: a saber, a integridade da instalação e da identificação de origem do certificado-raiz.

E quanto à necessidade do sigilo no OCSP? Antes de explicarmos, seria melhor falarmos das vantagens e desvantagens dos dois métodos de validação de certificados.

A vantagem do OCSP em relação à CRL estaria na latência da informação sobre o status do certificado, "quase" nula com o OCSP, e proporcional à frequência de emissão de CRLs. Porém, se considerarmos o que significa esse "quase", e que o problema de latência é muito maior para o titular do que para o usuário de um certificado, veremos que esta vantagem é relativa e, quiçá, ilusória, pelo menos para alguns refenciais de risco.

Num cenário típico que leva em conta o estado médio da segurança de usuários de plataformas computacionais, hoje prevalente tanto em abientes privados como institucionais, havendo intrusão com vazamento ou uso indevido da chave privada, o titular só terá, via de regra, indícios que o motivem a solicitar revogação quando perceber que foi vítima de fraude, situação na qual a revogação, mesmo que instantaneamente processável e comunicável, lhe seria, contra tal risco, inóqua. E caso a revogação pudesse retroagir, as possibilidades de fraudes "legais" seriam horrendas.

Além disso, há argumentos, levantados por quem analisa os riscos pertinentes ao negócio da certificação digital, sustendando que, pelo menos para certificados com maior nível de segurança, a revogação deve ser um processo lastreável em prova documental, semelhante ao registro, e portanto, com considerável latência de processamento (o que significa aceitar pedido de revogação de uma chave comprometida que tenha sido assinado pela mesma?).

Por outro lado, para a certificadora, o risco com o serviço de status on-line é bem maior que o de CRLs (como veremos), motivo pelo qual não se vê muita oferta do mesmo no mercado. Do ponto de vista da análise de riscos a diferença básica entre os dois métodos de validação (OCSP e CRLs) está em um parâmetro de segurança normalmente negligenciado por empresários e analistas, semelhante a -- porém distinto de -- sigilo: privacidade.

Quem requisita uma CRL não precisa dizer ao emissor da mesma qual certificado deseja validar. Ao passo que, com o OCSP, quem faz uma consulta precisa revelar de qual certificado, exatamente, lhe interessa conhecer o status. Esta informação, do lado da certificadora, pode ser valiosa para quem esteja disposto a trafegar influência em má fé, para a consecução de fraude interna.

Existem várias situações hipotéticas em que o responsavel pelo serviço OCSP na entidade certificadora poderia se beneficiar de conluio com clientes (titulares de certificados) para, em conjunto com brechas relativas a falta de transparencia e auditabilidade na prestação do serviço, interferir impunemente na execução do protocolo, induzindo usuários de certificados (com quem a entidade não mantém nenhuma relação contratual explícita) a erros de julgamento. Com o agravante de que tais erros de julgamento poderiam ser causados por comportamento anômalo no OCSP mais facilmente atribuível a falhas operacionais de origem e responsabilidade incerta ou difusa, do que a má fé do operador do protocolo na ponta da certificadora.

Além disso, existem riscos externos para os quais a cifragem da comunicação OCSP é a melhor defesa. Como a consulta via OCSP precisa revelar qual certificado o interlocutor está interessado em validar, e, além disso, precisa ocorrer em sessão TCP sobre IP, certos tipos de ataque pela rede seriam em princípio possíveis, caso a comuincação ocorra às claras, para alguém interessado em fraudar o consultante. Na ausência de cifragem o atacante poderia sequestrar a sessão autenticada entre usuário e certificadora, para injetar resposta falsa ao primeiro, passando-se pelo segundo (na presença de cifragem, caso o sequestro de sessão ocorra a tentativa de decifragem revelaria a interferência).

Ainda na esfera dos riscos de ataque externo, a certificadora precisa se expor a maiores riscos de invasão à sua base de dados de certificados revogados, mais facilmente corrompível em má fé com a diminuição do número de camadas de proteção e filtragem de processamento e tráfego entre suas redes interna e externa, se quiser que o serviço de consulta a status de certificados emitidos funcione on-line, como prescreve o OCSP.

2.  O senhor  acha que o modelo que está sendo adotado pela ICP-Brasil é o mais adequado para ser implementado aqui? Na sua opnião, quais as vantagens e desvantagens do modelo hierárquico adotado pela ICP? ( Minha opnião *->* Acho que esse modelo foi um grande iniciativa para o desenvolvimento da pesquisa sobre o tema no país, mas acredito que a forma que ele está sendo implementada é muito excludente e antidemocrática. Digo isso baseado na MP 2200-2, que praticamente foi criada para instituir a ICP-Brasil, mas, na verdade, pouco regulou sobre a implantação da infra-estrutura de chave pública de forma geral).

Esta pergunta eu abordei em relatório entregue à autarquia responsável pela operacionalização da ICP-BR, o ITI, em http://www.pedro.jmrezende.com.br/trabs/forumiti.htm

3. Também gostaria que o senhor comentasse sobre a impossibilidade de se possuir um único certificado digital tanto no processo de autenticação como para criptografia de dados, que na minha opnião limita o modelo adotado pela ICP-Brasil?

Não está muito claro para mim sobre o que se refere a pergunta, mas posso supor que "autenticação" se refira a assinatura digital, e "criptografia de dados" se refira a cifragem/decifragem para sigilo (ambas são aplicações de algoritmos criptográficos assimétricos, com funcionalidades distintas).

Na primeira dessas funcionalidades, a chave privada do emissor do um documento inicia o processo criptográfico, produzindo um autenticador para um arquivo onde este documento está representado, com a correspondente chave pública empregada ao final, por iniciativa de um destinatário que queira verificar a integridade e origem desse arquivo. Na cifragem/decifragem para sigilo, a chave pública do destinatário é que inicia o processo criptográfico, e a correspondente chave privada é a que o finaliza, por iniciativa do destinatário que queira conhecer o conteúdo transmitido, decifrável somente por sua chave privada.

Portanto, na assinatura (assinatura aqui no sentido de processo autenticatório), primeiro é usada uma chave privada (a do emissor), para a lavra de uma assinatura (assinatura aqui no sentido de marca autenticatória, anexada ou vinculada a um documento digital com o propósito de identificar o seu emissor e a integridade do seu conteúdo sintático), e depois a chave pública correspondente é usada para a verificação dessa assinatura (isto é, para validação desta marca autenticatória). Enquanto, na cifragem/decifragem, primeiro é usada uma chave pública (a do destinatário) para a cifragem, e depois a chave privada correspondente para a decifragem, pelo destinatário.

Por isso, para que um par de chaves assimétricas (pública/privada) possa ser usado em qualquer das duas funções (assinatura e cifragem/decifragem), uma chave de um par qualquer precisa inverter a operação executada pela outra chave do par, qualquer que seja a ordem em que são empregadas no processo (na assinatura ou na cifragem/decifragem).

Se exibir tal propriedade (a propriedade de que as operações criptográficas com as chaves publica e privada de qualquer par de chaves comutam), um algoritmo criptográfico assimétrico é chamado de comutativo. Existem algoritmos criptográficos assimétricos que são comutativos (ex: RSA, El Gamal, etc), para os quais um par de chaves pode, portanto, ser usado tanto para assinatura quanto para cifragem/decifragem. E existem algoritmos que não são comutativos (ex: DSA, Rabin, etc.), para os quais um par de chaves serve apenas para uma dessas duas funções (assinatura ou cifragem/decifragem).

Para se obter um certificado, é preciso que um par de chaves assimétricas tenha sido antes gerado (geralmente este é o primeiro passo no processo de emissão do certificado, que deve ser executado pelo software do solicitante). A geração de um par de chaves começa pela escolha do algoritmo a que se destina. A escolha de algoritmo, por sua vez, determina a possibilidade técnica do par de chaves ser útil ou não para uma ou duas funções. Desse par, o certificado será o meio de transporte da chave que é pública.

Mas isso não é só o começo.

O padrão x-509 é uma sintaxe e semânticas para certificados digitais de chave pública, que são documentos digitais destinados ao transporte interoperável de tais chaves devidamente tituladas. O padrão x-509, junto com o conjunto de extensões e especializações destinado para uso desse padrão na internet, conhecido pela sigla PKIX, determinam que o certificado deve (pode) conter um campo descrevendo a função pretendida para a chave pública nele transportada. Esse campo é chamado de extensão "key usage".

Diferentemente do campo "algorithm identifier", obrigatório no x-509, a extensão PKIX "key usage" carrega informação redundante. Isto porque o software que vai manipular o certificado já incorpora, em seu código, na função pretendida pelo usuário desse software, o conhecimento de como o usuário do software pretende usar a chave pública que está contida no certificado (verificação de assinatura ou cifragem). Ao passo que a informação sobre qual é o algoritmo alvo daquela chave o software só pode conhecer através do próprio certificado.

Se a identificação do algoritmo a que se destina a chave, junto com a mesma, estiver correta no certificado, e se o software que manipula o certificado tiver implementado corretamente este algoritmo, o software selecionará corretamente a operação cripográfica pretendida para a chave no certificado, evitando erro no uso do certificado por falha de comunicação (a respeito da função e do modo criptográfico a que se destina a chave).

Se o algoritmo não for comutativo, não adianta o usuário, ou o software, quererem usar a chave pública para uma função à qual ela não se encaixa. Ao passo que se o algoritmo for comutativo, nada impede que a chave funcione corretamente, qualquer que seja a função (verificação de assinatura ou cifragem) que o usuário do software tenha selecionado.

Assim, se o certificado contiver, por exemplo, uma chave RSA, esta chave poderá ser usada, pelo software que manipular este certificado, para ambas as funções, já que o RSA é comutativo.

O que a ICP-Br determina, é que as certificadoras credenciadas devem (são obrigadas a) emitir certificados contendo a extensão "key usage" estipulando que a chave ali trasportada se destina a uma só função, qualquer que seja o algorimo, mesmo se comutativo.

No caso do algoritmo a que se destina a chave ser o RSA, há uma razão prática para se restingir o uso do par de chaves a apenas uma função: a cautela. O padrão PKIX recomenda que a política de certificação da entidade certificadora inclua restrição do tipo "apenas um uso" na extensão "key usage" de certificados de chaves públicas RSA, devido à possibilidade teórica de certos tipos de ataque ao uso do RSA se tornarem plausíveis, em determindads circunstâncias, quando um par de chaves estiver sendo usado tanto para assinatura quanto para cifragem/decifragem.

Doutra feita, esta possiblidade teórica não atinge o algoritmo El Gamal, nem a outras variantes dele que fazem uso de aritmética de curvas elípticas. Isto porque a segurança do RSA se baseia na dificuldade computacional de um problema matemático (fatoração de números inteiros) que é distinto do problema em que se baseia o El Gamal e variantes (logaritmo discreto).

Mas a norma da ICP-Br foi além do que recomenda o PKIX, tornando aquela a recomendação de restrição funcional obrigatória, e não só para o RSA, mas para qualquer algoritmo. Outrossim, o risco técnico que representa o uso de um par de chaves RSA para as duas funções é, a meu ver, ordens de grandeza inferior aos riscos decorrentes do fator humano, que se apresentam na possibilidade de conluio ente agentes que alimentam interesses aparentemente distintos no processo, ou mesmo riscos técnicos decorrentes de falhas de implementação dos softwares.

Ocorre que o software que irá manipular um certificado não faz parte, pelo menos por enquanto, do processo de credenciamento à ICP-Br. E portanto tal software não estará, em princípio, obrigado a respeitar o que determina a extensão "key usage" em certificados emitidos por certificadoras credenciadas à ICP-Br. E o software pode, se assim quiser seu programador, ignorar aquela restrição funcional da norma ICP-Br ocorrente nessa extensão, em qualquer certificado que transporte chave pública de algoritmo comutativo, sem prejuízo formal da funcionalidade do software. Mas, nesse caso, haverá senões.

Primeiro, uma questão prática: a capacidade desse software desprezar uma tal restrição funcional pode se tornar inóqua, por uma questão de interoperabilidade -- se o software usado na outra ponta do processo (assinatura ou cifragem/decifragem) honrar a restrição, de nada adianta ele ignorar, pois não terá com quem conversar "fora da norma". Além disso, se o usuário escolher um algoritmo pouco difundido quando vai gerar seu par de chaves, poderá ter problemas de interoperabilidade decorrente desta escolha (o RSA é o algoritmo mais difundido)

Segundo, uma questão legal. Se a escolha de ertificadora credenciada à ICP-Br para emissão de certificado objetivar algum respaldo jurídico de atos praticados eletronicamente, esta capacidade do software de desprezar a restrição funcional da extensão "key usage" perderia sua utilidade.

Por outro lado, se um uso particular de certificados digitais de chave pública não levar em conta a necessidade de aderência à norma ICP-Br, mesmo para se buscar o devido respaldo jurídico dos atos eletronicos praticados com seu intermédio, talvez por se acreditar que hajam falhas jurídicas na MP2200, como acreditam membros da comissão de informática jurídica da OAB, os que desejem um certificado somente para ambas funções -- assinatura e cifragem/decifragem -- podem buscar, no mercado ou na internet, uma certificadora que não imponha tal restrição funcional na extensão "key usage" de certificados com chave comutativa, escapando assim dos problemas de interoperabilidade anteriormente citados.

A impossibilidade de se usar um só par de chaves para ambas as funções -- assinatura e cifragem/decifragem -- é, portanto, relativa: depende formalmente do algoritmo alvo da chave no certificado (se comutativo ou não), depende operacionalmente da política de certificação da emissora do certificado, e depende pragmaticamente de limitações de interoperabilidade de softwares em uso, que daí decorrem. No caso da norma ICP-Br, motivos para que tal impossibilidade tenha nela se absolutizando se fazem especuláveis, através das mudanças ocorridas na linguagem das versões anteriores da MP2200-2 (MP2200, de 28/06/01 e MP2200-1, de 26/07/01)

Outro sentido que sua pergunta poderia estar denotando é o da política de certificação para uso geral, perseguida desde o início pela primeira gestão do comitê gestor, cujos riscos analiso em http://www.pedro.jmrezende.com.br/trabs/forumiti.htm, onde também abordo o tema da sua última pergunta, pertinente a vantagens e desvantagens nos modelos de ICPs.

---

email 2

Gostaria de saber como funciona o processo de atualização de um  certificado, ou melhor, da recuperação de chaves públicas antes dela expirar?

No processo de "atualização" de certificados X.509, apenas o registro do titular é recuperado e, se necessário, atualizado. Um novo par de chaves deve ser gerado segundo os padrões PKIX. Talvez em algum formato fechado, tipo PGP, uma reemissão de certificado com a mesma chave possa ocorrer, mas não nos padrões PKIX.  No PKIX as chaves propriamente não são recuperadas. Quando a requisição ocorre por intermédio do navegador que usa SSL, este gera um novo par de chaves como se fosse pedir um certificado novo, e a certificadora reusa apenas a parte do certificado velho que não se altera, o que não inclui a chave publica, campos correlatos e a sua assinatura no certificado.
.

Também gostaria de saber como uma pessoa poderá visualizar um documento que foi criptografado por uma chave privada, depois que a chave pública correspondente ou certificado dessa chave expirar?

Uma chave privada não criptografa mensagem. Ela criptografa o hash de uma mensagem para produzir um autenticador (assinatura do titular na mensagem), se sua função for autenticatória, ou decripta um envelope digital (desvela uma chave de seção), se sua função for a privacidade.

Além disso, há que se notar que nesses dois casos as chaves privadas são de titulares distintos: a do remetente para lavrar
assinatura, e a do destinatário para abrir envelope digital.

Quando se trata do segundo caso (a chave pública do destinatário teria sido usada para fechar envelope digital) é que, segundo o padrão x.509, esta chave pública não deve ser usada após o prazo de validade do certificado que a transporta.

O que não é o caso da chave pública do signatário, que estaria sendo usada para verificação de assinaturas em mensagens ou documentos. Isto porque pode haver a necessidade de, havendo transcorrido o prazo de validade do certifica, verificar-se uma assinatura que tenha sido lavrada dentro do seu prazo de validade.

A assinatura deve ser invalidada por expiração de prazo de certificado apenas quando puder ser estabelecido que o documento teria sido assinado após o prazo de validade do certificado, ou quando o certificado não puder ser validado por outros certificados que vigiram no mesmo prazo.

Embora a data em que foi lavrada a assinatura e a data de verificação não sejam normalmente as mesmas, pode-se supor que serão muito próximas em casos bem especificos de importância, como o correio eletrônico, por exemplo. Mas para documentos que serão arquivados, esta não será a regra, mas a excessão. Nesse caso o software que verifica assinaturas deve levar em conta o fato que essas duas datas podem ser distantes.

Mas de volta à sua pergunta, no caso do uso das chaves para privacidade quem enviou o criptograma deveria saber, pelo prazo de validade do certificado, que o titular pode não mais estar guardadndo a chave privada correspondente, depois de expirada. Caso ele encripte com a chave antes de vencer o prazo, para armazenamento e posterior acesso pelo titular, aí o titular é que deve se prevenir para esses casos, e não jogar fora sua chave privada quando o certificado correspondente expira. Como por exemplo, se ele considera a possivel necessidade de acesso a arquivos armazenados de forma encriptada.

Há tambem um caso interessante, onde o signatário usa a chave pública antes desta expirar, mas desejando que o titular só possa abrir o criptograma tempos depois. Algoritmos e protocolos para esse tipo de aplicação se chama criptografia temporal, e existe um pesquisador brasileiro na UFSC, prof. Ricardo Custódio, que se dedica ao tema.

No final, é o software que decide como interpretar os campos do x.509, nos quais se incluem as datas de início e final de validade. Fica a critério do software, portanto, a semântica de datas nos certificados e no documento, notando-se, entretanto, que o preço a pagar por não respeitar a semântica padrão -- como por exemplo as da PKIX -- será a interoperabilidade com outros softwares numa PKI.

Como funciona o método de suspensão de um certificado? Ele é determinado somente pela lista de revogação de certificados?

Suspensão é uma revogação temporaria que pode expirar ainda dentro do prazo de validade do certificado. O status de certificado suspenso pode ser comunicado tanto através de CRLs como do protocolo OCSP. Está especificado, mas unca o vi sendo usado na prática.

A lista de revogação apenas registra a informação de que determinado certificado encontra-se suspenso por determinado período. O processo de suspensão em si é feito antes da insersão deste registro em CRLs, por um protocolo que nunca vi implementado. Quem já vi tocar neste assunto com mais detalhe, mas apenas do ponto de vista teórico e técnico, são os
autores de "planning for PKI", de Russ Housley e Tim Polk, que estão envolvidos na padronização PKIX.

Qual as diferenças entre o certificado emitidos numa ICP, no SPKI e no SET ?

A diferença está no uso de extensões, e na semantica dessas extensões, que geralmente empregam a sintaxe dos certificados x.509. Pelo menos para as PKIs hoje em operação e o SET (que está sendo descontinuado, devido à sua complexidade).

Qual a vantagem do certificado de atributo em relação ao Kerberos?

O kerberos usa apenas criptografia simétrica, o que impõe premissas de confiança para o uso do protocolo irrealizáveis em uma rede genuinamente aberta, como a Internet em si.

---

* - Em email de 2-02-2004 16:27, o remetente autorizou a publicação deste debate neste site e nesses termos.