Zusammenfassung

  • RFC 3982 unterschied bei leeren Werten private von denied: Der erste Zustand konnte dauerhafte Nichtveröffentlichung bedeuten, der zweite eine Verweigerung auf der aktuellen Zugriffsstufe.
  • Sichtbare Werte konnten specialAccess und doNotRedistribute tragen. Damit blieb der Grund des privilegierten Empfangs von der Befugnis zur Weitergabe getrennt.

Ein Bearbeiter erhält nach erfolgreicher Anmeldung den Kontakt zu einer Domain. Das System hat ihm den Wert zu Recht gezeigt. Daraus folgt jedoch nicht, dass er ihn in ein öffentliches Ticket kopieren darf. Authentisierung beantwortet, wer anfragt; Zugriffsrichtlinien beantworten, was diese Person sehen darf; eine Weitergaberegel beantwortet, was danach mit dem gesehenen Wert geschehen darf.

RFC 3982 gab dieser letzten Unterscheidung einen Platz im Protokoll. Der Statusdatensatz, die Errata und die Datatracker-Akte dokumentieren die Standards-Track-Spezifikation vom Januar 2005. Sie definierte den IRIS-Registertyp für Domains mit strukturierten Suchen und Ergebnissen für Domains, Hosts, Kontakte, Registrare und Registrierungsstellen.

Die Grundlage stand in den CRISP-Anforderungen. RFC 3707, Status, Errata und IETF-Verlauf verlangten, dass Betreiber granulare Zugriffsarten nach eigener Richtlinie vergeben konnten. Für einen nicht ausgegebenen Wert musste das Protokoll vollständige Auslassung, unzureichende Berechtigung und eine von der Berechtigung unabhängige Datenschutzgrenze ausdrücken können. Für einen ausgegebenen Wert waren mindestens „nicht weitergeben“ und „Sonderzugang gewährt“ vorgesehen, auch gleichzeitig.

Das Gegenmodell war das dokumentierte WHOIS. RFC 3912, dessen Statusseite, Errata und Datatracker-Verlauf beschreiben Textanfrage und Textantwort über TCP-Port 43. Das Dokument nennt ausdrücklich das Fehlen starker Sicherheit, Zugriffskontrolle, Integrität und Vertraulichkeit. Betreiber konnten menschenlesbare Hinweise hinzufügen, doch ein gemeinsames Feldmodell zum Erhalt des Auslassungsgrundes gab es nicht.

RFC 3982 erlaubte einschlägigen Ergebniselementen Inhalt oder leeren Inhalt. War ein Element vorhanden, aber leer, musste es mindestens eines von zwei booleschen Attributen tragen. private erklärte, dass der Inhalt fehlte, weil er möglicherweise nie veröffentlicht werden durfte. denied erklärte, dass die Richtlinie eine Ausgabe auf der aktuellen Zugriffsstufe nicht zuließ.

Der Unterschied verändert die nächste Entscheidung. Bei denied könnte eine andere Rolle oder Zugriffsklasse zu einem anderen Ergebnis führen, ohne dass dies versprochen wird. private bezeichnet eine grundsätzlichere Veröffentlichungsgrenze. Keines der Attribute behauptet, der Wert sei im Register nicht vorhanden. Wird das Element vollständig weggelassen, erhält der Client weiterhin keine standardisierte Begründung.

Bei vorhandenem Inhalt kamen zwei andere Attribute in Betracht. specialAccess kennzeichnete, dass Sonderrechte die Ausgabe ermöglicht hatten. doNotRedistribute kennzeichnete, dass der Inhalt nicht weitergegeben werden sollte. Das eine beschreibt den Zugangsweg, das andere die nachgelagerte Verwendung. Beide konnten zusammenstehen, weil ein privilegierter Empfänger nicht automatisch zu einem unbeschränkten Verteiler wird.

In Datenketten geht genau diese Trennung verloren. Ein Konverter übernimmt nur den Textknoten. Ein Data Warehouse macht aus nil einen leeren String. Eine Oberfläche zeigt den Kontakt, aber nicht die Weitergabesperre. Ein Cache mischt privilegierte und öffentliche Antworten. Zeichen und Spalten bleiben korrekt, während die Steuerungsinformation verschwindet.

Die Attribute waren selbst keine Durchsetzung. RFC 3981 und der Statusdatensatz sahen Berechtigungsfehler und eine vorgelagerte Berechtigungsprüfung im IRIS-Kern vor, überließen Authentisierung und Vertraulichkeit aber dem Anwendungstransport. RFC 3983 und dessen Statusseite definierten die BEEP-Abbildung. Ein Label verschlüsselt nicht, authentisiert nicht, verhindert keine Kopie und schafft allein keine Rechtsfolge. Es macht eine Richtlinienentscheidung transportierbar.

Das Problem tauchte im RDAP-Kontext wieder auf. RFC 9083, Status, Errata und Datatracker definieren das JSON-Antwortmodell. RFC 9537, Status, Errata und IETF-Akte ergänzen explizite Angaben zu redigierten Feldern.

RFC 9537 unterscheidet Entfernung, Leerwert, Teilwert und Ersatzwert. Es kann das betroffene Feld, die Methode und einen Grund nennen. Platzhalter wie XXXX werden abgelehnt, weil sie ein unzuverlässiges Signal sind und Feldformate verletzen können. Zugleich kann schon der Hinweis auf Redigierung verraten, dass sensible Daten existieren; dann darf der Server den Hinweis selbst unterdrücken.

Die offiziellen Quellen belegen keine direkte Abstammung dieser Erweiterung von RFC 3982. Eine solche Geschichte wäre stärker als die Evidenz. Sicher ist nur, dass dieselbe Mehrdeutigkeit bestehen blieb. Ein leeres Feld ist kein vollständiger Befund. Ein sichtbarer Wert ist keine grenzenlose Nutzungserlaubnis. Systeme müssen daher Wert, Abwesenheitsgrund, Zugriffskontext und Weitergaberecht getrennt erhalten.

Quellen