Zusammenfassung
- Seit der Änderung vom 12. Mai 2026 enthält die Registration Data Policy für authentifizierte Eilanfragen eine Zwei-Stunden-Bestätigung, eine 24-Stunden-Antwort und eine äußerste Ausnahmegrenze von 72 Stunden.
- Nach dem Umsetzungshinweis wird Abschnitt 10.7 erst an dem Tag wirksam, an dem ICANN eine Consensus Policy für einen Authentifizierungsprozess vollständig umgesetzt hat.
- Die Authentication Input Group berät einen Machbarkeitsnachweis technisch und betrieblich. Sie entwickelt keine Policy; Testbeginn im Dezember 2026 und Ergebnispublikation im März 2027 sind keine automatischen Wirksamkeitsdaten.
- Authentifizierung bestätigt eng umrissene Merkmale des Antragstellers. Dringlichkeit, Zuständigkeit, Rechtsgrundlage, Erforderlichkeit und Offenlegungsentscheidung bleiben getrennte Prüfungen.
Der Normtext hat bereits eine klare Uhr
Die Registration Data Policy behandelt nicht jede Anfrage nach nichtöffentlichen gTLD-Registrierungsdaten als möglichen Eilfall. Abschnitt 3.8 verlangt einen authentifizierten Antragsteller und begrenzt die Kategorie auf eine unmittelbar drohende Lebensgefahr, schwere Körperverletzung, kritische Infrastruktur oder Ausbeutung von Kindern, wenn die Offenlegung zur Bekämpfung oder Abwehr der Gefahr erforderlich ist.
Abschnitt 3.9 definiert den Authenticated Requestor als Strafverfolgungsstelle oder vertrauenswürdige beziehungsweise zuständige Behörde, die durch einen nach ICANN Consensus Policy umgesetzten Mechanismus authentifiziert wurde. Abschnitt 10.7.1 verlangt zusätzlich eine Erklärung des Antragstellers, dass der konkrete Fall unter die Eildefinition fällt.
Danach beginnt eine messbare Abfolge. Registrar und Registry-Betreiber bestätigen den Eingang binnen zwei Stunden. Sie antworten ohne unangemessene Verzögerung und normalerweise spätestens nach 24 Stunden. Liegen außergewöhnliche Umstände vor, muss auch die Verlängerungsmitteilung innerhalb von 24 Stunden erfolgen, den Grund nennen und einen Endtermin festlegen, der 72 Stunden seit Eingang nicht überschreitet.
Die Policy grenzt die Ausnahme ein. Höhere Gewalt oder die Komplexität einer Anfrage mit sehr vielen Domainnamen können genügen. Feiertage, geplanter Urlaub und geplante Reisen genügen ausdrücklich nicht. Damit wird nicht nur Geschwindigkeit gefordert. Es werden Eingang, Bestätigung, Antwort, Ausnahme und äußerste Grenze als unterschiedliche Zustände definiert.
Die ICANN-Mitteilung vom 12. Mai ordnet die Frist in ihren Zweck ein. Wo Leben, körperliche Unversehrtheit, Kinder oder kritische Infrastruktur betroffen sind, kann eine unklare Übergabe den Schaden vergrößern. Eine überprüfbare Zeitregel ist deshalb ein legitimes Ziel.
In derselben Mitteilung steht aber auch, dass der neue Eilanfrage-Text erst nach Umsetzung eines Authentifizierungsmechanismus für Strafverfolgungsbehörden in Kraft tritt.
Die Startbedingung gehört zur Pflicht
Der Umsetzungshinweis formuliert die Schwelle noch genauer: Die Pflichten aus Abschnitt 10.7 werden an dem Tag wirksam, an dem ICANN eine Consensus Policy vollständig umgesetzt hat, die einen Prozess zur Authentifizierung des Antragstellers schafft. Benötigt werden also sowohl die richtige normative Autorität als auch der abgeschlossene Umsetzungszustand.
Die Registration Data Policy insgesamt gilt seit dem 21. August 2025. Es wäre falsch, die gesamte Policy als noch nicht wirksam zu bezeichnen. Der Vorbehalt betrifft die 2026 ergänzten Eilpflichten. Ebenso falsch wäre es, aus der Veröffentlichung der MUST-Sätze ihre gegenwärtige Durchsetzbarkeit abzuleiten.
Die Statusseite zur GAC Advice hält beide Ebenen fest. Das Board schloss den Beratungspunkt zur Antwortfrist, weil der 24-Stunden-Text veröffentlicht worden war. Im selben Eintrag stellt es fest, dass die Durchsetzung der Frist von der Verfügbarkeit eines Authentifizierungsmechanismus abhängt. Der Auftrag, eine Frist zu formulieren, ist erledigt; ihre Aktivierung ist es nicht.
Gerade weil der Text amtlich ist, kann die Differenz praktisch gefährlich werden. Eine Suchmaschine hebt Abschnitt 10.7 hervor und verliert den späteren Hinweis. Eine Polizeistelle plant mit dem veröffentlichten Versprechen. Ein Registrar sieht die Bedingung und verschiebt jede Bereitschaft. Ein Compliance-System beginnt zu früh mit seiner Verstoßzählung. Alle zitieren echte Informationen, aber nicht denselben Policy-Zustand.
Bedingte Wirksamkeit ist kein Fehler. Sie ist sinnvoll, wenn eine Pflicht ohne verlässliche Eingangsvoraussetzung nicht einheitlich angewandt werden kann. Der Fehler wäre, Regel und Abhängigkeit bei jeder Weitergabe zu trennen. Version, Bedingung, Aktivierungsakt und betroffene Kohorte müssen als Einheit reisen.
Ein Prototyp kann Machbarkeit, nicht Zuständigkeit beweisen
ICANNs Input Group: Law Enforcement Agency Authentication Mechanisms unterstützt einen Machbarkeitsnachweis für die Authentifizierung von Strafverfolgungsmitarbeitern über RDRS oder ein Nachfolgesystem. Sie befasst sich mit Prozessablauf, technischen Anforderungen und Authentifizierung.
Der öffentliche Fahrplan nennt RDRS-Wireframes im Oktober 2026, Testbeginn im Dezember und eine Zusammenfassung der Erkenntnisse im März 2027. Diese Meilensteine machen Projektfortschritt überprüfbar. Sie ersetzen keinen Wirksamkeitsakt.
Die Projektseite sagt ausdrücklich, dass die Gruppe kein Policy-Entwicklungsorgan ist und keine Policy-Empfehlungen erstellt. Der Teilnahmeaufruf nennt operative Themen: die Integration vorhandener Authentifizierungssysteme, zu validierende Informationen, Datenschutz, Datensparsamkeit, Sicherheit, Transparenz, Revisionsfähigkeit, Protokollierung und Benutzbarkeit.
Ein Test kann zeigen, ob ein signiertes Merkmal interoperabel ist, wie schnell ein Widerruf ankommt oder welche personenbezogenen Daten unnötig offengelegt würden. Er kann die Policy-Entscheidung informieren. Aus technischem Erfolg entsteht aber nicht die Befugnis, die im Umsetzungshinweis verlangte Consensus Policy zu schaffen.
Parallel befasst sich das GNSO Supplemental Recommendations Team mit Akkreditierungsfragen für ein künftiges standardisiertes Zugangs- und Offenlegungssystem. Eine Verbindung zwischen beiden Arbeitssträngen ist notwendig, weil technische Entscheidungen politische Konsequenzen sichtbar machen. Die Verbindung verschmilzt ihre Mandate nicht. Dezember bleibt ein Testtermin, März ein Berichtstermin, solange eine zuständige Quelle sie nicht ausdrücklich mit der vollständigen Policy-Umsetzung verbindet.
Wer authentifiziert ist, hat noch keinen Anspruch auf Daten
Eine gemeinsame Authentifizierung kann wertvolle Zeit sparen. Ein Registrar sollte im Eilfall nicht jedes Mal von vorn prüfen müssen, ob eine Behörde existiert, der Mitarbeiter zu ihr gehört, sein Nachweis gültig ist und er ihn verwenden darf. Eine signierte, widerrufbare und begrenzte Behauptung kann diesen Schritt standardisieren.
Sie darf nicht mehr behaupten, als sie geprüft hat. Die Identität eines Polizeimitarbeiters beweist keine unmittelbar drohende Gefahr. Die Zugehörigkeit zu einer Behörde beweist keine Zuständigkeit für den konkreten Domainnamen. Der Nachweis klärt weder Rechtsgrundlage noch Erforderlichkeit oder Verhältnismäßigkeit und berechtigt nicht automatisch zum Erhalt jedes angeforderten Datenfelds.
Die Policy trennt die Prüfungen. Der Antragsteller gibt eine eigene Dringlichkeitserklärung ab. Der Umsetzungshinweis lässt Zuständigkeit und anwendbares Recht in der Offenlegungsprüfung bestehen. Die Antwort kann vollständig oder teilweise offenlegen oder begründet ablehnen. Abschnitt 10.8 erlaubt Korrekturmaßnahmen bei missbräuchlichen Anfragen oder Antragstellern.
Eine Authentifizierungsentscheidung sollte deshalb nur sagen: Dieses Subjekt trägt zu diesem Zeitpunkt nach diesem Vertrauensniveau die genannten Merkmale. Die Sachentscheidung bleibt beim Registrar oder Registry-Betreiber, der dafür rechtlich und vertraglich einstehen muss.
Würde dieselbe zentrale Stelle Identität, Dringlichkeit, Zuständigkeit und Offenlegung bestimmen, entstünde durch technische Akkreditierung eine grenzüberschreitende Entscheidungsinstanz. Authentifizierung allein liefert weder ihr Mandat noch Haftung oder Rechtsschutz.
Der Briefwechsel mit Indien macht die Kompetenzkette sichtbar
Im Schreiben vom 11. August 2026 an die indische Regierung bestätigt ICANNs CEO, dass die Registration Data Policy eine 24-Stunden-Regel enthält, ihre Durchsetzung aber von einem geeigneten Authentifizierungsmechanismus abhängt. Er verweist auf die Zusammenarbeit mit der GAC Public Safety Working Group, Strafverfolgungsvertretern und der neuen Input Group.
Der Brief behandelt außerdem Indiens Vorschlag einer 15-tägigen Verifizierungsfrist und zusätzlicher Berichtspflichten. Die Antwort macht daraus keine unmittelbaren Pflichten. Neue Verpflichtungen für Vertragsparteien müssen durch den zuständigen Policy- oder Vertragsprozess entstehen. Nach den ICANN Bylaws entwickelt die GNSO gTLD-Policy und führt den PDP. Der CEO kann unterstützen und angenommene Policy umsetzen, aber keine Prioritäten oder Ergebnisse der GNSO bestimmen.
Diese Reihenfolge kann angesichts eines Sicherheitsinteresses langsam erscheinen. Sie ist dennoch die Quelle der Verbindlichkeit. Eine Regierung formuliert den Bedarf. Der GAC berät. Fachgruppen testen. Die GNSO entscheidet in ihrem Mandat. Das Board handelt, die Organisation implementiert und Vertragsparteien erfüllen. Wer einen Glied überspringt, beschleunigt nicht notwendigerweise die Reaktion; er verschiebt die Auseinandersetzung in den Ernstfall.
Eine Aktivierungsquittung für den Zustandswechsel
Daniel Kade schlägt eine kurze, versionierte Aktivierungsquittung vor. Sie wäre weder geltende ICANN-Policy noch ein öffentliches Verzeichnis von Beamten oder Fällen. Sie würde nachweisbar machen, dass die in Abschnitt 10.7 genannte Abhängigkeit autorisiert erfüllt wurde.
Die Quittung bindet exakte Policy-Version und Fingerabdruck, die abhängige Consensus Policy, den Vollzugsakt, die zuständige Autorität, Datum, Uhrzeit, Zeitzone und kanonische Fundstelle. Sie nennt abgedeckte Antragstellerklassen, Version und Bedeutung des Assurance-Profils, Widerrufssignal und alle Eingangsflächen, die den Zeitlauf starten können.
Sie muss Eingang definieren. Beginnt die Frist bei Annahme durch RDRS, beim Eintreffen im System der Vertragspartei oder beim Öffnen durch einen Mitarbeiter? Welcher Zeitstempel gilt nach einer Wiederholung? Wie verhält sich ein direkter Kanal bei RDRS-Ausfall? Welches Regime gilt für eine Anfrage, die im Aktivierungszeitpunkt bereits unterwegs war? Eine genaue Endfrist benötigt einen genauen Start.
Auch Ausnahmeweg und Compliance-Nenner gehören hinein: Zwei-Stunden-Bestätigung, 24-Stunden-Antwort, rechtzeitige Verlängerungsmitteilung, 72-Stunden-Obergrenze. Eine Anfrage vor Inkrafttreten, ein Authentifizierungsfehler und ein wirksam eingegangener authentifizierter Eilfall dürfen nicht gemeinsam bewertet werden.
Die wichtigste Zeile ist negativ: Der Nachweis bestätigt ausschließlich die aufgeführten Merkmale. Er bestätigt keine Dringlichkeit, Zuständigkeit, Rechtsgrundlage, Erforderlichkeit, Verhältnismäßigkeit oder Offenlegungsberechtigung. Antragstelleridentitäten, Ermittlungen, Zieldomains und nichtöffentliche Registrierungsdaten gehören nicht in die öffentliche Quittung.
Antwortqualität ist nicht Offenlegungsquote
Der SAC122-Bericht empfahl aggregierte Angaben über Anzahl, Bearbeitungsgeschwindigkeit, ungültige Anfragen und Einhaltung der Vertragsfristen. Seine früheren Detailvorschläge ersetzen nicht den finalen Text; sein Messprinzip bleibt nützlich.
Nach Aktivierung sollte der Nenner mit authentifizierten Eilanfragen beginnen, die über einen anerkannten Kanal eingegangen sind. Nachweisfehler, Formatmängel, Nicht-Eil-Einstufung, Nachforderung, rechtliche Ablehnung, Teil- und Volloffenlegung, Verlängerung und Systemausfall müssen getrennt bleiben. Ebenso Eingangsbestätigung, Antwort und Abschlusszeit.
Eine fristgerechte begründete Ablehnung kann die Antwortpflicht erfüllen. Eine späte Offenlegung kann sie verletzen. Die Offenlegungsquote ist deshalb kein Qualitätswert. Würde sie zum Ziel, würde sorgfältiger Datenschutz als geringe Produktion behandelt.
Grenzen der Belege
Die ausgewerteten Quellen bestimmen weder das endgültige Aktivierungsdatum noch Identitätsanbieter, Föderationsmodell, Assurance-Profil, Übergangsregel oder Compliance-Nenner. Sie bezeichnen den Test im Dezember 2026 nicht als Inkrafttreten von Abschnitt 10.7. Der Beitrag folgert nicht, dass Eilanfragen vor der Aktivierung nicht über andere rechtmäßige Verfahren bearbeitet werden können. Aktivierungsquittung und schlanke Authentifizierung sind Analysen von Daniel Kade.
Quellen
Mitgliederbriefing
Detaillierter Profilkontext
Melden Sie sich mit der richtigen Mitgliedschaftsstufe an, um das vollständige Briefing und die Quellennotizen freizuschalten.
Nur für Strategic Circle
Strategic Circle
Offen für alle Leser. Schalten Sie Profil-Briefings nach Beitritt und Anmeldung frei.
Strategic Circle beitretenNur für Leadership Alliance
Leadership Alliance
Für qualifizierte Inhaber von IP-Assets und Management; melden Sie sich an, um Leadership-Alliance-Briefings freizuschalten.
Leadership Alliance beitreten