Resumo

  • HP-Outer registra dentro da carga criptografada os campos que o compositor decidiu expor fora, preservando a decisão sem alegar que observou todo o trajeto.
  • As camadas MIME efetivamente recebidas determinam o estado criptográfico; o parâmetro hp documenta a intenção original e não pode transformar tentativa em confidencialidade.
  • From interno e externo, assinatura, vínculo com o endereço, autenticação do transporte, valor exibido e destinatário da resposta precisam de provas separadas.

Um diretor recebe um e-mail cujo assunto aparece como [...]. O corpo abre depois da descriptografia e a interface mostra um cadeado. Ele pergunta: “O assunto ficou privado?”

A pergunta parece binária, mas contém pelo menos quatro observadores. O compositor viu o assunto antes de enviar. Os agentes de transporte podem ter visto uma versão externa. Cada destinatário autorizado vê a versão interna depois de descriptografar. Um adversário pode inferir assunto, relação ou horário por metadados que não são o próprio campo. Dizer apenas “sim, estava criptografado” apaga essas fronteiras.

O RFC 9788 cria uma resposta verificável. Ele não aumenta o tamanho do cadeado; registra o que o compositor fez com cada cabeçalho.

A proteção é uma topologia MIME

O RFC 9787 descreve S/MIME e PGP/MIME como camadas criptográficas em uma árvore MIME. Uma camada de assinatura oferece integridade e autenticidade sujeitas à validação. Uma camada de criptografia oferece confidencialidade e, conforme o formato, integridade. A ordem altera as propriedades: assinar e depois criptografar não equivale a criptografar e depois assinar.

O envelope criptográfico é a maior sequência contínua dessas camadas a partir do tipo MIME externo. A primeira parte não criptográfica dentro dele é a carga protegida. Se uma parte comum interrompe a sequência, uma assinatura mais profunda não transfere automaticamente sua condição ao e-mail inteiro. Compressão num contêiner CMS também não vira proteção criptográfica por associação.

Essa estrutura recebida tem precedência sobre a apresentação. Historicamente, muitos clientes protegiam o corpo e deixavam assunto, autor aparente e outros campos fora. Um atacante podia alterar o que o usuário via sem quebrar a criptografia do corpo.

O RFC 8551 propôs proteger cabeçalhos envolvendo um objeto message/rfc822. Clientes legados mostraram problemas ao renderizar e processar esse arranjo. O RFC 9788 o substitui: os cabeçalhos conhecidos pelo compositor são copiados diretamente para a carga criptográfica. Num e-mail criptografado, um campo não estrutural pode ficar igual no exterior, ser obscurecido ou desaparecer dali.

Uma cópia dentro do envelope não revela qual dessas escolhas ocorreu. O mesmo campo pode estar criptografado e também ter sido publicado em claro.

HP-Outer documenta a exposição deliberada

O novo campo HP-Outer fica dentro da carga criptografada. Para cada cabeçalho não estrutural colocado deliberadamente do lado de fora, o compositor deve incluir um registro protegido com o nome e o valor externo escolhido.

Se Subject virou [...] no exterior, esse valor consta do recibo. Se Date passou sem alteração, a data clara consta dele. Se um campo protegido não possui nenhum HP-Outer correspondente, o compositor afirma que não colocou uma instância desse campo fora do envelope no momento da injeção.

O recibo tem autoridade sobre esse ato. Não é uma telemetria de ponta a ponta. Um intermediário ainda pode inserir Received, remover um campo ou reescrever o exterior. Uma lista pode acrescentar controles. O destino SMTP, os identificadores das chaves, a posição no mailbox e o tamanho podem permitir inferências.

Mesmo assim, o registro impede que uma remoção posterior seja confundida com privacidade original. Suponha que Cc tenha saído em claro e uma cópia esteja protegida. Um atacante elimina o Cc externo. Um cliente que compare apenas o estado final poderá classificar o campo interno como confidencial. O HP-Outer coincidente prova que o compositor o expôs.

Para descrever o passado, o cliente deve chamá-lo de assinado, não de secreto. Para preparar uma resposta, pode tratá-lo de forma conservadora e evitar uma nova exposição. Explicação histórica e ação defensiva não precisam produzir o mesmo rótulo.

Essa é a disciplina das camadas de realidade: o recibo não recebe autoridade sobre eventos que não presenciou.

Uma política executável, não uma promessa

A Header Confidentiality Policy, HCP, é uma função. Ela recebe nome e valor de um cabeçalho não estrutural e devolve o mesmo valor, um substituto obscurecido ou null, que retira o campo da seção externa.

O hcp_baseline, recomendado, é pequeno. Troca Subject por [...], remove Comments e Keywords e mantém os demais. O hcp_shy também elimina nomes de exibição de From, To e Cc e converte Date para UTC. Pode reduzir metadados legíveis, mas exige parsing mais sofisticado e traz maior risco de entrega ou apresentação; por isso não é o padrão recomendado.

O nome da política nunca aparece no fio. O destinatário observa suas decisões por meio de HP-Outer. O registro da IANA fornece descrições estáveis e identifica a política recomendada. Não certifica um cliente, uma configuração ou uma mensagem.

O desenho mantém a camada comum estreita: sintaxe, decisões reproduzíveis e regras de registro. Um ambiente pode esconder To, Cc, References ou In-Reply-To, mas filtros, threading, listas e suporte podem depender desses campos. A escolha mais privada precisa de prova local de entrega e uso; o registro não a torna gratuita.

O parâmetro hp registra intenção

No Content-Type protegido, hp=cipher diz que o compositor tentou aplicar proteção de cabeçalhos com criptografia; hp=clear acompanha a forma somente assinada. O estado recebido continua sendo derivado das camadas reais.

Um e-mail apenas assinado com hp=cipher continua sem confidencialidade. A interface não pode promover a intenção a resultado. Também é possível que um intermediário envolva em criptografia um e-mail originalmente apenas assinado. O destinatário recebeu uma camada criptografada, mas ela não prova autoria dessa camada.

Quando intenção e envelope divergem, a falta de HP-Outer não demonstra que o autor escondeu tudo. É preciso preservar árvore MIME, sequência de camadas, hp, recibos internos, cabeçalhos externos finais e a decisão do parser. Um log encrypted=true perde a causalidade.

O endereço mostrado pode não comandar a resposta

O From externo pode ser avaliado por mecanismos do transporte. O From interno pode ser protegido por assinatura ponta a ponta. O RFC define mismatch quando os addr-spec são diferentes.

Estar na área protegida não autentica a identidade sozinho. A assinatura precisa ser válida e corretamente vinculada ao endereço interno. Diante de mismatch sem vínculo válido, o cliente deveria alertar como faz com phishing e mostrar os dois endereços.

Se o cliente depende do transporte para avaliar o remetente externo, a exibição cautelosa deve usar o From externo real. Isso evita que um compositor malicioso escreva uma identidade prestigiosa no interior, assine com outra credencial e ganhe aparência de autenticidade.

Na resposta, a regra muda: os destinatários devem vir apenas dos campos protegidos. Um atacante em trânsito não pode controlar a resposta alterando o endereço exterior e assim capturar o conteúdo.

Não há contradição. Exibir procura reduzir spoofing; responder procura reduzir vazamento por desvio. O nome humano exibido é uma terceira evidência, pois não tem a unicidade global do endereço nem vínculo automático com o certificado.

Privacidade sempre tem um público

Um cabeçalho idêntico dentro e fora não é privado dos agentes de transporte. Removê-lo do exterior não o esconde dos destinatários que podem abrir a mensagem. Identificadores de chave, envelope SMTP, Received e sequência temporal ainda podem expor relações.

O próprio compositor pode incluir informação indesejada para o destinatário: versão no User-Agent, host no Message-ID ou Bcc na cópia errada. A criptografia protege a entrega desse erro.

Listas e servidores acrescentam campos depois da composição; eles não herdam proteção ponta a ponta. Responder ou encaminhar pode copiar Subject, References ou texto descriptografado para uma mensagem clara.

O RFC 9788 melhora a proteção de cabeçalhos justamente por rejeitar uma conclusão total. O campo, o observador, o momento e a ação precisam permanecer visíveis.

Fontes

  1. RFC 9788 — Header Protection for Cryptographically Protected Email
  2. RFC 9787 — Guidance on End-to-End Email Security
  3. RFC 8551 — S/MIME 4.0 Message Specification
  4. RFC 5322 — Internet Message Format
  5. RFC 3156 — MIME Security with OpenPGP
  6. RFC 7489 — Domain-based Message Authentication, Reporting, and Conformance
  7. IANA — Mail Header Confidentiality Policies
  8. IANA — Message Headers
  9. Heng Lu — Primazia do código em execução
  10. Heng Lu — Especificação inicial mínima e decisão futura localizada
  11. Heng Lu — Camadas da realidade e poder simbólico