Resumo

  • O RFC 1805 propôs um certificado assinado por terceiro confiável que registrava o hash de um arquivo, a data e a forma de identificar seu autor, sem prender a verificação ao lugar de download.
  • A identificação do autor ficou aberta no protocolo. Na implementação Betsi descrita pela Bellcore, o terceiro buscava o telefone local e ligava para conferir os dados de registro.

O arquivo viaja; a reputação do autor não pega carona automaticamente. Aviel Rubin tratou dessa diferença no RFC 1805, publicado em junho de 1995. A proposta punha em cena autor, usuário e terceiro confiável. O arquivo podia vir de um site suspeito; um certificado separado permitia conferir seus bytes e sua data. O detalhe que dá vida à história é a identificação. No sistema Betsi da Bellcore, o terceiro usava a infraestrutura telefônica para descobrir o número do autor e retornar a ligação. A rede distribuía o arquivo; a confiança ainda precisava falar com alguém.

Rubin desconfiava até do programa de verificação. Se um atacante modifica o arquivo e a ferramenta encarregada de fiscalizá-lo, um selo verde na tela vira piada de mau gosto. Por isso o desenho usava mensagens ASCII e sistemas conhecidos de assinatura, permitindo que o destinatário criasse seu próprio verificador ou obtivesse uma cópia confiável por outro caminho. O protocolo não apostava a prova inteira num aplicativo especial. Repartia a verificação em passos que podiam ser repetidos.

Esses passos formavam cinco fases: registro do autor, verificação de identidade, certificação do arquivo, distribuição e conferência final. A segunda fase foi deixada em aberto de propósito. Diferentes aplicações poderiam verificar autores de formas diferentes, desde que o método aparecesse no certificado. A assinatura prova uma ligação com a chave; dizer de quem é a chave exige outro trabalho. Segundo o RFC, Betsi funcionava nos Estados Unidos. O terceiro consultava o serviço telefônico da cidade do autor, ligava para o número encontrado e confirmava as informações enviadas, em especial a chave pública.

Telefonar era a solução dessa implementação, não a regra universal do protocolo.

Depois do registro, o autor calculava o hash criptográfico do arquivo e enviava um pedido de certificação assinado. O terceiro verificava o pedido e devolvia um certificado assinado por ele, com hash, função usada, data, nome do autor e método de verificação de identidade. O endereço onde o arquivo estava guardado era opcional no pedido. Isso muda a superfície da confiança: a declaração se referia ao conteúdo e ao tempo, não ao diretório FTP que abrigava uma cópia. Arquivo e certificado podiam ser distribuídos juntos por redes e sites inseguros.

O destinatário tinha uma lista própria de tarefas. Precisava obter a chave pública do terceiro por fontes independentes, verificar a assinatura dele, julgar o método de identificação declarado, calcular o hash do arquivo recebido e comparar os resultados. Se a data importasse, deveria examiná-la também. Por fim, consultaria a lista de certificados revogados, atual, completa e assinada pelo terceiro. Uma assinatura bonita não salva um certificado revogado.

Ao fim, o sistema sustentava uma afirmação precisa sobre os bytes recebidos e o momento em que aqueles bytes foram certificados, condicionada à cadeia de identidade e revogação examinada. Não decidia se executar o software seria uma boa ideia. A ligação telefônica revela a estrutura: era possível soltar a integridade do arquivo do endereço de origem, mas a autoridade da identidade ainda tinha um lugar e um responsável.