Resumo

  • A Última Chamada do grupo OpenPGP para draft-ietf-openpgp-nist-bp-comp-04 tinha 9 de setembro de 2026 como prazo. O documento continua sendo um Internet-Draft ativo, com status pretendido Informational; o fim do prazo não comprova decisão ou aprovação.
  • A revisão 04 usa 100–107 como identificadores experimentais. Proposta, branch editorial e implementações testam 37–44, mas o registro da IANA capturado mantém 37–99 como não atribuídos.
  • Nos KEMs compostos, o identificador entra em multiKeyCombine e altera a chave derivada que envolve o material da chave de sessão. Nas assinaturas, ele muda pacotes, impressões digitais e outros artefatos.
  • Cada alegação de interoperabilidade deveria trazer um recibo de estado com revisão, número usado, commit, hash dos vetores, build, linha observada no registro e condição de lançamento formal.

A Última Chamada do grupo foi aberta em 19 de agosto e pediu manifestações até 9 de setembro. Prazo é marco de processo, não resultado. No material capturado, a página do Datatracker ainda mostra In WG Last Call; no IESG, apenas I-D Exists. O histórico registra a evolução do draft, mas a ficha não exibe shepherd, Area Director responsável ou telechat. O objetivo declarado é um documento Informational.

A revisão 04 especifica combinações de algoritmos pós-quânticos do NIST com algoritmos de curva elíptica já estabelecidos no contexto do OpenPGP. São quatro opções compostas de KEM e quatro de assinatura, todas facultativas. Os números 100 a 107 pertencem à faixa privada ou experimental. O próprio texto limita seu uso a software não lançado e a testes de interoperabilidade, veda lançamentos formais com eles e diz que o documento não seguirá para a IANA até que todos os algoritmos listados tenham números não experimentais.

Preparar o próximo estado não o torna vigente

Uma proposta na lista distribui as oito opções entre 37 e 44. Daniel Kahn Gillmor, em sua resposta, considera o arranjo plausível, porém orienta implementadores a continuar com identificadores experimentais até que um draft publicado contenha os não experimentais. A formulação permite testar a mudança sem produzir a falsa impressão de que a decisão já percorreu todo o caminho.

A pull request 50 faz exatamente esse ensaio. Na captura, estava aberta, não marcada como draft e ainda não mesclada. O commit de ponta é 577adce5255e7382e5d4b0c9e52be626deb77126; a mudança troca 100–107 por 37–44 e regenera impressões digitais, resultados de KEM e vetores em 27 arquivos.

Uma mensagem dos autores descreve vetores que usam os pontos chamados de “atribuídos”. Um relato sobre rPGP informa a atualização para 37–44 e concordância com os vetores do NIST, ao mesmo tempo que deixa a suite de interoperabilidade à espera da confirmação. A merge request 255 preserva esse limite: aberta, marcada como draft, não mesclada e com a instrução de não incorporar a mudança antes da atribuição oficial.

Um byte que participa da derivação

Nos KEMs compostos, a implementação lê do pacote de chave pública o identificador do algoritmo e o passa como algId para multiKeyCombine. O resultado é a chave de criptografia usada para envolver o material da chave de sessão. Se um lado usa 100 e o outro 37, a entrada é diferente. Eles não chegam à mesma chave de envolvimento, ainda que os valores dos componentes ML-KEM e ECDH sejam idênticos.

Nas combinações de assinatura, o identificador também fica serializado nos pacotes de chave OpenPGP. A troca altera os bytes que alimentam impressões digitais e outros artefatos verificáveis. O renumeramento não muda a definição matemática de ML-KEM, ECDH ou das primitivas de assinatura; tampouco demonstra força ou falha de segurança. Muda a vinculação protocolar. Por isso, regenerar os vetores é parte substantiva da alteração.

O quarto relógio: a IANA

O registro OpenPGP da IANA capturado exibe atualização em 2 de julho de 2026. Os valores 35 e 36 estão associados ao RFC 9980; 37–99 aparecem como Unassigned e 100–110 como Private or Experimental Use. Nesse retrato, “atribuído” em uma conversa de desenvolvimento significa o estado previsto ou adotado por um branch, não o estado público do registro.

O RFC 9580 organiza o formato moderno do OpenPGP e seus registros. O RFC 8126 define o vocabulário de políticas de atribuição. Registro, consenso, edição e implementação não são sinônimos. A presença de um número na IANA não certifica a segurança, não obriga adoção e não aprova uma versão de produto. Sua ausência também não anula um teste de laboratório, desde que o teste declare honestamente o estado exercitado.

Um recibo de estado resolve a ambiguidade sem impedir o trabalho. Junto de cada vetor ou resultado, registre: revisão e estágio do documento; identificador experimental publicado; identificador proposto no branch; estado e commit de PR ou MR; linha da IANA e horário da observação; commit e hash do vetor; versão e build da implementação; número realmente usado; e se o texto citado permite lançamento formal. O vetor antigo continua sendo evidência do estado experimental antigo. O novo comprova uma hipótese futura sem fingir que o registro já mudou.

Fontes