Resumo

  • A RFC 9995 faz do digest o payload COSE, exige o payload_hash_alg no cabeçalho protegido e permite proteger também o tipo e uma localização opcional do preimage.
  • A assinatura ou o MAC podem ser validados sem o objeto original. O resultado autentica o envelope em um contexto de chave e aplicação, não a disponibilidade, segurança, atualidade, semântica ou permissão de uso do objeto.
  • O consumidor ainda precisa identificar signatário e propósito, buscar sob limites, preservar bytes exatos, recalcular e comparar, analisar e avaliar, autorizar a ação específica e observar o efeito.

Considere uma central que assina evidências para filiais conectadas por satélite. A filial produz um arquivo grande, calcula seu hash e envia somente o valor curto. A central devolve uma estrutura COSE assinada. A operação poupou banda e reduziu a exposição do conteúdo.

Horas depois, um segundo sistema recebe apenas o envelope. Ele consegue verificar a criptografia imediatamente. Não consegue saber se o arquivo que a filial produzirá de novo terá os mesmos bytes, se o repositório ainda os guarda ou se o documento serve à decisão pretendida.

A RFC 9995, publicada em julho de 2026 no Standards Track do IETF, define o COSE Hash Envelope para esse cenário. O ganho vem da ausência deliberada do preimage. Não é um formato que comprime o objeto dentro da assinatura; é um formato que protege uma afirmação curta sobre um objeto externo.

Há três estados de conteúdo

O preimage é a sequência exata submetida ao hash. O digest é a saída curta e se torna o payload COSE. Além disso, pelas regras normais de COSE, o próprio payload-digest pode ser detached e fornecido separadamente durante a validação.

O primeiro afastamento — não transportar o preimage grande — é a função do Hash Envelope. O segundo — não transportar nem o digest dentro da serialização — é uma opção adicional. Um log que diz apenas “payload detached disponível” não revela se o verificador recebeu algumas dezenas de bytes ou o artefato inteiro.

A RFC 9052 define as estruturas COSE. Em COSE_Sign1, a assinatura abrange o cabeçalho protegido, os dados autenticados externos escolhidos pela aplicação e o payload completo usado em Sig_structure. Cabeçalhos desprotegidos não recebem a mesma cobertura. No Hash Envelope, o payload coberto é o digest; o preimage ausente não entra na assinatura por associação.

Portanto, “envelope válido” e “preimage correspondente” são resultados diferentes. O primeiro pode ocorrer offline. O segundo exige bytes candidatos e novo cálculo.

Três parâmetros delimitam a afirmação

payload_hash_alg, rótulo 258, é obrigatório no cabeçalho protegido e proibido no desprotegido. Ele seleciona o algoritmo que produziu o digest.

preimage_content_type, rótulo 259, é opcional e protegido. Indica o media type ou o CoAP Content-Format dos bytes originais. Não se confunde com o content_type COSE comum, rótulo 3, que descreveria o payload atual — o digest. A RFC 9995 proíbe o rótulo 3 no envelope para evitar essa ambiguidade.

payload_location, rótulo 260, pode carregar texto ou URI para localizar o preimage. A proteção impede alteração silenciosa da pista. Ela não garante que o destino responda, permaneça com o mesmo controlador, entregue o mesmo conteúdo, aceite o verificador ou seja seguro.

O registro COSE da IANA coordena rótulos e referências. A RFC 8126 explica as políticas que sustentam registros IANA. Registro não é atestado de implementação, conformidade ou autorização local.

A RFC 8610 fornece a gramática CDDL. Ela pode exigir forma e tipos; não determina proveniência ou valor. A RFC 7252 fornece o espaço de CoAP Content-Format. O número ajuda a selecionar um parser, mas não atesta sintaxe, esquema ou verdade.

Criptografia válida não completa a identidade

Uma assinatura válida prova uma relação entre os bytes protegidos, os algoritmos, a chave e as entradas aceitas. Um MAC válido prova relação análoga no contexto do segredo compartilhado. Isso é significativo, mas não basta para a aplicação agir.

A RFC 9052 deixa à aplicação associar a chave à identidade certa e decidir se essa identidade tem autorização. Uma chave de teste, uma chave de recibos e uma chave de liberação podem todas gerar operações matematicamente válidas. Mudança de função, fim de contrato ou revogação alteram autoridade sem alterar uma assinatura histórica.

External authenticated data pode ligar ambiente, tenant ou transação quando um perfil define seus bytes. Se o contexto for vazio ou genérico, a assinatura não inventa a finalidade ausente.

A RFC 9421 assina componentes HTTP escolhidos e depende de um perfil de aplicação. Ela serve de contraste: Hash Envelope não é assinatura de requisição HTTP e o local protegido não autoriza o acesso. Em ambos os casos, o escopo assinado não deve se expandir por linguagem operacional vaga.

Um sistema auditável mantém estados separados para estrutura, operação criptográfica, associação da chave, identidade, função autorizada e contexto.

Uma URI protegida precisa de política de download

O consumidor pode já ter o objeto, operar offline ou depender de uma transferência aprovada por outro canal. A RFC 9995 permite usar a localização; não obriga dereference automático.

Se um verificador privilegiado segue qualquer URI assinada, o signatário passa a influenciar conexões de rede. Redirecionamentos podem cruzar domínios, credenciais podem acompanhar a requisição, nomes antigos podem ter novo proprietário, respostas podem exceder memória ou expandir depois da descompressão. Uma chave comprometida transforma a pista íntegra em entrada hostil íntegra.

A RFC 9110 separa recurso, representação, conteúdo, coding, localização e redirecionamento. A política deve limitar schemes, origens, redirects, DNS/TLS, credenciais, tempo, tamanho, expansão e alcance de rede; registrar destino final e transformações; e executar a busca isoladamente.

A RFC 6920 separa nomes baseados em hash de mecanismos de localização. Essa separação permite trocar o espelho sem trocar a identidade dos bytes. A localização oferece candidato; o digest decide a correspondência depois da transferência.

A igualdade depende de um contrato de bytes

Após obter o candidato, o verificador executa o algoritmo do rótulo 258 e compara com o payload. Nome, versão ou chave de storage não substituem esse cálculo.

A RFC 9530 distingue digest do conteúdo HTTP e digest dos dados de representação selecionados. Content coding pode dar bytes distintos à mesma informação abstrata. Os campos Digest tampouco oferecem autenticação, autorização ou privacidade.

O perfil precisa dizer se o preimage é o arquivo comprimido armazenado, o conteúdo decodificado, uma serialização canônica ou outro fluxo. Fazer parse e serializar JSON/CBOR novamente pode mudar ordem, espaços e números. Normalizar quebras de linha ou descomprimir implicitamente também muda o objeto.

O processo seguro retém a resposta bruta, aplica somente transformações declaradas, calcula sobre os bytes definidos e registra a comparação. Um match estabelece igualdade com a afirmação do digest na força dos algoritmos. Não estabelece frescor, segurança ou adequação.

Depois do match começa a análise

Um SBOM correspondente pode falhar no parser. Pode passar e violar o schema. Pode cumprir o schema e descrever outro build. Pode descrever o build e omitir dependências. Pode ser completo e indicar algo proibido.

O tipo do preimage orienta o parser, não a decisão. Um objeto antigo continua combinando com seu hash antigo. A aplicação deve ligar versão, tempo, audience, revogação e finalidade.

RFC 9995 cobre COSE_Sign, Sign1, Mac e Mac0. Encrypt e Encrypt0 estão fora do escopo. O envelope não fornece confidencialidade nem decide como combinar hash e criptografia em futuros perfis.

A seleção de algoritmos também exige governo. A RFC 9053 define algoritmos COSE e verificações. RFC 9995 exige combinação de força coerente com o hash. A RFC 7696 mostra que agility é migração ativa: produtores emitem o sucessor, consumidores suportam sobreposição, política fixa retirada e arquivos duradouros recebem tratamento. Um identificador ainda reconhecido pode já não ser aceitável.

Evidência é o caminho executado

O princípio de running code de Heng Lu exige fatos da execução: bytes produzidos, digest, envelope, algoritmos, chave, identidade, finalidade, decisão de busca, trilha de transferência, recálculo, comparação, parser, avaliação, autorização e efeito. “Suporta RFC 9995” não fecha a cadeia.

Sua tese de especificação inicial mínima e decisão futura localizada corresponde ao desenho. Rótulos e forma oferecem coordenação comum. Privilégios de download, formatos, frescor, papéis, migração, retenção e rollback permanecem decisões locais com proprietários e resultados.

A distinção entre camadas de realidade impede que parse, criptografia, identidade, obtenção, igualdade, semântica, autorização e efeito virem sinônimos de “validado”. Cada camada pode passar e a seguinte falhar.

As fontes descrevem protocolos e doutrina editorial, não adoção, desempenho ou produto. O cenário de satélite explica a fronteira e não relata um deployment.