Resumo

  • O RFC 9563 atribui o algoritmo DNSSEC 17 ao SM2 com SM3 e o tipo de resumo DS 6 ao SM3, criando significados inequívocos no fio.
  • É um RFC Informational do Independent Stream, não uma especificação Standards Track; o texto afirma que IETF e IRTF não analisaram a adequação dos algoritmos ao uso.
  • Registro, implementação do assinante, delegação, capacidade do validador, política local, verificação e resultado da aplicação continuam sendo superfícies de prova separadas.

Um resolvedor validador recebe uma resposta assinada e encontra o número 17. O número agora tem definição pública. Mesmo assim, o software pode não incluir SM2, pode desconhecer o tipo de resumo do pai ou pode rejeitar o caminho por política. Uma assinatura também pode ser matematicamente válida sem dizer quem guardava a chave privada. O registro permite começar a verificação; não entrega o veredito final.

Publicado em 4 de dezembro de 2024, o RFC 9563 define como SM2 e SM3 são representados em DNSSEC. O algoritmo recebe o número 17 e o mnemônico SM2SM3; SM3 recebe o tipo DS 6. A própria publicação limita sua autoridade. Ela pertence ao Independent Stream, tem categoria Informational e não resulta de consenso da comunidade IETF. O documento diz que nem IETF nem IRTF analisaram se SM2 ou SM3 são adequados ao propósito e avisa que podem existir fragilidades intencionais ou não.

Essa ressalva impede que publicação seja confundida com certificação.

Alocação resolve identidade, não adoção

Sem um código comum, implementações não conseguem declarar o mesmo algoritmo de forma confiável em DNSKEY, RRSIG ou DS. A alocação, portanto, produz valor real: dá um nome interoperável ao formato e evita colisões entre interpretações privadas.

Em 27 de setembro de 2026, o registro IANA de algoritmos DNSSEC marcava como MAY o uso e a implementação do algoritmo 17 para assinatura e validação. O registro DS fazia o mesmo para o tipo 6. Esses são fatos datados sobre o cadastro, não uma pesquisa de adoção, autorização de compra ou parecer criptanalítico.

O RFC 6014 organiza justamente a governança da alocação: quem pode obter um valor, sob qual análise e o que o valor designa. O registro pode estar correto mesmo que nenhum resolvedor de uma frota implemente a entrada. Código também pode existir muito antes de aceitação ampla. Um catálogo não é telemetria de produção.

O RFC 7841 ajuda a ler a etiqueta. Cabeçalho e boilerplate identificam o fluxo e o status. O número RFC torna o documento estável e encontrável; não apaga Independent Stream nem cria consenso do IETF.

DNSSEC valida um caminho, não apenas uma assinatura

DNSSEC não pergunta somente se uma equação fecha. O RFC 4033 separa servidores autoritativos, resolvedores cientes de segurança e âncoras de confiança. O RFC 4034 define DNSKEY, RRSIG, DS e registros de negação. O RFC 4035 exige construir um caminho de autenticação, selecionar algoritmos suportados, localizar a chave, reconstruir dados canônicos, conferir o intervalo temporal e validar a assinatura numa cadeia aceita.

Um produto pode interpretar o número 17 sem calcular SM2. Pode implementar SM2 e não aceitar o resumo DS 6. A zona filha pode publicar DNSKEY enquanto a delegação do pai não oferece DS utilizável. Todas as primitivas podem estar presentes e a política local ainda recusar o caminho.

O RFC 6840 explicita uma consequência importante: um resumo DS não suportado é descartado como um algoritmo DNSKEY desconhecido. Se nenhum DS suportado permanecer, a delegação pode ser tratada como insegura, não como inválida. A zona está assinada e o registro está certo, mas aquele validador não consegue montar uma rota de autenticação executável.

Por isso o RFC 8624 mantém recomendações de uso e implementação. Agilidade depende de sobreposição entre quem assina e quem valida. Sua tabela antecede o RFC 9563 e não demonstra o suporte atual do algoritmo 17 ou do tipo 6. Esse suporte precisa ser medido por produto, versão, backend criptográfico, build, configuração e população real.

Assinatura válida responde a uma pergunta limitada

O RFC 9563 estabelece as codificações necessárias à operação criptográfica. Uma verificação bem-sucedida mostra que dados DNS canônicos correspondem à assinatura sob determinada chave, regra e janela de validade. Ela não mostra quem controlava a chave privada, se o uso foi autorizado, se o rollover manteve continuidade ou se a aplicação aceitou o endereço.

O RFC 7583 trata geração, armazenamento, troca, comprometimento e retirada como trabalho operacional. O RFC 9563 também exige criptoagilidade: se surgir uma fraqueza, materiais DS, DNSKEY, RRSIG e NSEC3 podem precisar de regeneração coordenada com caches. Uma linha de registro não executa essa mudança.

A trilha defensável liga procedência editorial, estado atual da IANA, build e configuração do assinante, DNSKEY/DS/RRSIG observados, capacidades do resolvedor, âncoras e política, log de validação, continuidade do rollover e resultado da aplicação. Cada recibo tem alcance próprio.

A primazia do código em execução proposta por Heng Lu organiza essa leitura. Autoridade simbólica, intenção configurada, capacidade executável e observação são realidades diferentes. O RFC 9563 permite nomear SM2 e SM3 no DNSSEC. Somente código e observações mostram o que ocorreu depois.