Zusammenfassung

  • RFC 9563 weist SM2 mit SM3 die DNSSEC-Algorithmusnummer 17 und SM3 den DS-Digest-Typ 6 zu. Die Werte haben damit eine eindeutige Bedeutung auf dem Draht.
  • Das Dokument ist ein Informational RFC aus dem Independent Stream, kein IETF-Standards-Track-Dokument. Es hält ausdrücklich fest, dass weder IETF noch IRTF die Eignung der Algorithmen untersucht haben.
  • Zwischen Registereintrag und authentifizierter DNS-Antwort liegen Implementierung, Delegation, Validator-Fähigkeit, lokale Policy, Signaturprüfung und Anwendungsergebnis.

Ein validierender Resolver liest in einer signierten Antwort die Algorithmusnummer 17. Die Nummer ist nicht mehr unbekannt: Das IANA-Register beschreibt ihre Bedeutung. Trotzdem kann dem Resolver SM2-Code fehlen, der in der Delegation verwendete Digest kann nicht unterstützt sein oder die lokale Policy kann den Pfad ablehnen. Selbst eine mathematisch gültige Signatur sagt nichts Abschließendes über die Verwahrung des privaten Schlüssels. Die Nummer eröffnet eine prüfbare Kette; sie ersetzt sie nicht.

RFC 9563 erschien am 4. Dezember 2024 und beschreibt SM2- und SM3-Formate für DNSSEC. Algorithmus 17 trägt das Kürzel SM2SM3, SM3 erhält den DS-Typ 6. Zugleich grenzt das Dokument seine Autorität klar ein: Informational, Independent Stream, kein Ergebnis eines IETF-Community-Konsenses. Weder IETF noch IRTF hätten die Eignung von SM2 oder SM3 für diesen Zweck analysiert; beabsichtigte oder unbeabsichtigte Schwächen seien möglich.

Dieser Hinweis ist kein redaktioneller Zierrat. Er verhindert, dass Publikation als Sicherheitsurteil ausgegeben wird.

Zuteilung beseitigt Mehrdeutigkeit, nicht Unsicherheit

Ohne gemeinsamen Codepunkt können zwei Implementierungen in DNSKEY, RRSIG oder DS nicht zuverlässig denselben Algorithmus signalisieren. Die Zuteilung hat daher einen konkreten Wert: Sie gibt einem Wire-Format einen interoperablen Namen und verhindert kollidierende Privatdeutungen.

Am 27. September 2026 führte das IANA-Register Algorithmus 17 bei Nutzung und Implementierung für Signatur und Validierung jeweils als MAY. Auch der DS-Digest-Typ 6 stand in allen einschlägigen Spalten auf MAY. Das ist ein datierter Registerbefund, keine Erhebung zur Verbreitung, Beschaffungsfreigabe oder kryptanalytische Bewertung.

RFC 6014 regelt den Zuteilungskontext: Wer darf nach welchem Prüfverfahren einen Wert erhalten und was bezeichnet er? Ein Register kann sachlich korrekt sein, obwohl kein Resolver einer bestimmten Flotte den Eintrag implementiert. Ebenso kann Code lange vor breiter Akzeptanz existieren. Ein Katalog ist keine Produktionsmessung.

RFC 7841 zeigt, wie Stream und Status in Header und Boilerplate lesbar bleiben. Die RFC-Nummer identifiziert eine dauerhafte Veröffentlichung. Sie löscht den Independent Stream nicht und erzeugt keinen IETF-Konsens.

DNSSEC validiert einen Pfad, nicht nur eine Operation

DNSSEC fragt nicht lediglich, ob eine Gleichung aufgeht. RFC 4033 trennt autoritative Server, sicherheitsfähige Resolver und Trust Anchors. RFC 4034 definiert DNSKEY, RRSIG, DS und Nachweise der Nichtexistenz. RFC 4035 verlangt dann einen Authentifizierungspfad: unterstützten Algorithmus auswählen, passenden Schlüssel finden, kanonische Daten rekonstruieren, Gültigkeitszeit prüfen und die Signatur entlang einer akzeptierten Kette verifizieren.

Ein Produkt kann die 17 parsen, ohne SM2 zu berechnen. Es kann SM2 unterstützen und den DS-Digest 6 nicht. Die Child-Zone kann DNSKEY veröffentlichen, während in der Parent-Delegation kein nutzbarer DS liegt. Selbst bei vorhandenen Primitiven kann die lokale Policy den Weg ausschließen.

RFC 6840 beschreibt die Folge eines nicht unterstützten DS-Digests: Er wird wie ein unbekannter DNSKEY-Algorithmus verworfen. Bleibt kein unterstützter DS übrig, kann die Delegation als insecure statt bogus behandelt werden. Die Zone ist signiert und das Register korrekt, doch dieser Validator besitzt keinen ausführbaren Authentifizierungspfad.

Darum pflegt RFC 8624 Empfehlungen für Einsatz und Implementierung. Algorithmuswechsel brauchen eine Überlappung zwischen Signierern und Validatoren. Die dortige Tabelle entstand vor RFC 9563 und beweist keinen heutigen Support für Nummer 17 oder Typ 6. Dieser muss in Produkt, Version, Kryptobibliothek, Build, Konfiguration und realer Resolver-Population gemessen werden.

Eine gültige Signatur beantwortet eine begrenzte Frage

RFC 9563 definiert die Kodierungen, die für die kryptografische Operation nötig sind. Eine erfolgreiche Prüfung zeigt, dass kanonische DNS-Daten unter einem bestimmten Schlüssel, Regelwerk und Zeitfenster zur Signatur passen. Sie beweist nicht, wer den privaten Schlüssel kontrollierte, ob seine Nutzung autorisiert war, ob ein Rollover Kontinuität wahrte oder ob die Anwendung die Antwort annahm.

RFC 7583 behandelt Erzeugung, Speicherung, Rollover, Kompromittierung und Stilllegung als operative Aufgaben. Auch RFC 9563 fordert Krypto-Agilität: Bei Schwächen müssen DS, DNSKEY, RRSIG und NSEC3 möglicherweise cachebewusst erneuert werden. Eine Registerzeile führt diesen Übergang nicht aus.

Die belastbare Beweiskette verbindet Publikationsherkunft, aktuellen Registerstand, Build und Konfiguration des Signierers, beobachtete DNSKEY/DS/RRSIG, Resolver-Fähigkeiten, Trust Anchors und Policy, Validierungsprotokoll, Rollover-Kontinuität und Anwendungsergebnis. Jeder Beleg behält seine Grenze.

Heng Lus Vorrang des laufenden Codes liefert dafür die Leseregel: Symbolische Autorität, konfigurierte Absicht, ausführbare Fähigkeit und beobachtetes Ergebnis sind verschiedene Realitäten. RFC 9563 macht SM2 und SM3 in DNSSEC benennbar. Was danach geschieht, zeigen nur konkrete Systeme.