Zusammenfassung

  • AFRINICs aktuelle Resource-Certification-Seite verlinkt direkt auf ein 48-seitiges RPKI Certification Practice Statement, Version 3.0 vom Mai 2020.
  • Abschnitt V.8 behauptet, AFRINIC habe von IANA die alleinige Zuständigkeit für IP-Adressen und AS-Nummern in der „Asia-Pacific region“ erhalten. AFRINIC und IANA verorten das Register dagegen in Afrika und Teilen des Indischen Ozeans.
  • Das aktuelle CPS von APNIC enthält eine fast gleich aufgebaute Drei-Satz-Klausel und verbindet APNIC korrekt mit Asien-Pazifik. Aus der Ähnlichkeit folgen weder Kopierrichtung noch Urheberschaft.
  • Der Befund betrifft ein öffentliches Kontrolldokument. Er belegt keinen falschen Ressourcen­nachweis, kein Zertifikat, keine ROA, keinen Trust Anchor, keinen Validatorzustand und keinen Routingausfall.

Ein alter Dateistand am aktuellen Einstiegspunkt

Das Alter eines PDF entscheidet nicht darüber, ob es noch gilt. Entscheidend ist, wohin die Institution heute verweist. AFRINICs Seite zur Resource Certification führt unter den Richtliniendokumenten einen Link Certificate Practice Statement (CPS). Er zeigt ohne Archiv- oder Ablösungshinweis auf CPS.

Die für diese Recherche abgerufene Datei hat 48 Seiten und 195.830 Byte. Ihr SHA-256 lautet 2770e175edbd611c798d0036229a05f3e830843dc4ee202e35e5e944db91d5f0. Auf dem Deckblatt stehen AFRINIC Certification Practice Statement for the Resource PKI, Version 3.0 und Mai 2020. Die gedruckte Versionsgeschichte nennt Version 1.0 vom Januar 2011 und Version 2.0 vom März 2015.

Der Widerspruch steht auf Seite 36 in Abschnitt V.8, CA or RA termination. Dort heißt es, IANA habe AFRINIC die alleinige Befugnis erteilt, die Zuweisung von IP-Adressraum und AS-Nummern in der „the Asia-Pacific region“ zu verwalten. Der nächste Satz führt AFRINICs RPKI für die eigene Region auf diese Befugnis zurück. Abschließend erklärt der Absatz, es gebe keine Bestimmungen zur Beendigung und Übertragung der CA-Funktion auf eine andere Stelle.

Die Seite wurde zusätzlich zur Textextraktion als Bild gerendert und visuell geprüft. Die Regionsbezeichnung ist weder ein OCR-Fehler noch ein Suchindex-Schnipsel oder ein Spaltenbruch. Sie steht im normalen Satzbild desselben Absatzes wie der Name AFRINIC.

Der Ort erhöht die Bedeutung. In V.8 geht es nicht um eine beiläufige Anschrift, sondern um die institutionelle Grundlage der CA und um die öffentlich erklärte Behandlung ihres Endes. Die Region bildet eine Prämisse der Autoritätsaussage.

Die richtige Zuordnung steht bei AFRINIC selbst

Für die Feststellung ist keine Ableitung aus IP-Zuteilungen nötig. AFRINICs Über-uns-Seite bezeichnet die Organisation als Regional Internet Registry für Afrika und den Indischen Ozean. Die Service-Region-Seite gliedert den Bereich in Nord-, West-, Zentral-, Ost- und Südafrika sowie den Indischen Ozean.

IANA veröffentlicht dieselbe Aufteilung. In der Übersicht zu den fünf RIRs steht AFRINIC für Afrika und Teile des Indischen Ozeans, APNIC für Asien/Pazifik. Der AFRINIC-Anerkennungsbericht von 2005 dokumentiert die afrikanische und insulare Region sowie den Übergang zum fünften RIR.

Es stehen also nicht zwei vertretbare Grenzziehungen gegeneinander. Gesichert ist eine schmalere Aussage: Das von AFRINIC aktuell verlinkte CPS verbindet in V.8 den Institutionsnamen mit der Region eines anderen Registers.

Auch HTTP-Daten tragen keine weitergehende Schlussfolgerung. Beim Abruf meldete die HTML-Seite ein Last-Modified vom 20. August 2026, das PDF eines vom 28. Mai 2020. Diese Header belegen die von den Servern gemeldeten Dateizustände. Sie belegen nicht, dass im August ein Mensch jeden Link und jeden Absatz geprüft hat. Ein allgemeiner Site-Build oder eine Migration kann den HTML-Zeitstempel ändern, ohne das CPS neu freizugeben.

APNIC liefert den Textspiegel, nicht den Stammbaum

Der engste Vergleich findet sich im aktuellen CPS von APNIC. Abschnitt 5.8 folgt nahezu derselben dreiteiligen Abfolge: IANA-Befugnis über Adress- und AS-Nummernressourcen, Aufbau des RPKI für die Region und fehlende Regelung zur Übertragung der CA-Funktion.

Im APNIC-Dokument passen Name und Gebiet zusammen. APNIC wird mit Asien-Pazifik verbunden. Reihenfolge, Funktion und große Teile der Formulierungen ähneln der AFRINIC-Passage.

Ein übernommener Text oder eine gemeinsame Vorlage ist damit eine vernünftige Arbeitshypothese. Ein Nachweis ist es nicht. Die eingefrorenen Quellen enthalten weder Änderungsverfolgung noch Autorenkommentare oder Freigabeprotokolle. Sie zeigen nicht, welches Dokument zuerst vorlag, in welche Richtung Text floss oder wer eine Ersetzung übersah.

Der Vergleich bleibt nützlich. Leser können die korrekten Paare aus offiziellen Quellen prüfen: APNIC und Asien-Pazifik; AFRINIC und Afrika/Indischer Ozean. Außerdem warnt die Parallele vor einem pauschalen Suchen-und-Ersetzen. Die geographische Korrektur ist eine Entscheidung. Der Status des benachbarten Satzes zur CA-Übertragung ist eine zweite.

Ein CPS-Satz erzeugt keinen RPKI-Validierungszustand

RPKI-Dokumente stehen nahe an betrieblicher Vertrauensinfrastruktur, sind aber nicht mit ihren Objekten identisch. RFC 6484 beschreibt das Verhältnis zwischen der RPKI Certificate Policy und dem Certification Practice Statement jeder CA. Das CPS ist die öffentliche Darstellung, wie die Stelle die Policy nach eigener Aussage umsetzt. Es ist relevante Governance- und Praxis­evidenz. Es ist kein Ressourcenzertifikat, keine ROA, kein Manifest, keine CRL, keine TAL und kein Validatorergebnis.

Im Quellenbestand findet sich kein AFRINIC-Zertifikat mit einer Regionskennzeichnung Asien-Pazifik. Nichts zeigt, dass wegen V.8 eine Adresse oder ASN dorthin vergeben wurde oder APNIC Zuständigkeit verlor. Es gibt keinen Hinweis auf einen Trust-Anchor-Schlüsselwechsel, ein defektes Repository-Objekt oder veränderte validierte Payloads.

Ebenso fehlt eine Messung, die den Absatz mit einer Route im Zustand Invalid, NotFound oder nicht erreichbar verbindet. Kein Announcement ist nachweislich deswegen abgelehnt worden. Die Quellen zeigen weder Schlüssel- oder Kontokompromittierung noch einen Ausfall.

Auch der letzte Satz muss genau gelesen werden. Das öffentliche CPS sagt, es gebe keine Bestimmungen für Beendigung und Übergang der CA-Funktion auf eine andere Stelle. Daraus folgt nicht, AFRINIC habe keinen internen Business-Continuity-Plan, keine Disaster-Recovery-Verfahren oder keine rechtliche Notfallbefugnis. Diese Behauptungen bräuchten andere Dokumente.

Die Begrenzung macht den Fehler nicht harmlos. Gerade das CPS soll Abonnenten und Relying Parties erklären, wie die CA arbeitet. Bei einer falschen Verbindung von Institution, Autorität und Region ist von außen nicht erkennbar, ob nur ein Wort geerbt wurde oder ein ganzer Absatz ohne wirksame Versionskontrolle blieb. Angemessen ist eine belegte Korrektur, weder ein erfundener Routingvorfall noch Gleichgültigkeit.

Der neue Satz braucht einen alten Hash

AFRINIC könnte Asia-Pacific durch Africa and the Indian Ocean ersetzen und die Datei am selben URL überschreiben. Die sichtbare Unstimmigkeit wäre fort. Unbeantwortet bliebe, welche Version geändert wurde, wer sie freigab, wann die Änderung wirksam wurde, welche Bytes vorher galten und ob der übrige Absatz mitgeprüft wurde.

Ein öffentlicher Korrekturbeleg kann diese Fragen ohne Offenlegung sensibler Betriebsdetails beantworten. Er sollte die stabile Dokumentkennung, die neue Versionsnummer und Klausel V.8 nennen, alten und neuen Text gegenüberstellen und die SHA-256-Werte beider PDF-Dateien aufzeichnen. Jede Änderung sollte als redaktionelle Korrektur, Klarstellung oder Praxisänderung klassifiziert werden.

Nötig sind außerdem die freigebende Rolle und ihre Rechts- oder Organisationsgrundlage sowie getrennte Zeitpunkte für Genehmigung, Veröffentlichung und Wirksamkeit. Für den Satz zur CA-Übertragung muss der Beleg ausdrücklich beibehalten, geändert, ersetzt oder anderweitig geregelt ausweisen.

Version 3.0 sollte unter einem unveränderlichen historischen URL erhalten bleiben. Der stabile aktuelle URL muss exakt die angekündigten neuen Bytes liefern. Ein öffentlicher Hinweis oder Changelog sollte beide Fassungen verbinden. Danach kann ein unabhängiger Readback HTTP-Status, Redirects, ETag, Größe, SHA-256, Deckblatt und V.8 gegentesten.

Falls kein Zertifikat, Schlüssel, Repository-Objekt und kein Dienstzustand geändert wurde, sollte der Beleg document correction only sagen. Diese begrenzte Negativaussage ist informativer als die pauschale Versicherung, RPKI sei „nicht betroffen“, weil sie die tatsächlich geprüften Oberflächen benennt.

Alter und Ähnlichkeit reichen nicht zur Zuschreibung

Das Jahr 2020 sagt nicht, wann die falsche Region erstmals erschien. Dafür müssten die Versionen 1.0 und 2.0 beschafft und anhand ihrer Bytes authentifiziert werden. Ebenso könnte eine interne Prüfung den Fehler erkannt haben oder ein neueres Instrument existieren, ohne dass der öffentliche Link aktualisiert wurde. Fest steht der heutige Pfad zur Version 3.0.

Die Quellen benennen auch keinen individuellen Verfasser. CPS-Redaktion, rechtliche Freigabe, CA-Betrieb und Webpublikation können an verschiedenen Stellen liegen. Eine Zuständigkeit im Organigramm beweist keine Satzautorschaft. Die Korrektur sollte die aktuell verantwortliche Rolle nennen, nicht rückwirkend Schuld vermuten.

Schließlich macht die korrekte APNIC-Zuordnung deren Übergangssatz nicht zum empfohlenen Modell für AFRINIC. Die Parallele ist ein Text- und Institutionenvergleich. Eine materielle Änderung der Kontinuitätsregel wäre ein eigener Governance-Akt mit eigener Autorität und Wirksamkeit.

Eine Korrektur, die sich wiederholen lässt

Der Abschlusstest ist einfach: Ein Leser muss den aktuellen URL öffnen, die Version identifizieren, den Hash bestätigen, die korrigierte Region lesen, die Behandlung des Übergangssatzes erkennen und die abgelöste Datei wiederfinden können.

So kann AFRINIC einen Dokumentfehler anerkennen, ohne einen unbelegten Betriebsausfall zu behaupten. Relying Parties erhalten überprüfbare öffentliche Evidenz, ohne private Schlüssel- oder Anlagendaten zu verlangen. Der Erhalt der alten Fassung zeigt, was vor und nach der autorisierten Änderung öffentlich war.

Ein langlebiger URL kann Aktualität vortäuschen, während seine Bytes altern. Die dauerhafte Entscheidung ist deshalb eng: Region korrigieren, den Rest von V.8 bewusst entscheiden, Version 3.0 bewahren und Autorität, Zeitpunkt und Wirkung der Ablösung veröffentlichen.

Quellen