Zusammenfassung

  • RFC 9509 registriert id-kp-jwt, id-kp-httpContentEncrypt und id-kp-oauthAccessTokenSigning für drei verschiedene Sicherheitsaufgaben im 5G-System.
  • Die heutige 3GPP-Spezifikation erlaubt ein Zertifikat je Zweck oder ein Zertifikat mit mehreren Zwecken. Die Wahl verändert den Ausfall- und Widerrufsradius.
  • Der Zweck ersetzt weder anfängliches Vertrauen und NF-Identität noch KU, JOSE-Prüfung, Claims, Autorisierung und den Nachweis der ausgeführten Dienstoperation.

Die wichtigste Frage stellt sich beim Widerruf. Wenn ein Zertifikat nicht mehr für CCA-Signaturen gelten darf, soll dieselbe Netzfunktion dann auch ihre TLS-Verbindung verlieren? Falls beide Aufgaben auf einer Urkunde und einem Schlüssel liegen, lautet die technische Antwort möglicherweise ja – unabhängig davon, ob die Organisation diese Kopplung je bewusst beschlossen hat.

RFC 9509 wurde im März 2024 als Proposed Standard veröffentlicht. Die RFC-Editor-Seite und der Datatracker dokumentieren den Status. Im SMI-Register der IANA steht 37 für id-kp-jwt, 38 für id-kp-httpContentEncrypt und 39 für id-kp-oauthAccessTokenSigning.

Der erste Zweck betrifft eine JWS-Signatur über einem JWT, etwa der Client Credentials Assertion. Der zweite kennzeichnet JWE-Schutz für JSON in HTTP-Nachrichten zwischen SEPPs. Der dritte gilt dem Signieren von Zugriffstoken in OAuth 2.0. TLS-Client- und Serverzwecke bleiben daneben bestehen.

Damit wird eine Privilegienvererbung sichtbar. Ein Service Consumer soll nicht als Producer auftreten können, nur weil beide Zertifikate derselben Betreiber-PKI tragen. Ein TLS-Client-Schlüssel darf auch nicht allein wegen seiner Signaturfähigkeit eine CCA ausstellen. RFC 9509 bindet den Zweck deshalb an Key Usage: Signaturzwecke brauchen Signaturbits, das JWE-Beispiel für Schlüsseltransport keyEncipherment.

Mehrzweck ist eine Richtlinie, kein Registereintrag

Nach RFC 5280 müssen KU und EKU beide passen, wenn beide vorhanden sind. RFC 9509 verbietet weitere EKUs nicht. Das erlaubte und ausgeschlossene Zweckmodell aus RFC 9336 kann bestimmte Kombinationen, ein fehlendes EKU oder anyExtendedKeyUsage zurückweisen.

Die aktuelle 3GPP TS 33.310 V19.5.0 formuliert die Portfolioentscheidung ausdrücklich: Implementierungen dürfen je Zweck ein eigenes Zertifikat oder ein Zertifikat mit mehreren Zwecken einsetzen – sowohl im anfänglichen Vertrauen als auch beim finalen NF-Zertifikat.

Getrennte Zertifikate beschränken die Reichweite eines privaten Schlüssels. Der Widerruf einer CCA-Berechtigung muss TLS nicht beenden; ein kompromittierter JWE-Schlüssel verleiht keine Token-Signatur. Dafür steigen Anzahl und Komplexität von Enrollment, Speicherung, Verteilung, Erneuerung, Ablauf, Widerruf und Verifier-Konfiguration.

Ein Mehrzweckzertifikat senkt die Stückzahl, koppelt aber mehrere Dienste an Schlüssel, Pfad und Widerrufsereignis. Ein dringender Wechsel für eine Aufgabe kann weitere Aufgaben unterbrechen. Das ist keine allgemeine Empfehlung gegen Bündelung, sondern ein Grund, ihre Folgen als bewusste Entscheidung zu behandeln.

Zweck ist nicht Identität

TS 33.310 beginnt mit initialem Vertrauen über ein OAM-Zertifikat, signierte NF-Profildaten oder einen Initial Authentication Key. Die Betreiber-RA/CA prüft Besitznachweis, NF Instance ID und gegebenenfalls NF Type. Trägt das initiale Vertrauen ein EKU, kann dessen Übereinstimmung mit dem Antrag vor Ausstellung geprüft werden.

id-kp-jwt sagt daher nicht, welche NF den Schlüssel besitzt. Es benennt eine zertifizierte Verwendung. Instanzkennung im subjectAltName, tatsächlich validierter Pfad, Sperrstatus und Enrollment-Nachweis bleiben getrennt.

Im Betrieb verlangt die aktuelle 3GPP TS 33.501 V19.5.0 weitere Entscheidungen. Die CCA ist ein vom Service Consumer signiertes JWT; der Empfänger prüft JWS, Identität und Zeit. Im OAuth-Modell ist das NRF Autorisierungsserver, die Consumer-NF Client und die Producer-NF Resource Server. Der Producer prüft zugelassenen Aussteller, Signatur, Subjekt, Audience, gegebenenfalls Slice- und Service-Set-Kennungen, Scope, zusätzliche Ressourcen und Aktionen, Ablauf sowie bei Bedarf die Übereinstimmung mit CCA und TLS-Identität. Erst danach folgt die Dienstoperation.

3GPP TS 29.500 beschreibt die servicebasierten Schnittstellen, TS 29.573 die PLMN-Interconnection und SEPP-Umgebung. Ein Verschlüsselungs-EKU beweist weder Zulässigkeit noch Zustellung, Entschlüsselung oder Wirkung eines bestimmten JSON-Objekts.

Sperrstatus und Discovery können auseinanderlaufen

TS 33.310 weist darauf hin, dass ein NRF eine Producer-Instanz liefern kann, deren Zertifikat bereits gesperrt ist, wenn der Widerruf dort noch unbekannt ist. Kryptografischer Status und Discovery-Zustand sind verschiedene Ebenen. Der Beleg muss initiales Vertrauen, NF-Instanz und -Typ, Zertifikat, Schlüssel und Pfad, KU/EKU, Kombinationen, JOSE-Algorithmus und Header, Claims, Policy-Version, Sperrnachweis, Request, Response und Telemetrie enthalten.

Auch der Zweck kann sichtbar werden. TLS 1.2 kann Zertifikate offen übertragen; TLS 1.3 schützt Zertifikatsnachrichten nach ServerHello; Certificate Transparency kann öffentlich vertraute Zertifikate veröffentlichen. Sichtbar ist eine vorbereitete Fähigkeit, nicht deren Ausübung.

Die redaktionelle Linse ist offengelegt: Primat des laufenden Codes, Realitätsebenen und minimale Anfangsspezifikation mit lokaler Entscheidung. Gemeinsame Namen helfen der Interoperabilität. Sie nehmen dem Betreiber nicht die Verantwortung für die Schlüsselstruktur.