Resumo

  • Em 24 de setembro de 2026, o IESG aprovou o draft-ietf-jose-hpke-encrypt-22 para publicação como Proposed Standard. Ele continua sendo um Internet-Draft, não um RFC publicado nem prova de implantação.
  • Integrated Encryption cifra o texto diretamente com HPKE para exatamente um destinatário. Key Encryption protege uma CEK compartilhada e permite receptores HPKE, ECDH e RSA no mesmo JWE JSON.
  • A especificação exige ao menos um destinatário válido, mas cabe à aplicação decidir se um basta ou se todos devem funcionar. A segurança da CEK comum é limitada pelo algoritmo de destinatário mais fraco.

A mensagem abriu; a obrigação pode continuar pendente

Uma empresa endereça o mesmo JWE ao serviço de produção, ao cofre de retenção e ao sistema de recuperação. O serviço de produção recupera a CEK, a autenticação do conteúdo passa e a biblioteca entrega o texto. O resultado criptográfico é legítimo.

Ainda assim, o caminho de recuperação pode ter falhado. O cofre pode usar um algoritmo que a política já retirou. Um destinatário não autorizado pode ter sido acrescentado. O texto claro não informa quais participantes eram obrigatórios, qual lista foi aprovada nem qual exceção permitiu um caminho antigo.

Essa diferença dá conteúdo operacional à notícia de 24 de setembro. O IESG aprovou a revisão 22 do trabalho JOSE sobre HPKE com JWE para publicação como Proposed Standard. A decisão confirma uma etapa do processo. Não atesta implementação, configuração, custódia de chaves, interoperabilidade ou execução de política. O documento também ainda não concluiu o processo de publicação como RFC.

Dois modos, duas superfícies de controle

Integrated Encryption usa HPKE sobre o próprio texto. Não existe CEK separada, portanto enc deve ficar ausente. O cabeçalho protegido traz um alg que identifica a suíte HPKE completa; ek é proibido e há exatamente um destinatário. O JWE Encrypted Key carrega o segredo encapsulado do HPKE, enquanto os campos de IV e tag do JWE ficam vazios porque essas funções estão dentro da operação integrada.

Key Encryption preserva uma camada de conteúdo distinta. Uma CEK aleatória cifra o corpo segundo enc; depois, HPKE cifra a CEK para cada destinatário HPKE. O JWE Encrypted Key daquele destinatário contém o ciphertext da CEK, e ek contém o segredo encapsulado. Recipient_structure leva ao key schedule o contexto JOSE, o algoritmo de conteúdo e uma informação adicional opcional da aplicação.

Essa indireção permite vários destinatários. Na serialização JSON, uma rota HPKE pode conviver com ECDH-ES+A128KW ou RSA-OAEP-256. O corpo é cifrado uma vez, mas cada participante recebe uma entrada diferente para a mesma CEK.

É uma arquitetura útil para migração gradual, arquivo e contingência. Também faz da lista inteira de destinatários uma unidade de risco.

“Pelo menos um” é o piso do protocolo

O procedimento de decrypt da revisão 22 afirma que a aplicação decide quais destinatários precisam validar. Em um caso, qualquer um pode bastar; em outro, todos os participantes obrigatórios têm de funcionar. A regra comum é apenas que nenhum sucesso torna o JWE inválido.

Para JWE JSON, o consumidor também deve retornar à aplicação quais destinatários passaram e quais falharam. Esse vetor impede que uma biblioteca esconda um resultado plural atrás de um único booleano.

Se A passa com HPKE, B falha por rotação incompleta e C passa com um algoritmo legado, o conteúdo pode ser recuperado. Uma aplicação que exige apenas A aceita. Outra que exige A e B rejeita. Uma terceira pode rejeitar porque o algoritmo de C não está na allow list, mesmo que C tenha aberto a CEK. O mesmo plaintext sustenta decisões diferentes porque as obrigações são diferentes.

O texto ainda recomenda invalidar o JWE quando os algoritmos empregados não são aceitáveis para o contexto, mesmo depois de um decrypt bem-sucedido. A norma fornece fatos interoperáveis; a autoridade para aceitar permanece onde o risco é suportado.

O caminho mais fraco alcança a mesma CEK

Em Key Encryption, todas as rotas levam à CEK compartilhada. Qualquer rota aceita que a revele abre o conteúdo comum. Por isso, as considerações de segurança dizem que a proteção do conteúdo é limitada pelo algoritmo mais fraco usado para cifrar a CEK.

Não é uma condenação automática de ambientes mistos. É um limite de avaliação. A rota HPKE mais moderna não eleva as garantias de uma segunda rota que continua autorizada a entregar a mesma chave com proteção inferior.

A própria revisão 22 mostra a necessidade de registrar o modo. Uma segunda Last Call do grupo JOSE avaliou especificamente a remoção de HPKE-4-KE e HPKE-6-KE. Esses identificadores de Key Encryption não aparecem na revisão 22; HPKE-4 e HPKE-6 continuam no modo Integrated Encryption. Um inventário que diga apenas “HPKE habilitado” não consegue expressar a mudança.

A especificação também desaconselha usar o mesmo par KEM em vários modos ou suítes HPKE e compartilhar a mesma chave entre algoritmos HPKE e não HPKE. Para auditoria, destinatário, modo, suíte, identidade da chave e finalidade autorizada precisam permanecer ligados.

A separação de camadas defendida por Heng Lu ajuda a não ampliar o significado dos registros. A aprovação do IESG é um fato institucional. alg é um fato do formato. O sucesso de um destinatário é um fato criptográfico. A lista aprovada e a escolha entre “um” e “todos” são fatos de controle. O veredicto observado da aplicação é outro registro, que precisa existir por si.

Fontes