Resumo

  • O RFC 1421 instalou o processamento do Privacy Enhanced Mail nas pontas, permitindo que retransmissores SMTP existentes carregassem a mensagem sem conhecer sua criptografia. A proteção abrangia o corpo encapsulado, não todo campo externo criado ou alterado durante o transporte.
  • O MIC-CLEAR conservava autenticação e integridade, mas retirava a codificação imprimível que isolava o MIC-ONLY de certas reescritas. Quem não tivesse PEM podia ler o texto; não podia, por isso, validar a assinatura.
  • O MIC era calculado sobre uma forma canônica em ASCII com finais CRLF. Uma conversão comum de linhas ou um escape de encaminhamento podia produzir falha, de modo que resultado, causa e classificação como incidente precisavam permanecer separados.

O correio seguro dos anos 1990 não começou em um terreno vazio. Começou no meio de uma rede que já entregava mensagens todos os dias e cuja diversidade era, ao mesmo tempo, sua força e seu problema.

Um agente do usuário compunha o texto em um formato local. Servidores SMTP o aceitavam, retransmitiam e entregavam. Gateways faziam a travessia para ambientes diferentes. Sistemas não concordavam necessariamente sobre conjuntos de caracteres ou finais de linha. Um encaminhador ainda podia envolver a mensagem original em outra. Exigir que todos esses participantes entendessem uma nova proteção criptográfica teria transformado coordenação global em pré-requisito.

A opção do RFC 1421 foi manter o Privacy Enhanced Mail no User Agent ou acima dele. A origem preparava e protegia o corpo antes de entregá-lo à infraestrutura normal; o destino desfazia o processamento e validava depois da entrega. Os servidores intermediários continuavam a operar como antes. A adoção podia começar nas bordas sem uma reforma sincronizada de toda a rota.

Essa independência tinha contorno. Campos adicionados ou transformados entre os dois componentes PEM ficavam fora do mecanismo. O objeto protegido seguia dentro do corpo da mensagem exterior, mas não incorporava automaticamente endereço, envelope, rastros ou decisões de roteamento. Proximidade visual não ampliava a assinatura.

Por isso, “a mensagem” não possuía uma única história. Havia a sucessão de transações SMTP, a evolução dos cabeçalhos externos, as transformações do objeto encapsulado, a reconstrução feita pelo receptor e, enfim, o que a pessoa viu e fez. Uma luz verde para todas essas realidades teria sido uma simplificação perigosa.

Uma rota antiga para um serviço novo

O princípio de implantação do RFC 1421 era contido: aumentar a capacidade dos usuários sem integrar obrigatoriamente a segurança a cada servidor SMTP. O texto também não tentava impedir tecnicamente o envio de correio desprotegido. Reconhecia que não se podia pressupor um agente do usuário confiável em todo computador.

Os incentivos foram redistribuídos. Operadores de retransmissão não precisavam investir antes de haver demanda local. Desenvolvedores das pontas ganhavam espaço para implantar por conta própria. Em troca, o remetente precisava conhecer a capacidade do destinatário e escolher apenas transformações que ele conseguisse inverter. Gestão de chaves e acordo de algoritmos continuavam fora da simples aceitação do endereço.

Uma resposta positiva a RCPT TO dizia que um nó assumira a próxima responsabilidade de transporte. Não dizia que o agente final possuía PEM, a chave correta ou autorização para agir. Entrega e capacidade criptográfica eram afirmações diferentes.

O próprio documento fixava outras ausências: não resolvia controle de acesso, sigilo do fluxo de tráfego, exatidão da lista de endereços, controle de rota, garantia ou não repúdio do recebimento, correlação de confirmações, duplicatas ou replay. Um MIC válido não podia ser promovido a prova desses fatos.

A assinatura começava antes da aparência

Cada máquina tinha uma representação local. Para que duas pontas comparassem o mesmo objeto, o RFC 1421 definiu uma forma canônica inspirada na representação inter-SMTP: caracteres ASCII e linhas encerradas por CRLF. O dot stuffing usado pela transparência SMTP não fazia parte desse objeto.

O Message Integrity Check era produzido sobre a sequência canônica. Quando havia confidencialidade, a criptografia também partia dela. O encadeamento geral aparecia como Encode(Encrypt(Canonicalize(Local_Form))), com as operações irrelevantes omitidas em cada tipo. No destino, as inversas vinham na ordem adequada antes da conversão final para o formato local.

Essa arquitetura permitia que computadores diferentes concordassem, mas delimitava o significado da assinatura. Ela não autenticava a ideia de um parágrafo, sua tipografia ou aquilo que o leitor julgava equivalente. Autenticava os bytes alcançados pelo processo especificado. Duas telas parecidas poderiam esconder finais de linha divergentes; uma representação visivelmente alterada poderia voltar ao original depois que uma camada removesse sua própria transformação reversível.

O RFC 822 descrevia mensagens com campos e um corpo opcional, ASCII e orientado a linhas. O RFC 821 definia o DATA e as regras de transparência do SMTP. PEM tomou essa disciplina conhecida como modelo comum. Não afirmou que todo estado canônico intermediário fora observado como uma transação SMTP real.

O preço variava conforme o tipo

ENCRYPTED juntava confidencialidade, autenticação e integridade. O corpo canônico era cifrado e depois representado por um alfabeto imprimível restrito para atravessar ambientes variados.

MIC-ONLY dispensava o segredo, mas não exibia simplesmente a prosa. A codificação imprimível ainda protegia a representação assinada de transformações comuns do sistema de transferência. Um programa PEM recuperava o corpo e verificava o MIC antes de apresentá-lo.

MIC-CLEAR escolhia autenticação e integridade equivalentes às do MIC-ONLY, retirando a etapa de codificação. Era a concessão feita à compatibilidade humana. O destinatário sem software especial lia o conteúdo. A mesma ausência de software, chave e reconstrução o impedia de validar.

Ler, então, era uma propriedade da apresentação. Verificar exigia controles interpretados, uma trajetória de chave adequada, a forma canônica correta e o MIC correspondente. Um estado não implicava o outro.

Existe uma consequência que não é apenas técnica. Pessoas reagem à linguagem assim que ela aparece. Um pedido claro pode parecer urgente ou autorizado antes que qualquer cálculo termine. Quanto mais fácil é oferecer o texto a sistemas antigos, maior é a obrigação de mostrar que sua autoridade continua pendente.

A falha não vinha com uma causa embutida

A codificação do MIC-ONLY tornava seu conteúdo menos vulnerável a um conjunto de modificações do Message Transfer System. Ao privilegiar o texto claro, o MIC-CLEAR aceitava outro regime. Seu MIC só seria validado se o MTS não alterasse o corpo, ou se cada alteração relevante pudesse ser reconhecida e desfeita.

Finais de linha exemplificam o problema. O SMTP usava CRLF, mas o sistema receptor podia converter as linhas para seu padrão nativo antes de entregar o conteúdo ao módulo PEM. Cabia ao verificador recanonizar o que recebera, reconstruir a representação inter-SMTP e calcular o MIC de referência.

O encaminhamento acrescentava outra transformação. O RFC 1421 adotou as fronteiras de encapsulamento do RFC 934. Se uma linha clara iniciada por hífen pudesse parecer uma fronteira, a camada exterior acrescentava . Como o MIC havia sido calculado antes desse escape, a mesma camada precisava removê-lo na volta. Caso contrário, uma proteção reversível do invólucro se tornava diferença permanente para o verificador.

Uma comparação malsucedida provava que a reconstrução não chegara ao objeto assinado. Não identificava o agente responsável. Poderia haver adulteração maliciosa; também poderia haver uma conversão normal que o receptor não soube reconhecer ou inverter. Por isso, o RFC dizia que a falha de um MIC-CLEAR não significava necessariamente um evento relevante de segurança.

A interface deveria preservar esse raciocínio. Ao comunicar a falha, indicaria também o tipo de mensagem. Uma mensagem sintaticamente válida, mas com MIC incorreto, não deveria ser exibida silenciosamente como confiável: o usuário receberia um alerta sobre autenticidade e integridade e teria de confirmar que desejava continuar. A evidência era firme; o rótulo causal continuava condicionado à investigação.

O invólucro não assinava o que estava ao lado

Os controles PEM residiam em um cabeçalho encapsulado dentro do corpo externo. Podiam existir anotações não protegidas fora das fronteiras, vários objetos protegidos e encaminhamentos aninhados. Uma observação colocada ao lado de um objeto válido continuava sendo uma observação sem proteção.

Nem mesmo o êxito do MIC demonstrava que a lista exterior de destinatários era correta, que a rota fora autorizada, que a caixa postal certa recebera ou que uma pessoa lera. Ele associava um corpo canônico a controles e a uma cadeia de chaves. Identidade humana, poder para ordenar, recebimento, resposta e efeito exigiam outros registros.

O RFC 1423 separou algoritmos, modos e identificadores da gramática principal de processamento. Isso permitia tratar a superfície criptográfica como módulo substituível. Tanto o RFC 1421 quanto o RFC 1423 têm hoje status Historic. A separação arquitetural ainda ensina; o conjunto de algoritmos de 1993 não constitui recomendação atual de segurança.

O legado de MIC-CLEAR não é uma promessa de segurança sem custo para correio antigo. É um mapa do custo. Servidores legados permaneciam úteis, e leitores sem PEM preservavam acesso ao texto. Em contrapartida, toda mudança entre a forma assinada e a forma mostrada precisava ser reversível, atribuível ou assumida como incerteza. O conteúdo continuou legível; a história do caminho tornou-se trabalho do verificador.