1. Introduction (Einführung)
Das Transport Layer Security (TLS) Extension Framework [RFC6066] definiert unter anderem die Certificate Status Extension (Zertifikatsstatus-Erweiterung) (auch als "OCSP stapling" bezeichnet), die Clients verwenden können, um den Server aufzufordern, seine Kopie des aktuellen Status seines Zertifikats über den TLS-Handshake zu übertragen, anstatt sie über separate Verbindungen herunterzuladen. Die Vorteile dieser Erweiterung umfassen eine reduzierte Anzahl von Roundtrips und Netzwerkverzögerungen für den Client zur Überprüfung des Status des Serverzertifikats sowie eine reduzierte Last auf den Status-Response-Servern des Zertifikatausstellers, wodurch ein Problem gelöst wird, das signifikant werden kann, wenn das ausgestellte Zertifikat von einem häufig besuchten Server präsentiert wird.
Es gibt zwei Probleme mit der bestehenden Certificate Status Extension. Erstens bietet sie keine Funktionalität, um Statusinformationen über Zwischenzertifizierungsstellen (CA)-Zertifikate anzufordern, was bedeutet, dass der Client Statusinformationen über andere Methoden anfordern muss, wie z.B. Certificate Revocation Lists (CRLs, Zertifikatsperrlisten), was weitere Verzögerungen einführt. Zweitens verhindern das aktuelle Format der Erweiterung und Anforderungen im TLS-Protokoll, dass ein Client dem Server mehrere Status-Methoden anbieten kann.
Viele CAs stellen jetzt Zwischenzertifizierungs-CA-Zertifikate aus, die nicht nur den Veröffentlichungspunkt für ihre CRLs in einem CRL Distribution Point [RFC5280] angeben, sondern auch eine URL für ihren OCSP [RFC6960]-Server in Authority Information Access [RFC5280] spezifizieren. Da clientseitig gecachte CRLs häufig veraltet sind, würden Clients davon profitieren, OCSP zu verwenden, um auf aktuelle Statusinformationen über Zwischenzertifizierungs-CA-Zertifikate zuzugreifen. Der Vorteil für die ausstellende CA ist weniger klar, da die Bereitstellung der Bandbreite für den OCSP-Responder kostspielig sein kann, insbesondere für CAs mit vielen stark frequentierten Subscriber-Sites, und diese Kosten sind für viele CAs ein Anliegen. Es gibt Fälle, in denen OCSP-Anfragen für eine einzelne stark frequentierte Site erhebliche Netzwerkprobleme für die ausstellende CA verursachten.
Clients werden davon profitieren, dass der TLS-Server Zertifikatsstatus-Informationen unabhängig vom Typ bereitstellt, nicht nur für das Serverzertifikat, sondern auch für die Zwischenzertifizierungs-CA-Zertifikate. Die Kombination der Statusprüfungen in einer Erweiterung wird die Roundtrips reduzieren, die der Client zur Vervollständigung des Handshakes benötigt, auf nur diejenigen, die für das Aushandeln der TLS-Verbindung erforderlich sind. Auch für die Zertifizierungsstellen wird die Last auf ihren Servern von der Anzahl der von ihnen ausgestellten Zertifikate abhängen, nicht von der Anzahl der Besucher dieser Sites. Darüber hinaus reduziert die Verwendung dieser Erweiterung erheblich Datenschutzbedenken dahingehend, dass Clients den Zertifikataussteller darüber informieren, welche Sites sie besuchen.
Damit ein solches neues System nahtlos eingeführt werden kann, müssen Clients in der Lage sein, die Unterstützung für die bestehende OCSP Certificate Status-Methode und einen neuen Multiple-OCSP-Modus anzugeben.
Leider erlaubt die Definition der Certificate Status Extension nur, dass eine einzelne Certificate Status Extension in einem einzigen Extension Record im Handshake definiert wird, und das TLS-Protokoll [RFC5246] erlaubt nur einen einzelnen Record in der Extension-Liste für jede gegebene Erweiterung. Dies bedeutet, dass es für Clients nicht möglich ist, die Unterstützung für neue Methoden anzuzeigen und gleichzeitig ältere Methoden zu unterstützen, was Probleme für die Interoperabilität zwischen neueren Clients und älteren Servern verursachen würde. Dies wird nicht nur ein Problem für den oben vorgeschlagenen Multiple Status Request-Modus sein, sondern auch für alle anderen zukünftigen Status-Methoden, die möglicherweise eingeführt werden. Dies wird nicht nur für die aktuelle PKIX-Infrastruktur [RFC5280], sondern auch für alternative PKI-Strukturen gelten.
Die Lösung für dieses Problem besteht darin, eine neue Erweiterung zu definieren, status_request_v2, mit einem erweiterten Format, das es dem Client ermöglicht, die Unterstützung für mehrere Status-Request-Methoden anzuzeigen. Dies wird durch die Verwendung einer Liste von CertificateStatusRequestItemV2-Records im Extension Record implementiert. Da der Server die einzelne Status-Methode basierend auf der ausgewählten Cipher Suite und dem präsentierten Zertifikat auswählt, sind keine signifikanten Änderungen im Extension-Format des Servers erforderlich.