Resumo

  • Publicado em julho de 2026 no fluxo do IETF, o RFC 9955 é um documento Informational que organiza propriedades de assinaturas híbridas. Compatibilidade retroativa, não falsificação híbrida, não separabilidade forte, verificação simultânea, desempenho, composição de provas e facilidade de aprovação podem exigir escolhas incompatíveis.
  • O mesmo objeto pode ser verificado por completo num receptor novo e apenas pelo componente tradicional num receptor antigo. Os dois podem registrar “válido”, embora só o primeiro tenha exercido a garantia híbrida pretendida.
  • Um recibo de verificação híbrida, sem segredos, deve ligar o objeto e a construção aos resultados de cada componente, aos vestígios de intenção híbrida, à origem e ao uso das chaves, à versão e política do verificador, ao alcance das aprovações, à coorte receptora e ao vencimento das exceções. Esta é uma proposta operacional do artigo, não uma exigência do RFC 9955, do IETF ou do NIST.

O selo e a decisão respondem a perguntas diferentes

Uma aprovação de algoritmo ou de módulo responde a uma pergunta delimitada: determinada implementação satisfaz um conjunto identificado de requisitos. Uma decisão de aceitar uma assinatura responde a outra: esta instância, processada por este verificador, sob esta política, alcançou quais propriedades?

É tentador ligar as duas respostas com a palavra “híbrido”. O projeto compra componentes aprovados, o emissor gera duas assinaturas e o painel contabiliza a migração. Mas a garantia surge na borda receptora. Se uma aplicação antiga ignora um componente, a presença dele no arquivo não torna a decisão resistente à falha do componente aceito.

O RFC 9955 ajuda a impedir esse salto. O texto reflete consenso do IETF, mas é Informational. Não seleciona uma construção, não recomenda a hibridização para todos os sistemas, não registra parâmetros na IANA e não relata implantação. Em vez disso, separa metas que costumam ser comprimidas numa única etiqueta.

Há metas criptográficas, como não falsificação híbrida e não separabilidade. Há metas de implantação, como compatibilidade com verificadores antigos. Há metas de engenharia, como desempenho e economia de espaço. Há ainda a necessidade de aproveitar componentes já aprovados. O mapa é valioso justamente porque uma posição conveniente num eixo pode cobrar preço noutro.

A mesma assinatura, duas políticas de aceitação

Considere um certificado, uma atualização ou um ato administrativo assinado com dois algoritmos. O receptor moderno exige sucesso dos dois. O receptor legado reconhece apenas a assinatura tradicional e recebe permissão para ignorar a nova. Nada mudou no que o emissor produziu. Mudou o que cada receptor aceitou como prova.

O RFC 9955 trata a compatibilidade retroativa como propriedade da verificação. Isso significa que um sistema pode fornecer não falsificação híbrida a um verificador e não fornecê-la a outro. A divergência acontece quando a decisão é tomada, não quando a assinatura é criada.

Manter o receptor antigo pode ser necessário. Sistemas de infraestrutura, arquivos e raízes de confiança atravessam ciclos de aquisição longos. O problema não é admitir essa realidade. É transformá-la em exceção sem população, dono ou prazo.

O RFC explicita a troca: compatibilidade retroativa e Não Separabilidade Forte são mutuamente exclusivas. Se retirar uma parte deve tornar o restante inválido, o receptor que entende somente essa parte não pode continuar funcionando. Quando a compatibilidade é efetivamente usada para pular um componente, a não falsificação híbrida também deixa de caracterizar aquela aceitação.

Uma métrica como “objetos com assinatura híbrida” mede o emissor. Para medir risco, a organização precisa saber quais receptores verificam tudo, quais só conseguem analisar o formato e quais ainda têm autorização para aceitar um componente.

Onde fica o vestígio de que havia duas partes

O RFC chama de artefato o indício da intenção de hibridizar que permanece depois da remoção de um componente. Esse indício pode estar na própria assinatura, num certificado, na negociação de algoritmo ou no texto assinado.

Cada lugar entrega a responsabilidade a um nível diferente. Um artefato na assinatura pode ser tratado pelo algoritmo. Um artefato no certificado depende do protocolo, da proveniência das chaves e da cadeia relevante. Um rótulo no texto depende de política e de permissão para interpretar o conteúdo.

O último caso pode criar dependência circular. A autenticidade do texto depende da assinatura; a obrigação de verificar duas assinaturas depende de uma declaração dentro do texto. Um verificador desatento pode ignorar a declaração, aceitar o componente restante e ainda deixar evidência suficiente para uma investigação posterior descobrir a separação.

Essa é a fronteira da Não Separabilidade Fraca: sobra um vestígio, mas o componente separado pode continuar válido. Na Não Separabilidade Forte, a separação não produz uma assinatura de componente válida. Com Verificação Simultânea, o verificador normal também não consegue encerrar com sucesso ao descobrir apenas o resultado de um componente.

Os nomes “concatenação”, “aninhamento” e “fusão” não substituem essa análise. O RFC demonstra que uma mesma categoria pode colocar artefatos em lugares diferentes. A arquitetura precisa declarar onde está o vestígio e qual ação o verificador toma quando ele falta ou diverge.

A política de chaves termina no último verificador

Um risco de separação pode aparecer fora do sistema previsto. Se o mesmo par de chaves de componente for aceito por outra aplicação ou protocolo, uma assinatura extraída pode ser apresentada ali. Obrigar o destinatário principal a verificar duas partes não obriga esse outro verificador.

Restringir a reutilização de chaves, reservar chaves para a construção híbrida e codificar usos permitidos nos certificados são medidas importantes. O RFC 9955, porém, mantém a descrição precisa: trata-se de requisito de política, não de garantia criptográfica. Ele vale somente onde é aplicado de forma consistente.

Assim, o universo de controle não coincide com um projeto. Ele inclui todo local que confia na chave pública. Inventários de chaves, certificados, protocolos, aplicações, versões e responsáveis precisam ser consultáveis em conjunto. Uma equipe que analisa só o serviço principal não sabe se outro sistema transformou um componente híbrido numa credencial comum.

É nesse ponto que uma política escrita precisa encontrar seu espelho operacional. “Uso exclusivo” é uma afirmação verificável, não uma qualidade criada pelo documento de arquitetura.

Aprovação não é uma propriedade do conjunto inteiro

O RFC 9955 apresenta um espectro separado para a necessidade de aprovação. Uma construção nova e fusionada pode exigir nova avaliação. Um invólucro que chama módulos de componentes sem alterá-los pode aproveitar aprovações existentes com mais facilidade. Esse benefício logístico não lhe dá automaticamente verificação simultânea ou não separabilidade forte.

A FAQ de criptografia pós-quântica do NIST descreve a verificação de uma assinatura dupla como o sucesso de todos os componentes e informa que padrões atuais podem acomodá-la quando pelo menos um algoritmo de componente é aprovado. O FIPS 204 padroniza o ML-DSA. Nada disso é uma crítica à acomodação. É uma razão para manter a gramática exata: algoritmo aprovado, módulo validado, construção analisada e decisão executada são substantivos diferentes.

Uma compra pode legitimamente preferir a solução que preserva validações existentes. Nesse caso, as dependências adicionais de política, cadeia e controle de chaves devem aparecer na aceitação. O selo continua valioso, mas não fala por aquilo que não avaliou.

O conteúdo do recibo

O arquivo assinado já guarda os dados criptográficos. O recibo deve guardar a decisão que lhes deu efeito. Em cada aceitação relevante, ele liga:

  1. hash do objeto, contexto, construção híbrida e versão esperada;
  2. algoritmos, identificadores públicos e não secretos das chaves, certificados e cadeias realmente validadas;
  3. localização de cada artefato de intenção híbrida e confirmação de que foi examinado;
  4. vetor de resultados exigido, resultado observado de cada componente e decisão composta;
  5. propriedade alegada — separabilidade fraca, forte ou verificação simultânea — com base na construção e na execução;
  6. versão do software, hash da configuração e revisão da política;
  7. restrições de reutilização de chaves e população responsável por impô-las;
  8. aprovação ou validação atribuída ao componente e ao módulo exatos;
  9. coorte receptora, exceção legada, responsável e vencimento;
  10. tratamento de erros e de resultados parciais;
  11. horário da decisão, prazo de retenção e gatilho de nova verificação;
  12. autoridade para rejeitar, isolar ou reverter a aceitação quando a garantia não puder ser reproduzida.

Esse registro não contém chave privada, segredo de assinatura nem texto confidencial. Usa hashes, versões e referências protegidas. Também não fortalece uma construção inadequada. Sua tarefa é impedir que a palavra válido seja usada para reivindicar mais do que foi verificado.

Uma prova de migração centrada na recepção

O ensaio deve selecionar um conjunto comum de objetos e submetê-lo a cada combinação material de verificador e política. Devem faltar, falhar e variar os componentes; os artefatos precisam ser alterados; cadeias devem mudar; uma chave de componente deve ser testada em outro contexto potencialmente aceito.

O relatório precisa mostrar quais operações ocorreram, em qual ordem, sob qual configuração e com que decisão. Depois, compara-se a evidência com a afirmação institucional.

“Todos os emissores geram duas assinaturas” é uma afirmação pequena. “Todos os receptores críticos verificam ambas” é outra. “A construção é fortemente não separável” é uma terceira. “Um módulo é aprovado” é uma quarta. A especificação inicial mínima exige começar pela menor proposição que o conjunto de evidências sustenta, em vez de reuni-las sob “seguro contra quantum”.

Se o teste revelar uma coorte antiga, o resultado permite governar: limitar funções, separar chaves, financiar substituição, nomear um responsável e marcar a saída. Uma exceção identificada pode terminar. Uma compatibilidade presumida não termina nunca.

Limites

Não há aqui relato de ataque, fraude, defeito de produto, falha regulatória ou incidente. As fontes tratam de padrões e propriedades, não de prevalência de implantação. Não Separabilidade Forte e Verificação Simultânea não são declaradas superiores em todos os contextos; cobram compatibilidade, desempenho e aprovação. O recibo não prevê novas descobertas criptográficas.

Ele preserva algo que a conformidade isolada não preserva: a verdade da decisão feita pelo verificador real.

Fontes