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

2.2. Multiple Certificate Status Request Record (複数証明書ステータス要求レコード)

OCSP などの証明書ステータスプロトコルをサポートするクライアントは, "status_request_v2" 拡張をサーバーに送信して, 別の接続を通じてダウンロードするのではなく, TLS ハンドシェイクを使用してそのようなデータを転送できます。この拡張を使用する場合, ([RFC5246] のセクション 7.4.1.4 で定義された) "extension_data" フィールドには CertificateStatusRequestListV2 を含めなければなりません。ここで:

  struct {
    CertificateStatusType status_type;
    uint16 request_length; /* request フィールドの長さ (バイト単位) */
    select (status_type) {
      case ocsp: OCSPStatusRequest;
      case ocsp_multi: OCSPStatusRequest;
    } request;
  } CertificateStatusRequestItemV2;

  enum { ocsp(1), ocsp_multi(2), (255) } CertificateStatusType;

  struct {
    ResponderID responder_id_list<0..2^16-1>;
    Extensions request_extensions;
  } OCSPStatusRequest;

  opaque ResponderID<1..2^16-1>;
  opaque Extensions<0..2^16-1>;

  struct {
    CertificateStatusRequestItemV2
                     certificate_status_req_list<1..2^16-1>;
  } CertificateStatusRequestListV2;

OCSPStatusRequest ([RFC6066] で元々定義された) では, "ResponderID" はクライアントが信頼する OCSP レスポンダのリストを提供します。長さゼロの "responder_id_list" シーケンスには, レスポンダがサーバーに暗黙的に知られている (例えば, 事前の取り決めによって, またはサーバーが使用する証明書によって識別される) という特別な意味があります。"Extensions" は OCSP 要求拡張の DER エンコーディング [X.690] であり, サーバーが OCSP 要求拡張の転送をサポートしている場合, この値は変更なしで転送されなければなりません。

"ResponderID" と "Extensions" の両方は, [RFC6960] で定義されている DER エンコードされた ASN.1 タイプです。"Extensions" は [RFC5280] からインポートされます。長さゼロの "request_extensions" 値は, 拡張がないことを意味します ("Extensions" タイプに対して有効でない DER エンコードされた長さゼロの ASN.1 SEQUENCE とは対照的です)。

ResponderID フィールドを使用したクライアントのレスポンダ選択をサポートするサーバーは, クライアントのリストの responder ID 値を既知の OCSP レスポンダの ResponderID と照合することで, この選択を実装できます。値のバイナリ比較またはハッシュ計算と比較の方法を使用します。

"id-pkix-ocsp-nonce" OCSP 拡張の場合, [RFC2560] はそのエンコーディングについて不明確です。明確にするために, nonce は DER エンコードされた OCTET STRING でなければならず, これは別の OCTET STRING としてカプセル化されます (既存の OCSP クライアントに基づく実装は, この要件への準拠を確認する必要があることに注意してください)。これは [RFC6960] で明確にされています。

CertificateStatusRequestItemV2 エントリのリスト内の項目は, クライアントの優先順位に従って順序付けられます (最も好まれる選択が最初)。

"status_request_v2" 拡張を含むクライアント hello を受信したサーバーは, サーバーの証明書とともにクライアントに適切な証明書ステータス応答メッセージを返してもよいです (MAY)。OCSP が要求された場合, サーバーは OCSP レスポンダを選択する際に拡張に含まれる情報を使用すべきであり (SHOULD), OCSP 要求に request_extensions を含めるべきです (SHOULD)。

サーバーは, "Certificate" メッセージ ([RFC5246] のセクション 7.4.2) の直後 (および任意の "ServerKeyExchange" または "CertificateRequest" メッセージの前) に "CertificateStatus" メッセージ ([RFC6066] で元々定義された) を送信することで, 証明書とともに証明書ステータス応答を返します。サーバーが "status_request_v2" 要求に応答して "CertificateStatus" メッセージを返す場合, サーバーは拡張サーバー hello に空の "extension_data" を持つ "status_request_v2" タイプの拡張を含めなければなりません (MUST)。

"CertificateStatus" メッセージは, ([RFC6066] で定義された) ハンドシェイクメッセージタイプ "certificate_status" を使用して次のように伝達されます ([RFC6066] の定義から更新):

  struct {
    CertificateStatusType status_type;
    select (status_type) {
      case ocsp: OCSPResponse;
      case ocsp_multi: OCSPResponseList;
    } response;
  } CertificateStatus;

  opaque OCSPResponse<0..2^24-1>;

  struct {
    OCSPResponse ocsp_response_list<1..2^24-1>;
  } OCSPResponseList;

"OCSPResponse" 要素 ([RFC6066] で元々定義された) には, 完全な DER エンコードされた OCSP 応答 ([RFC6960] で定義された ASN.1 [X.680] タイプ OCSPResponse を使用) が含まれます。status_type "ocsp" に対しては, 少なくとも1バイトの長さを持つ1つの OCSP 応答のみを送信できます。

"ocsp_response_list" には, 上記で指定されたように "OCSPResponse" 要素のリストが含まれ, 各要素はサーバーの Certificate TLS ハンドシェイクメッセージ内の対応する一致する証明書の OCSP 応答を含みます。つまり, 最初のエントリは Certificate リストの最初の証明書の OCSP 応答であり, 2番目のエントリは2番目の証明書の応答, というようになります。リストは, Certificate ハンドシェイクメッセージの証明書よりも少ない OCSP 応答を含んでもよいですが (MAY), リストの証明書よりも多くの応答があってはなりません (MUST NOT)。サーバーがその特定の証明書に対する OCSP 応答を保存していない場合, リストの個々の要素は長さ 0 (ゼロ) バイトを持つことができます (MAY)。その場合, クライアントはその特定の証明書に対して応答が受信されなかったかのように動作しなければなりません (MUST)。クライアントが完了した証明書チェーンの1つ以上の証明書に対する応答を含まない "ocsp_response_list" を受信した場合, クライアントは関連する CRL をダウンロードするなどの代替取得方法を使用して証明書を検証しようとすべきです (SHOULD)。OCSP は, この状況では, 上記の理由により, エンドエンティティ証明書にのみ使用すべきであり (SHOULD), 中間 CA 証明書には使用すべきではありません。

サーバーは, クライアント hello メッセージで "status_request_v2" 拡張を受信し, サーバー hello メッセージで "status_request_v2" 拡張を送信した場合でも, "CertificateStatus" メッセージを送信しないことを選択してもよいことに注意してください (MAY)。さらに, サーバーは, クライアント hello メッセージで "status_request" または "status_request_v2" 拡張を受信し, サーバー hello メッセージで対応する "status_request" または "status_request_v2" 拡張を送信した場合を除いて, "CertificateStatus" メッセージを送信してはならないことに注意してください (MUST NOT)。

OCSP 応答を要求し, "CertificateStatus" メッセージで1つ以上の OCSP 応答を受信するクライアントは, OCSP 応答をチェックしなければならず (MUST), 応答が "revoked" (失効) ステータスまたは (クライアントポリシーによって決定される) その他の受け入れられない応答である場合, bad_certificate_status_response(113) アラートでハンドシェイクを中止しなければなりません (MUST)。このアラートは常に致命的です。

サーバーから受信した OCSP 応答が明確な "good" (正常) または "revoked" (失効) ステータスにならない場合, それは不確定です。そのような場合の TLS クライアントは, 他の手段 (例えば, 証明書発行者に直接クエリを実行するなど) を通じてサーバー証明書の有効性をチェックしてもよいです (MAY)。そのような処理でもまだ不確定な応答になる場合, TLS 接続を使用するアプリケーションは接続を閉じるかどうかを決定する必要があります。この問題は, アプリケーションからの情報なしに汎用 TLS クライアントコードでは決定できないことに注意してください。アプリケーションがそのような情報を提供しない場合, クライアントは接続を中止しなければなりません (MUST)。サーバー証明書が十分に検証されていないためです。

アプリケーションが継続を希望する可能性がある例としては, EAP-TLS (Extensible Authentication Protocol - TLS) (拡張可能認証プロトコル - TLS) があります。アプリケーションは, ネットワークアクセスを取得した後, 別のメカニズムを使用して証明書のステータスをチェックできます。この場合, アプリケーションはクライアントにハンドシェイクを続行させることができますが, サーバー証明書を完全に検証するまでユーザー名とパスワードを開示してはなりません (MUST NOT)。

に最終更新