RFC 6961 - The Transport Layer Security (TLS) Multiple Certificate Status Request Extension 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc6961
タイトル : RFC 6961 - トランスポート層セキュリティ（TLS）の複数の証明書ステータス要求拡張
翻訳編集 : 自動生成

[要約] RFC 6961は、Transport Layer Security (TLS) プロトコルにおけるMultiple Certificate Status Request Extensionに関するものです。この拡張機能の目的は、クライアントが単一のハンドシェイク中に複数の証明書のステータス情報を効率的に要求し、検証することを可能にすることです。これは、特にサーバーが複数の証明書チェーンを提供する場合や、クライアントが複数の証明書のステータスを一度に確認したい場合に有用です。この拡張機能は、TLSのパフォーマンスとセキュリティを向上させることを目指しています。関連するRFCには、TLSの基本を定義するRFC 5246（TLS 1.2）や、証明書のステータスプロトコルを定義するRFC 6960（OCSP）などがあります。

Internet Engineering Task Force (IETF)                      Y. Pettersen
Request for Comments: 6961                                     June 2013
Category: Standards Track
ISSN: 2070-1721

The Transport Layer Security (TLS) Multiple Certificate Status Request Extension

トランスポート層セキュリティ（TLS）の複数の証明書ステータス要求拡張

Abstract

概要

This document defines the Transport Layer Security (TLS) Certificate Status Version 2 Extension to allow clients to specify and support several certificate status methods. (The use of the Certificate Status extension is commonly referred to as "OCSP stapling".) Also defined is a new method based on the Online Certificate Status Protocol (OCSP) that servers can use to provide status information about not only the server's own certificate but also the status of intermediate certificates in the chain.

このドキュメントでは、トランスポート層セキュリティ（TLS）証明書ステータスバージョン2拡張を定義して、クライアントがいくつかの証明書ステータスメソッドを指定およびサポートできるようにします。（証明書ステータス拡張の使用は、一般に「OCSPステープリング」と呼ばれます。）また、サーバーがサーバー自身の証明書だけでなくステータス情報を提供するために使用できるオンライン証明書ステータスプロトコル（OCSP）に基づく新しいメソッドも定義されています。チェーン内の中間証明書のステータスも。

Status of This Memo

本文書の状態

This is an Internet Standards Track document.

これはInternet Standards Trackドキュメントです。

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.

このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 5741のセクション2をご覧ください。

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6961.

このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6961で入手できます。

著作権表示

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。

This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.

このドキュメントには、2008年11月10日より前に公開または公開されたIETFドキュメントまたはIETFコントリビューションのマテリアルが含まれている場合があります。このマテリアルの著作権を管理する人物が、IETF Trustにそのようなマテリアルの変更を許可する権利を付与していないIETF標準プロセス外。このような資料の著作権を管理する人から適切なライセンスを取得しない限り、このドキュメントはIETF標準プロセス外で変更できません。また、その派生物は、IETF標準プロセス外で作成できません。 RFCとして、またはそれを英語以外の言語に翻訳するために発行します。

1. Introduction

1. はじめに

The Transport Layer Security (TLS) Extension [RFC6066] framework defines, among other extensions, the Certificate Status extension (also referred to as "OCSP stapling") that clients can use to request the server's copy of the current status of its certificate. The benefits of this extension include a reduced number of roundtrips and network delays for the client to verify the status of the server's certificate and a reduced load on the certificate issuer's status response servers, thus solving a problem that can become significant when the issued certificate is presented by a frequently visited server.

トランスポート層セキュリティ（TLS）拡張[RFC6066]フレームワークは、他の拡張の中でも、クライアントが証明書の現在のステータスのサーバーのコピーを要求するために使用できる証明書ステータス拡張（「OCSPステープリング」とも呼ばれる）を定義します。この拡張の利点には、クライアントがサーバーの証明書のステータスを確認するための往復回数とネットワーク遅延の数が減り、証明書発行者のステータス応答サーバーの負荷が減るので、発行された証明書が重要な場合に重大になる可能性がある問題が解決されます頻繁にアクセスされるサーバーによって提示されます。

There are two problems with the existing Certificate Status extension. First, it does not provide functionality to request the status information about intermediate Certification Authority (CA) certificates, which means the client has to request status information through other methods, such as Certificate Revocation Lists (CRLs), introducing further delays. Second, the current format of the extension and requirements in the TLS protocol prevent a client from offering the server multiple status methods.

既存の証明書ステータス拡張には2つの問題があります。まず、中間認証局（CA）証明書に関するステータス情報を要求する機能は提供されません。つまり、クライアントは証明書失効リスト（CRL）などの他の方法でステータス情報を要求する必要があり、さらに遅延が発生します。次に、TLSプロトコルの拡張と要件の現在の形式では、クライアントがサーバーに複数のステータスメソッドを提供できません。

Many CAs are now issuing intermediate CA certificates that not only specify the publication point for their CRLs in a CRL Distribution Point [RFC5280] but also specify a URL for their OCSP [RFC6960] server in Authority Information Access [RFC5280]. Given that client-cached CRLs are frequently out of date, clients would benefit from using OCSP to access up-to-date status information about intermediate CA certificates. The benefit to the issuing CA is less clear, as providing the bandwidth for the OCSP responder can be costly, especially for CAs with many high-traffic subscriber sites, and this cost is a concern for many CAs. There are cases where OCSP requests for a single high-traffic site caused significant network problems for the issuing CA.

多くのCAは、CRL配布ポイント[RFC5280]でCRLの公開ポイントを指定するだけでなく、機関情報アクセス[RFC5280]でOCSP [RFC6960]サーバーのURLも指定する中間CA証明書を発行しています。クライアントキャッシュのCRLは頻繁に古くなっているため、クライアントはOCSPを使用して中間CA証明書に関する最新のステータス情報にアクセスすることでメリットを得られます。 OCSPレスポンダーに帯域幅を提供することは、特に多くの高トラフィックサブスクライバーサイトを持つCAにとってコストがかかる可能性があるため、発行元CAへの利点はあまり明確ではなく、このコストは多くのCAにとって懸念事項です。単一の高トラフィックサイトに対するOCSP要求により、発行元CAに重大なネットワーク問題が発生した場合があります。

Clients will benefit from the TLS server providing certificate status information regardless of type, not just for the server certificate but also for the intermediate CA certificates. Combining the status checks into one extension will reduce the roundtrips needed to complete the handshake by the client to just those needed for negotiating the TLS connection. Also, for the Certification Authorities, the load on their servers will depend on the number of certificates they have issued, not on the number of visitors to those sites. Additionally, using this extension significantly reduces privacy concerns around the clients informing the certificate issuer about which sites they are visiting.

クライアントは、サーバー証明書だけでなく、中間CA証明書についても、タイプに関係なく証明書ステータス情報を提供するTLSサーバーの恩恵を受けます。ステータスチェックを1つの拡張に組み合わせると、クライアントによるハンドシェイクを完了するために必要なラウンドトリップが、TLS接続のネゴシエーションに必要なラウンドトリップだけに削減されます。また、証明機関の場合、サーバーの負荷は、発行した証明書の数に依存し、それらのサイトへの訪問者の数には依存しません。さらに、この拡張機能を使用すると、クライアントの周りのプライバシーの問題が大幅に軽減され、どのサイトにアクセスしているかが証明書発行者に通知されます。

For such a new system to be introduced seamlessly, clients need to be able to indicate support for the existing OCSP Certificate Status method and a new multiple-OCSP mode.

このような新しいシステムをシームレスに導入するには、クライアントが既存のOCSP証明書ステータスメソッドと新しいマルチOCSPモードのサポートを示すことができる必要があります。

Unfortunately, the definition of the Certificate Status extension only allows a single Certificate Status extension to be defined in a single extension record in the handshake, and the TLS protocol [RFC5246] only allows a single record in the extension list for any given extension. This means that it is not possible for clients to indicate support for new methods while still supporting older methods, which would cause problems for interoperability between newer clients and older servers. This will not just be an issue for the multiple status request mode proposed above but also for any other future status methods that might be introduced. This will be true not just for the current PKIX infrastructure [RFC5280] but also for alternative PKI structures.

残念ながら、証明書ステータス拡張の定義では、ハンドシェイクの単一の拡張レコードで定義できる単一の証明書ステータス拡張のみが許可され、TLSプロトコル[RFC5246]では、指定された拡張の拡張リストに単一のレコードしか許可されません。これは、クライアントが古いメソッドをサポートしながら新しいメソッドのサポートを示すことができないため、新しいクライアントと古いサーバー間の相互運用性に問題が発生することを意味します。これは、上記で提案された複数ステータス要求モードの問題だけでなく、導入される可能性のある他の将来のステータスメソッドの問題でもあります。これは、現在のPKIXインフラストラクチャ[RFC5280]だけでなく、別のPKI構造にも当てはまります。

The solution to this problem is to define a new extension, "status_request_v2", with an extended format that allows the client to indicate support for multiple status request methods. This is implemented using a list of CertificateStatusRequestItemV2 records in the extension record. As the server will select the single status method based on the selected cipher suite and the certificate presented, no significant changes are needed in the server's extension format.

この問題の解決策は、クライアントが複数のステータス要求メソッドのサポートを示すことを可能にする拡張形式で、新しい拡張「status_request_v2」を定義することです。これは、拡張レコードのCertificateStatusRequestItemV2レコードのリストを使用して実装されます。サーバーは、選択された暗号スイートと提示された証明書に基づいて単一のステータス方式を選択するため、サーバーの拡張形式に大きな変更を加える必要はありません。

1.1. Requirements Language

1.1. 要件言語

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].

このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 RFC 2119 [RFC2119]で説明されているように解釈されます。

1.2. Presentation Language

1.2. プレゼンテーション言語

This document defines protocol structures using the same conventions and presentation language as defined in Section 4 of [RFC5246].

このドキュメントでは、[RFC5246]のセクション4で定義されているのと同じ規則と表示言語を使用してプロトコル構造を定義します。

2. Multiple Certificate Status Extension

2. 複数の証明書ステータス拡張

2.1. New Extension

2.1. 新しい拡張子

The extension defined by this document is indicated by "status_request_v2" in the ExtensionType enum (originally defined by [RFC6066]), which uses the following value:

このドキュメントで定義されている拡張機能は、ExtensionType列挙型（最初は[RFC6066]で定義されています）の "status_request_v2"で示され、次の値を使用します。

     enum {
       status_request_v2(17), (65535)
     } ExtensionType;

2.2. Multiple Certificate Status Request Record

2.2. 複数の証明書ステータス要求レコード

Clients that support a certificate status protocol like OCSP may send the "status_request_v2" extension to the server in order to use the TLS handshake to transfer such data instead of downloading it through separate connections. When using this extension, the "extension_data" field (defined in Section 7.4.1.4 of [RFC5246]) of the extension SHALL contain a CertificateStatusRequestListV2 where:

OCSPなどの証明書ステータスプロトコルをサポートするクライアントは、「status_request_v2」拡張機能をサーバーに送信して、TLSハンドシェイクを使用して、個別の接続を通じてデータをダウンロードするのではなく、そのようなデータを転送します。この拡張機能を使用する場合、拡張機能の[extension_data]フィールド（[RFC5246]のセクション7.4.1.4で定義）には、CertificateStatusRequestListV2が含まれている必要があります（SHALL）。

     struct {
       CertificateStatusType status_type;
       uint16 request_length; /* Length of request field in bytes */
       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;

In the OCSPStatusRequest (originally defined by [RFC6066]), the "ResponderID" provides a list of OCSP responders that the client trusts. A zero-length "responder_id_list" sequence has the special meaning that the responders are implicitly known to the server, e.g., by prior arrangement, or are identified by the certificates used by the server. "Extensions" is a DER encoding [X.690] of the OCSP request extensions, and if the server supports the forwarding of OCSP request extensions, this value MUST be forwarded without modification.

OCSPStatusRequest（最初は[RFC6066]で定義されています）では、 "ResponderID"はクライアントが信頼するOCSPレスポンダのリストを提供します。長さがゼロの「responder_id_list」シーケンスは、レスポンダーがサーバーに暗黙的に認識されている（たとえば、事前の取り決めによって）か、サーバーが使用する証明書によって識別されるという特別な意味を持っています。「拡張」はOCSP要求拡張のDERエンコード[X.690]であり、サーバーがOCSP要求拡張の転送をサポートしている場合、この値は変更せずに転送する必要があります。

Both "ResponderID" and "Extensions" are DER-encoded ASN.1 types as defined in [RFC6960]. "Extensions" is imported from [RFC5280]. A zero-length "request_extensions" value means that there are no extensions (as opposed to a DER-encoded zero-length ASN.1 SEQUENCE, which is not valid for the "Extensions" type).

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

Servers that support a client's selection of responders using the ResponderID field could implement this selection by matching the responder ID values from the client's list with the ResponderIDs of known OCSP responders, either by using a binary compare of the values or a hash calculation and compare method.

ResponderIDフィールドを使用してクライアントのレスポンダーの選択をサポートするサーバーは、値のバイナリ比較またはハッシュ計算および比較メソッドを使用して、クライアントのリストからのレスポンダーID値を既知のOCSPレスポンダーのResponderIDと照合することにより、この選択を実装できます。

In the case of the "id-pkix-ocsp-nonce" OCSP extension, [RFC2560] is unclear about its encoding; for clarification, the nonce MUST be a DER-encoded OCTET STRING, which is encapsulated as another OCTET STRING (note that implementations based on an existing OCSP client will need to be checked for conformance to this requirement). This has been clarified in [RFC6960].

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

The items in the list of CertificateStatusRequestItemV2 entries are ordered according to the client's preference (favorite choice first).

CertificateStatusRequestItemV2エントリのリストの項目は、クライアントの設定に従って並べられます（最初にお気に入りの選択）。

A server that receives a client hello containing the "status_request_v2" extension MAY return a suitable certificate status response message to the client along with the server's certificate message. If OCSP is requested, it SHOULD use the information contained in the extension when selecting an OCSP responder and SHOULD include request_extensions in the OCSP request.

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

The server returns a certificate status response along with its certificate by sending a "CertificateStatus" message (originally defined by [RFC6066]) immediately after the "Certificate" message (Section 7.4.2 of [RFC5246]) (and before any "ServerKeyExchange" or "CertificateRequest" messages). If a server returns a "CertificateStatus" message in response to a "status_request_v2" request, then the server MUST have included an extension of type "status_request_v2" with empty "extension_data" in the extended server hello.

サーバーは、「Certificate」メッセージ（[RFC5606]のセクション7.4.2）の直後（かつ「ServerKeyExchange」の前）に「CertificateStatus」メッセージ（[RFC6066]によって最初に定義された）を送信することにより、証明書と一緒に証明書ステータス応答を返します。または「CertificateRequest」メッセージ）。「status_request_v2」リクエストに応答してサーバーが「CertificateStatus」メッセージを返す場合、サーバーは、拡張サーバーhelloに空の「extension_data」を含む「status_request_v2」タイプの拡張を含めている必要があります。

The "CertificateStatus" message is conveyed using the handshake message type "certificate_status" (defined in [RFC6066]) as follows (updated from the definition in [RFC6066]):

「CertificateStatus」メッセージは、ハンドシェイクメッセージタイプ「certificate_status」（[RFC6066]で定義）を使用して次のように伝えられます（[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;

An "OCSPResponse" element (originally defined by [RFC6066]) contains a complete, DER-encoded OCSP response (using the ASN.1 [X.680] type OCSPResponse defined in [RFC6960]). Only one OCSP response, with a length of at least one byte, may be sent for status_type "ocsp".

「OCSPResponse」要素（[RFC6066]によって当初定義された）には、完全なDERエンコードされたOCSP応答が含まれます（[RFC6960]で定義されたASN.1 [X.680]タイプOCSPResponseを使用）。 status_type "ocsp"には、少なくとも1バイトの長さのOCSP応答を1つだけ送信できます。

An "ocsp_response_list" contains a list of "OCSPResponse" elements, as specified above, each containing the OCSP response for the matching corresponding certificate in the server's Certificate TLS handshake message. That is, the first entry is the OCSP response for the first certificate in the Certificate list, the second entry is the response for the second certificate, and so on. The list MAY contain fewer OCSP responses than there were certificates in the Certificate handshake message, but there MUST NOT be more responses than there were certificates in the list. Individual elements of the list MAY have a length of 0 (zero) bytes if the server does not have the OCSP response for that particular certificate stored, in which case the client MUST act as if a response was not received for that particular certificate. If the client receives a "ocsp_response_list" that does not contain a response for one or more of the certificates in the completed certificate chain, the client SHOULD attempt to validate the certificate using an alternative retrieval method, such as downloading the relevant CRL; OCSP SHOULD in this situation only be used for the end-entity certificate, not intermediate CA certificates, for reasons stated above.

「ocsp_response_list」には、上記で指定した「OCSPResponse」要素のリストが含まれ、それぞれに、サーバーの証明書TLSハンドシェイクメッセージ内の対応する対応する証明書のOCSP応答が含まれています。つまり、最初のエントリは証明書リストの最初の証明書に対するOCSP応答で、2番目のエントリは2番目の証明書に対する応答というように続きます。リストには、証明書ハンドシェイクメッセージにある証明書よりも少ないOCSP応答が含まれる場合がありますが、リストにある証明書よりも多くの応答があってはなりません。サーバーにその特定の証明書に対するOCSP応答が格納されていない場合、リストの個々の要素の長さは0（ゼロ）バイトである場合があります。その場合、クライアントはその特定の証明書に対する応答が受信されなかったかのように動作する必要があります。完了した証明書チェーン内の1つ以上の証明書に対する応答を含まない「ocsp_response_list」をクライアントが受信した場合、クライアントは、関連するCRLのダウンロードなど、別の取得方法を使用して証明書を検証する必要があります（SHOULD）。この状況では、OCSPは上記の理由により、中間CA証明書ではなく、エンドエンティティ証明書にのみ使用する必要があります（SHOULD）。

Note that a server MAY also choose not to send a "CertificateStatus" message, even if it has received a "status_request_v2" extension in the client hello message and has sent a "status_request_v2" extension in the server hello message. Additionally, note that a server MUST NOT send the "CertificateStatus" message unless it received either a "status_request" or "status_request_v2" extension in the client hello message and sent a corresponding "status_request" or "status_request_v2" extension in the server hello message.

サーバーは、クライアントhelloメッセージで「status_request_v2」拡張を受信し、サーバーhelloメッセージで「status_request_v2」拡張を送信した場合でも、「CertificateStatus」メッセージを送信しないことも選択できることに注意してください。さらに、サーバーは、クライアントのhelloメッセージで「status_request」または「status_request_v2」拡張を受信し、サーバーのhelloメッセージで対応する「status_request」または「status_request_v2」拡張を送信しない限り、「CertificateStatus」メッセージを送信してはならないことに注意してください。

Clients requesting an OCSP response and receiving one or more OCSP responses in a "CertificateStatus" message MUST check the OCSP response(s) and abort the handshake if the response is a "revoked" status or other unacceptable responses (as determined by client policy) with a bad_certificate_status_response(113) alert. This alert is always fatal.

OCSP応答を要求し、「CertificateStatus」メッセージで1つ以上のOCSP応答を受信するクライアントは、OCSP応答を確認し、応答が「取り消し」ステータスまたはその他の許容できない応答（クライアントポリシーによって決定される）である場合、ハンドシェイクを中止する必要があります。 bad_certificate_status_response（113）アラート。このアラートは常に致命的です。

If the OCSP response received from the server does not result in a definite "good" or "revoked" status, it is inconclusive. A TLS client in such a case MAY check the validity of the server certificate through other means, e.g., by directly querying the certificate issuer. If such processing still results in an inconclusive response, then the application using the TLS connection will have to decide whether to close the connection or not. Note that this problem cannot be decided by the generic TLS client code without information from the application. If the application doesn't provide any such information, then the client MUST abort the connection, since the server certificate has not been sufficiently validated.

サーバーから受信したOCSP応答が明確な「良好」または「取り消し」ステータスにならない場合、それは決定的ではありません。そのような場合のTLSクライアントは、証明書発行者に直接照会するなど、他の方法でサーバー証明書の有効性をチェックしてもよい（MAY）。それでもこのような処理の結果が決定的でない場合、TLS接続を使用するアプリケーションは、接続を閉じるかどうかを決定する必要があります。この問題は、アプリケーションからの情報がないと、一般的なTLSクライアントコードでは判断できないことに注意してください。アプリケーションがそのような情報を提供しない場合、サーバー証明書が十分に検証されていないため、クライアントは接続を中止する必要があります。

An example of where the application might wish to continue is with EAP-TLS (Extensible Authentication Protocol - TLS), where the application can use another mechanism to check the status of a certificate once it obtains network access. In this case, the application could have the client continue with the handshake, but it MUST NOT disclose a username and password until it has fully validated the server certificate.

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

3. IANA Considerations

3. IANAに関する考慮事項

Section 2.1 defines the new TLS extension status_request_v2 (17) enum, which has been added to the "ExtensionType Values" list in the IANA "Transport Layer Security (TLS) Extensions" registry.

セクション2.1では、新しいTLS拡張のstatus_request_v2（17）enumが定義されています。これは、IANAの "Transport Layer Security（TLS）Extensions"レジストリの "ExtensionType Values"リストに追加されています。

Section 2.2 describes a TLS CertificateStatusType registry that is now maintained by IANA. The "TLS Certificate Status Types" registry has been created under the "Transport Layer Security (TLS) Extensions" registry. CertificateStatusType values are to be assigned via IETF Review as defined in [RFC5226]. The initial registry corresponds to the definition of "CertificateStatusType" in Section 2.2.

セクション2.2では、現在IANAによって維持されているTLS CertificateStatusTypeレジストリについて説明します。「TLS Certificate Status Types」レジストリは、「Transport Layer Security（TLS）Extensions」レジストリの下に作成されています。 CertificateStatusType値は、[RFC5226]で定義されているIETFレビューを介して割り当てられます。初期レジストリは、セクション2.2の「CertificateStatusType」の定義に対応しています。

   Value   Description   Reference
   -----------------------------------------
   0       Reserved      [RFC6961]
   1       ocsp          [RFC6066] [RFC6961]
   2       ocsp_multi    [RFC6961]
   3-255   Unassigned

4. Security Considerations

4. セキュリティに関する考慮事項

General security considerations for TLS extensions are covered in [RFC5246]. Security considerations for the particular extension specified in this document are given below. In general, implementers should continue to monitor the state of the art and address any weaknesses identified.

TLS拡張に関する一般的なセキュリティの考慮事項は、[RFC5246]でカバーされています。このドキュメントで指定されている特定の拡張機能のセキュリティに関する考慮事項を以下に示します。一般に、実装者は最新の技術を監視し続け、特定された弱点に対処する必要があります。

4.1. Security Considerations for status_request_v2

4.1. status_request_v2のセキュリティに関する考慮事項

If a client requests an OCSP response, it must take into account that an attacker's server using a compromised key could (and probably would) pretend not to support the extension. In this case, a client that requires OCSP validation of certificates SHOULD either contact the OCSP server directly or abort the handshake.

クライアントがOCSP応答を要求する場合、侵害されたキーを使用する攻撃者のサーバーが拡張機能をサポートしないふりをする可能性がある（そしておそらくそうする）ことを考慮する必要があります。この場合、証明書のOCSP検証を必要とするクライアントは、OCSPサーバーに直接接続するか、ハンドシェイクを中止する必要があります。

Use of the OCSP nonce request extension (id-pkix-ocsp-nonce) may improve security against attacks that attempt to replay OCSP responses; see Section 4.4.1 of [RFC6960] for further details.

OCSPナンス要求拡張（id-pkix-ocsp-nonce）を使用すると、OCSP応答を再生しようとする攻撃に対するセキュリティが向上する可能性があります。詳細については、[RFC6960]のセクション4.4.1を参照してください。

This extension allows the client to send arbitrary data to the server. The server implementers need to handle such data carefully to avoid introducing security vulnerabilities.

この拡張機能により、クライアントは任意のデータをサーバーに送信できます。サーバーの実装者は、セキュリティの脆弱性の導入を回避するために、このようなデータを慎重に処理する必要があります。

The security considerations of [RFC6960] apply to OCSP requests and responses.

[RFC6960]のセキュリティに関する考慮事項は、OCSP要求と応答に適用されます。

5. Acknowledgements

5. 謝辞

This document is based on [RFC6066], authored by Donald Eastlake 3rd.

このドキュメントは、Donald Eastlake 3rdによって作成された[RFC6066]に基づいています。

6. References

6. 参考文献

6.1. Normative References

6.1. 引用文献

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。

[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.

[RFC5226] Narten、T。およびH. Alvestrand、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 5226、2008年5月。

[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.

[RFC5246] Dierks、T。およびE. Rescorla、「The Transport Layer Security（TLS）Protocol Version 1.2」、RFC 5246、2008年8月。

[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008.

[RFC5280] Cooper、D.、Santesson、S.、Farrell、S.、Boeyen、S.、Housley、R。、およびW. Polk、「Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List（CRL）Profile "、RFC 5280、2008年5月。

[RFC6066] Eastlake, D., "Transport Layer Security (TLS) Extensions: Extension Definitions", RFC 6066, January 2011.

[RFC6066] Eastlake、D。、「Transport Layer Security（TLS）Extensions：Extension Definitions」、RFC 6066、2011年1月。

[RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. Adams, "X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP", RFC 6960, June 2013.

[RFC6960] Santesson、S.、Myers、M.、Ankney、R.、Malpani、A.、Galperin、S.、and C. Adams、 "X.509 Internet Public Key Infrastructure Online Certificate Status Protocol-OCSP"、RFC 6960、2013年6月。

[X.680] ITU-T Recommendation X.680 (2008) | ISO/IEC 8824-1:2008, "Abstract Syntax Notation One (ASN.1): Specification of basic notation", November 2008.

[X.680] ITU-T勧告X.680（2008）| ISO / IEC 8824-1：2008、「Abstract Syntax Notation One（ASN.1）：Specification of basic notation」、2008年11月。

[X.690] ITU-T Recommendation X.690 (2008) | ISO/IEC 8825-1:2008, "ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)", November 2008.

[X.690] ITU-T勧告X.690（2008）| ISO / IEC 8825-1：2008、「ASN.1エンコーディングルール：Basic Encoding Rules（BER）、Canonical Encoding Rules（CER）and Distinguished Encoding Rules（DER）」、2008年11月の仕様。

6.2. Informative References

6.2. 参考引用

[RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. Adams, "X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP", RFC 2560, June 1999.

[RFC2560]マイヤーズ、M。、アンクニー、R。、マルパニ、A。、ガルペリン、S。、およびC.アダムス、「X.509インターネット公開鍵インフラストラクチャオンライン証明書ステータスプロトコル-OCSP」、RFC 2560、1999年6月。

Author's Address

著者のアドレス

Yngve N. Pettersen

イングヴェ・N・ペッターセン

   EMail: yngve@spec-work.net