Resumo

  • A RFC 3923 protegia um objeto CPIM com S/MIME e o transportava dentro do envelope XMPP ; o namespace do envelope não definia o significado da mensagem.
  • O gateway XMPP-CPIM podia remover ou acrescentar o envelope do serviço, mas tinha de encaminhar o objeto protegido sem alterações.

A alteração permitida ao gateway

Um gateway permite que dois serviços de mensagens, mesmo usando protocolos diferentes, troquem mensagens. Mas, quando um deles traduz a mensagem, surge uma pergunta de segurança: o que pode ser alterado sem que o tradutor passe também a fazer parte da fronteira de confiança? Publicada em outubro de 2004 como padrão do IETF, a RFC 3923 respondeu com uma unidade de confiança deliberadamente restrita. Um gateway XMPP-CPIM podia retirar o envelope de um serviço e colocar o de outro. Não podia modificar o objeto S/MIME assinado ou criptografado que estava dentro.

Essa distinção tornava a proteção de ponta a ponta compatível, ao menos na fronteira entre protocolos, com um intermediário que conhecesse os dois serviços. O gateway não era um endpoint criptográfico; transportava o objeto protegido como carga opaca. Assim, a arquitetura separava o trabalho de interoperabilidade das tarefas de assinar, criptografar e interpretar o conteúdo.

Um objeto protegido dentro de uma stanza XMPP

O remetente começa criando um objeto Message/CPIM. Ele contém cabeçalhos e conteúdo, e a RFC exige que ambos sejam cobertos pela assinatura ou criptografia S/MIME. O objeto resultante é colocado numa seção CDATA de XML, dentro de um elemento <e2e/> que pertence a uma stanza XMPP de mensagem ou presença. Em alguns usos, o objeto encapsulado também pode ser um documento de presença PIDF ou um objeto XML XMPP.

<e2e/> transporta, mas não interpreta. Segundo a RFC, seu namespace não tem semântica própria: as especificações de CPIM, PIDF ou XMPP definem o objeto encapsulado. Por isso, um intermediário não precisa entender o conteúdo protegido só porque consegue analisar a stanza XMPP que o transporta.

A regra do gateway decorre dessa divisão. Para enviar tráfego para fora do XMPP, ele remove o envelope XMPP — inclusive as tags <e2e> —, revela o objeto S/MIME multipart e o encaminha, acrescentando o envelope do serviço não XMPP quando necessário. No sentido inverso, remove o envelope não XMPP, coloca o mesmo objeto num envelope XMPP e encaminha a stanza. A RFC é explícita: o objeto S/MIME encapsulado deve ser imutável e não pode ser modificado pelo gateway XMPP-CPIM.

Uma fronteira, não um sistema completo de segurança

A imutabilidade é uma instrução forte do protocolo, mas não prova que um gateway implantado a tenha seguido. O envelope tampouco torna confiáveis todos os fatos ao redor. O destinatário ainda precisa obter e validar certificados e decidir o que uma assinatura demonstra sobre a identidade do remetente. A RFC deixa a inscrição de certificados fora de seu escopo e exige que o agente receptor ofereça algum mecanismo para obtê-los. Portanto, a promessa é preservar um objeto protegido numa rota específica de interoperabilidade, não resolver identidade, distribuição de chaves ou interface com o usuário.

O compromisso operacional também fica claro. O transporte opaco permite que um intermediário carregue conteúdo que não deve reescrever, mas reduz sua capacidade de transformar ou inspecionar esse conteúdo. Se um serviço exigir conversão, o local onde ela ocorre e seu efeito sobre a assinatura tornam-se decisivos. Alterar um objeto coberto pela assinatura não é tradução neutra; o desenho deixa essa decisão para os endpoints.

Em 2014, a RFC 7165 descreveu a abordagem S/MIME como ainda sem ampla adoção e apontou os desafios de gestão de chaves e a dificuldade de processar objetos S/MIME como fatores parciais. Trata-se de uma observação de um documento normativo daquele ano, não de um levantamento atual nem de uma explicação única. Ainda assim, ela reforça a lição histórica: uma fronteira clara pode preservar o significado criptográfico sem tornar simples o produto ou a gestão de chaves. A contribuição duradoura da RFC 3923 não foi tornar os gateways confiáveis. Foi mostrar que interoperar não exigia reescrever aquilo que os endpoints haviam protegido.

Fontes