Zum Hauptinhalt springen

4. Details of the Protocol (Protokolldetails)

4. Details of the Protocol (Protokolldetails)​

Die ASN.1-Syntax importiert Begriffe, die in [RFC5280] definiert sind. Zur Signaturberechnung werden die zu signierenden Daten unter Verwendung der ASN.1 distinguished encoding rules (DER) [X.690] kodiert.

ASN.1 EXPLICIT Tagging wird standardmäßig verwendet, sofern nicht anders angegeben.

Die von anderswo importierten Begriffe sind Extensions, CertificateSerialNumber, SubjectPublicKeyInfo, Name, AlgorithmIdentifier und CRLReason.

4.1. Request Syntax (Anfragesyntax)​

Dieser Abschnitt spezifiziert die ASN.1-Spezifikation für eine Bestätigungsanfrage. Die tatsächliche Formatierung der Nachricht könnte variieren, abhängig vom verwendeten Transportmechanismus (HTTP, SMTP, LDAP usw.).

4.1.1. ASN.1 Specification of the OCSP Request (ASN.1-Spezifikation der OCSP-Anfrage)​

Die ASN.1-Struktur, die OCSPRequest entspricht, ist:

OCSPRequest     ::=     SEQUENCE {
    tbsRequest                  TBSRequest,
    optionalSignature   [0]     EXPLICIT Signature OPTIONAL }

TBSRequest      ::=     SEQUENCE {
    version             [0]     EXPLICIT Version DEFAULT v1,
    requestorName       [1]     EXPLICIT GeneralName OPTIONAL,
    requestList                 SEQUENCE OF Request,
    requestExtensions   [2]     EXPLICIT Extensions OPTIONAL }

Signature       ::=     SEQUENCE {
    signatureAlgorithm      AlgorithmIdentifier,
    signature               BIT STRING,
    certs               [0] EXPLICIT SEQUENCE OF Certificate
OPTIONAL}

Version         ::=             INTEGER  {  v1(0) }

Request         ::=     SEQUENCE {
    reqCert                     CertID,
    singleRequestExtensions     [0] EXPLICIT Extensions OPTIONAL }

CertID          ::=     SEQUENCE {
    hashAlgorithm       AlgorithmIdentifier,
    issuerNameHash      OCTET STRING, -- Hash of issuer's DN
    issuerKeyHash       OCTET STRING, -- Hash of issuer's public key
    serialNumber        CertificateSerialNumber }

Die Felder in OCSPRequest haben folgende Bedeutungen:

  • tbsRequest ist die optional signierte OCSP-Anfrage.

  • optionalSignature enthält den Algorithmusidentifikator und alle zugehörigen Algorithmusparameter in signatureAlgorithm; den Signaturwert in signature; und optional Zertifikate, die der Server benötigt, um die signierte Antwort zu verifizieren (normalerweise bis zu, aber nicht einschließlich des Stammzertifikats des Clients).

Der Inhalt von TBSRequest umfasst folgende Felder:

  • version gibt die Version des Protokolls an, die für dieses Dokument v1(0) ist.

  • requestorName ist OPTIONAL und gibt den Namen des OCSP-Anforderers an.

  • requestList enthält eine oder mehrere Einzelzertifikatsstatusanfragen.

  • requestExtensions ist OPTIONAL und enthält Erweiterungen, die auf die in reqCert gefundenen Anfragen anwendbar sind. Siehe Abschnitt 4.4.

Der Inhalt von Request umfasst folgende Felder:

  • reqCert enthält die Kennung eines Zielzertifikats.

  • singleRequestExtensions ist OPTIONAL und enthält Erweiterungen, die auf diese einzelne Zertifikatsstatusanfrage anwendbar sind. Siehe Abschnitt 4.4.

Der Inhalt von CertID umfasst folgende Felder:

  • hashAlgorithm ist der Hash-Algorithmus, der verwendet wird, um die Werte issuerNameHash und issuerKeyHash zu generieren.

  • issuerNameHash ist der Hash des Distinguished Name (DN) des Ausstellers. Der Hash soll über die DER-Kodierung des Namensfelds des Ausstellers im zu prüfenden Zertifikat berechnet werden.

  • issuerKeyHash ist der Hash des öffentlichen Schlüssels des Ausstellers. Der Hash soll über den Wert (unter Ausschluss von Tag und Länge) des Feldes für den öffentlichen Schlüssel des Subjekts im Zertifikat des Ausstellers berechnet werden.

  • serialNumber ist die Seriennummer des Zertifikats, für das der Status angefordert wird.

4.1.2. Notes on OCSP Requests (Hinweise zu OCSP-Anfragen)​

Der Hauptgrund für die Verwendung des Hashs des öffentlichen Schlüssels der CA zusätzlich zum Hash des Namens der CA zur Identifizierung des Ausstellers ist, dass es möglich ist, dass zwei CAs denselben Namen verwenden (Eindeutigkeit im Namen ist eine Empfehlung, die nicht erzwungen werden kann). Zwei CAs werden jedoch niemals denselben öffentlichen Schlüssel haben, es sei denn, die CAs haben sich entweder ausdrücklich dazu entschlossen, ihren privaten Schlüssel zu teilen, oder der Schlüssel einer der CAs wurde kompromittiert.

Die Unterstützung für jede spezifische Erweiterung ist OPTIONAL. Das Critical-Flag SOLLTE NICHT (SHOULD NOT) für eine von ihnen gesetzt werden. Abschnitt 4.4 schlägt mehrere nützliche Erweiterungen vor. Zusätzliche Erweiterungen KÖNNEN (MAY) in zusätzlichen RFCs definiert werden. Nicht erkannte Erweiterungen MÜSSEN (MUST) ignoriert werden (es sei denn, sie haben das Critical-Flag gesetzt und werden nicht verstanden).

Der Anforderer KANN (MAY) wählen, die OCSP-Anfrage zu signieren. In diesem Fall wird die Signatur über die tbsRequest-Struktur berechnet. Wenn die Anfrage signiert ist, MUSS (SHALL) der Anforderer seinen Namen im Feld requestorName angeben. Außerdem KANN (MAY) der Anforderer bei signierten Anfragen Zertifikate, die dem OCSP-Responder helfen, die Signatur des Anforderers zu verifizieren, in das Feld certs von Signature aufnehmen.

4.2. Response Syntax (Antwortsyntax)​

Dieser Abschnitt spezifiziert die ASN.1-Spezifikation für eine Bestätigungsantwort. Die tatsächliche Formatierung der Nachricht könnte variieren, abhängig vom verwendeten Transportmechanismus (HTTP, SMTP, LDAP usw.).

4.2.1. ASN.1 Specification of the OCSP Response (ASN.1-Spezifikation der OCSP-Antwort)​

Eine OCSP-Antwort besteht mindestens aus einem responseStatus-Feld, das den Verarbeitungsstatus der vorherigen Anfrage angibt. Wenn der Wert von responseStatus eine der Fehlerbedingungen ist, wird das responseBytes-Feld nicht gesetzt.

OCSPResponse ::= SEQUENCE {
   responseStatus         OCSPResponseStatus,
   responseBytes          [0] EXPLICIT ResponseBytes OPTIONAL }

OCSPResponseStatus ::= ENUMERATED {
    successful            (0),  -- Response has valid confirmations
    malformedRequest      (1),  -- Illegal confirmation request
    internalError         (2),  -- Internal error in issuer
    tryLater              (3),  -- Try again later
                                -- (4) is not used
    sigRequired           (5),  -- Must sign the request
    unauthorized          (6)   -- Request unauthorized
}

Der Wert für responseBytes besteht aus einem OBJECT IDENTIFIER und einer Antwortsyntax, die durch diese OID identifiziert und als OCTET STRING kodiert ist.

ResponseBytes ::=       SEQUENCE {
    responseType   OBJECT IDENTIFIER,
    response       OCTET STRING }

Für einen grundlegenden OCSP-Responder wird responseType id-pkix-ocsp-basic sein.

id-pkix-ocsp           OBJECT IDENTIFIER ::= { id-ad-ocsp }
id-pkix-ocsp-basic     OBJECT IDENTIFIER ::= { id-pkix-ocsp 1 }

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

Der Wert für response MUSS (SHALL) die DER-Kodierung von BasicOCSPResponse sein.

BasicOCSPResponse       ::= SEQUENCE {
   tbsResponseData      ResponseData,
   signatureAlgorithm   AlgorithmIdentifier,
   signature            BIT STRING,
   certs            [0] EXPLICIT SEQUENCE OF Certificate OPTIONAL }

Der Wert für signature MUSS (SHALL) auf dem Hash der DER-Kodierung von ResponseData berechnet werden. Der Responder KANN (MAY) Zertifikate in das certs-Feld von BasicOCSPResponse aufnehmen, die dem OCSP-Client helfen, die Signatur des Responders zu verifizieren. Wenn keine Zertifikate enthalten sind, SOLLTE (SHOULD) certs fehlen.

ResponseData ::= SEQUENCE {
   version              [0] EXPLICIT Version DEFAULT v1,
   responderID              ResponderID,
   producedAt               GeneralizedTime,
   responses                SEQUENCE OF SingleResponse,
   responseExtensions   [1] EXPLICIT Extensions OPTIONAL }

ResponderID ::= CHOICE {
   byName               [1] Name,
   byKey                [2] KeyHash }

KeyHash ::= OCTET STRING -- SHA-1 hash of responder's public key
(excluding the tag and length fields)

SingleResponse ::= SEQUENCE {
   certID                       CertID,
   certStatus                   CertStatus,
   thisUpdate                   GeneralizedTime,
   nextUpdate         [0]       EXPLICIT GeneralizedTime OPTIONAL,
   singleExtensions   [1]       EXPLICIT Extensions OPTIONAL }

CertStatus ::= CHOICE {
    good        [0]     IMPLICIT NULL,
    revoked     [1]     IMPLICIT RevokedInfo,
    unknown     [2]     IMPLICIT UnknownInfo }

RevokedInfo ::= SEQUENCE {
    revocationTime              GeneralizedTime,
    revocationReason    [0]     EXPLICIT CRLReason OPTIONAL }

UnknownInfo ::= NULL

4.2.2. Notes on OCSP Responses (Hinweise zu OCSP-Antworten)​

4.2.2.1. Time (Zeit)​

Antworten können vier Zeiten enthalten -- thisUpdate, nextUpdate, producedAt und revocationTime. Die Semantik dieser Felder ist in Abschnitt 2.4 definiert. Das Format für GeneralizedTime entspricht der Spezifikation in Abschnitt 4.1.2.5.2 von [RFC5280].

Die Felder thisUpdate und nextUpdate definieren ein empfohlenes Gültigkeitsintervall. Dieses Intervall entspricht dem {thisUpdate, nextUpdate}-Intervall in CRLs. Antworten, deren nextUpdate-Wert früher als der lokale Systemzeitwert ist, SOLLTEN (SHOULD) als unzuverlässig betrachtet werden. Antworten, deren thisUpdate-Zeit später als die lokale Systemzeit ist, SOLLTEN (SHOULD) als unzuverlässig betrachtet werden.

Wenn nextUpdate nicht gesetzt ist, zeigt der Responder an, dass ständig neuere Widerrufsinformationen verfügbar sind.

4.2.2.2. Authorized Responders (Autorisierte Responder)​

Der Schlüssel, der die Statusinformationen eines Zertifikats signiert, muss nicht derselbe Schlüssel sein, der das Zertifikat signiert hat. Es ist jedoch notwendig sicherzustellen, dass die Entität, die diese Informationen signiert, dazu autorisiert ist. Daher MUSS (MUST) der Aussteller eines Zertifikats eines der Folgenden tun:

  • die OCSP-Antworten selbst signieren, oder

  • diese Autorität explizit einer anderen Entität übertragen

Die Delegierung der OCSP-Signatur MUSS (SHALL) durch die Aufnahme von id-kp-OCSPSigning in eine Zertifikatserweiterung für erweiterte Schlüsselverwendung im Zertifikat des OCSP-Antwortunterzeichners gekennzeichnet werden. Dieses Zertifikat MUSS (MUST) direkt von der in der Anfrage identifizierten CA ausgestellt werden.

Die CA SOLLTE (SHOULD) denselben Ausgabeschlüssel verwenden, um ein Delegierungszertifikat auszustellen, wie den, der zum Signieren des auf Widerruf geprüften Zertifikats verwendet wurde. Systeme, die sich auf OCSP-Antworten verlassen, MÜSSEN (MUST) ein Delegierungszertifikat nur dann als von der CA ausgestellt anerkennen, die das fragliche Zertifikat ausgestellt hat, wenn das Delegierungszertifikat und das auf Widerruf geprüfte Zertifikat mit demselben Schlüssel signiert wurden.

Hinweis: Aus Gründen der Abwärtskompatibilität mit RFC 2560 [RFC2560] ist es nicht verboten, ein Zertifikat für einen Authorized Responder unter Verwendung eines anderen Ausgabeschlüssels auszustellen als dem Schlüssel, der zum Ausstellen des auf Widerruf geprüften Zertifikats verwendet wurde. Eine solche Praxis wird jedoch dringend abgeraten, da Clients nicht verpflichtet sind, einen Responder mit einem solchen Zertifikat als Authorized Responder anzuerkennen.

id-kp-OCSPSigning OBJECT IDENTIFIER ::= {id-kp 9}

Systeme oder Anwendungen, die sich auf OCSP-Antworten verlassen, MÜSSEN (MUST) in der Lage sein, die Verwendung des Wertes id-kp-OCSPSigning wie oben beschrieben zu erkennen und durchzusetzen. Sie KÖNNEN (MAY) Mittel bereitstellen, um lokal eine oder mehrere OCSP-Signaturautoritäten zu konfigurieren und den Satz von CAs anzugeben, für die jede Signaturautorität vertrauenswürdig ist. Sie MÜSSEN (MUST) die Antwort ablehnen, wenn das zur Validierung der Signatur auf der Antwort erforderliche Zertifikat nicht mindestens eines der folgenden Kriterien erfüllt:

  1. Entspricht einer lokalen Konfiguration der OCSP-Signaturautorität für das fragliche Zertifikat, oder

  2. Ist das Zertifikat der CA, die das fragliche Zertifikat ausgestellt hat, oder

  3. Enthält einen Wert von id-kp-OCSPSigning in einer Erweiterung für erweiterte Schlüsselverwendung und wird von der CA ausgestellt, die das fragliche Zertifikat wie oben angegeben ausgestellt hat.

Zusätzliche Annahme- oder Ablehnungskriterien können entweder auf die Antwort selbst oder auf das zur Validierung der Signatur auf der Antwort verwendete Zertifikat angewendet werden.

4.2.2.2.1. Revocation Checking of an Authorized Responder (Widerrufsprüfung eines autorisierten Responders)​

Da ein autorisierter OCSP-Responder Statusinformationen für eine oder mehrere CAs bereitstellt, müssen OCSP-Clients wissen, wie sie überprüfen können, dass das Zertifikat eines Authorized Responders nicht widerrufen wurde. CAs können wählen, dieses Problem auf eine von drei Arten zu behandeln:

  • Eine CA kann festlegen, dass ein OCSP-Client einem Responder für die Lebensdauer des Responder-Zertifikats vertrauen kann. Die CA tut dies durch Aufnahme der Erweiterung id-pkix-ocsp-nocheck. Dies SOLLTE (SHOULD) eine nicht kritische Erweiterung sein. Der Wert der Erweiterung MUSS (SHALL) NULL sein. CAs, die ein solches Zertifikat ausstellen, sollten sich darüber im Klaren sein, dass eine Kompromittierung des Schlüssels des Responders genauso schwerwiegend ist wie die Kompromittierung eines CA-Schlüssels, der zum Signieren von CRLs verwendet wird, zumindest für die Gültigkeitsdauer dieses Zertifikats. CAs können wählen, diesen Zertifikatstyp mit einer sehr kurzen Lebensdauer auszustellen und ihn häufig zu erneuern.
id-pkix-ocsp-nocheck OBJECT IDENTIFIER ::= { id-pkix-ocsp 5 }

  • Eine CA kann festlegen, wie das Zertifikat des Responders auf Widerruf geprüft werden soll. Dies kann unter Verwendung von CRL-Verteilungspunkten erfolgen, wenn die Prüfung mit CRLs durchgeführt werden soll, oder unter Verwendung des Behördeninformationszugriffs (Authority Information Access), wenn die Prüfung auf andere Weise durchgeführt werden soll. Details zur Spezifikation eines dieser beiden Mechanismen sind in [RFC5280] verfügbar.

  • Eine CA kann wählen, keine Methode zur Widerrufsprüfung für das Zertifikat des Responders festzulegen; in diesem Fall obliegt es der lokalen Sicherheitsrichtlinie des OCSP-Clients, zu entscheiden, ob dieses Zertifikat auf Widerruf geprüft werden soll oder nicht.

4.2.2.3. Basic Response (Basisantwort)​

Der Basisantworttyp enthält:

  • die Version der Antwortsyntax, die für diese Version der Basisantwortsyntax v1 (Wert ist 0) sein MUSS (MUST);

  • entweder den Namen des Responders oder einen Hash des öffentlichen Schlüssels des Responders als ResponderID;

  • den Zeitpunkt, zu dem die Antwort generiert wurde;

  • Antworten für jedes der Zertifikate in einer Anfrage;

  • optionale Erweiterungen;

  • eine Signatur, die über einen Hash der Antwort berechnet wurde; und

  • die Signaturalgorithmus-OID.

Der Zweck der ResponderID-Informationen besteht darin, Clients das Auffinden des Zertifikats zu ermöglichen, das zum Signieren einer signierten OCSP-Antwort verwendet wurde. Daher MÜSSEN (MUST) die Informationen dem Zertifikat entsprechen, das zum Signieren der Antwort verwendet wurde.

Der Responder KANN (MAY) Zertifikate in das certs-Feld von BasicOCSPResponse aufnehmen, die dem OCSP-Client helfen, die Signatur des Responders zu verifizieren.

Die Antwort für jedes der Zertifikate in einer Anfrage besteht aus:

  • einer Kennung des Zertifikats, für das Widerrufsstatusinformationen bereitgestellt werden (d. h. das Zielzertifikat);

  • dem Widerrufsstatus des Zertifikats (good, revoked oder unknown); wenn revoked (widerrufen), gibt dies den Zeitpunkt an, zu dem das Zertifikat widerrufen wurde, und optional den Grund, warum es widerrufen wurde;

  • dem Gültigkeitsintervall der Antwort; und

  • optionalen Erweiterungen.

Die Antwort MUSS (MUST) für jedes Zertifikat in der Anfrage eine SingleResponse enthalten. Die Antwort SOLLTE KEINE (SHOULD NOT) zusätzlichen SingleResponse-Elemente enthalten, aber beispielsweise könnten OCSP-Responder, die Statusantworten vorgenerieren, zusätzliche SingleResponse-Elemente enthalten, wenn dies erforderlich ist, um die Leistung der Antwortvorgenerierung oder die Cache-Effizienz zu verbessern (gemäß [RFC5019], Abschnitt 2.2.1).

4.3. Mandatory and Optional Cryptographic Algorithms (Obligatorische und optionale kryptografische Algorithmen)​

Clients, die OCSP-Dienste anfordern, MÜSSEN (SHALL) in der Lage sein, Antworten zu verarbeiten, die mit RSA mit SHA-256 (identifiziert durch die in [RFC4055] spezifizierte sha256WithRSAEncryption-OID) signiert sind. Clients SOLLTEN (SHOULD) auch in der Lage sein, Antworten zu verarbeiten, die mit RSA mit SHA-1 (identifiziert durch die in [RFC3279] spezifizierte sha1WithRSAEncryption-OID) und dem Digital Signature Algorithm (DSA) mit SHA-1 (identifiziert durch die in [RFC3279] spezifizierte id-dsa-with-sha1-OID) signiert sind. Clients KÖNNEN (MAY) andere Algorithmen unterstützen.

Letztes Update am