Zum Hauptinhalt springen

4.4. Extensions (Erweiterungen)

4.4. Extensions (Erweiterungen)​

Dieser Abschnitt definiert einige Standarderweiterungen, basierend auf dem Erweiterungsmodell, das in X.509 Version 3 Zertifikaten verwendet wird (siehe [RFC5280]). Die Unterstützung für alle Erweiterungen ist sowohl für Clients als auch für Responder optional. Für jede Erweiterung gibt die Definition ihre Syntax, die vom OCSP-Responder durchgeführte Verarbeitung und alle Erweiterungen an, die in der entsprechenden Antwort enthalten sind.

4.4.1. Nonce (Nonce)​

Die Nonce bindet eine Anfrage und eine Antwort kryptografisch aneinander, um Replay-Angriffe zu verhindern. Die Nonce wird als eine der requestExtensions in Anfragen aufgenommen, während sie in Antworten als eine der responseExtensions aufgenommen würde. Sowohl in der Anfrage als auch in der Antwort wird die Nonce durch den Objektidentifikator id-pkix-ocsp-nonce identifiziert, während der extnValue der Wert der Nonce ist.

id-pkix-ocsp           OBJECT IDENTIFIER ::= { id-ad-ocsp }
id-pkix-ocsp-nonce     OBJECT IDENTIFIER ::= { id-pkix-ocsp 2 }

Nonce ::= OCTET STRING

4.4.2. CRL References (CRL-Referenzen)​

Es kann für den OCSP-Responder wünschenswert sein, die CRL anzugeben, auf der ein widerrufenes oder onHold (ausgesetztes) Zertifikat gefunden wird. Dies kann nützlich sein, wenn OCSP zwischen Repositorys verwendet wird, sowie als Prüfmechanismus. Die CRL kann durch eine URL (die URL, unter der die CRL verfügbar ist), eine Nummer (CRL-Nummer) oder eine Zeit (die Zeit, zu der die relevante CRL erstellt wurde) angegeben werden. Diese Erweiterungen werden als singleExtensions spezifiziert. Der Identifikator für diese Erweiterung ist id-pkix-ocsp-crl, während der Wert CrlID ist.

id-pkix-ocsp-crl       OBJECT IDENTIFIER ::= { id-pkix-ocsp 3 }

CrlID ::= SEQUENCE {
    crlUrl               [0]     EXPLICIT IA5String OPTIONAL,
    crlNum               [1]     EXPLICIT INTEGER OPTIONAL,
    crlTime              [2]     EXPLICIT GeneralizedTime OPTIONAL }

Für die Auswahl crlUrl gibt der IA5String die URL an, unter der die CRL verfügbar ist. Für crlNum gibt der INTEGER den Wert der CRL-Nummernerweiterung der relevanten CRL an. Für crlTime gibt die GeneralizedTime die Zeit an, zu der die relevante CRL ausgestellt wurde.

4.4.3. Acceptable Response Types (Akzeptable Antworttypen)​

Ein OCSP-Client KANN (MAY) wünschen, die Arten von Antworttypen anzugeben, die er versteht. Dazu SOLLTE (SHOULD) er eine Erweiterung mit der OID id-pkix-ocsp-response und dem Wert AcceptableResponses verwenden. Diese Erweiterung wird als eine der requestExtensions in Anfragen aufgenommen. Die in AcceptableResponses enthaltenen OIDs sind die OIDs der verschiedenen Antworttypen, die dieser Client akzeptieren kann (z. B. id-pkix-ocsp-basic).

id-pkix-ocsp-response  OBJECT IDENTIFIER ::= { id-pkix-ocsp 4 }

AcceptableResponses ::= SEQUENCE OF OBJECT IDENTIFIER

Wie in Abschnitt 4.2.1 angemerkt, MÜSSEN (SHALL) OCSP-Responder in der Lage sein, mit Antworten des Antworttyps id-pkix-ocsp-basic zu antworten. Dementsprechend MÜSSEN (SHALL) OCSP-Clients in der Lage sein, Antworten des Antworttyps id-pkix-ocsp-basic zu empfangen und zu verarbeiten.

4.4.4. Archive Cutoff (Archivierungsgrenze)​

Ein OCSP-Responder KANN (MAY) wählen, Widerrufsinformationen über den Ablauf eines Zertifikats hinaus aufzubewahren. Das Datum, das durch Subtraktion dieses Aufbewahrungsintervallwerts von der producedAt-Zeit in einer Antwort erhalten wird, ist als "archive cutoff" (Archivierungsgrenze) Datum des Zertifikats definiert.

OCSP-fähige Anwendungen würden ein OCSP-Archivierungsgrenzdatum verwenden, um zu beweisen, dass eine digitale Signatur zum Zeitpunkt ihrer Erstellung zuverlässig war (oder nicht), selbst wenn das Zertifikat, das zur Validierung der Signatur benötigt wird, längst abgelaufen ist.

OCSP-Server, die Unterstützung für eine solche historische Referenz bieten, SOLLTEN (SHOULD) eine Archivierungsgrenzdatums-Erweiterung in Antworten aufnehmen. Wenn enthalten, MUSS (SHALL) dieser Wert als OCSP singleExtensions-Erweiterung bereitgestellt werden, die durch id-pkix-ocsp-archive-cutoff identifiziert wird und die Syntax GeneralizedTime hat.

id-pkix-ocsp-archive-cutoff OBJECT IDENTIFIER ::= {id-pkix-ocsp 6}

ArchiveCutoff ::= GeneralizedTime

Zur Veranschaulichung: Wenn ein Server mit einer Richtlinie für ein 7-jähriges Aufbewahrungsintervall betrieben wird und der Status zum Zeitpunkt t1 erstellt wurde, wäre der Wert für ArchiveCutoff in der Antwort (t1 - 7 Jahre).

4.4.5. CRL Entry Extensions (CRL-Eintragserweiterungen)​

Alle Erweiterungen, die als CRL-Eintragserweiterungen spezifiziert sind -- in Abschnitt 5.3 von [RFC5280] -- werden auch als singleExtensions unterstützt.

4.4.6. Service Locator (Service-Locator)​

Ein OCSP-Server kann in einem Modus betrieben werden, in dem der Server eine Anfrage empfängt und sie an den OCSP-Server weiterleitet, der als autoritativ für das identifizierte Zertifikat bekannt ist. Die serviceLocator-Anfrageerweiterung ist für diesen Zweck definiert. Diese Erweiterung wird als eine der singleRequestExtensions in Anfragen aufgenommen.

id-pkix-ocsp-service-locator OBJECT IDENTIFIER ::= {id-pkix-ocsp 7}

ServiceLocator ::= SEQUENCE {
    issuer    Name,
    locator   AuthorityInfoAccessSyntax OPTIONAL }

Werte für diese Felder werden aus den entsprechenden Feldern im Subjektzertifikat erhalten.

4.4.7. Preferred Signature Algorithms (Bevorzugte Signaturalgorithmen)​

Da andere Algorithmen als die obligatorisch zu implementierenden Algorithmen erlaubt sind und da ein Client derzeit keinen Mechanismus hat, um seine Algorithmuspräferenzen anzugeben, besteht immer das Risiko, dass ein Server, der einen nicht obligatorischen Algorithmus wählt, eine Antwort generiert, die der Client möglicherweise nicht unterstützt.

Während ein OCSP-Responder Regeln für die Algorithmusauswahl anwenden kann, z. B. unter Verwendung des Signaturalgorithmus, der von der CA zum Signieren von CRLs und Zertifikaten verwendet wird, können solche Regeln in häufigen Situationen fehlschlagen:

  • Der zum Signieren der CRLs und Zertifikate verwendete Algorithmus ist möglicherweise nicht konsistent mit dem Schlüsselpaar, das vom OCSP-Responder zum Signieren von Antworten verwendet wird.

  • Eine Anfrage für ein unbekanntes Zertifikat bietet dem Responder keine Grundlage, aus mehreren Algorithmusoptionen auszuwählen.

Das letzte Kriterium kann nicht durch die Informationen gelöst werden, die aus der In-Band-Signalisierung unter Verwendung des RFC 2560 [RFC2560] Protokolls verfügbar sind, ohne das Protokoll zu ändern.

Darüber hinaus möchte ein OCSP-Responder möglicherweise aus zwei Gründen andere Signaturalgorithmen verwenden als den, der von der CA zum Signieren von Zertifikaten und CRLs verwendet wird:

  • Der Responder verwendet möglicherweise einen Algorithmus für die Zertifikatsstatusantwort, der weniger rechenintensiv ist als das Signieren des Zertifikats selbst.

  • Eine Implementierung möchte sich möglicherweise gegen die Möglichkeit einer Kompromittierung schützen, die aus einer Kompromittierung des Signaturalgorithmus resultiert, indem sie zwei separate Signaturalgorithmen verwendet.

Dieser Abschnitt beschreibt:

  • Eine Erweiterung, die es einem Client ermöglicht, den Satz bevorzugter Signaturalgorithmen anzugeben.

  • Regeln für die Signaturalgorithmusauswahl, die die Wahrscheinlichkeit eines erfolgreichen Betriebs maximieren, falls keine unterstützten bevorzugten Algorithmen angegeben sind.

4.4.7.1. Extension Syntax (Erweiterungssyntax)​

Ein Client KANN (MAY) einen bevorzugten Satz von Algorithmen in einer Anfrage deklarieren, indem er eine Erweiterung für bevorzugte Signaturalgorithmen in requestExtensions der OCSPRequest aufnimmt.

id-pkix-ocsp-pref-sig-algs OBJECT IDENTIFIER ::= { id-pkix-ocsp 8 }

PreferredSignatureAlgorithms ::= SEQUENCE OF
                                 PreferredSignatureAlgorithm

PreferredSignatureAlgorithm ::= SEQUENCE {
   sigIdentifier        AlgorithmIdentifier,
   pubKeyAlgIdentifier  SMIMECapability OPTIONAL
   }

Die Syntax von AlgorithmIdentifier ist in Abschnitt 4.1.1.2 von RFC 5280 [RFC5280] definiert. Die Syntax von SMIMECapability ist in RFC 5751 [RFC5751] definiert.

sigIdentifier spezifiziert den Signaturalgorithmus, den der Client bevorzugt, z. B. algorithm=ecdsa-with-sha256. Parameter fehlen bei den meisten gängigen Signaturalgorithmen.

pubKeyAlgIdentifier spezifiziert den Identifikator des öffentlichen Schlüssels des Subjekts, den der Client im Zertifikat des Servers bevorzugt, das zur Validierung der OCSP-Antwort verwendet wird, z. B. algorithm=id-ecPublicKey und parameters= secp256r1.

pubKeyAlgIdentifier ist OPTIONAL und bietet ein Mittel, um Parameter anzugeben, die zur Unterscheidung zwischen verschiedenen Verwendungen eines bestimmten Algorithmus erforderlich sind; z. B. kann es vom Client verwendet werden, um anzugeben, welche Kurve er für einen bestimmten elliptischen Kurvenalgorithmus unterstützt.

Der Client MUSS (MUST) jeden der angegebenen bevorzugten Signaturalgorithmen unterstützen, und der Client MUSS (MUST) die Algorithmen in der Reihenfolge der Präferenz angeben, vom am meisten bevorzugten zum am wenigsten bevorzugten.

Abschnitt 4.4.7.2 dieses Dokuments beschreibt, wie ein Server einen Algorithmus zum Signieren von OCSP-Antworten an den anfragenden Client auswählt.

4.4.7.2. Responder Signature Algorithm Selection (Auswahl des Responder-Signaturalgorithmus)​

RFC 2560 [RFC2560] spezifizierte keinen Mechanismus zur Entscheidung über den Signaturalgorithmus, der in einer OCSP-Antwort verwendet werden soll. Dies bietet keinen ausreichenden Grad an Sicherheit hinsichtlich des ausgewählten Algorithmus, um die Interoperabilität zu erleichtern.

4.4.7.2.1. Dynamic Response (Dynamische Antwort)​

Ein Responder KANN (MAY) das Potenzial zur Gewährleistung der Interoperabilität maximieren, indem er einen unterstützten Signaturalgorithmus unter Verwendung der folgenden Rangfolge auswählt, solange der ausgewählte Algorithmus alle Sicherheitsanforderungen des OCSP-Responders erfüllt, wobei der erste Auswahlmechanismus die höchste Priorität hat:

  1. Wähle einen Algorithmus aus, der als bevorzugter Signaturalgorithmus in der Client-Anfrage angegeben ist.

  2. Wähle den Signaturalgorithmus aus, der zum Signieren einer Zertifikatswiderrufsliste (CRL) verwendet wird, die vom Zertifikatsaussteller ausgestellt wurde, der Statusinformationen für das durch CertID spezifizierte Zertifikat bereitstellt.

  3. Wähle den Signaturalgorithmus aus, der zum Signieren der OCSPRequest verwendet wurde.

  4. Wähle einen Signaturalgorithmus aus, der als Standard-Signaturalgorithmus für den Signaturdienst unter Verwendung eines Out-of-Band-Mechanismus beworben wurde.

  5. Wähle einen obligatorischen oder empfohlenen Signaturalgorithmus aus, der für die verwendete OCSP-Version spezifiziert ist.

Ein Responder SOLLTE (SHOULD) immer den Auswahlmechanismus mit der niedrigsten Nummer anwenden, der zur Auswahl eines bekannten und unterstützten Algorithmus führt, der die Kriterien des Responders für die Stärke des kryptografischen Algorithmus erfüllt.

4.4.7.2.2. Static Response (Statische Antwort)​

Aus Effizienzgründen ist es einem OCSP-Responder gestattet, statische Antworten vor einer Anfrage zu generieren. Der Fall erlaubt es dem Responder möglicherweise nicht, die Client-Anfragedaten während der Antwortgenerierung zu nutzen; der Responder SOLLTE (SHOULD) jedoch die Client-Anfragedaten während der Auswahl der zurückzugebenden vorgenerierten Antwort verwenden. Responder KÖNNEN (MAY) die historischen Client-Anfragen als Teil der Eingabe für die Entscheidungen verwenden, welche verschiedenen Algorithmen zum Signieren der vorgenerierten Antworten verwendet werden sollen.

4.4.8. Extended Revoked Definition (Erweiterte Widerrufsdefinition)​

Diese Erweiterung gibt an, dass der Responder die erweiterte Definition des Status "revoked" (widerrufen) unterstützt, um auch nicht ausgestellte Zertifikate gemäß Abschnitt 2.2 einzuschließen. Einer ihrer Hauptzwecke besteht darin, Prüfungen zu ermöglichen, um die Betriebsart des Responders zu bestimmen. Clients müssen diese Erweiterung nicht parsen, um den Status von Zertifikaten in Antworten zu bestimmen.

Diese Erweiterung MUSS (MUST) in der OCSP-Antwort enthalten sein, wenn diese Antwort einen Status "revoked" für ein nicht ausgestelltes Zertifikat enthält. Diese Erweiterung KANN (MAY) in anderen Antworten vorhanden sein, um zu signalisieren, dass der Responder die erweiterte Widerrufsdefinition implementiert. Wenn enthalten, MUSS (MUST) diese Erweiterung in responseExtensions platziert werden, und sie DARF NICHT (MUST NOT) in singleExtensions erscheinen.

Diese Erweiterung wird durch den Objektidentifikator id-pkix-ocsp-extended-revoke identifiziert.

id-pkix-ocsp-extended-revoke OBJECT IDENTIFIER ::= {id-pkix-ocsp 9}

Der Wert der Erweiterung MUSS (SHALL) NULL sein. Diese Erweiterung DARF NICHT (MUST NOT) als kritisch markiert werden.

Letztes Update am