6.5 Certificate Revocation (Zertifikatswiderruf)

6.5 Certificate Revocation (Zertifikatswiderruf)

Die folgenden Überlegungen und Empfehlungen repräsentieren den aktuellen Stand der Technik in Bezug auf Zertifikatswiderruf, obwohl keine vollständige und effiziente Lösung für das Problem der Überprüfung des Widerrufsstatus üblicher Public-Key-Zertifikate existiert [RFC5280]:

• Obwohl Certificate Revocation Lists (CRLs) der am weitesten unterstützte Mechanismus zur Verteilung von Widerrufsinformationen sind, haben sie bekannte Skalierungsprobleme, die ihre Nützlichkeit einschränken (trotz Workarounds wie partitionierten CRLs und Delta-CRLs).

• Proprietäre Mechanismen, die Widerrufslisten in die Konfigurationsdatenbank des Webbrowsers einbetten, können nicht über eine kleine Anzahl der am häufigsten verwendeten Webserver hinaus skalieren.

• Das On-Line Certification Status Protocol (OCSP) [RFC6960] stellt sowohl Skalierungs- als auch Datenschutzprobleme dar. Darüber hinaus führen Clients typischerweise ein "soft-fail" durch, was bedeutet, dass sie die TLS-Verbindung nicht abbrechen, wenn der OCSP-Server nicht antwortet. (Dies könnte jedoch ein Workaround sein, um Denial-of-Service-Angriffe zu vermeiden, wenn ein OCSP-Responder offline genommen wird.)

• Die TLS Certificate Status Request Erweiterung (Abschnitt 8 von [RFC6066]), allgemein als "OCSP stapling" bezeichnet, löst die operativen Probleme mit OCSP. Sie ist jedoch immer noch ineffektiv in Gegenwart eines MITM-Angreifers, da der Angreifer einfach die Anforderung des Clients nach einer gestapelten OCSP-Antwort ignorieren kann.

• OCSP stapling, wie in [RFC6066] definiert, erstreckt sich nicht auf Zwischenzertifikate, die in einer Zertifikatskette verwendet werden. Obwohl die Multiple Certificate Status Erweiterung [RFC6961] diesen Mangel behebt, ist sie eine neuere Ergänzung ohne viel Verbreitung.

• Sowohl CRLs als auch OCSP hängen von relativ zuverlässiger Konnektivität zum Internet ab, die möglicherweise nicht für bestimmte Arten von Knoten verfügbar ist (wie neu bereitgestellte Geräte, die eine sichere Verbindung herstellen müssen, um zum ersten Mal zu booten).

In Bezug auf übliche Public-Key-Zertifikate SOLLTEN Server das Folgende als Best Practice angesichts des aktuellen Stands der Technik und als Grundlage für eine mögliche zukünftige Lösung unterstützen:

1. OCSP [RFC6960]

2. Sowohl die status_request Erweiterung, die in [RFC6066] definiert ist, als auch die status_request_v2 Erweiterung, die in [RFC6961] definiert ist (Dies könnte Interoperabilität mit der breitesten Palette von Clients ermöglichen.)

3. Die OCSP stapling Erweiterung, die in [RFC6961] definiert ist

Die Überlegungen in diesem Abschnitt gelten nicht für Szenarien, in denen der DANE-TLSA Resource Record [RFC6698] verwendet wird, um einem Client zu signalisieren, welches Zertifikat ein Server als gültig und gut zur Verwendung für TLS-Verbindungen betrachtet.