Resumen

  • IANA asigna el número 18 a ML-DSA-44 y marca MAY para su uso en firma y validación. La regla EPP del registro es el siguiente filtro para los datos DS enviados.
  • En RIPE 93, Joe Abley puso el foco en esa barrera previa. Su borrador individual de octubre propone que registros y registradores basen su aceptación de algoritmos y resúmenes en los registros DNSSEC de IANA.

El número ya estaba escrito. El trámite todavía podía quedar detenido en la ventanilla siguiente.

En la sesión DNS de RIPE 93, el 29 de octubre, Joe Abley contó sus intentos de enviar por EPP el algoritmo 18. Según su intervención, no encontró registros que lo aceptaran entre los sistemas que había comprobado. Luego citó una excepción: un mantenedor incorporó un cambio de código después de conversar con Garth Miller. Una charla y una integración abrieron un camino; no dieron a los demás registros una regla previsible.

El registro de algoritmos DNSSEC de IANA muestra el número 18 como ML-DSA-44. Permite la firma de zona y marca MAY en los campos de uso e implementación para firma y validación. Esos campos fijan el nivel de requisito permitido; el despliegue en registros, firmantes y resolutores corresponde a otro estado operativo.

El detalle de EPP es pequeño y decisivo. RFC 5910 transporta datos DS mediante EPP. El campo alg identifica el algoritmo de la DNSKEY asociada; digestType identifica el resumen que forma la DS. El borrador individual de Joe Abley, fechado el 14 de octubre, se limita a esos dos campos. Propone que los registros DNSSEC de IANA sirvan como regla común, con excepciones para valores incapaces de aportar seguridad DNSSEC. Datatracker mantiene únicamente la versión individual 00 en estado I-D Exists; el texto carece de estatus normativo de IETF.

Así aparece el punto de control. El firmante prepara un algoritmo nuevo e IANA puede asignarle un número; el registro padre todavía decide si el registrador puede enviar la DS. Si rechaza la solicitud, la zona hija no completa el paso en la zona padre que requiere el cambio de algoritmo. Una lista local sin publicar convierte la transición en una apuesta.

Aceptar y validar son decisiones distintas. Un resolutor que no admite el algoritmo ignora esa DS. Si no queda otra DS compatible, trata la zona hija como no firmada. EPP abre el canal de envío; el soporte del resolutor es una etapa de despliegue separada.

Al borrador le falta una matriz fechada que nombre los registros y los valores EPP probados; publicarla mostraría el alcance de la variación.

Fuentes primarias: charla de RIPE 93 · transcripción de la sesión · registro IANA de algoritmos DNSSEC · RFC 5910 · RFC 4035 · borrador individual de Joe Abley, versión 00.