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

4.4. Extensions (拡張機能)

4.4. Extensions (拡張機能)​

本セクションでは、X.509 バージョン 3 証明書で採用されている拡張モデル ( [RFC5280] 参照) に基づいて、いくつかの標準的な拡張機能を定義する。すべての拡張機能のサポートは、クライアントとレスポンダの両方にとってオプションである。各拡張機能について、定義はその構文、OCSP レスポンダによって実行される処理、および対応する応答に含まれる拡張機能を示す。

4.4.1. Nonce (ナンス)​

Nonce (ナンス) は、リプレイ攻撃を防ぐためにリクエストと応答を暗号的にバインドする。Nonce はリクエストの requestExtensions の 1 つとして含まれるが、応答では responseExtensions の 1 つとして含まれる。リクエストと応答の両方で、Nonce はオブジェクト識別子 id-pkix-ocsp-nonce によって識別され、extnValue は Nonce の値である。

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 参照)​

OCSP レスポンダにとって、失効した証明書または onHold (保留中) の証明書が見つかった CRL を示すことが望ましい場合がある。これは、OCSP がリポジトリ間で使用される場合や、監査メカニズムとしても役立つ。CRL は、URL (CRL が利用可能な URL)、番号 (CRL 番号)、または時刻 (関連する CRL が作成された時刻) で指定できる。これらの拡張機能は、singleExtensions として指定される。この拡張機能の識別子は id-pkix-ocsp-crl であり、値は CrlID である。

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 }

選択肢 crlUrl の場合、IA5String は CRL が利用可能な URL を指定する。crlNum の場合、INTEGER は関連する CRL の CRL 番号拡張の値を指定する。crlTime の場合、GeneralizedTime は関連する CRL が発行された時刻を示す。

4.4.3. Acceptable Response Types (許容される応答タイプ)​

OCSP クライアントは、理解できる応答タイプを指定したい場合がある (MAY)。そうするために、クライアントは OID id-pkix-ocsp-response と値 AcceptableResponses を持つ拡張機能を使用すべきである (SHOULD)。この拡張機能は、リクエストの requestExtensions の 1 つとして含まれる。AcceptableResponses に含まれる OID は、このクライアントが受け入れることができるさまざまな応答タイプの OID (たとえば、id-pkix-ocsp-basic) である。

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

AcceptableResponses ::= SEQUENCE OF OBJECT IDENTIFIER

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

4.4.4. Archive Cutoff (アーカイブカットオフ)​

OCSP レスポンダは、証明書の有効期限を超えて失効情報を保持することを選択してもよい (MAY)。応答内の producedAt 時刻からこの保持期間の値を差し引くことによって得られた日付は、証明書の「archive cutoff (アーカイブカットオフ)」日付として定義される。

OCSP 対応アプリケーションは、署名を検証するために必要な証明書の有効期限がずっと前に切れていたとしても、デジタル署名が作成された日付に信頼できた (または信頼できなかった) という証明に貢献するために、OCSP アーカイブカットオフ日付を使用するだろう。

このような履歴参照のサポートを提供する OCSP サーバーは、応答にアーカイブカットオフ日付拡張を含めるべきである (SHOULD)。含まれる場合、この値は id-pkix-ocsp-archive-cutoff によって識別され、構文 GeneralizedTime を持つ OCSP singleExtensions 拡張として提供されなければならない (SHALL)。

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

ArchiveCutoff ::= GeneralizedTime

例として、サーバーが 7 年間の保持間隔ポリシーで運用され、ステータスが時刻 t1 に生成された場合、応答内の ArchiveCutoff の値は (t1 - 7 年) になる。

4.4.5. CRL Entry Extensions (CRL エントリ拡張)​

CRL エントリ拡張として指定されたすべての拡張機能 ([RFC5280] のセクション 5.3) も、singleExtensions としてサポートされる。

4.4.6. Service Locator (サービスロケータ)​

OCSP サーバーは、サーバーがリクエストを受信し、識別された証明書に対して権限があることがわかっている OCSP サーバーにルーティングするモードで運用される場合がある。serviceLocator リクエスト拡張はこの目的のために定義されている。この拡張機能は、リクエストの singleRequestExtensions の 1 つとして含まれる。

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

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

これらのフィールドの値は、サブジェクト証明書の対応するフィールドから取得される。

4.4.7. Preferred Signature Algorithms (優先署名アルゴリズム)​

実装が必須のアルゴリズム以外のアルゴリズムが許可されており、クライアントには現在そのアルゴリズムの好みを示すメカニズムがないため、必須ではないアルゴリズムを選択するサーバーが、クライアントがサポートしない可能性のある応答を生成するリスクが常に存在する。

OCSP レスポンダは、アルゴリズム選択のルール (たとえば、CRL や証明書の署名に CA が採用している署名アルゴリズムを使用するなど) を適用する場合があるが、そのようなルールは一般的な状況で失敗する可能性がある：

  • CRL や証明書の署名に使用されるアルゴリズムが、応答を署名するために OCSP レスポンダによって使用されている鍵ペアと一致しない場合がある。

  • 未知の証明書に対するリクエストは、レスポンダが複数のアルゴリズムオプションから選択するための根拠を提供しない。

最後の基準は、プロトコルを変更せずに RFC 2560 [RFC2560] プロトコルを使用した帯域内シグナリングから得られる情報を通じて解決することはできない。

さらに、OCSP レスポンダは、2 つの理由から、CA が証明書や CRL の署名に使用するアルゴリズムとは異なる署名アルゴリズムを採用したい場合がある：

  • レスポンダは、証明書自体の署名よりも計算上の要求が少ないアルゴリズムを証明書ステータス応答に採用する場合がある。

  • 実装は、2 つの別々の署名アルゴリズムを採用することによって、署名アルゴリズムの侵害によって生じる侵害の可能性を防ぎたい場合がある。

本セクションでは以下について説明する：

  • クライアントが優先署名アルゴリズムのセットを示すことを可能にする拡張機能。

  • サポートされている優先アルゴリズムが指定されていない場合に、正常な操作の確率を最大化する署名アルゴリズム選択ルール。

4.4.7.1. Extension Syntax (拡張構文)​

クライアントは、OCSPRequest の requestExtensions に優先署名アルゴリズム拡張を含めることにより、リクエストで優先アルゴリズムのセットを宣言してもよい (MAY)。

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

PreferredSignatureAlgorithms ::= SEQUENCE OF
                                 PreferredSignatureAlgorithm

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

AlgorithmIdentifier の構文は、RFC 5280 [RFC5280] のセクション 4.1.1.2 で定義されている。SMIMECapability の構文は、RFC 5751 [RFC5751] で定義されている。

sigIdentifier は、クライアントが優先する署名アルゴリズム (たとえば、algorithm=ecdsa-with-sha256) を指定する。パラメータは、最も一般的な署名アルゴリズムには存在しない。

pubKeyAlgIdentifier は、OCSP 応答を検証するために使用されるサーバーの証明書でクライアントが優先するサブジェクト公開鍵アルゴリズム識別子 (たとえば、algorithm=id-ecPublicKey および parameters= secp256r1) を指定する。

pubKeyAlgIdentifier は OPTIONAL であり、特定のアルゴリズムのさまざまな使用法を区別するために必要なパラメータを指定する手段を提供する (たとえば、特定の楕円曲線アルゴリズムに対してどの曲線をサポートするかをクライアントが指定するために使用される場合がある)。

クライアントは、指定された優先署名アルゴリズムのそれぞれをサポートしなければならず (MUST)、クライアントは、最も優先されるものから最も優先されないものの順にアルゴリズムを指定しなければならない (MUST)。

本文書のセクション 4.4.7.2 では、サーバーがリクエスト元のクライアントへの OCSP 応答に署名するためのアルゴリズムを選択する方法について説明する。

4.4.7.2. Responder Signature Algorithm Selection (レスポンダ署名アルゴリズムの選択)​

RFC 2560 [RFC2560] は、OCSP 応答で使用される署名アルゴリズムを決定するためのメカニズムを指定していなかった。これは、相互運用性を促進するために選択されたアルゴリズムに関して十分な程度の確実性を提供しない。

4.4.7.2.1. Dynamic Response (動的応答)​

選択されたアルゴリズムが OCSP レスポンダのすべてのセキュリティ要件を満たす限り、レスポンダは次の優先順位を使用してサポートされている署名アルゴリズムを選択することにより、相互運用性を確保する可能性を最大化してもよい (MAY)。ここで、最初の選択メカニズムが最も高い優先順位を持つ：

  1. クライアントリクエストで優先署名アルゴリズムとして指定されたアルゴリズムを選択する。

  2. CertID で指定された証明書のステータス情報を提供する証明書発行者によって発行された証明書失効リスト (CRL) の署名に使用される署名アルゴリズムを選択する。

  3. OCSPRequest の署名に使用された署名アルゴリズムを選択する。

  4. 帯域外メカニズムを使用して署名サービスのデフォルトの署名アルゴリズムとしてアドバタイズされている署名アルゴリズムを選択する。

  5. 使用中の OCSP のバージョンに指定された必須または推奨の署名アルゴリズムを選択する。

レスポンダは、暗号化アルゴリズムの強度に関するレスポンダの基準を満たす、既知でサポートされているアルゴリズムの選択をもたらす最も番号の低い選択メカニズムを常に適用すべきである (SHOULD)。

4.4.7.2.2. Static Response (静的応答)​

効率のために、OCSP レスポンダはリクエストの前に静的な応答を生成することが許可されている。この場合、レスポンダは応答生成中にクライアントのリクエストデータを利用できない場合があるが、レスポンダは返される事前に生成された応答の選択中にクライアントのリクエストデータを使用すべきである (SHOULD)。レスポンダは、事前に生成された応答に署名するためにどのような異なるアルゴリズムを使用すべきかの決定への入力の一部として、過去のクライアントリクエストを使用してもよい (MAY)。

4.4.8. Extended Revoked Definition (拡張された失効定義)​

この拡張機能は、セクション 2.2 に従って、発行されていない証明書も含めるように「revoked (失効)」ステータスの拡張定義をレスポンダがサポートしていることを示す。その主な目的の 1 つは、監査によってレスポンダの操作の種類を決定できるようにすることである。クライアントは、応答内の証明書のステータスを決定するためにこの拡張機能を解析する必要はない。

OCSP 応答に発行されていない証明書の「revoked」ステータスが含まれている場合、この拡張機能をその応答に含めなければならない (MUST)。この拡張機能は、レスポンダが拡張された失効定義を実装している合図として他の応答に存在してもよい (MAY)。含まれる場合、この拡張機能は responseExtensions に配置されなければならず (MUST)、singleExtensions に出現してはならない (MUST NOT)。

この拡張機能は、オブジェクト識別子 id-pkix-ocsp-extended-revoke によって識別される。

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

拡張機能の値は NULL でなければならない (SHALL)。この拡張機能は critical としてマークされてはならない (MUST NOT)。

に最終更新