Resumo

  • Em 26 de setembro, o IESG abriu a votação de aprovação da revisão 05 do projeto que pretende substituir RFC 9180 e incluiu o texto na reunião de 8 de outubro. O processo está em avaliação; ainda não há RFC sucessora aprovada.
  • A nova tabela especifica Base 0x00 e PSK 0x01, reservando 0x02 e 0x03, usados para Auth e AuthPSK no documento de 2022. A revisão 04 já fazia essa escolha.
  • O campo Auth do registro de KEMs é mantido para a interface antiga, embora o projeto novo não o use. Capacidade registrada não comprova que um serviço utiliza o modo nem que uma mudança de biblioteca preservou sua promessa de identidade.

Uma referência normativa pode ser trocada em uma tarde. A dependência de um produto de determinada propriedade de autenticação não desaparece com a mesma rapidez. É esse desencontro que torna a votação do novo HPKE relevante para além da redação de um padrão. A proposta se apresenta como sucessora de RFC 9180 e pretende obsoletá-la caso seja aprovada. Ao mesmo tempo, deixa de especificar dois modos em que a chave do remetente participa da autenticação. Quem lê apenas o novo nome do padrão pode não perceber a ressalva.

RFC 9180 usa quatro valores de modo: Base, PSK, Auth e AuthPSK. Na revisão 05 do projeto, somente os dois primeiros aparecem como modos definidos; as posições 0x02 e 0x03 ficam reservadas. O apêndice de diferenças reconhece expressamente a retirada de Auth e AuthPSK e limita a compatibilidade pretendida ao comportamento descrito em ambos os textos. Isso protege a continuidade do terreno comum, não transforma toda função antiga em parte da sucessora. Também não elimina toda autenticação: PSK autentica a posse de um segredo pré-compartilhado. Essa propriedade, porém, não se confunde com a posse da chave privada assimétrica do remetente afirmada pelos modos Auth anteriores.

A sequência das versões importa para não fabricar uma novidade técnica. A tabela da revisão 04 já reservava os mesmos dois valores. A revisão 05 foi disponibilizada em 25 de setembro; no dia seguinte vieram a cédula de aprovação, a mudança para IESG Evaluation e o agendamento da discussão em 8 de outubro. O registro público ainda apontava posições de voto pendentes e a necessidade de nova análise da IANA após a atualização da versão. Nada disso equivale à publicação de uma RFC, nem altera retroativamente o status de RFC 9180.

O próprio acompanhamento do documento reconhece a tensão. Em março, Martin Thomson escreveu que o grupo optou, com relutância, por retirar os modos autenticados diante de implantação limitada e da falta de suporte pós-quântico adequado ao desenho atual. A mesma explicação reconhece usos existentes e chama a opção de adiamento, não de depreciação, mencionando a possibilidade de retomá-los em trabalho futuro. Trata-se do relato qualitativo de um responsável pelo processo, não de uma contagem auditada de sistemas e muito menos de um aviso de falha criptográfica nos modos antigos.

O trecho de IANA separa outras camadas que frequentemente são misturadas. O projeto pede atualização das referências nos registros se aprovado, mas preserva os códigos e registros KEM existentes. O formulário de KEM mantém um campo booleano Auth que indica suporte às operações AuthEncap() e AuthDecap() de RFC 9180; a sucessora declara que ela própria não utiliza esse campo. Portanto, a informação continua disponível para leitores do padrão antigo. Não se consegue inferir daí qual aplicativo chama essas funções, qual modo foi negociado entre pares ou qual identidade foi efetivamente validada.

Daniel Kade propõe tratar cada integração como uma decisão documentada: apontar a versão de referência, o modo realmente invocado, a garantia esperada sobre o remetente, as capacidades do outro extremo e o resultado de um teste entre as partes. Pode ser apropriado manter um caminho específico de RFC 9180, alterar a autenticação em outra camada ou aguardar trabalho posterior; o projeto não escolhe isso por cada operador. É uma recomendação editorial de governança, não um requisito do IETF. Um teste que apenas confirma que o texto cifrado abre não responde, sozinho, se a garantia de origem prometida continuou válida.

Fontes