Resumo

  • A assinatura protege a signature base formada pelos campos, componentes derivados e parâmetros declarados em ordem. Um método, uma autoridade, um URI, uma credencial ou um corpo fora dessa base pode mudar sem invalidar a prova.
  • O verificador decide qual assinatura importa, qual chave e algoritmo são aceitáveis, se a mensagem está fresca e inédita, se o digest descreve o corpo recebido e se o principal pode executar a ação atual.
  • Quando um proxy verifica, transforma e assina de novo, ele produz outro testemunho. Sua chave responde pela visão interna; ela não amplia retroativamente o que o cliente havia coberto.

Um corpo aprovado ganhou um verbo que nunca foi assinado

Uma equipe integra assinatura de mensagens a uma API. O primeiro painel mostra sucesso: assinatura válida, chave conhecida, horário recente, Content-Digest idêntico ao JSON recebido.

O perfil, porém, cobre apenas date e content-digest. Não inclui @method, @authority, @target-uri, a credencial nem um identificador de uso único. O corpo pode ter sido preparado para uma consulta ou simulação e ser reapresentado como comando. Pode atravessar de um host para outro. Pode ser repetido enquanto a janela de tempo estiver aberta.

Em todos esses casos, os bytes cobertos continuam iguais. A falha está na interpretação operacional: a organização tratou prova de integridade parcial como permissão sobre método, destino e consequência.

A norma assina uma representação reconstruída

Mensagens HTTP raramente são objetos binários imóveis de ponta a ponta. Proxies combinam linhas de campos, traduzem versões, mudam codificação e introduzem contexto de encaminhamento. Uma assinatura sobre a imagem bruta de uma conexão quebraria ao primeiro intermediário legítimo.

RFC 9421 define uma base determinística. O signatário escolhe campos HTTP e componentes derivados, entre eles @method, @authority, @target-uri e @status. A ordem fica em Signature-Input. A linha final @signature-params prende a própria lista e parâmetros como created, expires, keyid, nonce e tag.

O destinatário reconstrói a base a partir da mensagem que recebeu. O resultado positivo prova equivalência semântica somente para o subconjunto coberto. Não existe uma expansão implícita para o restante da requisição.

Duas assinaturas com coberturas diferentes falam de objetos diferentes, mesmo que usem a mesma chave e o mesmo algoritmo.

A cobertura é uma política por operação

Uma norma geral não sabe o que altera o sentido de cada produto. Uma leitura pode precisar de método, authority e alvo. Uma mudança de configuração pode exigir também digest, identidade da conta, versão do recurso, chave de idempotência e desafio do servidor. Um recibo pode precisar do status da resposta e de componentes da solicitação original.

Por isso, o serviço compara a cobertura recebida com o perfil exato daquela rota e daquele método. Encontrar os campos Signature e Signature-Input não basta.

Sem @method, uma declaração ligada a GET pode acompanhar POST ou DELETE. Sem @authority e @target-uri, um conteúdo pode atravessar fronteiras de serviço ou de tenant. Se a autorização não estiver coberta, uma credencial substituída pode viajar ao lado de uma assinatura perfeita.

Assinar tudo cegamente também falha. Via e Forwarded existem para serem modificados ao longo do caminho. A regra é cobrir todo componente cuja alteração mude permissão ou efeito e declarar, por confiança explícita, o que cada intermediário pode transformar.

É a aplicação prática da Minimum Initial Specification de Heng Lu: o plano comum define com rigor a construção e a verificação, enquanto a decisão futura sobre cobertura, chaves e rejeição permanece com quem roda o sistema.

O corpo só entra por uma afirmação conferida

RFC 9421 não coloca conteúdo arbitrário diretamente na base. A ligação normal usa RFC 9530: calcular Content-Digest, cobrir esse campo, validar a assinatura e recalcular o digest sobre o corpo realmente recebido.

Assinar o digest sem recalculá-lo protege apenas o valor declarado. Um atacante pode preservar o campo e trocar o corpo. Recalcular um digest que não foi assinado também é insuficiente, pois corpo e digest podem ser substituídos juntos.

Metadados de representação entram no risco. Content-Type ou Content-Encoding livres podem levar os mesmos bytes a outro parser ou mudar a camada sobre a qual se espera o cálculo.

Se o digest chega em trailer, o aplicativo precisa esperar. Intermediários podem remover trailers, e processar o fluxo antes da conferência cria o efeito antes da prova. Uma operação reversível pode aceitar esse desenho; uma exclusão definitiva precisa de buffer ou transação.

O artigo existente sobre Digest Fields acompanha o objeto de bytes. Este acompanha a autoridade que liga essa afirmação de bytes ao método, ao destino e ao signatário. São fronteiras diferentes.

keyid não autentica a chave que aponta

O parâmetro keyid é fornecido por quem assina. RFC 9421 deixa descoberta de chave, algoritmos permitidos e vínculo com identidade para a aplicação.

Um verificador que aceita qualquer chave entregue com a mensagem deixa o atacante assinar a própria ordem e passar. A matemática prova posse da chave privada correspondente. O sistema local deve provar que aquela versão de chave representava um principal autorizado naquele momento e naquela classe de ação.

O registro útil guarda versão resolvida, fonte e versão de confiança, algoritmo, intervalo de ativação, principal, papel e escopo. O texto de keyid sozinho não permite reconstruir uma decisão depois da rotação.

Durante migração, assinaturas antigas e novas podem coexistir. O intervalo precisa de começo, métricas e retirada. Compatibilidade sem fim preserva privilégios que deveriam expirar.

IANA registra nomes para interoperabilidade. Não certifica que um algoritmo serve para movimentar dinheiro, apagar dados ou mudar uma rede.

Um tempo recente pode ser usado duas vezes

created registra a criação; expires informa até quando o signatário aceita responder pela assinatura. O verificador define idade e tolerância de relógio. Uma assinatura correta pode estar velha demais para a política.

Freshness não é unicidade. Durante trinta segundos, uma mensagem pode ser repetida várias vezes.

nonce oferece um valor de uso único, mas o verificador precisa consumi-lo atomicamente. Duas regiões podem observar “livre” ao mesmo tempo e produzir dois commits. Anti-replay depende de estado distribuído, escopo e retenção, não apenas de sintaxe.

tag ajuda a localizar a assinatura voltada a um perfil. Como é público, pode ser copiado e não autoriza nada.

O proxy abre outra etapa de custódia

RFC 9110 trata intermediários como parte normal de HTTP. Um gateway pode validar a assinatura externa, retirar um campo sensível, reescrever o destino e assinar a forma interna.

A nova assinatura diz o que o gateway afirma. Não demonstra que o cliente assinou campos acrescentados depois. O origin precisa saber se o gateway só atesta a validação ou se recebeu mandato para agir como principal interno.

Preservar apenas “assinatura do gateway válida” apaga a origem. A cadeia deve guardar contexto externo, assinatura cliente selecionada, perfil aplicado, transformação e contexto interno protegido pelo proxy.

Tradução entre HTTP/1.1 e HTTP/2 exige o mesmo cuidado. Host e :authority representam a autoridade em formas diferentes; @authority oferece o valor semântico. Assinar uma forma do fio pode quebrar no caminho ou levar verificador e autorizador a ler autoridades distintas.

Muitas assinaturas não eliminam a escolha

Cliente, gateway e aprovador podem assinar a mesma mensagem. Uma rotação pode adicionar dois algoritmos. Todas as assinaturas podem validar, mas só uma combinação de papel e cobertura pode atender à operação.

Aceitar a primeira assinatura válida transforma um recibo de auditoria em autorização ou confunde a assinatura do proxy com o mandato do usuário. Label e tag selecionam candidatos; a regra final exige chave, papel, componentes e contexto.

Em respostas, req permite cobrir partes da requisição correspondente. O verificador precisa daquela requisição exata. Duas mensagens assinadas, separadas do vínculo original, não provam que uma causou a outra.

TLS e autorização continuam trabalhando

TLS 1.3 protege um canal e fornece confidencialidade. HTTP Message Signatures preserva semântica escolhida através de conexões e alguns intermediários. Uma assinatura de mensagem não cifra e não substitui TLS.

Autenticação HTTP apresenta credenciais; a aplicação ainda compara principal, recurso, ação e estado. Uma resposta assinada também não recebe licença universal para cache; essa política permanece em RFC 9111.

Na disciplina de Reality Layers, a signature base é um artefato comum, a verificação é um fato criptográfico, o mapa da chave é uma afirmação de identidade, a autorização é decisão local e o commit é realidade operacional. Clareza significa impedir que uma camada se apresente como soberana sobre a seguinte.

Fontes e limites

As fontes não demonstram adoção atual, comportamento de fornecedor, identidade humana, intenção legal, não repúdio ou correção comercial. Cada conclusão exige evidência própria.