Resumo

  • draft-ietf-cose-hpke-27 permite que o ciphertext seja transportado fora de COSE_Encrypt ou COSE_Encrypt0, com nil no campo correspondente. Uma assinatura ou MAC aplicado depois ao objeto COSE não cobre esses bytes separados.
  • Um AEAD pode dar integridade ao ciphertext externo, mas seu tag não substitui autenticação pública do remetente, resolução de identidade, autorização da operação nem prova de execução.
  • Em 1º de outubro de 2026, a revisão 27 ainda estava em AD Evaluation::AD Followup no IESG. Três implementações teriam validado exemplos; isso não certifica a custódia de blobs em produção.

Há uma diferença entre proteger uma referência e proteger aquilo que a referência entregou naquele instante. Em sistemas com conteúdo separado, confundir as duas coisas cria uma assinatura perfeitamente válida ao lado de um objeto que ela nunca viu.

A revisão 27 do COSE-HPKE não deixa essa fronteira implícita. Se COSE_Encrypt ou COSE_Encrypt0 usa ciphertext separado, a proteção posterior via COSE_Sign, COSE_Sign1, COSE_Mac ou COSE_Mac0 não alcança esse ciphertext. O implementador deve assegurar proteção de integridade para ele.

Separar o conteúdo cria uma nova cadeia de custódia

RFC 9052 permite transportar conteúdo fora da estrutura COSE. A posição interna recebe nil, enquanto a aplicação fornece os bytes por outro caminho. Isso é eficiente para firmware, mídia, arquivos extensos e repositórios endereçados por conteúdo.

No modo integrado, HPKE produz ct. O texto da revisão permite colocá-lo em COSE_Encrypt0 ou transportá-lo separadamente. No modo de criptografia de chave, a camada 0 cifra o conteúdo uma vez com uma CEK; a camada 1 protege essa CEK para cada destinatário. A fonte XML registra a mesma arquitetura.

O ganho operacional é real. Também é real a nova dependência: o localizador precisa resolver exatamente a versão examinada. Um alias mutável, um objeto sobrescrito, a recomposição de ranges por CDN, compressão transparente ou restauração de backup pode trocar bytes sem tocar o envelope assinado. Guarde hash, tamanho, versão imutável e caminho de resolução.

Cada primitiva emite um comprovante limitado

A assinatura externa prova a estrutura exata que entrou em Sig_structure; o MAC faz o equivalente em seu contexto. Nenhum dos dois incorpora bytes apenas porque a interface os exibe dentro do mesmo cartão.

O AEAD da camada 0 pode proteger o ciphertext separado. Com CEK, nonce e dados associados corretos, o tag detecta alteração. Essa é uma prova forte de integridade sob uma chave simétrica, mas não declara publicamente quem enviou o objeto nem se esse ator podia solicitar uma ação.

HPKE Open produz outro resultado: o processamento para a chave do destinatário. A resolução de kid tenta ligar um identificador à versão de chave correta. Depois vêm identidade, autorização e commit.

Comprovante Afirmação válida Limite
Assinatura/MAC externo Validade dos bytes cobertos sob uma chave Não inclui automaticamente o blob separado
AEAD Integridade de ciphertext e AAD sob a CEK Não identifica publicamente o remetente
HPKE Open Processamento bem-sucedido para o destinatário Não concede autorização de negócio
Identidade Vínculo aceito entre chave e principal Não permite esta operação por si só
Autorização Política permite a ação agora Não prova que houve commit
Efeito Estado externo mudou Precisa ser ligado à cadeia anterior

O contexto amarra algoritmos, não organizações inteiras

Recipient_structure leva o algoritmo da camada imediatamente inferior e os cabeçalhos protegidos do destinatário para a entrada info de HPKE. Isso impede que o algoritmo de conteúdo fique solto em relação ao mecanismo que protege a CEK.

A estrutura deve usar codificação determinística de RFC 8949. Remetente e destinatário constroem localmente a mesma entrada não transmitida; representações diferentes quebrariam a operação mesmo com chaves corretas. Determinismo resolve a forma dos bytes, não a propriedade da chave ou a autorização.

recipient_extra_info pode incluir contexto obtido fora do objeto: tenant, sessão, canal ou finalidade. Como o valor não viaja na mensagem, sua origem, versão e política de ausência precisam ser observáveis. Voltar silenciosamente à string vazia pode remover a separação entre contextos.

O kid recomendado ajuda a selecionar a chave pública estática do destinatário e pode entrar no key schedule quando protegido. Mesmo assim, continua sendo um identificador. Namespaces diferentes podem reutilizar o mesmo valor; caches podem manter uma chave antiga; uma chave de recuperação pode decifrar sem representar o papel operacional pretendido.

Destinatário correto não implica remetente autorizado

RFC 9180 estabeleceu o modelo conhecido de HPKE. O draft sucessor ativo pretende substituí-lo se aprovado, mas permanece em elaboração. Inventários devem fixar versão, modo e suite, não apenas a palavra HPKE.

No modo Base, o KEM de HPKE não autentica o remetente. Uma assinatura ou MAC de COSE pode acrescentar essa autenticação, desde que cubra a informação pretendida. RFC 9338 reforça a diferença entre atestar dados cifrados e atestar o plaintext. Um resultado sobre um não pode ser promovido retroativamente a aprovação semântica do outro.

RFC 9053, o registro COSE da IANA e o registro HPKE coordenam algoritmos e códigos. Registro não é certificação de produto, de rotação de chave ou de política de autorização.

Maturidade editorial e segurança operacional não são sinônimos

O Datatracker mostrava a revisão 27 como documento do WG COSE destinado a Proposed Standard, submetido ao IESG e em AD Evaluation::AD Followup em 1º de outubro de 2026. O histórico marca a revisão em 12 de setembro. Ainda não havia número de RFC.

O relatório do shepherd descreve discussão ampla e informa que os autores mencionaram três implementações independentes usadas para validar exemplos no IETF 125. É evidência útil de running code, mas não comprova resolução imutável de blobs, contexto externo, revogação ou autorização em um produto específico.

Um manifesto para os bytes efetivos

Registre os bytes COSE completos; tipo e tag; cabeçalhos protegidos e não protegidos; estado embutido ou separado; localizador, versão, tamanho e hash do blob; hash da entrada de assinatura/MAC; algoritmo AEAD, hash do AAD e resultado do tag; modo e suite HPKE; hashes de ek e Recipient_structure; origem de recipient_extra_info; namespace e versão de chave de kid; resultado de abertura; hash do plaintext dentro da fronteira confiável; identidade; autorização; commit; efeito observado.

Não registre chaves privadas ou plaintext desnecessário. Hashes e referências versionadas preservam continuidade. A ausência deve continuar visível: assinatura_externa_cobre_blob=false pode ser desenho correto quando integridade_aead=true, mas não deve virar o rótulo genérico assinado=true.

Minimum Initial Specification favorece esse manifesto comum e mínimo. Running-Code Primacy manda observar buffers reais. The Policy Mirror expõe o poder dos defaults de storage e de resolução de chave. Reality Layers mantém sintaxe, bytes, prova, identidade, permissão e efeito separados.

Fontes