Zusammenfassung

  • In TLS 1.3 zeigt certificate_request_context, auf welches CertificateRequest ein Authentisierungsblock des Clients antwortet. Das ist besonders wichtig, wenn mehrere Antworten nach dem Handshake in anderer Reihenfolge eintreffen. Eindeutigkeit und Unvorhersagbarkeit schützen diese Zuordnung innerhalb einer Verbindung; sie schaffen keinen Autorisierungsbereich.
  • Ein belastbarer Nachweis hält TLS-Kontext, Schlüsselbesitz, Zertifikatspfad, Anwendungsprinzipal, Ressource, Handlung, Regel, Entscheidung, Gültigkeit und Widerruf getrennt fest. Ersetzt der undurchsichtige Wert diese Verbindung, erscheint eine genaue Korrelation fälschlich als nie getroffene Zugriffsentscheidung.

Man stelle sich eine langlebige Verbindung vor, über die ein Dienst zwei Client-Zertifikate anfordert. Die erste Anforderung geht einer Kontenabfrage voraus, die zweite einer administrativen Änderung. Das Programm hält kurzzeitig eine Tabelle, die die beiden Kontexte „Abfrage“ und „Administration“ nennt. Weil der Client auf ein Kryptogerät wartet, treffen die Antworten umgekehrt ein, und TLS ordnet sie richtig zu. Ein Jahr später lautet der einzige Protokolleintrag, der zweite Kontext sei erfolgreich authentisiert worden. Daraus lässt sich weder das betroffene Konto noch die damalige Regel noch die Befugnis des Schlüsselinhabers ableiten.

RFC 9846, der Proposed Standard vom Juli 2026 und Nachfolger von RFC 8446, begrenzt die Aufgabe des Feldes präzise. Eine CertificateRequest-Nachricht enthält einen undurchsichtigen certificate_request_context von null bis 255 Oktetten und Erweiterungen mit den verlangten Authentisierungsparametern. Der Client übernimmt den Kontext in seine Certificate-Antwort. So kann der Server die Antwort ihrer auslösenden Anforderung zuordnen.

Innerhalb einer Verbindung muss jeder Kontext eindeutig sein. Würden zwei Anforderungen denselben Wert verwenden, könnte ein CertificateVerify als Antwort auf die falsche Anforderung erscheinen. Beim anfänglichen Handshake ist der Kontext leer; nicht leere Werte gehören zur Authentisierung nach dem Handshake. Diese Reichweite ist entscheidend: Die Eindeutigkeit umfasst weder neue Verbindungen noch Organisationen, Konten, Ressourcen oder die gesamte Lebensdauer eines Berechtigungsnachweises.

Für eine spätere Anforderung sollte der Server den Kontext außerdem für den Client unvorhersagbar erzeugen. Zufällige Werte sind das naheliegende Mittel. Ein Angreifer mit vorübergehendem Zugriff auf den privaten Schlüssel soll keine gültigen Antworten für vorhersehbare künftige Anforderungen vorbereiten können. Unvorhersagbarkeit schützt Frische und Bindung der Antwort. Sie verwandelt die Bytes nicht in ein geheimes Capability-Token, eine Rolle oder eine geschäftliche Delegation.

Die Erweiterungen der Anforderung beschreiben TLS-Auswahlparameter. signature_algorithms ist verpflichtend; weitere Erweiterungen können akzeptierte Zertifizierungsstellen, Filter für Objektkennungen oder Signaturalgorithmen für Zertifikate angeben. Sie begrenzen das Authentisierungsmaterial, das der Client liefern darf. Ob eine Person eine Akte öffnen, eine Zahlung auslösen oder einen anderen Mandanten verwalten darf, beantworten sie nicht.

Entscheidet sich der Client zur Authentisierung, sendet er Certificate, CertificateVerify und Finished. CertificateVerify weist den Besitz des passenden privaten Schlüssels nach und schützt das einschlägige Handshake-Transkript. Finished bindet den Block an den TLS-Zustand. Das sind starke Tatsachen, doch Beweisstärke erweitert den Beweisgegenstand nicht. Die Kontrolle eines Schlüssels in diesem kryptografischen Gespräch erfüllt nicht automatisch alle darüberliegenden Geschäftsregeln.

Der Client kann auch ordnungsgemäß ohne Zertifikat antworten: auf ein leeres Certificate folgt Finished. TLS erkennt damit genau, dass für diese Anforderung kein Zertifikat angeboten wurde. Daraus folgt nicht automatisch eine Abmeldung aus der Anwendung, ein Widerruf der Einwilligung, eine dauerhafte Ablehnung oder die Ungültigkeit anderer Nachweise. Das Anwendungsprotokoll entscheidet, ob anonymer Betrieb, ein anderer Faktor oder der Verbindungsabbruch angemessen ist.

Die mögliche Verzögerung erklärt den Bedarf an Korrelation. Der Client muss vielleicht einen Menschen fragen oder auf ein Schlüsselspeichergerät warten. Währenddessen fließen andere Nachrichten, und mehrere Anforderungen können gleichzeitig offen sein. Antworten müssen die Sendereihenfolge nicht einhalten. Der eindeutige Kontext beseitigt die Mehrdeutigkeit, ohne die Reihenfolge auf der Leitung zur Identität zu erklären.

Der Server darf eine Zertifikatsauthentisierung nach dem Handshake nur verlangen, wenn der Client zuvor die leere Erweiterung post_handshake_auth angeboten hat. Ohne dieses Angebot ist ein späteres CertificateRequest eine unerwartete Nachricht und löst einen fatalen Alarm aus. Selbst ein angekündigtes TLS-Merkmal darf aber vom Anwendungsprotokoll ausgeschlossen werden.

RFC 9113 macht diese Trennung anschaulich. Ein HTTP/2-Server darf nach dem TLS-1.3-Handshake kein CertificateRequest senden; der Client behandelt es als Verbindungsfehler. Das gilt auch dann, wenn er post_handshake_auth angeboten hat, denn dasselbe Angebot kann für andere Anwendungsprotokolle bestimmt gewesen sein. Eine TLS-Möglichkeit setzt die Multiplex- und Verbindungsregeln von HTTP/2 nicht außer Kraft.

Die Gültigkeit des Zertifikatspfads ist eine weitere unabhängige Entscheidung. RFC 5280 beschreibt die Pfadvalidierung unter Zertifikatsbeschränkungen, einem gewählten Vertrauensanker und Eingaben der vertrauenden Partei. Schon die Wahl des Ankers ist Politik; eine Anwendung kann an sich gültige Pfade zusätzlich beschränken. Das korrekte Zurücksenden des Kontexts wählt weder den Anker noch macht es jeden gültigen Pfad für jeden Zweck akzeptabel.

Drei Prädikate sollten deshalb getrennt bleiben. Der Besitznachweis zeigt, dass der Endpunkt einen privaten Schlüssel kontrolliert. Eine gewählte Pfadpolitik kann diesen Schlüssel in einem bestimmten Vertrauensrahmen an einen zertifizierten Namen binden. Danach bildet die Anwendung das Ergebnis auf ein Prinzipal ab und entscheidet, was dieses mit einer Ressource tun darf. Der Erfolg des ersten Prädikats entscheidet die beiden anderen nicht vorweg.

RFC 9525 zeigt, dass Anwendungsprotokolle selbst festlegen müssen, wie sie beim Einsatz von TLS die Dienstidentität prüfen. Sein Hauptgegenstand ist die Serveridentität, nicht ein universelles Modell für Client-Autorisierung. Die strukturelle Lehre bleibt: TLS liefert Mechanismen, das Nutzungsprofil bestimmt Identitätsreferenz und Folgen einer Übereinstimmung.

OAuth mit gegenseitigem TLS verdeutlicht die Aufteilung. RFC 8705 unterscheidet Client-Authentisierung mit Zertifikat von zertifikatsgebundenen Zugriffstoken. Der Autorisierungsserver wendet Regeln auf eine registrierte client_id an, vergleicht das Zertifikat mit erwarteten Daten und kann ein Token an den Besitznachweis binden. Am Ressourcenserver trägt weiterhin das Token die Zugriffsentscheidung; Zertifikat und Kontext nennen nicht von sich aus die erlaubten Ressourcen.

RFC 6749 verortet OAuth-Scopes in der Autorisierung. Nach RFC 7662 kann ein Ressourcenserver feststellen, ob ein Token aktiv ist, und einschlägige Metadaten erhalten. Ein richtig zugeordneter TLS-Kontext verrät weder Ablauf noch Widerruf oder Verkleinerung des Scopes. Wer beide Ebenen vermischt, kann Politikänderungen während einer beständigen Verbindung nicht zuverlässig durchsetzen.

Die Sicherheitsempfehlungen in RFC 9325 helfen bei sicheren Versionen, Algorithmen und Betriebsweisen für TLS und DTLS. Ein universelles Rollen- und Rechtesystem sind sie nicht. Ebenso koordiniert das TLS-Parameterregister der IANA interoperable Codes und Namen, entscheidet aber nicht über die Befugnisse von Beschäftigten oder Diensten in einer konkreten Umgebung.

Zur normativen Spur gehören auch die Informationsseite zu RFC 9846 und das Errata-Verzeichnis. RFC 8446 bleibt für das Verständnis des ersetzten Textes und des Übergangs relevant. Diese Herkunft belegt, welche Spezifikation geprüft wurde; die für eine Transaktion angewandte Autorisierungspolitik ersetzt sie nicht.

Die Grenze erinnert an zwei Gedanken von Lu Heng. Eine minimale Ausgangsspezifikation ermöglicht nötige Koordination, ohne alle künftigen lokalen Entscheidungen vorwegzunehmen. Der Policy Mirror lenkt den Blick darauf, wo Entscheidungen wirklich fallen, statt nur technische Spuren zu betrachten. certificate_request_context ist gute minimale Koordination: Es klärt die Nachrichtenzuordnung und lässt der Anwendung jene Autorität, die TLS nicht kennen kann.

Der Fehler beginnt häufig bei Namen. Ein Team nennt den Kontext „Scope“, die flüchtige Tabelle „Session Role“ und den kryptografischen Erfolg „authorized“. Bald übernehmen Überwachung, Support und Audit-Exporte diese Wörter. Eine lokale Gedächtnisstütze erscheint als Protokollgarantie, obwohl keine Spezifikation den Bytes eine geschäftliche Bedeutung über die Verbindung hinaus gegeben hat.

Ebenso gefährlich ist es, einen neuen Kontext als Erneuerung von Rechten zu behandeln. Die spätere Authentisierung kann den Schlüsselbesitz erneut beweisen, berechnet aber Kontostand, Vertrag, Token-Scope und Widerruf nicht automatisch neu. Umgekehrt darf eine alte Authentisierung die Politik vom Verbindungsbeginn nicht dauerhaft einfrieren. Authentisierungsereignis und Autorisierungsentscheidung brauchen eigene Wirksamkeitszeiten und ausdrücklich benannte Neubewertungsanlässe.

Eine verständliche Architektur hält mindestens vier Namensräume. TLS führt Verbindung, Anforderung, Kontext, Transkript und Beweisergebnis. Die PKI führt Zertifikat, Pfad, Vertrauensanker und Beschränkungen. Die Anwendungsidentität führt Prinzipal, Konto, Mandant und Bindungsmethode. Die Autorisierung führt Ressource, Handlung, Regel, Entscheidung und Gültigkeitsintervall. Bezeichner können die Räume verbinden, dürfen aber nicht die Semantik eines anderen Raums übernehmen.

Die Trennung verbessert auch die Reaktion auf Vorfälle. Wird ein Schlüssel kompromittiert, lassen sich die davon abhängigen Anwendungsentscheidungen finden, ohne jedem Auftreten eines Kontexts dieselben Rechte zu unterstellen. Ändert sich eine Regel, können künftige Handlungen trotz offener TLS-Verbindung abgelehnt werden. Wird die Identitätsabbildung bestritten, kann die Bindung vom Zertifikat zum Prinzipal geprüft werden, ohne die kryptografische Aussage des Transkripts umzudeuten.

Quellen