Zusammenfassung

  • RFC 5105 nennt eine gültige Signatur eine notwendige, aber nicht hinreichende Bedingung für ein gültiges Validation Token. Die Registry prüft zusätzlich Signaturumfang, Transformationen, Algorithmus, Zertifikat, VE-Akkreditierung, Registrar, Nummer, Methode, Datum und Replay-Regel.
  • Das Token bescheinigt eine Validierungshandlung. Es ist weder die Autorisierungsentscheidung noch ein EPP-Commit, eine autoritative DNS-Veröffentlichung, eine Resolver-Beobachtung oder ein erfolgreicher Dienst.

Ein XML-Dokument besteht die Schema-Prüfung und seine Signatur ist gültig. Es nennt jedoch eine Validierungsmethode, die für die beantragte Nummernklasse nicht mehr zugelassen ist. Welcher Befund gewinnt?

Beide Befunde bleiben wahr. Das Dokument ist formal und kryptografisch prüfbar. Die beantragte Delegierung kann trotzdem abgelehnt werden. Der Fehler entsteht erst, wenn ein System aus Formgültigkeit eine materielle Erlaubnis macht.

RFC 5105 standardisiert ein signiertes XML Validation Token für ENUM. ENUM-Domainnamen hängen an E.164-Nummern. Deshalb muss die beantragte Registrierung zum Assignee der Nummer und zu dessen Autorisierung passen.

RFC 4725 trennt Assignee, ENUM Registrant, Validation Entity, Registrar, Registry, DNS Service Provider und Application Service Provider. Die VE prüft. Der Registrar reicht ein. Die Registry entscheidet und betreibt die Masterdatenbank sowie die autoritative Zone. Eine spätere Anwendung nutzt das veröffentlichte Ergebnis.

Das Token transportiert die VE-Aussage über einen Weg, auf dem der Registrar selbst möglicherweise keine maßgebliche Nummernzuordnung kennt. Die Signatur schützt Herkunft und Inhalt gegen Veränderung. Sie überträgt keine Registry-Kompetenz an die VE oder an den kryptografischen Prüfer.

Pflichtfelder sind eine innerhalb der VE eindeutige Seriennummer, die E.164-Nummer, optional das Ende eines Nummernblocks, VE-ID, Registrar-ID, Methoden-ID, Ausführungsdatum und ein optionales Ablaufdatum. Ein eigener optionaler Bereich kann Kontaktdaten enthalten.

Die Seriennummer ist nicht global. Wer nur 000001 speichert, entfernt den Namensraum. VE und Serial gehören zusammen; für die Entscheidung werden außerdem exakter Token-Hash, Registrar, Nummernbereich, Methode, Zeitangaben und Policy-Fassung benötigt.

Der Nummernbereich ist ebenfalls eng. Anfang und optionales Ende bilden einen geschlossenen Bereich und müssen dieselbe Länge haben. Eine Normalisierung, die Struktur entfernt oder den Bereich erweitert, verändert die signierte Behauptung. Die Signatur kann diese spätere Fehlinterpretation nicht legitimieren.

RFC 5105 verwendet enveloped XML-DSIG und exklusive XML-Kanonisierung. Dadurch ändern geerbte Namespace-Deklarationen eines äußeren XML-Protokolls nicht das signierte Material. Kanonisierung stabilisiert eine Darstellung; sie bestätigt weder Schema-Semantik noch Registry-Policy.

Der Referenzumfang ist entscheidend. Reference URI="#TOKEN" muss das Element mit Id="TOKEN" bezeichnen. Würde die ID zum optionalen tokendata verschoben, könnte eine Bibliothek die Signatur über Kontaktdaten korrekt validieren, obwohl Nummer, Methode und Datum ungeschützt blieben. Der RFC nennt eine solche Signatur für den Zweck wertlos.

Die Registry darf daher nicht bei einem allgemeinen XML-DSIG-Erfolg stehen bleiben. Sie prüft zugelassene Transformationen und Algorithmen, die Referenz auf das vollständige Token und die Zuordnung des Schlüssels zu einer akkreditierten VE. Das signierte Beispiel sagt ausdrücklich: gültig ist notwendig, aber nicht ausreichend. Zertifikat und XML-Schema sind weitere Prüfungen.

Auch ein eingebettetes X.509-Zertifikat akkreditiert sich nicht selbst. Die Registry kann selbst CA sein, einer öffentlichen CA vertrauen oder nur vorregistrierte Schlüssel akzeptieren. Die Wahl ist lokale Policy. Das Zertifikat liefert Prüfmaterial, wählt aber weder Trust Anchor noch institutionellen VE-Status.

Eine belastbare Historie speichert deshalb Trust Store und Akkreditierung zum Entscheidungszeitpunkt. Die Zertifikatslaufzeit kann fortbestehen, nachdem die VE-Akkreditierung beendet wurde. Eine spätere Policy-Änderung kann die heutige Bewertung verändern, darf aber die damalige Beobachtung nicht überschreiben.

Die Registrar-ID bindet das Token an den vorgesehenen Einreicher. Kopiert ein zweiter Registrar das unveränderte Dokument, bleibt die Signatur gültig. Der Abgleich mit dem Antrag zeigt jedoch die falsche Partei. Perfekte Integrität wird in diesem Fall zum Beleg gegen die Autorisierung.

Auch die Daten benötigen Policy. executionDate bezeichnet die Durchführung. expirationDate bezeichnet das Ende; fehlt es, bedeutet das im Format unendliche Gültigkeit. Trotzdem muss die Registry prüfen, ob gerade diese fehlende Befristung zulässig ist. Die lokale Policy legt zusätzlich fest, wie lange nach Ausführung das Token verwendet werden darf.

„Nicht abgelaufen“ reicht deshalb nicht. Die Einreichungsfrist kann trotz späterem Ablaufdatum vorbei sein. Unbefristung kann verboten sein. Beide Zeitprüfungen können bestehen und der Registrar dennoch falsch sein. Jede Entscheidung braucht eine Policy-Version und einen verlässlichen Zeitbezug.

methodID ist ein Bezeichner, kein Ausführungsnachweis. RFC 4725 lässt Methoden je nach Datenquelle, Partei, Wahl des Assignee und regulatorischen Anforderungen variieren. Die Registry bewertet, ob die angegebene Methode für Nummer und Zeitpunkt genügt. Ein String führt die Prüfung nicht aus.

Die erste Validierung beendet den Lebenszyklus nicht. Die ENUM-Delegierung muss Änderungen der E.164-Zuordnung folgen. Erfolgreiche Revalidierung kann sie erhalten; Fehlschlag führt zur Suspendierung, ausdrücklich oder beim Ablauf, gegebenenfalls nach lokaler Schonfrist. Ein altes positives Token überstimmt kein jüngeres negatives Ereignis.

Replay-Schutz erfordert Verwendungszustand. VE, Serial, Hash, Registrar, Umfang, erste Vorlage, Entscheidung und zulässiges Fenster müssen gemeinsam gespeichert werden. Sonst lässt sich ein legitimer Retry nicht von einer bereits abgelehnten oder erneut missbrauchten Vorlage unterscheiden.

Optionale Kontaktdaten bleiben Unterstützung. Firmenname oder E-Mail beweisen keine aktuelle Nummernzuordnung. Das Token ist nicht verschlüsselt. Verlangt die Policy Vertraulichkeit, braucht sie einen anderen Schutz. Signatur, Transportverschlüsselung, Datenminimierung und Autorisierung dürfen nicht in einem Status „sicher“ verschwinden.

Algorithmen haben einen zeitlichen Kontext. RFC 5105 verlangte RSA-SHA1 und RSA-SHA256 und wies bereits auf Zweifel an SHA-1 hin. Welche Verfahren und Schlüssellängen akzeptiert werden, entscheidet die Registry. Rechenfähigkeit einer Bibliothek ist keine aktuelle Zulassung.

Nach der Token-Annahme folgt die Ausführung. RFC 5076 definiert eine EPP-Erweiterung zum Hinzufügen, Ändern, Entfernen und Abrufen von Validierungsinformationen. Ein erfolgreiches EPP-Ergebnis belegt diese Transaktion, nicht die Veröffentlichung der autoritativen Zone.

Die Registry-Datenbank kann committen und die Zonengenerierung scheitern. Autoritative Server können aktualisiert sein, während rekursive Caches alte Daten liefern. RFC 3761 kann über ENUM zu einer URI führen; Erreichbarkeit und abgeschlossene Kommunikation folgen daraus nicht.

Ein revisionsfähiges Modell erzeugt getrennte Belege. Der Kryptografie-Beleg enthält Originalbytes, Hash, Parser, Schema, aufgelöste ID, Referenzknoten, Transformationen, kanonisierte Eingabe, Algorithmen, Zertifikatspfad, Trust Anchors und Ergebnis. Er behauptet keine Delegierungsentscheidung.

Der Policy-Beleg enthält VE-Akkreditierung, Methode, Registrar-Abgleich, E.164-Umfang, Daten, Nutzungsfenster, Policy-Version und Replay-Historie. Die Registry gibt Annahme oder Ablehnung getrennt aus. EPP, Delegierungsdatenbank, autoritative Publikation, Resolver und Anwendung liefern nachgelagerte Belege.

So wird ein Vorfall lokalisierbar: falscher XML-Umfang, nicht akkreditierte VE, falscher Registrar, alte Methode, Replay, EPP-Fehler, DNS-Verzug oder nicht erreichbare Anwendung. Ein einziges „validiert“ verdeckt Ursache und Zuständigkeit.

Die Trennung folgt Heng Lus Realitätsebenen. Eine Signatur ist innerhalb ihrer Darstellungs- und Herkunftsebene stark. Sie wird gefährlich, wenn sie für Policy oder laufenden Dienst sprechen soll. Running-Code-Primacy verlangt von jeder Komponente den Nachweis ihres eigenen Übergangs.

Quellen