Resumo

  • Want-Content-Digest e Want-Repr-Digest indicam preferências de algoritmo. O destinatário pode ignorá-las, escolher outra opção ou omitir o campo de resumo sem que isso, isoladamente, seja um erro de protocolo.
  • A cadeia de integridade tem quatro estados: o pedido enviado, a evidência efetivamente recebida, o objeto HTTP coberto e o resultado do cálculo acompanhado da decisão local.
  • O resumo detecta divergência nos bytes delimitados; não autentica a origem, não autoriza a operação, não oferece sigilo e não protege automaticamente todos os metadados do HTTP.

Preferência não é contraproposta aceita

Em um painel de configuração, marcar SHA-512 como prioridade pode parecer suficiente para exigir seu uso. No protocolo, o campo só comunica uma ordem desejada. O acordo vinculante, se necessário, precisa vir da aplicação.

RFC9530 define dois dicionários de Structured Fields. Em ambos, a chave dá o nome do algoritmo e o inteiro expressa preferência relativa: 1 é a menor, 10 a maior, e 0 significa não aceitável. Want-Content-Digest trata do conteúdo da mensagem; Want-Repr-Digest, da representação selecionada.

O peso não mede força criptográfica nem confiança. Um 10 não obriga o par. Quem recebe o campo pode ignorar a lista, usar um algoritmo que não aparece nela ou não devolver Content-Digest nem Repr-Digest. A especificação deixa claro que a preferência não atendida, por si só, não configura erro HTTP.

Uma API pode exigir determinada resposta, mas deve dizer isso em seu contrato. O apêndice C mostra caminhos diferentes: servidor escolhe uma opção menos preferida, não suporta nenhuma ou emite um 4xx/5xx decidido pela aplicação. RFC9530 não escolhe um status universal para todas as recusas.

Há ainda a direção inversa. Um campo Want-* em uma resposta diz o que o servidor gostaria de receber em requisições futuras. Não contém o resumo da resposta atual. A presença do campo de preferência deve ser registrada como intenção, nunca como evidência já entregue.

Quatro registros evitam um sucesso imaginário

O primeiro registro guarda o pedido: qual campo, quais algoritmos e qual ordem. O segundo descreve o que apareceu: Content-Digest ou Repr-Digest, membros presentes e localização em cabeçalho ou trailer. O terceiro nomeia o objeto coberto. O quarto documenta o algoritmo aceito localmente, os bytes calculados, a correspondência e a decisão da aplicação.

Assim, “o cliente preferiu SHA-512” não vira “o servidor usou SHA-512”. A existência de sha-256 não vira “o cliente verificou”. E “resumo válido” deixa de ser uma conclusão sem objeto conhecido.

Fallbacks podem ser corretos. Um serviço talvez aceite algoritmo menos preferido ou siga sem resumo em conteúdo de baixo risco. Só não deve contar isso como validação genérica. “Ausência aceita por política” e “alternativa aceita” preservam o julgamento que ocorreu e permitem comparar períodos.

Conteúdo e representação são evidências diferentes

RFC9530 separa a ambiguidade herdada de RFC3230 em dois campos. Content-Digest cobre o conteúdo real de uma mensagem HTTP. Repr-Digest cobre toda a representação selecionada conforme a semântica de HTTP.

A diferença fica visível em respostas parciais, mas também existe com negociação e codificação. Um recurso pode ter várias representações. Content-Type e Content-Encoding alteram os bytes e sua interpretação. O arquivo mais conveniente no armazenamento, portanto, não é necessariamente o objeto indicado pelo campo.

Métodos de alteração de estado exigem igual cuidado. Em PATCH, a requisição pode carregar um documento de patch, enquanto a resposta se refere à representação selecionada do recurso resultante. Content-Location e Location não são atalhos equivalentes para determinar o alvo.

Uma coluna interna chamada apenas “payload checksum” elimina o contexto decisivo. Convém registrar campo, metadados de representação, tratamento das codificações e etapa em que os bytes foram capturados. Sem isso, dois componentes podem produzir cálculos corretos sobre materiais distintos e acreditar que verificaram a mesma coisa.

Entender um algoritmo não significa aceitá-lo

O registro atual da IANA classifica SHA-512 e SHA-256 como ativos. MD5, SHA, somas UNIX, Adler-32 e CRC32C estão entre os itens obsoletos. RFC9530 ainda admite algoritmos obsoletos para alguns casos não adversariais de detecção de corrupção acidental, mas proíbe seu uso quando há adversário ou assinatura digital.

O status do registro não substitui a política de risco. O destinatário pode ignorar qualquer membro e limitar os algoritmos ou a quantidade de cálculos. Também há motivo operacional: calcular vários resumos de objetos grandes consome CPU e largura de banda de memória. Permitir que o par escolha trabalho sem limite amplia uma superfície evitável.

É útil manter listas diferentes para algoritmos compreendidos e aceitos. Se a mensagem trouxer um membro forte e outro obsoleto, um componente pode validar o mais fácil enquanto outro presume que a prioridade máxima foi honrada. A agilidade, sozinha, não impede downgrade; a garantia real depende do membro escolhido pela regra local.

O registro de auditoria deve nomear algoritmo, campo, objeto e resultado. A aplicação define se uma correspondência aceitável basta, como reage a membros contraditórios e o que faz quando só aparecem opções desconhecidas ou proibidas. A gramática compartilhada coordena a escolha, mas não assume a responsabilidade.

O trailer muda o momento da decisão

Os dois campos podem aparecer em cabeçalhos ou trailers. O trailer é adequado quando o emissor calcula durante o streaming, porém pode ser descartado por intermediários e chegar depois que a aplicação já agiu.

Se o sistema confirma uma mudança, libera um arquivo ou encaminha dados antes da validação, não pode dizer depois que a ação foi condicionada à integridade. O cálculo tardio continua valioso para auditoria, mas não muda a ordem dos fatos. Trailer perdido deve ser tratado como ausência de evidência.

Uma correspondência também não garante o armazenamento para sempre. Ela descreve os bytes no ponto de validação. Para provar um estado posterior é preciso preservar todo o material coberto e verificá-lo de novo. Transformações e codificações tornam essencial registrar a etapa do processamento.

Resumo não é identidade, permissão ou sigilo

RFC9530 não apresenta os campos como proteção da mensagem inteira. Método, URI de destino, status e outros metadados podem ficar fora. O resumo não identifica o remetente, não decide autorização e não esconde conteúdo.

RFC9421 permite incluir o campo em HTTP Message Signatures, mas o assinante precisa selecioná-lo explicitamente, junto com os metadados relevantes, para a base de assinatura. Estarem lado a lado não cria vínculo. A assinatura ainda requer regras próprias de chave, tempo e replay.

Uma divergência demonstra que os bytes calculados não correspondem ao valor recebido. Ela não determina quem os alterou, se houve intenção ou se a operação era permitida. Essa fronteira ajuda a combinar integridade, transporte, identidade, autorização e armazenamento sem atribuir a um checksum uma função que ele nunca teve.

Fontes e limite probatório

Os exemplos operacionais são hipotéticos. O artigo não afirma taxa de adoção, número de incidentes, frequência de ataques, custo medido nem um limiar universalmente seguro.