Zusammenfassung

  • Die eingefrorene LACNIC-Ausgabe 20260828 erklärt im Versionskopf und in drei Summenzeilen 49.894 Datensatzzeilen. Nach den Ausschlussregeln des veröffentlichten RIR-Formats enthält sie 48.214. Die komplette Differenz von 1.680 liegt in der ASN-Summe: 16.000 gemeldet, 14.320 tatsächlich vorhanden.
  • latest und die datierte Datei waren bytegleich; beide veröffentlichten MD5-Werte stimmten mit der unabhängigen Berechnung überein. Damit scheidet bei dieser Erhebung eine gewöhnliche Transportabweichung aus. Die Kopfzahl und die Bedeutung einzelner Zeilen werden dadurch nicht richtig.
  • Für den dauerhaften Alias fehlte latest.asc. Die datierte Signatur ließ sich mathematisch verifizieren, wurde aber 2026 mit SHA-1 unter einem DSA-1024-Schlüssel von 2002 erstellt. Genau diese Kombination darf modernes OpenPGP nicht erzeugen oder akzeptieren.

Eine Summe, die nur auf dem Etikett stimmt

2|lacnic|20260828|49894|19870101|20260828|-0300 lautet die erste Zeile. Das RIR Statistics Exchange Format weist dem vierten Feld eine eindeutige Bedeutung zu: Zahl der Datensatzzeilen nach Abzug von Versionszeile, Summenzeilen, Kommentaren und Leerzeilen. Die typbezogenen Summen sollen ebenfalls Zeilen zählen, nicht die Gesamtmenge der darin dargestellten Ressourcen.

Die Metadaten sind untereinander schlüssig. Für IPv4 werden 20.375 Zeilen genannt, für IPv6 13.519 und für ASN 16.000. Zusammen ergibt das 49.894, genau wie im Versionskopf. Eine Prüfung, die nur Kopf und Summen vergleicht, findet keinen Fehler.

Der Dateikörper erzählt eine andere Geschichte. Insgesamt gibt es 48.218 physische Zeilen: eine Versionszeile, drei Summen und 48.214 Datensätze. IPv4 kommt tatsächlich auf 20.375, IPv6 auf 13.519. Der ASN-Teil enthält 14.320 Zeilen. Die Differenz zu den gemeldeten 16.000 beträgt 1.680 und erklärt die gesamte Lücke im Gesamtkopf.

Diese Beobachtung ist kein Beleg für 1.680 verschwundene ASNs. Das Format warnt selbst davor, die Zahl der Zeilen mit der Ressourcenmenge gleichzusetzen. Die Prüfung bewertet auch keinen einzelnen Eintrag als falsch. Sie belegt weder verlorene Rechte noch eine fehlerhafte Delegation, eine falsche Route oder einen Ausfall. Reproduzierbar ist nur: Wer die veröffentlichte Zähldefinition befolgt, erhält nicht die Zahl des Herausgebers.

Gerade diese enge Aussage ist für eine Maschinenschnittstelle relevant. LACNIC beschreibt das Verzeichnis als tägliche Übersicht über IPv4-, IPv6- und ASN-Zuteilungen und -Zuweisungen. Das Austauschformat schafft mit delegated-<registry>-latest einen dauerhaften Namen für automatische Jobs. Das Feld records ist damit eine zugesagte Prüfbedingung. Entweder sie gilt, oder die Abweichung braucht einen öffentlich lesbaren Status.

Was zugunsten von LACNIC feststeht

Eine belastbare Kritik muss LACNICs stärkste Argumente vollständig anerkennen.

Zum Erfassungszeitpunkt bestanden delegated-lacnic-latest und delegated-lacnic-20260828 aus denselben 2.311.991 Bytes. Beide hatten den SHA-256-Wert 95d59beaa4deb0ed5f40ae33a37210e11b4bce5b518613cfd4097fe442e7abf4. Auch ETag und Last-Modified der HTTP-Antworten waren gleich. Der beobachtete Alias verwies also nicht auf einen anderen Inhalt als die datierte Ausgabe.

Beide MD5-Begleitdateien nannten 30f2fac07e846d1706c1fa8c7bb0ebd6. Eine unabhängige Berechnung lieferte für beide Datenobjekte denselben Wert. Für die begrenzte Aufgabe, viele zufällige Übertragungsfehler zu erkennen, funktionierte das Altverfahren. Es gibt hier keinen Befund einer abgeschnittenen oder unterwegs veränderten Datei.

Auch die abgetrennte Signatur der datierten Ausgabe gehört mathematisch zu den Bytes. Die Prüfung zerlegte die OpenPGP-Pakete, rekonstruierte den signierten SHA-1-Hash und setzte die veröffentlichten DSA-Parameter in die Verifikationsgleichung ein. Das Ergebnis war wahr. Eine Fälschung oder Manipulation zu behaupten, wäre mit diesem Befund unvereinbar.

Schließlich verlangt das alte Austauschformat eine passende MD5-Datei, stellt eine zusätzliche PGP-Signatur aber frei. Deshalb ist das fehlende latest.asc allein kein Verstoß gegen eine damalige Signaturpflicht. Die berechtigte Frage lautet, ob die vorhandenen Bausteine heute eine gemeinsame Vertrauensentscheidung ermöglichen.

Vier Prüfungen statt eines Schlagworts

Transportkonsistenz fragt, ob empfangene Bytes zum veröffentlichten Digest passen. Die MD5-Dateien sagen hier ja. RFC 6151 hält MD5 jedoch für nicht mehr akzeptabel, wenn Kollisionsresistenz erforderlich ist. Das Verfahren kann gewöhnliche Übertragungsfehler aufdecken, aber keine moderne Herausgeberidentität begründen.

Authentizität fragt, ob ein vertrauenswürdiger Schlüssel diese Bytes mit akzeptablen Algorithmen autorisiert hat. Für die datierte Ausgabe existiert eine mathematische Beziehung. Für den automatischen Alias fehlt die namensgleiche Signatur.

Strukturelle Integrität fragt, ob die Datei ihre eigenen Invarianten erfüllt. Die Zeilenzahl tut es nicht. Eine korrekte Signatur kann einen falschen Kopf zuverlässig konservieren; sie macht ihn nicht richtig.

Semantische Richtigkeit fragt, ob jeder Eintrag die Registry-Wirklichkeit zutreffend beschreibt. Das wurde nicht untersucht. Die Statistik ist laut Spezifikation eine Momentaufnahme ohne Transaktions- oder Verlaufsdetails. Sie beweist weder Live-BGP-Routen noch Geografie, wirtschaftliches Eigentum oder aktuelle Nutzung.

Die Trennung schützt vor zwei Überdehnungen. Eine Signatur ist kein universelles Wahrheitssiegel. Zugleich ist die begrenzte Aussagekraft einer Signatur keine Entschuldigung, die vom Herausgeber beherrschbaren Angaben — Bytes, Ausgabe, Zahl, Schlüssel und Korrektur — unverbunden zu lassen.

Der Umweg vom Alias zur Signatur

Bei der Erhebung antwortete delegated-lacnic-latest.asc mit HTTP 404. delegated-lacnic-20260828.asc und delegated-lacnic-key waren verfügbar. Der Pfad zur aktuellen Datei und der Pfad zur Signatur tragen unterschiedliche Namen.

Ein sorgfältiger Verbraucher kann den Umweg programmieren: latest laden, aus dem Kopf 20260828 lesen, den datierten Namen bilden, beide Bytefolgen vergleichen und anschließend Signatur und Schlüssel abrufen. Das ist eine plausible lokale Methode. Sie ist aber keine von LACNIC signierte Aussage, dass der beobachtete Alias zu diesem Zeitpunkt genau auf jene Ausgabe zeigte.

Der Unterschied wird über die Zeit größer. Ein beweglicher Alias bewahrt weder den gestrigen Zustand noch die Identität einer später korrigierten Fassung. Jeder Verbraucher kann eigene Beobachtungsbelege speichern. Dann liegt die gemeinsame Versionsgeschichte jedoch in vielen privaten, möglicherweise unterschiedlichen Archiven.

Mathematisch gültig, protokollarisch nicht akzeptabel

Der veröffentlichte Hauptschlüssel hat den Fingerabdruck BED3BE6115A8AF036D271F9D3B8DD165F3FB5533 und die ID 3B8DD165F3FB5533. Er nutzt DSA mit einem 1.024-Bit-Hauptparameter, wurde am 12. Dezember 2002 angelegt und führt die User-ID Auto Zone Generator. In der geprüften Selbstzertifizierung ist kein Ablauf des Hauptschlüssels erklärt.

Die Signatur entstand am 29. August 2026 mit DSA und SHA-1. Ihre Issuer-ID passt zum Schlüssel, und die Mathematik stimmt.

RFC 9580 zieht trotzdem eine klare Grenze. OpenPGP-Implementierungen dürfen keine neuen SHA-1-Signaturen erzeugen und keine aktuellen Signaturen prüfen, die von SHA-1 abhängen. Ebenso dürfen sie nicht mit DSA-Schlüsseln signieren oder verifizieren. Eine 2026 erzeugte DSA/SHA-1-Signatur fällt unmittelbar darunter.

Die forensische Rekonstruktion beschreibt den vorhandenen Gegenstand. Sie ist keine Empfehlung, im Produktionsbetrieb eine Ausnahme zu schalten. Eine konforme Implementierung kann die Signatur ablehnen, ohne die richtige DSA-Gleichung zu bestreiten: Abgelehnt wird das Vertrauensverfahren.

NIST liefert einen zusätzlichen Übergangskontext. Bis Ende 2030 soll SHA-1 aus allen Anwendungen kryptografischen Schutzes verschwinden; Beteiligte sollen früher planen. Daraus muss man keine eigenständige NIST-Ungültigkeit für 2026 erfinden. Für diese OpenPGP-Signatur ist RFC 9580 die direktere Regel.

Ein Freigabebeleg als schmale Lösung

LACNIC braucht dafür keine neue zentrale Routinginstanz. Es reicht ein kleiner, mit modernem Schlüssel signierter SHA-256-Freigabebeleg pro Tagesausgabe.

Der Beleg verbindet seine eigene Schemaversion, RIR und Datensatz, Seriennummer und lokales Datum, datierten Dateinamen und latest-Alias, Bytelänge und SHA-256, erklärte und gezählte Zeilen je Typ, Stichtag und Zeitzone, Fingerabdruck, Algorithmus und Gültigkeit des Signaturschlüssels sowie Korrektur oder Ablösung.

Der neben latest liegende Beleg nennt die exakte datierte Ausgabe. Der datierte Beleg bleibt stabil. Wenn ein Generator wieder 49.894 erklärt und 48.214 Zeilen liefert, muss der Prozess sichtbar reagieren: Publikation stoppen, eine begründete Ausnahme kennzeichnen oder einen Korrekturbeleg mit Verweis auf den ersetzten Gegenstand veröffentlichen.

Altkompatibilität ist möglich. Bestehende Dateien und MD5-Namen bleiben; der moderne Beleg kommt hinzu. Ein Schlüsselwechsel erhält einen signierten Kontinuitätsnachweis. Spiegel können die kleinen Belege lange bewahren, auch wenn sie nicht jede große Tagesdatei archivieren.

Der Beleg verspricht bewusst nicht die Wahrheit jeder Ressourcenzeile. Er schließt nur Aussagen, für die LACNIC zuständig ist: diese Bytes, diese Namen, diese Zahlen, dieser Schlüssel, diese Korrektur. Wie Betreiber die Momentaufnahme verwenden, bleibt ihre Entscheidung. So wird die gemeinsame Schicht verlässlicher, ohne breiter zu werden.

Grenzen des Befunds

Es gibt keinen Nachweis eines Angriffs, Schlüsselverlusts, gefälschten Eintrags, Ressourcenverlusts, Routingfehlers, Ausfalls oder Schadens. Die öffentliche Evidenz erklärt nicht, weshalb die ASN-Summe um 1.680 höher liegt. Sie prüft weder den internen Generator noch private Freigaben und zeigt keinen konkreten Verbraucher, der aufgrund der Zahl scheiterte.

Belegt sind eine öffentliche, wiederholbare Strukturabweichung, ein Signaturloch am dauerhaften Alias und eine moderne Akzeptanzgrenze der datierten Signatur. Das rechtfertigt einen besseren Veröffentlichungsprozess, nicht die Erfindung eines Vorfalls.

Quellen