メインコンテンツまでスキップ

4. Details of the Protocol (プロトコルの詳細)

4. Details of the Protocol (プロトコルの詳細)​

ASN.1 構文は [RFC5280] で定義された用語をインポートする。署名の計算のために、署名されるデータは ASN.1 distinguished encoding rules (DER) [X.690] を使用してエンコードされる。

特に指定がない限り、ASN.1 EXPLICIT タグ付けがデフォルトとして使用される。

他の場所からインポートされる用語は、Extensions、CertificateSerialNumber、SubjectPublicKeyInfo、Name、AlgorithmIdentifier、および CRLReason である。

4.1. Request Syntax (リクエスト構文)​

本セクションでは、確認リクエストの ASN.1 仕様を指定する。メッセージの実際のフォーマットは、使用されるトランスポートメカニズム (HTTP、SMTP、LDAP など) によって異なる場合がある。

4.1.1. ASN.1 Specification of the OCSP Request (OCSP リクエストの ASN.1 仕様)​

OCSPRequest に対応する ASN.1 構造は以下のとおりである：

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 }

OCSPRequest のフィールドには以下の意味がある：

  • tbsRequest は、オプションで署名された OCSP リクエストである。

  • optionalSignature には、アルゴリズム識別子および signatureAlgorithm 内の関連するアルゴリズムパラメータ、signature 内の署名値、およびオプションでサーバーが署名付き応答を検証するために必要な証明書 (通常はクライアントのルート証明書まで含まれるが、ルート証明書は含まれない) が含まれる。

TBSRequest の内容には以下のフィールドが含まれる：

  • version はプロトコルのバージョンを示し、本書では v1(0) である。

  • requestorName は OPTIONAL であり、OCSP リクエスタの名前を示す。

  • requestList には、1 つ以上の単一の証明書ステータスリクエストが含まれる。

  • requestExtensions は OPTIONAL であり、reqCert にあるリクエストに適用可能な拡張機能が含まれる。セクション 4.4 を参照。

Request の内容には以下のフィールドが含まれる：

  • reqCert には、ターゲット証明書の識別子が含まれる。

  • singleRequestExtensions は OPTIONAL であり、この単一の証明書ステータスリクエストに適用可能な拡張機能が含まれる。セクション 4.4 を参照。

CertID の内容には以下のフィールドが含まれる：

  • hashAlgorithm は、issuerNameHash および issuerKeyHash 値の生成に使用されるハッシュアルゴリズムである。

  • issuerNameHash は、発行者の識別名 (DN) のハッシュである。ハッシュは、チェックされる証明書の発行者名フィールドの DER エンコードに対して計算されるものとする。

  • issuerKeyHash は、発行者の公開鍵のハッシュである。ハッシュは、発行者の証明書のサブジェクト公開鍵フィールドの値 (タグと長さを除く) に対して計算されるものとする。

  • serialNumber は、ステータスがリクエストされている証明書のシリアル番号である。

4.1.2. Notes on OCSP Requests (OCSP リクエストに関する注記)​

発行者を識別するために CA の名前のハッシュに加えて CA の公開鍵のハッシュを使用する主な理由は、2 つの CA が同じ名前を使用することを選択する可能性があるためである (名前の一意性は強制できない推奨事項である)。ただし、CA が秘密鍵を共有することを明示的に決定した場合、または CA のいずれかの鍵が侵害された場合を除き、2 つの CA が同じ公開鍵を持つことはない。

特定の拡張機能のサポートは OPTIONAL である。それらのいずれに対しても critical フラグを設定すべきではない (SHOULD NOT)。セクション 4.4 では、いくつかの有用な拡張機能を提案している。追加の拡張機能は、追加の RFC で定義されてもよい (MAY)。認識されない拡張機能は無視されなければならない (MUST) (critical フラグが設定されていて理解できない場合を除く)。

リクエスタは、OCSP リクエストに署名することを選択してもよい (MAY)。その場合、署名は tbsRequest 構造に対して計算される。リクエストが署名されている場合、リクエスタは requestorName フィールドにその名前を指定しなければならない (SHALL)。また、署名されたリクエストの場合、リクエスタは Signature の certs フィールドに、OCSP レスポンダがリクエスタの署名を検証するのに役立つ証明書を含めてもよい (MAY)。

4.2. Response Syntax (応答構文)​

本セクションでは、確認応答の ASN.1 仕様を指定する。メッセージの実際のフォーマットは、使用されるトランスポートメカニズム (HTTP、SMTP、LDAP など) によって異なる場合がある。

4.2.1. ASN.1 Specification of the OCSP Response (OCSP 応答の ASN.1 仕様)​

OCSP 応答は、少なくとも、前のリクエストの処理ステータスを示す responseStatus フィールドで構成される。responseStatus の値がエラー条件の 1 つである場合、responseBytes フィールドは設定されない。

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
}

responseBytes の値は、OBJECT IDENTIFIER と、その OID によって識別され、OCTET STRING としてエンコードされた応答構文で構成される。

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

基本的な OCSP レスポンダの場合、responseType は id-pkix-ocsp-basic になる。

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

OCSP レスポンダは、id-pkix-ocsp-basic 応答タイプの応答を生成できなければならない (SHALL)。これに対応して、OCSP クライアントは、id-pkix-ocsp-basic 応答タイプの応答を受信および処理できなければならない (SHALL)。

response の値は、BasicOCSPResponse の DER エンコードでなければならない (SHALL)。

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

signature の値は、ResponseData の DER エンコードのハッシュに対して計算されなければならない (SHALL)。レスポンダは、OCSP クライアントがレスポンダの署名を検証するのに役立つ証明書を BasicOCSPResponse の certs フィールドに含めてもよい (MAY)。証明書が含まれていない場合、certs は不在であるべきである (SHOULD)。

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 (OCSP 応答に関する注記)​

4.2.2.1. Time (時間)​

応答には、thisUpdate、nextUpdate、producedAt、および revocationTime の 4 つの時刻を含めることができる。これらのフィールドのセマンティクスはセクション 2.4 で定義されている。GeneralizedTime のフォーマットは [RFC5280] のセクション 4.1.2.5.2 で指定されているとおりである。

thisUpdate および nextUpdate フィールドは、推奨される有効期間を定義する。この間隔は CRL の {thisUpdate, nextUpdate} 間隔に対応する。nextUpdate 値がローカルシステム時刻値よりも早い応答は、信頼できないと見なされるべきである (SHOULD)。thisUpdate 時刻がローカルシステム時刻よりも遅い応答は、信頼できないと見なされるべきである (SHOULD)。

nextUpdate が設定されていない場合、レスポンダは常に新しい失効情報が利用可能であることを示している。

4.2.2.2. Authorized Responders (認可されたレスポンダ)​

証明書のステータス情報に署名する鍵は、証明書に署名した鍵と同じである必要はない。ただし、この情報に署名するエンティティがそうする権限を与えられていることを確認する必要がある。したがって、証明書の発行者は、次のいずれかを行わなければならない (MUST)：

  • OCSP 応答にそれ自体で署名する、または

  • この権限を別のエンティティに明示的に指定する

OCSP 署名の委任は、OCSP 応答署名者の証明書に含まれる extended key usage (拡張鍵使用法) 証明書拡張に id-kp-OCSPSigning を含めることによって指定されなければならない (SHALL)。この証明書は、リクエストで識別された CA によって直接発行されなければならない (MUST)。

CA は、委任証明書の発行に、失効チェック対象の証明書の署名に使用したのと同じ発行鍵を使用すべきである (SHOULD)。OCSP 応答に依存するシステムは、委任証明書と失効チェック対象の証明書が同じ鍵で署名されている場合にのみ、委任証明書が問題の証明書を発行した CA によって発行されたものであると認識しなければならない (MUST)。

注：RFC 2560 [RFC2560] との後方互換性のために、失効チェック対象の証明書を発行するために使用された鍵とは異なる発行鍵を使用して Authorized Responder の証明書を発行することは禁止されていない。ただし、クライアントはそのような証明書を持つレスポンダを Authorized Responder として認識する必要がないため、このような慣行は強く推奨されない。

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

OCSP 応答に依存するシステムまたはアプリケーションは、上記のように id-kp-OCSPSigning 値の使用を検出し、強制する機能を持っていなければならない (MUST)。これらは、1 つ以上の OCSP 署名機関をローカルに構成し、各署名機関が信頼される CA のセットを指定する手段を提供してもよい (MAY)。応答の署名を検証するために必要な証明書が、以下の基準の少なくとも 1 つを満たさない場合、それらは応答を拒否しなければならない (MUST)：

  1. 問題の証明書の OCSP 署名機関のローカル構成と一致する、または

  2. 問題の証明書を発行した CA の証明書である、または

  3. 拡張鍵使用法拡張に id-kp-OCSPSigning の値が含まれており、上記のように問題の証明書を発行した CA によって発行されている。

応答自体または応答の署名を検証するために使用される証明書に、追加の受け入れまたは拒否の基準が適用される場合がある。

4.2.2.2.1. Revocation Checking of an Authorized Responder (認可されたレスポンダの失効チェック)​

許可された OCSP レスポンダは 1 つ以上の CA のステータス情報を提供するため、OCSP クライアントは、Authorized Responder の証明書が失効していないことを確認する方法を知る必要がある。CA は、次の 3 つの方法のいずれかでこの問題に対処することを選択できる：

  • CA は、OCSP クライアントがレスポンダの証明書の有効期間中レスポンダを信頼できることを指定する場合がある。CA は、拡張機能 id-pkix-ocsp-nocheck を含めることによってこれを行う。これは非クリティカル拡張であるべきである (SHOULD)。拡張機能の値は NULL でなければならない (SHALL)。このような証明書を発行する CA は、レスポンダの鍵の侵害は、少なくともこの証明書の有効期間中は、CRL の署名に使用される CA 鍵の侵害と同じくらい深刻であることを認識すべきである。CA は、このタイプの証明書を非常に短い有効期間で発行し、頻繁に更新することを選択する場合がある。
id-pkix-ocsp-nocheck OBJECT IDENTIFIER ::= { id-pkix-ocsp 5 }

  • CA は、レスポンダの証明書の失効チェック方法を指定する場合がある。これは、チェックを CRL を使用して行う必要がある場合は CRL 配布ポイントを使用することによって、またはチェックを他の方法で行う必要がある場合は Authority Information Access (認証局情報アクセス) を使用することによって行うことができる。これら 2 つのメカニズムのいずれかを指定するための詳細は、[RFC5280] で入手できる。

  • CA は、レスポンダの証明書の失効確認方法を指定しないことを選択する場合がある。その場合、その証明書の失効確認を行うかどうかを決定するのは OCSP クライアントのローカルセキュリティポリシー次第となる。

4.2.2.3. Basic Response (基本応答)​

基本応答タイプには以下が含まれる：

  • 応答構文のバージョン。このバージョンの基本応答構文の場合は、v1 (値は 0) でなければならない (MUST)。

  • ResponderID としてのレスポンダの名前またはレスポンダの公開鍵のハッシュのいずれか。

  • 応答が生成された時刻。

  • リクエスト内の各証明書の応答。

  • オプションの拡張。

  • 応答のハッシュ全体で計算された署名。そして

  • 署名アルゴリズム OID。

ResponderID 情報の目的は、クライアントが署名付き OCSP 応答の署名に使用された証明書を見つけられるようにすることである。したがって、情報は応答の署名に使用された証明書に対応していなければならない (MUST)。

レスポンダは、OCSP クライアントがレスポンダの署名を検証するのに役立つ証明書を BasicOCSPResponse の certs フィールドに含めてもよい (MAY)。

リクエスト内の各証明書の応答は以下で構成される：

  • 失効ステータス情報が提供されている証明書の識別子 (つまり、ターゲット証明書)。

  • 証明書の失効ステータス (good, revoked, または unknown)。revoked の場合、証明書が失効した時刻と、オプションで失効した理由を示す。

  • 応答の有効期間。そして

  • オプションの拡張。

応答には、リクエスト内の各証明書に対して 1 つの SingleResponse を含めなければならない (MUST)。応答には追加の SingleResponse 要素を含めるべきではない (SHOULD NOT) が、たとえば、ステータス応答を事前に生成する OCSP レスポンダは、応答の事前生成パフォーマンスまたはキャッシュ効率を向上させるために必要であれば ([RFC5019] セクション 2.2.1 に従って) 追加の SingleResponse 要素を含める場合がある。

4.3. Mandatory and Optional Cryptographic Algorithms (必須およびオプションの暗号化アルゴリズム)​

OCSP サービスを要求するクライアントは、RSA と SHA-256 ([RFC4055] で指定された sha256WithRSAEncryption OID で識別) を使用して署名された応答を処理できなければならない (SHALL)。クライアントは、RSA と SHA-1 ([RFC3279] で指定された sha1WithRSAEncryption OID で識別) およびデジタル署名アルゴリズム (DSA) と SHA-1 ([RFC3279] で指定された id-dsa-with-sha1 OID で識別) を使用して署名された応答も処理できるべきである (SHOULD)。クライアントは他のアルゴリズムをサポートしてもよい (MAY)。

に最終更新