Zusammenfassung

  • Ein gültiges delegiertes Credential belegt die begrenzte Befugnis, eine kompatible TLS- oder DTLS-1.3-Verbindung unter einem übergeordneten Endentitätszertifikat zu authentisieren.
  • Es belegt weder die Kontrolle über die Domain noch die Befugnis einer Zertifizierungsstelle zur Zertifikatsausstellung, eine rechtliche Identität oder eine eigenständig vorzeitig widerrufbare Delegation.

Man stelle sich eine hypothetische Sicherheitsübersicht vor, die einen CDN-Edge beobachtet. Der Edge präsentiert ein gültiges delegiertes Credential, schließt TLS 1.3 ab und wird daraufhin als neuer Verwalter der Domain eingetragen. Die erste Beobachtung ist korrekt; die Einordnung nicht.

RFC 9345 definiert einen engeren Mechanismus. Der Zertifikatsinhaber signiert eine Struktur mit öffentlichem Schlüssel, Signaturalgorithmus und kurzer Gültigkeit. Das kompatible Frontend terminiert Verbindungen, ohne den langfristigen privaten Schlüssel des Zertifikats zu erhalten. Die Signatur bindet das Credential an das vollständige Endentitätszertifikat und an den Kontext der Client- oder Serverauthentisierung.

Die Gegenstelle prüft weiterhin die Zertifikatskette und gleicht das Endentitätszertifikat mit der erwarteten Identität ab. Das Zertifikat muss DelegationUsage enthalten und digitale Signaturen erlauben. Danach prüft die Gegenstelle die ausgehandelten Algorithmen, die Signatur des Credentials und seine zeitlichen Grenzen. Ohne anderes Anwendungsprofil beträgt die maximale Restlaufzeit sieben Tage und endet spätestens mit dem übergeordneten Endentitätszertifikat.

Nachgewiesen wird der Besitz des delegierten Schlüssels im festgelegten TLS-Rahmen. Er erlaubt weder die Ausgabe eines weiteren öffentlichen Zertifikats noch DNS-Änderungen, den Nachweis einer Unternehmensbeziehung oder die Bestimmung des rechtlichen Domaininhabers. Ein gültiger Handshake ist kein Eigentumstitel.

RFC 9345 schafft auch keinen eigenen Kanal für vorzeitigen Widerruf. Mit Ablauf der Gültigkeit endet das Credential; der Widerruf des übergeordneten Endentitätszertifikats macht es mittelbar ungültig. Wird der langfristige private Schlüssel zum Signieren delegierter Credentials kompromittiert oder außer Betrieb genommen, muss der Betreiber deshalb das übergeordnete Zertifikat widerrufen. Allein die Zustandsänderung des Schlüssels ist kein separates Widerrufssignal im Protokoll.

Mit einem gestohlenen delegierten Schlüssel kann sich ein Angreifer bis zum Ablauf oder Zertifikatswiderruf als die Partei ausgeben, an die die Authentisierung delegiert wurde. Kurze Laufzeit mindert das Risiko, ersetzt aber keine sichere Verwahrung.

Bei einer wiederaufgenommenen TLS-1.3-Sitzung werden weder Zertifikat noch delegiertes Credential erneut übertragen. Entscheidet sich eine Implementierung oder Abnahmerichtlinie dafür, die ursprüngliche Zertifikatskette bei der Wiederaufnahme zu speichern und erneut zu prüfen, sollte sie auch das ursprüngliche delegierte Credential zuordnen und prüfen. Das ist eine bedingte Sicherungsmaßnahme, kein allgemeiner Protokollschritt.

Der Betriebsbeleg verbindet Fingerabdruck und Laufzeit des übergeordneten Endentitätszertifikats, DelegationUsage, Fingerabdruck des delegierten öffentlichen Schlüssels, Aussteller, Client- oder Serverrolle, Algorithmen, Intervall, Verteilungsziel, Verwahrer, TLS-Version, beobachteten Handshake, Behandlung der Wiederaufnahme, Widerrufsstatus des übergeordneten Zertifikats, bestätigte Außerbetriebnahme und den Beobachtungszeitpunkt jedes Belegs. So wird aus einer begrenzten Befugnis zur TLS-Terminierung nicht versehentlich eine allgemeine Kontrolle über die Domain.

Quellen