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

8. 証明書ステータスリクエスト

制約のあるクライアントは、サーバー証明書の有効性を確認するために、OCSP [RFC2560] などの証明書ステータスプロトコルを使用して、CRL の送信を回避し、制約のあるネットワークで帯域幅を節約することを望む場合があります。この拡張により、TLS ハンドシェイクでそのような情報を送信でき、ラウンドトリップとリソースを節約できます。

証明書ステータス情報を受信したいという意思を示すために、クライアントは（拡張された）クライアント hello にタイプ「status_request」の拡張を含めることができます (MAY)。この拡張の「extension_data」フィールドには「CertificateStatusRequest」を含める必要があります (SHALL)。ここで：

struct {
    CertificateStatusType status_type;
    select (status_type) {
        case ocsp: OCSPStatusRequest;
    } request;
} CertificateStatusRequest;

enum { ocsp(1), (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>;

OCSPStatusRequest では、「ResponderIDs」はクライアントが信頼する OCSP レスポンダのリストを提供します。長さゼロの「responder_id_list」シーケンスには、レスポンダがサーバーに暗黙的に知られている（例：事前の取り決めによる）という特別な意味があります。「Extensions」は OCSP リクエスト拡張の DER エンコーディングです。

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

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

「status_request」拡張を含むクライアント hello を受信するサーバーは、証明書とともに適切な証明書ステータス応答をクライアントに返すことができます (MAY)。OCSP が要求された場合、OCSP レスポンダを選択する際に拡張に含まれる情報を使用すべきであり (SHOULD)、OCSP リクエストに request_extensions を含めるべきです (SHOULD)。

サーバーは、「Certificate」メッセージの直後（および「ServerKeyExchange」または「CertificateRequest」メッセージの前）に「CertificateStatus」メッセージを送信することによって、証明書とともに証明書応答を返します。サーバーが「CertificateStatus」メッセージを返す場合、サーバーは、空の「extension_data」を持つタイプ「status_request」の拡張を拡張サーバー hello に含めている必要があります (MUST)。

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

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

「OCSPResponse」要素（DER エンコード）には、完全な DER エンコードされた OCSP 応答（[RFC2560] で定義されている ASN.1 タイプ OCSPResponse を使用）が含まれます。1 つの OCSP 応答のみを送信できます。

「CertificateStatus」メッセージは、次のようにハンドシェイクメッセージタイプ「certificate_status」を使用して伝達されます（[RFC5246] のセクション 7.4.1.4 も参照）：

enum {
    HelloRequest(0), client_hello(1), server_hello(2),
    certificate(11), server_key_exchange (12),
    certificate_request(13), server_hello_done(14),
    certificate_verify(15), client_key_exchange(16),
    finished(20), certificate_status(22), (255)
} HandshakeType;

サーバーは、クライアント hello メッセージで「status_request」拡張を受信し、サーバー hello メッセージで「status_request」拡張を送信した場合でも、「CertificateStatus」メッセージを送信しないことを選択できます (MAY)。さらに、サーバーは、クライアント hello メッセージで「status_request」拡張または [RFC6961] で説明されている「status_request_v2」拡張を受信し、サーバー hello メッセージで対応する「status_request」または「status_request_v2」拡張を送信しない限り、「CertificateStatus」メッセージを送信してはなりません (MUST NOT)。

OCSP 応答を要求し、「CertificateStatus」メッセージで OCSP 応答を受信するクライアントは、OCSP 応答をチェックし、応答が満足できない場合はハンドシェイクを中止する必要があります (MUST)。

に最終更新