前のページ 目次 次のページ

最終更新日：2002年12月12日

4.3  OCSP モデル

4.3.1  OCSP 概要

OCSP は、オンラインで証明書の失効情報を確認するためのプロトコルであり、RFC2560 に規定されています。証明書利用者（OCSP リクエスタ）は、OCSP レスポンダ（OCSP サーバーとも呼ばれる）に失効情報を問い合わせます。OCSP レスポンダは、問い合わせに対して証明書の状態 について、有効(good)、失効(revoked)、不明(unknown) のいずれかとして返します(図 4-9)。

CA は、OCSP レスポンダの信頼性を保証するために、OCSP レスポンダに対して、証明書を発行します。OCSP レスポンダは、発行された証明書を用いて、証明書利用者への OCSP の応答に電子署名を付与します。

利用者に OCSP レスポンダの場所を通知するために、OCSP レスポンダのアドレスが、証明書の拡張領域の認証機関アクセス情報 (AIA: Authority Information Access) に URI 形式で記載されます。

証明書利用者と OCSP レスポンダ間の通信はリアルタイムで行われますが、必ずしも問い合わせ時点での失効情報が得られるとは限りません。RFC2560 においては OCSP レスポンダが CA から失効情報を取得する方法は規定されていませんが、実際には CRL、CRT、OCSP などが使用されています。仮に、OCSP レスポンダが CRL を用いて失効情報を取得する場合は、失効情報の更新周期は CRL の更新周期と同じになります。

図 4-9 OCSP 概要

4.3.2  要求と応答

OCSP リクエスタと OCSP レスポンダ間で用いる伝送レイヤについての規定は無く、HTTP、SMTP、LDAP などが使われます。OCSP は、OCSP リクエスタから OCSP レスポンダに証明書の失効情報を問い合わせる要求 (OCSPRequest) と、OCSP レスポンダからの失効情報の回答である応答(OCSPResponse) から構成されます。

OCSP リクエスタからの要求では、失効情報を確認したい証明書の一覧を指定します。要求には OCSP リクエスタの名前や署名を付与することもできます(図 4-10)。

図 4-10 OCSP 要求フォーマット概要

以下に、OCSP 要求フォーマットの詳細を示します(表 4-9)。

表 4-9 OCSP 要求フォーマット

項目

説明

tbsRequest

(署名前要求)

要求の署名対象箇所です。

　

version

(バージョン)

OCSP リクエストのバージョンを示します。

requestorName

(要求者名)

OCSP 要求の送信者 (OCSP リクエスタ) の名前を指定します。
このフィールドは省略可能です。

requestList

(要求リスト)

失効情報を確認したい証明書の一覧です。
詳細は、表 4-10 に示します。

requestExtensions

(要求拡張)

要求の拡張領域です。

optionalSignature

(付加署名)

OCSP 要求に付与する署名データです。
このフィールドは省略可能です。

　

signatureAlgorithm

(署名アルゴリズム)

署名に使用するアルゴリズムの OID を指定します。

signature

(署名)

署名前要求 (tbsRequest) に付与する OCSP リクエスタの電子署名です。

certs

(証明書)

署名の検証に使用する証明書です。
複数指定することが可能です。

失効情報を問い合わせる証明書の一覧は、要求リスト(requestList)に含まれます。要求リスト (requestList) は、要求 (Request) のリストから構成されます(表 4-10)。

要求 (Request) では、対象となる証明書を特定するために、「証明書のシリアル番号」、「証明書発行者のDNのハッシュ値」、「証明書発行者の公開鍵のハッシュ値」を指定します。

表 4-10 Request (要求)

項目

説明

reqCert

(要求証明書)

失効情報を問い合わせる証明書を指定します。

　

hashAlgorithm

(ハッシュアルゴリズム)

IssuerNameHash、issuerKeyHash で使用するハッシュアルゴリズムを OIDで指定します。

issuerNameHash

(発行者名ハッシュ)

証明書発行者名のハッシュ値を指定します。

issuerKeyHash

(発行者鍵ハッシュ)

証明書発行者の公開鍵のハッシュ値を指定します。

serialNumber

(シリアル番号)

証明書のシリアル番号を指定します。

singleRequestExtensions

(シングル要求拡張)

要求に対する拡張領域です。

OCSP レスポンダは、OCSP リクエスタからの問い合わせに対して、有効(good)、失効(revoked)、不明(unknown) のいずれかの証明書の状態を返します。応答には、改ざんを防止するために OCSP レスポンダの署名が付与されます。また、クライアントが署名を検証できるように OCSP レスポンダの証明書が付与されます(図 4-11)。

図 4-11 OCSP 応答フォーマット概要

以下に、OCSP 応答の詳細を示します(表 4-11)。

表 4-11 OCSPResponse (OCSP 応答)

項目

説明

responseStatus

(応答ステータス)

OCSP レスポンダの処理結果を示します。

responseBytes

(応答バイト)

応答メッセージ全体を示します。

　

responseType

(応答タイプ)

応答メッセージの種類を示します。

response

(応答)

応答メッセージ。
応答タイプ (responseType) で指定したデータをOCTET STRING 形式に変換したものです。
表 4-12 を参照。

応答バイト (responseBytes) 内の応答 (response) には、応答タイプ (responseType) で指定したデータを OCTET STRING 形式に変換した値が記載されます。RFC2560 においては、応答タイプとしてBasicOCSPResponse のみが定義されています。

表 4-12 BasicOCSPResponse (基本 OCSP 応答)

項目

説明

tbsResponseData

(署名前応答データ)

応答データの署名対象箇所です。

　

version

(バージョン)

OCSP のバージョンを示します。

responderID

(レスポンダID)

OCSP サーバーの ID を示します。レスポンダの X.500 識別名、もしくはレスポンダの公開鍵のハッシュ値を使用します。

producesAt

(生成時刻)

OCSP 応答を生成した時刻を表します。

responses

(応答)

各証明書の状態を表します。

SingleResponse (表 4-13) のリストで構成されます。

responseExtensions

(応答拡張)

応答の拡張領域です。

signatureAlgorithm

(署名アルゴリズム)

署名に使用するアルゴリズムのOIDを指定します。

signature

(署名)

署名前応答データ (tbsResponseData) に対する OCSP レスポンダのデジタル署名です。

certs

(証明書)

署名の検証に使用する証明書です。複数指定することが可能です。

以下に、SingleResponse の構成を示します。

表 4-13 SingleResponse (シングル応答)

項目

説明

certID (証明書ID)

失効情報を示す証明書を指定します。リクエスト (表 4-10) のreqCert と同様のフォーマットです。

　

hashAlgorithm

(ハッシュアルゴリズム)

issuerNameHash、issuerKeyHash で使用するハッシュアルゴリズムをOIDで指定します。

issuerNameHash

(発行者名ハッシュ)

証明書発行者名のハッシュ値を指定します。

issuerKeyHash

(発行者鍵ハッシュ)

証明書発行者の公開鍵のハッシュ値を指定します。

serialNumber

(シリアル番号)

証明書のシリアル番号を指定します。

certStatus

(証明書ステータス)

証明書の失効状態を示します。有効 (good)、失効 (revoked)、不明 (unknown) のいずれかの値を取ります。失効 (revoked)の場合は、失効日時と失効理由も示します。

thisUpdate

(今回更新日時)

OCSP レスポンダが証明書の状態を確認した日時を表します。

nextUpdate

(次回更新日時)

OCSP レスポンダが、次に証明書の状態を確認する日時を表します。このフィールドは省略可能です。

singleExtensions

(シングル拡張)

個々の応答に対する拡張領域です。

4.3.3  拡張領域

OCSP の要求と応答には、拡張領域を含めることができます(表 4-14)。

拡張領域は X.509v3 証明書の拡張領域と同様のフォーマットですが、全ての項目においてクリティカル (Critical) は FALSE に設定します。

表 4-14 OCSP エクステンション

項目

説明

Nonce

(ノンス)

悪意のある第三者によるリプレイ攻撃を防止するために、リクエストとレスポンスに同じ乱数を設定します。
requestExtensions と responseExtensions で使用します。

CrlID

(CRL 参照)

証明書の CRL が存在する場所 (URL、CRL 番号、生成時間) を示します。singleExtensions で使用します。

AcceptableResponses

(応答)

OCSP リクエスタが理解できる OCSP レスポンスの型 (OID) を指定します。requestExtensions で使用します。

ArchiveCutoff

(記録終止)

有効期限切れの証明書の失効情報を問い合わせの時点から起算して過去何年分保持しているかを指定します。
singleExtensions で使用します。

CRLEntryExtensions

(CRLエントリ拡張)

CRL エントリ拡張 (表 4-5) を指定することができます。

singleExtensions で使用します。

ServiceLocator

(サービスロケータ)

他のOCSP サーバーに問い合わせを行う場合、そのサーバーの名前を指定します。
singleRequestExtensions で使用します。

4.3.4  今後の拡張

OCSP を用いると、CRL による有効性検証の処理を証明書利用者が行わなくてよいというメリットがあります。しかし、OCSP は証明書が失効されているかどうかを確認するだけであり、証明書の有効性を検証するための証明書のパス構築と検証は、証明書利用者が実施しなければなりません。これらの処理は証明書利用者にとって、負荷のかかるものとなります。そこで、サーバー側で失効状態の確認だけでなく、証明書のパス構築と検証までを行う方式が IETF に おいて検討されています。

現在 (2002年 3月) においては、以下の 2種類のドラフトが提出されています。

(1)  DPD + DPV

OCSP を拡張し、証明書パス構築 (DPD： Delegated Path Discovery)と証明書パス検証 (DPV： Delegated Path Validation) を連携させる。

(2)  SCVP

シンプル証明書検証プロトコル (SCVP： Simple Certificate Validation Protocol) を使用する。

IETF においては、同じような標準を 2つ定めないことになっているので、この 2種類のどちらかの方式が採用されると考えられます。

前のページ 目次 次のページ Copyright © 2002 Information-technology Promotion Agency, Japan. All rights reserved.