Resumo

  • draft-ietf-hpke-hpke-05, em avaliação no IESG, define Base 0x00 e PSK 0x01 e marca como reservados 0x02 e 0x03, usados pelo RFC 9180 para Auth e AuthPSK.
  • A nova tabela define um alvo de padronização. Ela não demonstra que bibliotecas carregadas, perfis de aplicação, objetos duráveis e contrapartes já abandonaram o conjunto anterior.

Uma especificação pode reduzir seu núcleo em duas linhas. Uma operação distribuída não encolhe no mesmo commit.

O RFC 9180 definiu quatro modos. O projeto atual mantém Base e PSK, retirando Auth e AuthPSK. Para uma implementação nova, a direção fica clara. Para quem administra um parque heterogêneo, começa outro trabalho: descobrir onde o comportamento antigo ainda é possível, permitido, necessário ou efetivamente observado.

Confundir as duas tarefas transforma um marco documental em um atestado de execução que ninguém emitiu.

O documento ainda não é o RFC substituto

O Datatracker registra a revisão 05, de 26 de setembro de 2026, como Internet-Draft ativo do grupo HPKE. O texto pretende se tornar Proposed Standard, foi enviado ao IESG, está em avaliação e aparece na teleconferência de 8 de outubro. A revisão da IANA precisa ser refeita após a mudança de versão.

O cabeçalho diz que o documento tornaria o RFC 9180 obsoleto se aprovado. As fontes congeladas não mostram aprovação final nem publicação de um novo RFC.

A remoção dos modos também não nasceu na revisão 05. A revisão 04 de julho já trazia os dois valores reservados e a mesma lista de diferenças. O fato atual é a posição processual do desenho, não uma alteração recém-chegada.

O RFC 9180 é Informational no fluxo IRTF. Seu sucessor candidato busca o consenso de um Proposed Standard da IETF. Esse processo pode escolher o próximo contrato comum; não mede o estado de cada serviço que adotou o documento anterior.

A promessa de compatibilidade tem borda

O apêndice A afirma que, onde os dois documentos especificam a mesma função, o comportamento deve permanecer idêntico. Base e PSK fazem parte dessa interseção.

Auth e AuthPSK não fazem mais. O RFC 9180 atribui 0x02 e 0x03 e descreve funções que usam a chave estática do emissor. A revisão 05 reserva os valores e remove as variantes. Chamar toda a transição de retrocompatível sem essa ressalva apaga a própria dívida que precisa ser tratada.

Um vetor de teste Base pode provar equivalência para aquela suite e aquelas entradas. Não prova que um processo antigo reiniciou, que uma dependência vendorizada foi eliminada ou que um arquivo histórico não exige mais o caminho Auth.

Cada prova de compatibilidade deve nomear modo, suite, build, API, papel de chave, perfil de aplicação e par. “HPKE passou” não tem precisão suficiente para autorizar uma retirada.

O ciphertext não carrega um inventário universal

HPKE é incorporado por outros protocolos. O projeto deixa à aplicação o transporte de parâmetros não secretos como enc e psk_id. Se o destinatário possui várias chaves, a aplicação também define como selecionar a correta.

Modo e suite vêm do contexto. Não existe um envelope HPKE único, visível em todos os produtos, cujo cabeçalho resolva o censo. Um perfil escolhe uma função de API; outro fixa o modo na versão do objeto; um terceiro depende de configuração ou negociação.

O inventário precisa começar nos perfis e seguir até a dependência, o executável carregado, a configuração efetiva, o objeto persistente e a observação. Procurar símbolos no código é útil, mas só prova presença no escopo examinado. Capturar ciphertext sem metadados pode provar tráfego, mas não a origem do modo.

Ausência também precisa de escopo. Código estático, hardware, imagens de recuperação, workers adormecidos e versões antigas podem ficar fora do repositório principal. Um resultado negativo sem denominador é apenas silêncio.

Oito estados para uma retirada verificável

O primeiro estado é normativo: documento, revisão e etapa do processo. O segundo é o perfil: a regra da aplicação que escolhe o modo. O terceiro é a implementação: pacote, build e binário realmente carregado. O quarto é a configuração: caminhos permitidos por serviço, operação e par.

O quinto é a observação de uso. O sexto é o estado durável de filas, backups e arquivos. O sétimo é a contraparte, validada por interoperabilidade com o substituto. O oitavo é o resultado da aplicação depois da operação criptográfica.

Nenhum substitui todos os demais. Atualizar o pacote não reinicia todos os processos. Reiniciar não fecha uma exceção. Fechar a exceção não migra objetos antigos. Um canário PSK bem-sucedido não cobre todos os pares. Uma decriptação não prova autorização ou efeito.

O inverso também vale. Um símbolo Auth não comprova uso. Uma exceção configurada não comprova emissão. Um objeto antigo legível não comprova que o caminho deva permanecer habilitado para tráfego novo.

O relatório deve dizer quais estados foram observados, por quanto tempo e com quais pontos cegos.

A extensão proposta é outra trilha, não uma decisão concluída

draft-ms-hpke-auth-modes-01 propõe recuperar AuthPSK como extensão estrita. Reintroduz a mecânica Auth como componente, mas não o modo Auth isolado, que não forneceria resistência quântica.

O Datatracker alerta que se trata de um Internet-Draft individual, sem endosso nem posição formal no processo da IETF. Não é uma alternativa aprovada.

Seu valor probatório é mais restrito: mostra que retirar uma função do núcleo e impedir qualquer especificação separada são atos diferentes. Se a extensão avançar, formará outro conjunto de compatibilidade, com análise, binding de aplicação, implementação e adoção próprios.

As discussões nas listas HPKE e JOSE registram opiniões sobre assinatura, autenticação implícita, Key Encryption e transição pós-quântica. Elas não demonstram consenso, implantação, incidente ou prevalência. A autoridade da fonte precisa permanecer visível.

Posse de PSK não nomeia automaticamente uma organização

O núcleo candidato ainda atribui autenticação do emissor ao modo PSK: quem cria corretamente o contexto possui o segredo pré-compartilhado.

Uma PSK pode pertencer a um processo, a um cluster ou a vários equipamentos. Distribuição, escopo, rotação, isolamento e vínculo com uma identidade ficam fora do HPKE. A prova de posse não se converte sozinha em mandato de negócio ou autorização da operação.

O projeto também enumera não objetivos: replay e downgrade da aplicação, ordenação e perda de mensagens, ocultação do comprimento, má aleatoriedade efêmera e forward secrecy diante de futura perda da chave privada do destinatário.

Por isso, trocar Auth por PSK e abrir um ciphertext não conclui a migração semântica. A aplicação deve definir quem está autorizado, como prova frescor e qual resultado precisa observar.

O último objeto mantém vivo o leitor

Parar a criação de um formato é diferente de apagar a capacidade de leitura. Mensagens atrasadas, jobs retomáveis, backups, arquivos e retenções legais vivem além do emissor original.

Eliminar cedo chaves ou decodificadores pode causar perda irreversível. Mantê-los para sempre, sem isolamento, dono e prazo, converte uma exceção temporária em superfície permanente.

O inventário durável deve registrar formato, janela de criação, perfil, identificador de chave, horizonte de retenção e último teste de leitura. Se o sistema antigo não guardou metadados suficientes para identificar o modo, essa incerteza deve aparecer como risco, não ser escondida por uma inferência sobre o ciphertext.

A publicação cria o alvo; a observação fecha o programa

Os princípios de Minimum Initial Specification e Running-Code Primacy de Heng Lu distinguem documento e adoção. Uma alteração posterior se torna real por implementação, validação, implantação e uso. Quem não a adota permanece em outro conjunto de compatibilidade.

Isso não enfraquece a norma. Coloca cada autoridade no lugar certo. A IETF pode definir um núcleo menor; a organização precisa demonstrar que seus serviços e parceiros entraram nele.

Uma conclusão responsável delimita perfis e builds avaliados, exceções encerradas, objetos migrados ou destruídos, pares testados e janela sem observação antiga. Fora do limite, o estado continua desconhecido.

Fontes