Resumo

  • A revisão 05 afirma que os IDs experimentais 100–107 foram substituídos pelos IDs atribuídos 37–44. No recorte de 1º de outubro de 2026, o registro IANA de OpenPGP ainda mostrava 37–99 como não atribuídos. A divergência é datada e não revela a causa nem o desfecho do processo.
  • Todos os oito algoritmos são opcionais e se limitam a objetos v6 ou posteriores. Um parser que reconhece o número não prova que a construção foi habilitada ou executada.
  • Assinaturas exigem êxito simultâneo de ECDSA e ML-DSA. O KEM exige ECDH e ML-KEM, validação completa dos pontos, contexto correto do combinador e integridade no desembalamento AES-256.

A primeira coluna do inventário deveria ser “autoridade observada”

O texto da revisão 05 registra a troca de 100–107 por 37–44, refaz impressões digitais e vetores intermediários e adiciona vetores de assinatura destacada. As versões HTML e XML oferecem a mesma definição de wire format.

Já o registro IANA OpenPGP, capturado para esta apuração, publicava algoritmos até o 36 e deixava 37–99 como Unassigned. Isso não autoriza dizer que houve recusa, erro no texto ou atraso administrativo. A única conclusão é que as duas fontes públicas não estavam alinhadas naquele instante.

Por isso, o número não deve entrar sozinho no inventário. Ele precisa de URL e horário da captura do registro, revisão e hash do rascunho, versão do objeto e versão do binário que o interpretou. Sem essa composição, uma base que armazena “41” pode preservar apenas uma suposição.

O registro no Datatracker mostrava um Internet-Draft ativo do grupo OpenPGP, revisado em 24 de setembro de 2026 e com expiração em 28 de março de 2027. A API não declarava intended status, embora o cabeçalho dissesse Informational. O histórico indicava que ainda era necessária uma revisão antes do aval da coordenação. Não era RFC nem padrão aprovado.

Capacidade não é uma característica binária

Os IDs 37 e 38 combinam ML-KEM-768/1024 com ECDH nas curvas NIST P-384/P-521. Os IDs 39 e 40 usam Brainpool P-384/P-512. De 41 a 44, ML-DSA-65/87 se combina com ECDSA nessas famílias.

Cada linha é MAY. Um fornecedor pode entregar somente uma família de curvas, um nível de segurança ou apenas assinatura. Um pacote pode conter o código e mantê-lo desativado. Uma aplicação pode aceitar a chave e proibir seu uso. O inventário precisa distinguir presente, reconhecido, habilitado, testado e permitido.

O rascunho também exige chaves e certificados v6 ou posteriores; a assinatura composta deve ser v6 ou posterior e usar digest de pelo menos 256 bits. RFC 9580 organiza os objetos OpenPGP atuais. RFC 9980 fornece ML-KEM, ML-DSA e o multiKeyCombine. O recibo deve carregar essas versões e condições, não apenas o ID.

O KEM precisa de uma trilha de execução

Na encapsulação, ECDH e ML-KEM rodam separadamente. Os dois resultados, o ciphertext ECDH, a chave pública ECDH e o ID entram no combinador. A KEK resultante envolve a chave de sessão com AES-256 key wrap.

Na recepção, o ID do PKESK deve coincidir com o da chave secreta, os componentes devem ter os tamanhos exatos, as duas decapsulações devem rodar, o mesmo contexto deve ser recomposto e a verificação de integridade de 64 bits deve passar. Para PKESK v3, o tamanho da chave recuperada ainda precisa ser coerente com o algoritmo simétrico transportado fora do envoltório.

FIPS 203 especifica ML-KEM, enquanto SP 800-56A Rev. 3 dá o contexto tradicional de estabelecimento em curva elíptica. Um unwrap bem-sucedido é o último resultado, não uma gravação automática de todas as etapas anteriores.

O ponto recebido é uma entrada adversária

A revisão 04 tornou explícita a validação completa para pontos nas curvas curtas de Weierstrass. Antes de usar um escalar secreto, a implementação deve provar que o ponto não é o ponto no infinito, que as coordenadas pertencem ao campo e que a equação da curva é satisfeita.

Na encapsulação, o alvo é a chave pública ECDH do destinatário; na decapsulação, o ponto efêmero recebido. A falha encerra a operação. O próprio rascunho alerta que um ponto fora da curva pode viabilizar ataque de curva inválida e recuperação do segredo ECDH.

As referências clássicas incluem FIPS 186-5, SP 800-186, as curvas Brainpool de RFC 5639 e a validação de SEC 1 v2. Comprimento correto não é prova de pertencimento matemático. O inventário de capacidade deve dizer qual rotina validou o ponto e em qual build.

Duas assinaturas não oferecem duas chances de sucesso

A composição inclui ECDSA e ML-DSA sobre o digest OpenPGP. Ambas precisam passar. Não suportar uma parte, pular a validação ou encontrar uma malformação significa falha do todo.

Os tamanhos reforçam a obrigação de parse exato: R e S de ECDSA dependem da curva; ML-DSA-65 tem 3.309 octetos e ML-DSA-87, 4.627. Digest menor que 256 bits deve ser rejeitado. FIPS 204 define ML-DSA e RFC 9794 fornece a terminologia para combinações tradicionais e pós-quânticas. A palavra “híbrido” não cria uma lógica OR.

Os vetores de assinatura destacada ajudam a reproduzir bytes e cálculos. Não provam identidade do signatário, autorização, procedência da chave ou efeito no sistema. O recibo deve separar digest, resultado ECDSA, resultado ML-DSA, AND composto, confiança na chave e decisão de negócio.

Limites desta apuração

As fontes não demonstram implementação, produção, interoperabilidade, tráfego, ataque, incidente, desempenho ou adoção de qualquer fornecedor. Também não repetem a tese separada sobre mensagens de múltiplos destinatários do RFC 9980. O objeto aqui é o interior de um único algoritmo composto e a fronteira entre nome, execução e política.

Contar oito IDs pode ser útil para planejar trabalho. Contá-los como oito capacidades antes de obter os recibos cria uma dívida de significado que aparecerá no rollback, na auditoria ou no primeiro objeto hostil.