Resumo
- A IANA registra o algoritmo 18 como ML-DSA-44 e marca
MAYpara uso em assinatura e validação. A regra EPP do registro é a próxima barreira para os dados DS enviados. - Na RIPE 93, Joe Abley chamou atenção para essa barreira anterior à validação. Seu rascunho individual de outubro propõe que registros e registradores usem os registros DNSSEC da IANA para definir quais algoritmos e resumos aceitam.
O número já estava no registro. A transação ainda podia parar no balcão seguinte.
Na sessão de DNS da RIPE 93, em 29 de outubro, Joe Abley contou que tentou enviar o algoritmo 18 pelo EPP. Segundo sua apresentação, nenhum dos registros que havia verificado aceitava aquele valor. Ele citou uma exceção depois que um mantenedor incorporou uma alteração de código após conversar com Garth Miller. Uma conversa e um merge abriram um caminho; não criaram uma regra previsível para os demais.
O registro de algoritmos DNSSEC da IANA lista hoje o número 18 como ML-DSA-44. A linha permite uso para assinatura de zona e marca MAY para uso e implementação em assinatura e validação. Esses campos registram o nível de requisito permitido; a implantação por registros, assinadores e resolvedores validadores é outro estado operacional.
O detalhe do EPP é estreito e decisivo. A RFC 5910 leva dados DS pelo EPP. O campo alg identifica o algoritmo da DNSKEY referenciada pelo DS; digestType indica o resumo usado para construir o DS. O rascunho individual de Joe Abley, de 14 de outubro, trata desses dois campos. Ele propõe usar os registros de algoritmo e resumo da IANA como regra comum, com exclusões para valores incapazes de fornecer segurança DNSSEC. O Datatracker lista apenas a versão individual 00 em I-D Exists; o texto não tem status de padrão da IETF.
O ponto de controle aparece ali. O assinador pode preparar um algoritmo novo, e a IANA pode lhe dar um número; o registro pai ainda decide se o registrador pode enviar o DS. Se a solicitação for recusada, a zona filha não conclui o passo no pai exigido pela troca de algoritmo. Uma lista local que ninguém publica transforma uma mudança de padrão em tentativa e erro.
Aceitar e validar são decisões diferentes. Um resolvedor sem suporte ignora o DS daquele algoritmo. Se nenhum DS compatível restar, ele trata a zona filha como não assinada. O EPP libera o envio; o suporte do resolvedor é outra etapa de implantação.
O rascunho não traz uma matriz datada que identifique os registros e os valores EPP testados; publicar essa relação mostraria o alcance da variação.
Fontes primárias: apresentação na RIPE 93 · transcrição da sessão · registro de algoritmos DNSSEC da IANA · RFC 5910 · RFC 4035 · rascunho individual de Joe Abley, versão 00.
Briefing para membros
Contexto aprofundado do perfil
Faça login com o nível de assinatura correto para desbloquear o briefing completo e as notas das fontes.
Exclusivo para o Círculo Estratégico
Strategic Circle
Aberto a todos os leitores. Desbloqueie Briefings de perfil após se inscrever e fazer login.
Junte-se ao Strategic CircleSomente para Leadership Alliance
Leadership Alliance
Para proprietários e gestores qualificados de ativos de PI; faça login para desbloquear os briefings da Leadership Alliance.
Junte-se ao Leadership Alliance





