GOpenCNR-RPKI-Zertifizierungspraxis

1. Einleitung

Überblick

GOpenCNR ist ein von einer Registry betriebenes privates Overlay-Netz. Die Registry teilt Mitgliedern private IPv6- und IPv4-Adressen und ASNs zu, und die Hubs routen zwischen ihnen. Diese Erklärung beschreibt die Ressourcen-Public-Key-Infrastruktur (RPKI), die diese Ressourcen zertifiziert, damit ein Router prüfen kann, ob eine Route in GOpenCNR-Adressraum von dem Ursprung kommt, den die Registry nennt, und ob ihr Pfad zu den Provider-Beziehungen passt, die die Registry kennt. Sie folgt dem Aufbau von RFC 7382 und legt dar, wie Gelhaus Solutions als Tier 0 die Zertifizierungsstelle betreibt.

Dies ist eine private RPKI und nicht Teil der RPKI der Regionalen Internet-Registries. Ihr Vertrauensanker ist der eigene von GOpenCNR, und sie zertifiziert nichts als den eigenen privaten Adressraum von GOpenCNR:

• die IPv6-Wurzel fdc0:0900::/24 im Bereich der Unique Local Addresses fc00::/7 (RFC 4193);
• die IPv4-Pools, die die Registry hält: 10.113.0.0/16 im privaten Bereich nach RFC 1918, die Ausweich-Pools (ein zweites reserviertes 10.x /16, danach 198.18.0.0/15) und den experimentellen Pool in 240.0.0.0/4, der nur auf ausdrücklichen Wunsch genutzt wird, jeweils ab dem Zeitpunkt, zu dem der GOpenCNR-Community-Rat ihn geschaffen hat;
• den ASN-Block 4223000000 bis 4223009999 innerhalb des Bereichs, den RFC 6996 für die private Nutzung reserviert.

Ein Validator nutzt den Trust Anchor Locator (TAL) von GOpenCNR neben den TALs der Regionalen Internet-Registries, nie an ihrer Stelle. Nichts in dieser RPKI sagt etwas über öffentlichen Adressraum oder öffentliche ASNs aus.

Die Registry ist maßgeblich. Jedes ROA und jedes ASPA-Objekt erzeugt die Online-CA von GOpenCNR aus dem Stand der Registry, bei jeder angenommenen Änderung, und nichts wird von Hand eingerichtet. Der Schlüssel des Vertrauensankers signiert nur in Zeremonien nach Skript, ein getrennter Schlüssel der Online-CA signiert alles andere, und jedes signierte Objekt trägt einen Einmalschlüssel, der nach seiner einen Signatur vernichtet wird.

Name und Kennung des Dokuments

Dies ist die Erklärung zur Zertifizierungspraxis (Certification Practice Statement) der RPKI von GOpenCNR. Die Zertifikate, für die sie gilt, tragen die Richtlinienkennung, die RFC 6487 für jedes RPKI-Zertifikat verlangt, id-cp-ipAddr-asNumber (1.3.6.1.5.5.7.14.2), aus der RPKI-Zertifizierungsrichtlinie von RFC 6484. Wo diese Richtlinie die Hierarchie der Regionalen Internet-Registries voraussetzt, sagt diese Erklärung, was GOpenCNR stattdessen tut.

Beteiligte

• Vertrauensanker. Gelhaus Solutions hält als Tier 0 von GOpenCNR den Vertrauensanker. Sein Schlüssel signiert nur in Zeremonien (Abschnitt 5).
• Online-CA. Eine Zertifizierungsstelle unterhalb des Vertrauensankers, von Tier 0 betrieben, hält jede zertifizierte Ressource und stellt alles Übrige aus: die End-Entity-Zertifikate (EE-Zertifikate) von ROAs, ASPA-Objekten und Manifesten, ihre Sperrlisten und die Zertifikate delegierter CAs.
• Delegierte CAs. Ein Inhaber kann verlangen, eine eigene CA unterhalb der Online-CA zu betreiben. Er hält dann deren Schlüssel und signiert seine eigenen Objekte für die Ressourcen in ihrem Zertifikat.
• Registrierung. Eine gesonderte Registrierungsstelle gibt es nicht. Die GOpenCNR-Registry hält fest, wer was innehat, und die CA zertifiziert, was die Registry sagt. Änderungen erreichen die Registry vom Inhaber signiert, und über solche, die eine menschliche Beurteilung brauchen, entscheidet Tier 0 im Vier-Augen-Prinzip (Abschnitt 3).
• Zertifikatsnehmer. Die Inhaber, also Menschen und verifizierte Organisationen, deren Zuteilungen, ASNs und Routenobjekte zertifiziert werden, sowie die Inhaber, die eine delegierte CA betreiben.
• Vertrauende Parteien. Die Hubs von GOpenCNR, die jede Route, die sie annehmen, auf RPKI- und ASPA-Gültigkeit prüfen; die Router der Mitglieder, die über die RTR-Caches von Tier 0 im Netz oder über einen eigenen Validator validieren; und jede Person, die den TAL nach den Nutzungsbedingungen für TAL und Repository lädt.
• GOpenCSR. Die Konten, der Signierschritt, die Freigaben im Vier-Augen-Prinzip und das eine Transparenzlog unter csr.gplatform.org/tlog gehören zu GOpenCSR, und diese RPKI stützt sich auf sie.

Verwendung der Zertifikate

Zertifikate und signierte Objekte dienen zwei Zwecken:

• Prüfung des Routenursprungs (Route Origin Validation): ob eine Route in GOpenCNR-Adressraum von der ASN angekündigt wird, die ihr Routenobjekt nennt;
• Pfadprüfung mit ASPA: ob der AS-Pfad einer Route zu den Provider-Beziehungen passt, die für die ASNs darin registriert sind.

Zu nichts anderem. Sie identifizieren niemanden, sie sagen nichts über Adressraum außerhalb von GOpenCNR, und keines von ihnen ist ein BGPsec-Router-Zertifikat: BGPsec wird in GOpenCNR nicht verwendet.

Verwaltung dieser Erklärung

Gelhaus Solutions, Eichenwald 3, 49624 Löningen, verwaltet diese Erklärung. Fragen richten Sie an contact@gplatform.org. Den Verdacht, dass ein Schlüssel kompromittiert oder ein Objekt fehlerhaft ausgestellt ist, melden Sie, wie es die GOpenCNR-Sicherheits- und Offenlegungsrichtlinie beschreibt, an dieselbe Adresse oder über GAdvisory.

Diese Erklärung ist eine der Gründungsrichtlinien des Netzes von GOpenCNR. Sie ändert sich, wie sich Netzrichtlinien nach dem GOpenCNR-Zusatz zur Governance-Charta ändern: durch Antrag des GOpenCNR-Registry-Rats, nach öffentlicher Kommentierung, vorbehaltlich des Vetos von Tier 0 aus Gründen der Sicherheit oder des Rechts. Jede Fassung wird im Dokumentenarchiv aufbewahrt, und in Kraft ist die Fassung dort mit dem jüngsten Datum. Die betrieblichen Werte, die diese Erklärung den veröffentlichten Objekten überlässt (Abschnitt 4), ändern sich ohne neue Fassung, und jede solche Änderung wird im Transparenzlog angekündigt.

Begriffe

• ASPA (Autonomous System Provider Authorisation): ein signiertes Objekt, das die Provider-ASNs einer Kunden-ASN aufführt.
• CA: eine Zertifizierungsstelle. Vertrauensanker: die oberste CA, deren Schlüssel eine vertrauende Partei unmittelbar vertraut. TAL: der Trust Anchor Locator, eine kleine Datei, die einem Validator sagt, wo das Zertifikat des Vertrauensankers liegt und welchen Schlüssel es tragen muss.
• Sperrliste (CRL): eine Liste gesperrter Zertifikate, signiert von der CA, die sie ausgestellt hat.
• EE-Zertifikat: das End-Entity-Zertifikat in einem signierten Objekt, für einen Schlüssel, der genau dieses eine Objekt signiert.
• Manifest: eine signierte Liste aller Objekte, die eine CA aktuell veröffentlicht, jedes mit seinem Hash.
• ROA (Route Origin Authorisation): ein signiertes Objekt, das festhält, dass eine ASN die Präfixe darin ankündigen darf.
• Routenobjekt: der Eintrag der Registry, dass ein Präfix von einer Ursprungs-ASN angekündigt werden darf.
• RRDP: das RPKI Repository Delta Protocol (RFC 8182) über HTTPS. rsync: der ältere Weg, ein Repository abzurufen. RTR: das RPKI-to-Router-Protokoll, über das ein Cache validierte Daten an Router weitergibt.
• Zeremonie-Identität: die eine Identität im Schlüsselspeicher, die den Schlüssel des Vertrauensankers verwenden darf.
• Tier 0: die Rolle des Root-Betreibers von GOpenCNR, die Gelhaus Solutions innehat.

2. Veröffentlichung und Verantwortung für das Repository

• Das Repository wird von cnr.gplatform.org ausgeliefert, über RRDP und über rsync. RRDP ist der Weg, es abzurufen. rsync gibt es, weil das Zertifikatsprofil in jedem Zertifikat weiterhin rsync-Adressen verlangt und manche Validatoren sie noch nutzen. Das Repository enthält jedes Zertifikat, jedes ROA, jedes ASPA-Objekt, jedes Manifest und jede Sperrliste, die der Vertrauensanker und die Online-CA veröffentlichen.
• Wann es sich ändert. ROAs und ASPA-Objekte werden bei jeder angenommenen Änderung der Registry neu erzeugt; das Repository ändert sich also, wenn sich die Registry ändert. Manifeste und Sperrlisten werden neu ausgestellt, wenn sich die Objekte ändern, und vor ihrem nächsten Aktualisierungszeitpunkt auch dann, wenn sich nichts geändert hat.
• Der TAL folgt RFC 8630. Er wird unter cnr.gplatform.org veröffentlicht, ist signiert und liegt jeder Fassung des GOpenCNR-Agenten bei, damit der Router eines Mitglieds den Anker hat, bevor irgendetwas validiert wird. Er ändert sich nur in einer Zeremonie, und jede Änderung wird im Transparenzlog angekündigt und mit einer Fassung des Agenten ausgeliefert.
• Dieselben Daten in anderer Form. Für Router ohne eigenen Validator betreibt Tier 0 RTR-Caches innerhalb von GOpenCNR. Dieselben Daten werden außerdem als JSON im Format von dn42 exportiert, als SLURM-Datei nach RFC 8416, damit ein Mitglied, das die öffentliche RPKI validiert, die Daten von GOpenCNR darüberlegen kann, und als ROA-Tabellen für BIRD. Diese Exporte tragen keine eigenen Signaturen: Wer einen Nachweis braucht, validiert das Repository.
• Wer schreibt. In das Repository gelangt nur, was die Online-CA oder eine Zeremonie signiert hat. Von Hand wird nichts veröffentlicht.
• Wer liest. Jede Person, kostenlos, nach den Nutzungsbedingungen für TAL und Repository, die auch sagen, wie Sie abrufen, ohne andere zu belasten.
• Diese Erklärung wird unter dieser Adresse veröffentlicht und mit allen früheren Fassungen im Dokumentenarchiv aufbewahrt.

3. Identifizierung und Authentifizierung

• Ein Zertifikat nennt niemanden. Es bindet Ressourcen an einen Schlüssel. Es sagt nicht, wer den Schlüssel hält, und wer sich für Aussagen über eine Person oder eine Organisation darauf stützt, verwendet es falsch.
• Inhaber. Ressourcen halten GOpenCSR-Konten mit bestätigter E-Mail-Adresse und Organisationen, die nach den Bedingungen für die Verifizierung von Organisationen verifiziert sind. Jeder Inhaber wird, sobald er erstmals Inhaber wird, und danach täglich mit der konsolidierten Finanzsanktionsliste der EU abgeglichen: eine Person mit dem amtlichen Namen und dem Land, die sie dabei angibt, eine Organisation mit ihrem verifizierten Namen und Land. Vor dem ersten Tunnel eines Inhabers verlangt GOpenCNR außerdem eine Fürsprache, die keine Bürgschaft ist, wie es die GOpenCNR-Nutzungsbedingungen regeln.
• Jede Änderung signiert der Inhaber. Eine Änderung an einer Zuteilung, einer ASN oder einem Routenobjekt erreicht die Registry nur mit der Signatur des Inhabers: einer Passkey-Bestätigung über den Hash der Änderung, abgegeben im Signierschritt von GOpenCSR unter csr.gplatform.org, der zeigt, was signiert wird, oder einer Signatur mit einem Ed25519-Automatisierungsschlüssel, der unter einem Passkey registriert ist. Die Änderung und ihre Signatur werden in das Transparenzlog eingetragen, sodass jede Person ein ROA mit der signierten Änderung abgleichen kann, die es ausgelöst hat.
• Was automatisch geschieht und was ein Mensch entscheidet. Zuteilungen in Standardgröße, ASNs und Routenobjekte im eigenen Adressraum des Inhabers werden im Rahmen der Richtlinien automatisch angenommen. Über größere Zuteilungen, die schriftlich zu begründen sind, über geschlossene Präfixe, Übertragungen und Rücknahmen entscheidet Tier 0 im Vier-Augen-Prinzip. Pools entstehen nur durch Antrag des GOpenCNR-Community-Rats. Eine Änderung wird nur angenommen, wenn jedes daraus abgeleitete Artefakt, ROAs und ASPA-Objekte eingeschlossen, sich fehlerfrei neu erzeugen lässt.
• Ressourcen von außen werden nie zertifiziert. Eine ASN aus dn42 oder aus dem öffentlichen Internet, die ein Inhaber mitbringt, wird nach dem Nachweis der Inhaberschaft in der Registry erfasst. Sie wird nie zugeteilt und hier nie zertifiziert.
• Delegierte CAs. Ein Inhaber verlangt eine, und die Online-CA zertifiziert ihr die Ressourcen, die die Registry für diesen Inhaber hält, und nichts darüber hinaus.
• Tier 0. Jede Änderung durch Tier 0 wird mit einem Passkey bestätigt.
• Rückzug. Ein Inhaber zieht ein ROA zurück, indem er das Routenobjekt dahinter ändert oder entfernt, signiert wie jede andere Änderung.

4. Betriebliche Anforderungen an den Lebenszyklus der Zertifikate

• Kein Antrag. Inhaber beantragen keine ROAs. Die Online-CA stellt ein ROA aus, weil die Registry ein Routenobjekt hält, und zieht es zurück, weil sie es nicht mehr hält. Eine delegierte CA ist das einzige Zertifikat, das ein Inhaber verlangt.
• ROAs. Ein ROA je Ursprungs-ASN, das jedes Präfix umfasst, das die Routenobjekte der Registry dieser ASN anzukündigen erlauben, jedes genau wie registriert und ohne maxLength (RFC 9319). Ein spezifischeres Präfix ist nur mit einem eigenen Routenobjekt gültig. Für ein Mitglied ohne BGP nennt das Routenobjekt die ASN des Hubs als Ursprung, und das ROA folgt ihm.
• Geschlossene Präfixe. Das ROA eines geschlossenen Präfixes wird wie jedes andere veröffentlicht: Präfix, Handle des Inhabers und Ursprungs-ASN sind öffentlich wie bei jedem Präfix. Geschlossen ist nur seine Erreichbarkeit. Wer zu seiner Zielgruppe (Audience) gehört und die Routen dorthin bleiben privat und stehen nie im Repository.
• ASPA-Objekte. Eines für jede ASN aus dem Block von GOpenCNR, für die in der Registry Provider-Beziehungen bestehen: die Hubs, die ihr Mitglied nutzt, und die Transit-Mitglieder, die es nennt. Der Agent des Mitglieds hält diese Beziehungen mit den Hubs in Einklang, die es tatsächlich nutzt.
• Ausstellung. Bei jeder angenommenen Änderung erzeugt die Online-CA die betroffenen Objekte neu, signiert jedes mit einem neuen EE-Schlüssel und veröffentlicht sie mit einem neuen Manifest und, wo etwas gesperrt wurde, einer neuen Sperrliste. Die CA liest die Registry über versionierte, nur lesbare Sichten und kann sie nicht verändern.
• Delegierte CAs. Das Zertifikat der untergeordneten CA trägt nur die Ressourcen, die die Registry für den Inhaber hält, und wird neu ausgestellt, wenn sie sich ändern. Der Inhaber betreibt den Schlüssel der delegierten CA und deren signierte Objekte und steht für sie ein.
• Erneuerung und neue Schlüssel. Objekte werden vor ihrem Ablauf neu signiert, jedes Mal mit einem neuen EE-Schlüssel. Ein EE-Schlüssel wird nie wiederverwendet und nie erneuert. Die Schlüssel des Vertrauensankers und der Online-CA wechseln nur in einer Zeremonie (Abschnitt 5).
• Gültigkeitsdauern und Intervalle. Diese Erklärung legt weder eine Gültigkeitsdauer für Zertifikate noch ein Intervall für Sperrlisten und Manifeste fest. Es gelten die Werte, die in den veröffentlichten Zertifikaten, Sperrlisten und Manifesten selbst stehen, die jeder Validator liest, und jede Änderung daran wird im Transparenzlog angekündigt.
• Sperrung. Ein Zertifikat wird gesperrt und bis zu seinem Ablauf auf der Sperrliste seines Ausstellers geführt, wenn
• das Routenobjekt, die Provider-Beziehung oder die Delegierung dahinter endet oder sich ändert, auch wenn Adressraum übertragen, zurückgegeben oder zurückgenommen wird;
• sein Schlüssel kompromittiert ist oder sein könnte;
• es fehlerhaft ausgestellt wurde;
• ein Gericht oder eine zuständige Behörde es anordnet.

Ein zurückgezogenes Objekt verlässt das Repository und das Manifest mit der Veröffentlichung, die es zurückzieht.

• Keine Aussetzung. Ein RPKI-Objekt ist veröffentlicht und gültig oder zurückgezogen und gesperrt; einen Zustand dazwischen gibt es nicht. Sanktionen gegen einen Inhaber wirken an den Hubs, die unmittelbar aus der Registry filtern. Wo eine Sanktion die Routenobjekte eines Inhabers beendet oder seinen Adressraum zurücknimmt, folgen die ROAs.
• Der Status wird nur über Sperrlisten und Manifeste veröffentlicht. OCSP gibt es nicht.
• Veraltete Daten. Ein Hub, dessen RPKI-Daten sich nicht auffrischen lassen, behält seinen letzten gültigen Stand, löst einen Alarm aus und nimmt nie Ursprünge an, die er nicht validieren kann.
• Keine Schlüsselhinterlegung. Kein Schlüssel dieser RPKI wird bei irgendjemandem hinterlegt. Die Schlüssel des Vertrauensankers und der Online-CA existieren nur im Schlüsselspeicher, ein EE-Schlüssel nur für seine eine Signatur.

5. Einrichtungs-, Verwaltungs- und Betriebskontrollen

• Wo was läuft. Die Online-CA läuft in der Steuerungsebene von GOpenCNR auf einem bei der IONOS SE in Deutschland gemieteten Server, der auch das Repository ausliefert. Die Schlüssel liegen nicht dort: Die Schlüssel des Vertrauensankers und der Online-CA liegen in HashiCorp Vault auf eigener Hardware in Deutschland, erreichbar über WireGuard.
• Der Schlüsselspeicher ist derselbe, der die DNSSEC-Schlüssel von GOpenCDR hält, unter denselben Kontrollen: Schlüssel sind nicht exportierbar, eine Klartextsicherung ist abgeschaltet, und jede Signatur entsteht im Schlüsselspeicher; er führt zwei Audit-Geräte; Zugangsdaten sind an Netzadressen gebunden; und ein dauerhaftes Root-Token existiert nicht. Die Schlüssel von GOpenCNR sind seine eigenen und werden unter einer Richtlinie und einer Identität je Dienst verwendet.
• Der Schlüssel des Vertrauensankers ist abgeschirmt. Eine Zugriffsregel im Schlüsselspeicher lässt nur die Zeremonie-Identität mit ihm signieren. Kein laufender Dienst kann ihn verwenden, auch nicht die Online-CA.
• Zeremonien. Der Schlüssel des Vertrauensankers wird nur in Zeremonien nach Skript verwendet: um das Zertifikat der Online-CA auszustellen oder neu auszustellen, etwa wenn sich die Menge der zertifizierten Pools ändert; um die eigene Sperrliste und das eigene Manifest des Vertrauensankers neu auszustellen; und um einen Schlüssel zu ersetzen. Eine Zeremonie läuft erst, wenn eine zweite berechtigte Person von Tier 0, ihr Zeuge, sie im Vier-Augen-Prinzip in der Datenbank mit einem Passkey freigegeben hat. Solange Tier 0 aus einer Person besteht, läuft das Vier-Augen-Prinzip im Einzelmodus, und eine allein erteilte Freigabe wird als „allein entschieden“ gekennzeichnet. Das Protokoll jeder Zeremonie wird im Transparenzlog eingetragen, das Menschen nur mit ihrer Kontokennung nennt.
• Den Schlüssel der Online-CA verwendet nur der RPKI-Dienst von GOpenCNR, über seine eigene Identität im Schlüsselspeicher.
• Einmalige EE-Schlüssel sind die schriftlich festgehaltene Ausnahme von der Regel, dass Schlüssel den Schlüsselspeicher nie verlassen. Jeder wird vom RPKI-Dienst im Arbeitsspeicher erzeugt, für genau eine Signatur verwendet und vernichtet. Sein Vertrauen beruht auf dem EE-Zertifikat, das die Online-CA im Schlüsselspeicher signiert, nicht darauf, wo der Schlüssel entstanden ist.
• Menschen. Die Root-Rollen von Tier 0 haben Menschen von Gelhaus Solutions inne, und jede Änderung durch Tier 0 wird mit einem Passkey bestätigt.
• Aufzeichnungen. Jede Änderung schreibt einen Audit-Eintrag, der nie verändert oder gelöscht wird, und jede Änderung der Registry steht mit der Signatur ihres Inhabers im Transparenzlog. Registrierungen und Sperrungen von Schlüsseln, Zeremonien, Maßnahmen an Pools und Sanktionen sind ebenfalls Einträge im Log.
• Sicherungen. Die Datenbank der Registry und das Repository werden jede Nacht auf einen Proxmox Backup Server auf eigener Hardware in Deutschland gesichert und 90 Tage aufbewahrt, und ihre Wiederherstellung wird in einer Übung erprobt.
• Überwachung. Zwei unabhängige Validatoren, rpki-client und Routinator, rufen das Repository fortlaufend ab. Tier 0 wird alarmiert, wenn sie voneinander abweichen, wenn das Repository veraltet und wenn eine Veröffentlichung fehlschlägt.
• Kompromittierung. Könnte ein Schlüssel dieser RPKI kompromittiert sein, handelt Tier 0 sofort nach seinem Notfallverfahren, das nur aussetzen oder verschärfen darf. Das Zertifikat für den kompromittierten Schlüssel wird gesperrt und in einer Zeremonie ein neuer Schlüssel erzeugt. Ein neuer Schlüssel des Vertrauensankers bedeutet einen neuen TAL, der im Transparenzlog angekündigt und mit einer Fassung des Agenten ausgeliefert wird. Das Ereignis und was dagegen getan wurde, wird im Transparenzlog veröffentlicht. Schriftliche Ablaufpläne gibt es für die Zeremonie des Vertrauensankers, für eine Kompromittierung von Schlüsseln und für einen Ausfall des Schlüsselspeichers.
• Ist der Schlüsselspeicher nicht erreichbar, wird nichts Neues signiert. Was veröffentlicht ist, bleibt bis zu seinem Ablauf veröffentlicht, und die Hubs behalten ihren letzten gültigen Stand.

6. Technische Sicherheitskontrollen

• Algorithmus. RSA-Schlüssel mit 2048 Bit und dem öffentlichen Exponenten 65537, Signaturen mit SHA-256, wie es RFC 7935 für jedes Zertifikat, jede Sperrliste und jedes signierte Objekt der RPKI verlangt. SHA-1 kommt nur in Schlüsselkennungen vor, wie es das Profil vorschreibt, und nie in einer Signatur.
• Erzeugung der Schlüssel. Die Schlüssel des Vertrauensankers und der Online-CA werden in Vault Transit als nicht exportierbare Schlüssel erzeugt und verwahrt. EE-Schlüssel werden für ihre eine Signatur im Arbeitsspeicher erzeugt.
• Eine Rolle, ein Schlüssel. Der Schlüssel des Vertrauensankers, der Schlüssel der Online-CA und ein neuer Schlüssel für jedes signierte Objekt. Die Pakete, die Agenten und Hubs konfigurieren, werden mit wieder einem anderen Schlüssel signiert, der mit der RPKI nichts zu tun hat.
• Kein privater Schlüssel des Vertrauensankers oder der Online-CA existiert außerhalb des Schlüsselspeichers.
• Hosts. Die Steuerungsebene läuft unter systemd mit einer nftables-Grundkonfiguration und stellt ihre Uhr über NTS. Die CA wird gegen ein schriftliches Bedrohungsmodell gebaut, weil ein gefälschtes ROA Verkehr umleitet.
• Netz. Das Repository ist öffentlich und nur lesbar. Der Schlüsselspeicher ist nur über WireGuard von benannten Hosts erreichbar.

7. Profile von Zertifikaten, Sperrlisten und Manifesten

• Ressourcenzertifikate folgen RFC 6487, mit den Erweiterungen für IP-Adressen und AS-Nummern aus RFC 3779. Jedes CA-Zertifikat nennt sein rsync-Repository, sein Manifest und seine RRDP-Benachrichtigungsadresse (RFC 8182), und jedes Zertifikat nennt seinen Aussteller und seine Sperrliste mit rsync-Adressen, wie es RFC 6487 verlangt.
• Das Zertifikat des Vertrauensankers ist selbst signiert und trägt die gesamte zertifizierte Ressourcenmenge aus Abschnitt 1. Das Zertifikat der Online-CA trägt dieselbe Menge.
• EE-Zertifikate: eines je signiertem Objekt, jedes für einen Schlüssel, der einmal verwendet wird.
• ROAs folgen RFC 9582: eines je Ursprungs-ASN, jedes Präfix ohne maxLength.
• ASPA-Objekte folgen dem Profil der IETF (draft-ietf-sidrops-aspa-profile): eine Kunden-ASN und die für sie registrierten Provider-ASNs.
• Manifeste folgen RFC 9286: eines je CA, mit jedem aktuellen Objekt und seinem Hash, jedes Manifest mit seinem eigenen einmaligen EE-Schlüssel signiert.
• Sperrlisten folgen dem Profil von RFC 6487, eine je CA.
• Signierte Objekte nutzen das CMS-Profil von RFC 6488.

8. Konformitätsprüfung und andere Bewertungen

Kein externer Prüfer prüft diese CA. Sie wird fortlaufend und öffentlich überprüft:

• Zwei unabhängige Validatoren rufen das Repository fortlaufend ab und validieren es, und jede Abweichung und jeder veraltete Stand alarmiert Tier 0;
• jedes Routenobjekt hinter einem ROA ist eine vom Inhaber signierte Änderung im Transparenzlog, und ein öffentlicher Monitor prüft jede protokollierte Änderung gegen die registrierten Schlüssel des Inhabers und warnt den Inhaber vor allem, was er nicht signiert hat;
• Inhaber erfahren von jeder Änderung an ihren Objekten, auch von solchen durch Tier 0;
• jede Person kann mit dem veröffentlichten TAL einen Validator gegen das Repository laufen lassen und das Ergebnis mit der Registry vergleichen.

Ein Befund wird als Sicherheitsmeldung nach der GOpenCNR-Sicherheits- und Offenlegungsrichtlinie behandelt.

9. Sonstige geschäftliche und rechtliche Regelungen

• Entgelte. Keine. Zertifizierung, Repository und TAL sind kostenlos.
• Was öffentlich ist. Alles im Repository, der TAL und diese Erklärung. Das Repository enthält Präfixe, ASNs, Schlüssel und Signaturen. Es enthält nie eine Endpunktadresse, eine E-Mail-Adresse oder die Mitglieder einer Zielgruppe.
• Datenschutz. Was GOpenCNR über Inhaber verarbeitet, steht im GOpenCNR-Datenschutzhinweis. Abrufe des Repositorys werden wie jede Anfrage an unsere Server protokolliert, und Anfrageprotokolle werden nach 14 Tagen gelöscht.
• Keine Gewährleistung. Weder Inhabern noch vertrauenden Parteien wird eine Gewährleistung gegeben, und ein Service Level gilt nicht. Eine vertrauende Partei entscheidet selbst, was ihr Validator und ihre Router tun, wenn Daten fehlen oder veraltet sind.
• Haftung. Die Zertifizierung ist unentgeltlich. Für Unentgeltliches ist die Haftung auf Vorsatz und grobe Fahrlässigkeit beschränkt (§ 521 BGB), im Übrigen gelten die allgemeinen Nutzungsbedingungen.
• Änderungen dieser Erklärung erfolgen, wie es Abschnitt 1 beschreibt, und jede Fassung wird im Dokumentenarchiv aufbewahrt.
• Recht. Es gilt deutsches Recht. Nichts in dieser Erklärung geht dem Gesetz, einer gerichtlichen Anordnung oder den Rechten vor, die Inhaber nach den GOpenCNR-Nutzungsbedingungen haben.