Zusammenfassung

  • IANA führt Algorithmus 18 als ML-DSA-44 und setzt für Verwendung und Implementierung bei Signatur und Validierung MAY. Für eingereichte DS-Daten bildet die EPP-Regel der Registry die nächste Schranke.
  • Auf der RIPE 93 rückte Joe Abley diese vorgelagerte Schranke ins Bild. Sein individuelles Draft vom Oktober schlägt vor, die Annahme von Algorithmen und Digest-Typen an den DNSSEC-Registern der IANA auszurichten.

Die Nummer stand fest. Der Antrag konnte trotzdem am nächsten Schalter liegenbleiben.

Am 29. Oktober erzählte Joe Abley in der DNS-Sitzung der RIPE 93 von seinen Versuchen, Algorithmus 18 über EPP einzureichen. In den von ihm geprüften Systemen habe er keine Registry gefunden, die den Wert annahm. Als Ausnahme nannte er einen Fall, in dem ein Maintainer nach einem Gespräch mit Garth Miller eine Codeänderung integrierte. Ein Gespräch und ein Merge öffneten einen Weg; für andere Registrys entstand daraus keine vorhersehbare Regel.

Das IANA-Register für DNSSEC-Algorithmen führt die Nummer 18 als ML-DSA-44. Die Zeile erlaubt den Einsatz für Zonen-Signaturen und weist für Nutzung sowie Implementierung bei Signatur und Validierung MAY aus. Das beschreibt das erlaubte Anforderungsniveau; die Einführung bei Registrys, Signierern und validierenden Resolvern ist ein eigener Betriebsstatus.

Der EPP-Mechanismus ist schmal, aber entscheidend. RFC 5910 transportiert DS-Daten über EPP. alg bezeichnet den Algorithmus des referenzierten DNSKEY; digestType benennt den Digest für die DS-Erzeugung. Joe Ableys individuelles Draft vom 14. Oktober behandelt genau diese beiden Felder. Es schlägt die IANA-Register für DNSSEC-Algorithmen und Digest-Typen als gemeinsame Annahmeregel vor, mit Ausschlüssen für Werte ohne DNSSEC-Schutzwirkung. Datatracker führt nur das individuelle Draft 00 im Status I-D Exists; ein IETF-Standardsstatus besteht nicht.

Damit wird der Kontrollpunkt sichtbar. Ein Signierer kann einen neuen Algorithmus vorbereiten und IANA ihm eine Nummer geben; die Parent-Registry entscheidet weiterhin, ob der Registrar die DS übermitteln darf. Lehnt sie die Anfrage ab, kann die Child-Zone den Parent-Schritt der Algorithmusumstellung nicht abschließen. Eine unveröffentlichte lokale Positivliste macht technische Weiterentwicklung zum Ratespiel.

Annahme und Validierung sind getrennte Entscheidungen. Ein Resolver ohne Unterstützung ignoriert die entsprechende DS. Bleibt keine unterstützte DS übrig, behandelt dieser Resolver die Child-Zone als unsigniert. EPP öffnet den Einreichungsweg; die Resolver-Unterstützung folgt als eigener Bereitstellungsschritt.

Dem Draft fehlt eine datierte, Registry-genaue Kompatibilitätsmatrix; veröffentlichte EPP-Testwerte je Registry würden das Ausmaß der Unterschiede zeigen.

Primärquellen: RIPE-93-Vortrag · Transkript der DNS-Sitzung · IANA-Register der DNSSEC-Algorithmen · RFC 5910 · RFC 4035 · Joe Ableys individuelles Draft, Version 00.