Zusammenfassung

  • Die PKCS#10-Signatur belegt den Besitz des Antragsschlüssels; BPKI authentifiziert den Vertreter und verbindet den Antrag mit AFRINICs Mitgliedsdatensatz.
  • Ein RPKI-Zertifikat wird nur ausgestellt, wenn die beantragten Ressourcen eine Teilmenge des verzeichneten Bestands sind; das öffentliche Zertifikat bestätigt jedoch keine Organisations- oder Personenidentität.
  • Eine gültige ROA autorisiert einen ASN für Präfixe, beweist aber weder eine aktuelle Ankündigung noch Erreichbarkeit, Pfadsicherheit oder Annahme durch ein Netz.
  • Ein Herkunftsbeleg könnte Versionen, Hashes, Entscheidungen und Zeiten festhalten, ohne Ausweisdokumente, private Kontakte oder Zugangsdaten offenzulegen.

Der undurchsichtige Name ist eine Funktionsgrenze

AFRINICs Certification Practice Statement erlaubt einen vom Aussteller erzeugten Subject-Namen, der für Menschen nicht aussagekräftig sein muss. Die Zertifikate dienen der Autorisierung zur Unterstützung der Routing-Sicherheit, nicht der Identifikation. Abgesehen von Registries bestätigen sie weder die Identität der Ressourcen haltenden Organisation noch die einer Person.

Die Seite Resource Certification beschreibt Ressourcenzertifikate ebenfalls nicht als Identitätszertifikate. Spezialisierte Anwendungen prüfen damit ein Nutzungsrecht an IP-Adressen oder AS-Nummern. Die Öffentlichkeit benötigt die Bindung von Schlüssel und Ressourcen, nicht die Identitätsunterlagen aus dem Mitgliedsprozess.

Sieben getrennte Aussagen hinter „gültig“

Erstens wird der PKCS#10-Antrag mit dem privaten Schlüssel signiert, der zum beantragten öffentlichen Schlüssel gehört. Das beweist Schlüsselbesitz, nicht Vertretungsmacht oder Ressourcen.

Zweitens darf nur eine Person mit AFRINIC-BPKI-Zertifikat einen RPKI-Antrag stellen. Drittens verbindet dieses BPKI-Zertifikat den Antrag mit der Mitgliedsdatenbank, in der AFRINIC Ressourcenzuteilungen führt.

Viertens wird der beantragte Satz mit dem verzeichneten Bestand verglichen. Nur eine Teilmenge wird zertifiziert. Fünftens verlangt RFC 6487 IP- oder AS-Ressourcenerweiterungen und einen Zertifizierungspfad, in dem die Ressourcen des Ausstellers die des Kindes umfassen.

Sechstens autorisiert eine ROA nach RFC 9582 einen ASN, Routen für Präfixe und gegebenenfalls bestimmte Maximallängen zu originieren. Siebtens leitet RFC 6811 den Ursprung aus einer empfangenen BGP-Route ab und vergleicht ihn mit validierten ROA-Daten.

Keine Stufe darf sich als die nächste ausgeben. Schlüsselbesitz benennt keinen Vertreter. BPKI vergrößert keinen Ressourcensatz. Das Zertifikat wählt keinen Ursprung. Die ROA sendet keine Route. Ein Valid-Ergebnis prüft nicht den ganzen AS_PATH und zwingt kein Netz zur Annahme.

BPKI ist die private Verbindung hinter dem öffentlichen Objekt

Ein fehlender Firmenname bedeutet weder, dass das Zertifikat eine juristische Person identifiziert, noch dass AFRINIC auf Kontrollen verzichtet. Das CPS ordnet Vertreteridentifikation und Antragsauthentisierung BPKI zu, den Ressourcenbestand dem Mitgliedsdatensatz und die Reichweite der Teilmengenprüfung. Das RPKI-Zertifikat veröffentlicht nur das für Vertrauende nötige Ergebnis.

RFC 6480 verfolgt denselben Entwurf: RPKI liefert Autorisierung statt Authentisierung; der Distinguished Name soll keine beschreibende Identität behaupten. Für den Aussteller kann er dennoch als Rückverweis auf interne Datensätze dienen.

Der Mitgliedsdatensatz ist ein operatives Register AFRINICs. Er trägt eine Ausstellungsentscheidung, wird dadurch aber weder Gerichtsurteil noch gesellschaftsrechtliche Vollmacht oder Eigentumstitel.

Eine ROA erlaubt; BGP beobachtet

RFC 9582 hält fest, dass die PKI zur ROA-Validierung Autorisierung, nicht Authentisierung oder Nichtabstreitbarkeit liefert. Eine gültige ROA erlaubt eine ASN-Präfix-Beziehung. Ob eine Ankündigung tatsächlich existiert, zeigt erst eine BGP-Beobachtung mit Quelle und Zeit.

Valid, Invalid und NotFound sind Vergleiche zwischen Route und VRPs und unterliegen lokaler Politik. Der AFRINIC TAL ist der Einstieg zur Vertrauenswurzel; reproduzierbar wird das Ergebnis erst mit Repository-, Manifest-, CRL-, ROA- und BGP-Zustand des Zeitpunkts.

Ein datensparsamer Autorisierungsbeleg

Der redaktionelle Vorschlag ist ein typisierter Beleg. Registry-seitig gehören hinein: Antragszeit, Schlüsselfingerabdruck, nicht geheime BPKI- oder Rollenreferenz, Authentisierungsergebnis, Version oder Hash des Mitgliedsdatensatzes, Ressourcen-Snapshot, Antrag, Teilmengenentscheidung, Seriennummer, SKI, Ressourcenerweiterungen und Gültigkeit.

Die Validierungsseite hält Veröffentlichungspunkt, Manifest, CRL, TAL und Zeit fest. Für die ROA kommen EE-Zertifikat, ASN, Präfixe, maxLength, Objekt-Hash und Ergebnis hinzu. Für den Ursprung: BGP-Quelle, Zeit, Beobachtungspunkt, Präfix, beobachteter ASN und Vergleich.

Das Mitglied kann den vollständigen Beleg behalten; öffentlich genügen Referenzen und Hashes. Prüfer brauchen keine Ausweisbilder, privaten Kontakte oder Geheimnisse. Korrekturen verweisen auf ersetzte Fassungen. Jeder Abschnitt nennt seine Grenze: kein Eigentumstitel, keine aktuelle Ankündigung, keine Pfadgarantie und keine weltweite Sicht.

Quellen