Network Working Group A. Deacon
Request for Comments: 5019 VeriSign
Category: Standards Track R. Hurst
Microsoft
September 2007
The Lightweight Online Certificate Status Protocol (OCSP) Profile for High-Volume Environments
大容量の環境のための軽量オンライン証明書状態プロトコル（OCSP）のプロフィール
Status of This Memo
このメモのステータス
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Abstract
抽象
This specification defines a profile of the Online Certificate Status Protocol (OCSP) that addresses the scalability issues inherent when using OCSP in large scale (high volume) Public Key Infrastructure (PKI) environments and/or in PKI environments that require a lightweight solution to minimize communication bandwidth and client-side processing.
この仕様は、大規模（大容量）でOCSPを使用する場合に固有のスケーラビリティの問題に対処するオンライン証明書状態プロトコル（OCSP）のプロファイルを定義する最小限に抑えるために軽量なソリューションを必要とする、および/またはPKI環境における公開鍵インフラストラクチャ（PKI）環境通信帯域幅とクライアント側の処理。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Requirements Terminology ...................................4
2. OCSP Message Profile ............................................4
2.1. OCSP Request Profile .......................................4
2.1.1. OCSPRequest Structure ...............................4
2.1.2. Signed OCSPRequests .................................5
2.2. OCSP Response Profile ......................................5
2.2.1. OCSPResponse Structure ..............................5
2.2.2. Signed OCSPResponses ................................6
2.2.3. OCSPResponseStatus Values ...........................6
2.2.4. thisUpdate, nextUpdate, and producedAt ..............7
3. Client Behavior .................................................7
3.1. OCSP Responder Discovery ...................................7
3.2. Sending an OCSP Request ....................................7
4. Ensuring an OCSPResponse Is Fresh ...............................8
5. Transport Profile ...............................................9
6. Caching Recommendations .........................................9
6.1. Caching at the Client .....................................10
6.2. HTTP Proxies ..............................................10
6.3. Caching at Servers ........................................12
7. Security Considerations ........................................12
7.1. Replay Attacks ............................................12
7.2. Man-in-the-Middle Attacks .................................13
7.3. Impersonation Attacks .....................................13
7.4. Denial-of-Service Attacks .................................13
7.5. Modification of HTTP Headers ..............................14
7.6. Request Authentication and Authorization ..................14
8. Acknowledgements ...............................................14
9. References .....................................................14
9.1. Normative References ......................................14
9.2. Informative References ....................................15
Appendix A. Example OCSP Messages .................................16
A.1. OCSP Request ..............................................16
A.2. OCSP Response .............................................16
The Online Certificate Status Protocol [OCSP] specifies a mechanism used to determine the status of digital certificates, in lieu of using Certificate Revocation Lists (CRLs). Since its definition in 1999, it has been deployed in a variety of environments and has proven to be a useful certificate status checking mechanism. (For brevity we refer to OCSP as being used to verify certificate status, but only the revocation status of a certificate is checked via this protocol.)
オンライン証明書状態プロトコル[OCSP]は、証明書失効リスト（CRL）を使用する代わりに、デジタル証明書のステータスを決定するために使用するメカニズムを指定します。 1999年の定義ので、さまざまな環境で展開されていると便利な証明書状態チェック機構であることが判明しました。 （簡潔にするために、我々は、証明書の状態を確認するために使用されるものとしてOCSPを参照するが、証明書の失効のみステータスは、このプロトコルを介してチェックされます。）
To date, many OCSP deployments have been used to ensure timely and secure certificate status information for high-value electronic transactions or highly sensitive information, such as in the banking and financial environments. As such, the requirement for an OCSP responder to respond in "real time" (i.e., generating a new OCSP response for each OCSP request) has been important. In addition, these deployments have operated in environments where bandwidth usage is not an issue, and have run on client and server systems where processing power is not constrained.
現在までに、多くのOCSPの展開は、銀行や金融環境のような高価値の電子取引や機密性の高い情報についてタイムリーかつ安全な証明書のステータス情報を確実にするために使用されています。そのようなものとして、「リアルタイム」に応答するOCSPレスポンダの要求（即ち、各OCSP要求のための新しいOCSPレスポンスを生成する）が重要となっています。また、これらの展開は帯域幅の使用量が問題ではない環境で動作している、と処理能力が制約されていないクライアントとサーバのシステム上で実行されています。
As the use of PKI continues to grow and move into diverse environments, so does the need for a scalable and cost-effective certificate status mechanism. Although OCSP as currently defined and deployed meets the need of small to medium-sized PKIs that operate on powerful systems on wired networks, there is a limit as to how these OCSP deployments scale from both an efficiency and cost perspective. Mobile environments, where network bandwidth may be at a premium and client-side devices are constrained from a processing point of view, require the careful use of OCSP to minimize bandwidth usage and client-side processing complexity. [OCSPMP]
PKIの利用が成長し、多様な環境に移動し続けると、その拡張性とコスト効率の証明書状態メカニズムの必要性がありません。現在定義されている展開OCSPは、有線ネットワーク上で強力なシステム上で動作する中型のPKIに小の必要性を満たしているが、これらのOCSPの展開は、効率とコストの観点の両方から拡張方法としては限界があります。ネットワーク帯域幅が貴重であってもよく、クライアント側装置が処理の観点から制約されているモバイル環境では、帯域幅の使用量と、クライアント側の処理の複雑さを最小限にするためにOCSPを慎重に使用する必要があります。 [OCSPMP]
PKI continues to be deployed into environments where millions if not hundreds of millions of certificates have been issued. In many of these environments, an even larger number of users (also known as relying parties) have the need to ensure that the certificate they are relying upon has not been revoked. As such, it is important that OCSP is used in such a way that ensures the load on OCSP responders and the network infrastructure required to host those responders are kept to a minimum.
PKIは、証明書の何百万、何百万でない場合は、何百が発行されている環境に配備され続けています。これらの環境の多くでは、（も依拠当事者として知られている）ユーザーのさらに大きな数は、彼らがに依存している証明書が失効していないことを確認する必要があります。このように、OCSPを最小限に維持されるOCSPレスポンダの負荷及びそれらの応答をホストするために必要なネットワークインフラストラクチャを保証するような方法で使用されることが重要です。
This document addresses the scalability issues inherent when using OCSP in PKI environments described above by defining a message profile and clarifying OCSP client and responder behavior that will permit:
この文書では、メッセージプロファイルを定義し、可能にするOCSPクライアントと応答者の挙動を明らかにすることにより、上述のPKI環境でOCSPを使用した固有のスケーラビリティの問題に対処します。
1) OCSP response pre-production and distribution. 2) Reduced OCSP message size to lower bandwidth usage. 3) Response message caching both in the network and on the client.
1）OCSP応答プリプロダクションおよび分布。 2）低帯域幅の使用にOCSPメッセージサイズを縮小。ネットワーク上のクライアントの両方で3）応答メッセージのキャッシュ。
It is intended that the normative requirements defined in this profile will be adopted by OCSP clients and OCSP responders operating in very large-scale (high-volume) PKI environments or PKI environments that require a lightweight solution to minimize bandwidth and client-side processing power (or both), as described above. As OCSP does not have the means to signal responder capabilities within the protocol, clients needing to differentiate between OCSP responses produced by responders conformant with this profile and those that are not need to rely on out-of-band mechanisms to determine when a responder operates according to this profile and, as such, when the requirements of this profile apply. In the case where out-of-band mechanisms may not be available, this profile ensures that interoperability will still occur between a fully conformant OCSP 2560 client and a responder that is operating in a mode as described in this specification.
なお、このプロファイルで定義された規範的要件は、帯域幅と、クライアント側の処理能力を最小限に抑えるために軽量ソリューションを必要とする非常に大規模な（大量）PKI環境またはPKI環境で動作するOCSPクライアントとOCSPレスポンダによって採用されることが意図されています（または両方）は、上述したように。 OCSPプロトコル内の機能レスポンダシグナリングする手段を持たないので、クライアントはOCSPのこのプロファイルに準拠レスポンダによって生成応答及び応答が動作するかを決定するために、アウトオブバンドメカニズムに頼る必要はないものとを区別する必要がこのプロファイルの要件が適用など、このプロファイルと、に記載の方法。アウトオブバンドメカニズムが利用可能ではないかもしれない場合に、このプロファイルは、相互運用性は、まだ完全に準拠OCSP 2560クライアントおよび本明細書に記載したようにモードで動作しているレスポンダの間で起こることを保証します。
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 [RFC2119].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC2119]に記載されているように解釈されます。
This section defines a subset of OCSPRequest and OCSPResponse functionality as defined in [OCSP].
このセクションでは、[OCSP]で定義されるようOCSPRequestとOCSPResponse機能のサブセットを定義します。
OCSPRequests conformant to this profile MUST include only one Request in the OCSPRequest.RequestList structure.
このプロファイルに準拠OCSPRequestsはOCSPRequest.RequestList構造で唯一のリクエストを含まなければなりません。
Clients MUST use SHA1 as the hashing algorithm for the CertID.issuerNameHash and the CertID.issuerKeyHash values.
クライアントはCertID.issuerNameHashとCertID.issuerKeyHash値のためのハッシュアルゴリズムとしてSHA1を使用しなければなりません。
Clients MUST NOT include the singleRequestExtensions structure.
クライアントはsingleRequestExtensions構造を含んではいけません。
Clients SHOULD NOT include the requestExtensions structure. If a requestExtensions structure is included, this profile RECOMMENDS that it contain only the nonce extension (id-pkix-ocsp-nonce). See Section 4 for issues concerning the use of a nonce in high-volume OCSP environments.
クライアントはrequestExtensions構造を含めるべきではありません。 requestExtensions構造が含まれている場合、このプロファイルは、それだけナンス拡張（ID-PKIX-OCSP-ノンス）を含有することをお勧めします。大量のOCSP環境におけるナンスの使用に関する問題については、第4章を参照してください。
Clients SHOULD NOT send signed OCSPRequests. Responders MAY ignore the signature on OCSPRequests.
クライアントが署名したOCSPRequestsを送るべきではありません。レスポンダはOCSPRequestsの署名を無視してもよいです。
If the OCSPRequest is signed, the client SHALL specify its name in the OCSPRequest.requestorName field; otherwise, clients SHOULD NOT include the requestorName field in the OCSPRequest. OCSP servers MUST be prepared to receive unsigned OCSP requests that contain the requestorName field, but must realize that the provided value is not authenticated.
OCSPRequestが署名されている場合、クライアントはOCSPRequest.requestorNameフィールドにその名前を指定しなければなりません。そうでない場合、クライアントはOCSPRequestにrequestorNameフィールドを含めるべきではありません。 OCSPサーバは、requestorNameフィールドが含まれている符号なしのOCSP要求を受信するために準備しなければなりませんが、提供された値が認証されていないことを認識しなければなりません。
Responders MUST generate a BasicOCSPResponse as identified by the id-pkix-ocsp-basic OID. Clients MUST be able to parse and accept a BasicOCSPResponse. OCSPResponses conformant to this profile SHOULD include only one SingleResponse in the ResponseData.responses structure, but MAY include additional SingleResponse elements if necessary to improve response pre-generation performance or cache efficiency.
ID-PKIX-OCSP塩基性OIDによって識別される応答はBasicOCSPResponseを生成しなければなりません。クライアントはBasicOCSPResponseを解析し、受け入れることができなければなりません。このプロファイルに準拠OCSPResponsesはResponseData.responses構造に唯一SingleResponseを含むべきであるが、必要に応じて応答プリ発電性能やキャッシュ効率を向上させるために、追加のSingleResponseの要素を含んでもよいです。
The responder SHOULD NOT include responseExtensions. As specified in [OCSP], clients MUST ignore unrecognized non-critical responseExtensions in the response.
レスポンダはresponseExtensionsを含むべきではありません。 [OCSP]で指定されているように、クライアントが応答で認識されていない非クリティカルresponseExtensionsを無視しなければなりません。
In the case where a responder does not have the ability to respond to an OCSP request containing a option not supported by the server, it SHOULD return the most complete response it can. For example, in the case where a responder only supports pre-produced responses and does not have the ability to respond to an OCSP request containing a nonce, it SHOULD return a response that does not include a nonce.
レスポンダは、サーバーでサポートされていないオプションを含むOCSP要求に応答する能力を持っていない場合には、それはそれができる最も完全な応答を返すべきです。例えば、応答者のみ事前生成応答をサポートし、nonceを含むOCSP要求に応答する能力を持っていない場合には、それはナンスが含まれていないレスポンスを返すべきです。
Clients SHOULD attempt to process a response even if the response does not include a nonce. See Section 4 for details on validating responses that do not contain a nonce. See also Section 7 for relevant security considerations.
応答がナンスが含まれていない場合でも、クライアントが応答を処理しようとすべきです。ナンスを含まない応答を検証する方法の詳細については、セクション4を参照してください。また、関連するセキュリティ上の考慮事項については、セクション7を参照してください。
Responders that do not have the ability to respond to OCSP requests that contain an unsupported option such as a nonce MAY forward the request to an OCSP responder capable of doing so.
こうしたそうすることのできるOCSPレスポンダに要求を転送することができるナンスとしてサポートされていないオプションが含まれているOCSP要求に応答する能力を持っていないレスポンダ。
The responder MAY include the singleResponse.singleResponse extensions structure.
レスポンダはsingleResponse.singleResponse拡張構造を含んでいてもよいです。
Clients MUST validate the signature on the returned OCSPResponse.
クライアントは、返されたOCSPResponseの署名を検証する必要があります。
If the response is signed by a delegate of the issuing certification authority (CA), a valid responder certificate MUST be referenced in the BasicOCSPResponse.certs structure.
応答が発行する認証局（CA）の代理人によって署名されている場合、有効なレスポンダ証明書はBasicOCSPResponse.certs構造で参照する必要があります。
It is RECOMMENDED that the OCSP responder's certificate contain the id-pkix-ocsp-nocheck extension, as defined in [OCSP], to indicate to the client that it need not check the certificate's status. In addition, it is RECOMMENDED that neither an OCSP authorityInfoAccess (AIA) extension nor cRLDistributionPoints (CRLDP) extension be included in the OCSP responder's certificate. Accordingly, the responder's signing certificate SHOULD be relatively short-lived and renewed regularly.
それは、証明書の状態をチェックする必要がないことをクライアントに示すために、[OCSP]で定義されていることは、OCSPレスポンダの証明書は、ID-PKIX-OCSP-NOCHECK拡張が含まれていることが推奨されます。また、OCSP authorityInfoAccess（AIA）の拡張子もcRLDistributionPoints（CRLDP）拡張機能のどちらもOCSPレスポンダの証明書に含まれることが推奨されます。したがって、応答の署名証明書は比較的短命と定期的に更新されるべきです。
Clients MUST be able to identify OCSP responder certificates using both the byName and byKey ResponseData.ResponderID choices. Responders SHOULD use byKey to further reduce the size of the response in scenarios where reducing bandwidth is an issue.
クライアントはBYNAMEとbyKey ResponseData.ResponderIDの選択肢の両方を使用して、OCSPレスポンダ証明書を特定できなければなりません。レスポンダは、さらに帯域幅を低減することが課題となっているシナリオでは、応答のサイズを小さくするためにbyKey使用すべきです。
As long as the OCSP infrastructure has authoritative records for a particular certificate, an OCSPResponseStatus of "successful" will be returned. When access to authoritative records for a particular certificate is not available, the responder MUST return an OCSPResponseStatus of "unauthorized". As such, this profile extends the RFC 2560 [OCSP] definition of "unauthorized" as follows:
限りOCSPインフラストラクチャは、特定の証明書の正式な記録を持っているとして、「成功」のOCSPResponseStatusが返されます。特定の証明書の権威記録へのアクセスが利用できない場合は、応答者は「不正」のOCSPResponseStatusを返さなければなりません。このように、このプロファイルは、以下のように「不正」のRFC 2560 [OCSP]の定義を拡張します。
The response "unauthorized" is returned in cases where the client is not authorized to make this query to this server or the server is not capable of responding authoritatively.
「不正」の応答は、クライアントがこのサーバーには、このクエリを作成する権限がないか、サーバーが正式に応答できないされた場合に返されます。
For example, OCSP responders that do not have access to authoritative records for a requested certificate, such as those that generate and distribute OCSP responses in advance and thus do not have the ability to properly respond with a signed "successful" yet "unknown" response, will respond with an OCSPResponseStatus of "unauthorized". Also, in order to ensure the database of revocation information does not grow unbounded over time, the responder MAY remove the status records of expired certificates. Requests from clients for certificates whose record has been removed will result in an OCSPResponseStatus of "unauthorized".
たとえば、これを生成し、事前にOCSP応答を配布しているものとして要求された証明書の正式な記録へのアクセスを持っていないOCSPレスポンダは、適切に署名「成功」はまだ「不明」応答で応答する能力を持っていません、「不正」のOCSPResponseStatusで応答します。また、時間をかけて無制限に成長しない失効情報のデータベースを確保するために、応答者は、期限切れの証明書のステータスレコードを削除することができます。レコードの削除された「不正」のOCSPResponseStatusになります証明書のクライアントからの要求。
Security considerations regarding the use of unsigned responses are discussed in [OCSP].
符号なしの応答の使用に関するセキュリティ上の考慮事項は、[OCSP]で議論されています。
When pre-producing OCSPResponse messages, the responder MUST set the thisUpdate, nextUpdate, and producedAt times as follows:
メッセージをOCSPResponse事前に製造する場合、以下のように、レスポンダはthisUpdateの、nextUpdateの、およびproducedAt時間を設定する必要があります。
thisUpdate The time at which the status being indicated is known to be correct.
ステータスが表示されるthisUpdateの時間が正確であることが知られています。
nextUpdate The time at or before which newer information will be available about the status of the certificate. Responders MUST always include this value to aid in response caching. See Section 6 for additional information on caching.
時刻をnextUpdateのか、その前に、より新しい情報は、証明書のステータスについて利用できるようになります。レスポンダは、常に応答キャッシュを支援するために、この値を含まなければなりません。キャッシングに関する追加情報については、セクション6を参照してください。
producedAt The time at which the OCSP response was signed.
OCSP応答が署名された時刻をproducedAt。
Note: In many cases the value of thisUpdate and producedAt will be the same.
注：多くの場合、thisUpdateおよびproducedAtの値が同じになります。
For the purposes of this profile, ASN.1-encoded GeneralizedTime values such as thisUpdate, nextUpdate, and producedAt MUST be expressed Greenwich Mean Time (Zulu) and MUST include seconds (i.e., times are YYYYMMDDHHMMSSZ), even where the number of seconds is zero. GeneralizedTime values MUST NOT include fractional seconds.
このプロファイルの目的のために、そのようなthisUpdateの、nextUpdateの、及びproducedAtとしてASN.1エンコードGeneralizedTimeの値は、グリニッジ標準時（ズールー）で表さなければならなくて、秒数であっても秒（すなわち、倍YYYYMMDDHHMMSSZある）、含まなければなりませんゼロ。 GeneralizedTimeの値は、小数点以下の秒を含んではいけません。
Clients MUST support the authorityInfoAccess extension as defined in [PKIX] and MUST recognize the id-ad-ocsp access method. This enables CAs to inform clients how they can contact the OCSP service.
クライアントは、[PKIX]で定義されるようauthorityInfoAccess拡張をサポートしなければならないし、ID-AD-OCSPアクセス方式を認識しなければなりません。これは、彼らがOCSPサービスに連絡することができますどのようにクライアントに通知するためにCAを可能にします。
In the case where a client is checking the status of a certificate that contains both an authorityInformationAccess (AIA) extension pointing to an OCSP responder and a cRLDistributionPoints extension pointing to a CRL, the client SHOULD attempt to contact the OCSP responder first. Clients MAY attempt to retrieve the CRL if no OCSPResponse is received from the responder after a locally configured timeout and number of retries.
クライアントは、OCSPレスポンダとCRLを指すcRLDistributionPoints拡張を指しauthorityInformationAccess（AIA）拡張の両方を含む証明書のステータスをチェックする場合に、クライアントは最初のOCSPレスポンダに連絡を試みます。クライアントは何OCSPResponseがローカルに設定されたタイムアウトと再試行回数後に応答者から受信されない場合、CRLを取得しようとすることができます。
To avoid needless network traffic, applications MUST verify the signature of signed data before asking an OCSP client to check the status of certificates used to verify the data. If the signature is invalid or the application is not able to verify it, an OCSP check MUST NOT be requested.
不要なネットワークトラフィックを避けるために、アプリケーションは、データを検証するために使用される証明書のステータスを確認するOCSPクライアントを尋ねる前に、署名されたデータの署名を検証しなければなりません。署名が無効であるか、アプリケーションがそれを確認できない場合、OCSPチェックが要求されてはなりません。
Similarly, an application MUST validate the signature on certificates in a chain, before asking an OCSP client to check the status of the certificate. If the certificate signature is invalid or the application is not able to verify it, an OCSP check MUST NOT be requested. Clients SHOULD NOT make a request to check the status of expired certificates.
同様に、アプリケーションは、証明書のステータスを確認するOCSPクライアントを尋ねる前に、チェーン内の証明書の署名を検証する必要があります。証明書の署名が無効であるか、アプリケーションがそれを確認できない場合、OCSPチェックが要求されてはなりません。クライアントは、期限切れの証明書の状態を確認するための要求を行うべきではありません。
In order to ensure that a client does not accept an out-of-date response that indicates a 'good' status when in fact there is a more up-to-date response that specifies the status of 'revoked', a client must ensure the responses they receive are fresh.
実際に「取り消された」の状態を指定し、より最新の応答があった場合、クライアントは「良い」状態を示し期限切れの応答を受け入れていないことを確実にするために、クライアントが確認する必要があります彼らが受け取る応答が新鮮です。
In general, two mechanisms are available to clients to ensure a response is fresh. The first uses nonces, and the second is based on time. In order for time-based mechanisms to work, both clients and responders MUST have access to an accurate source of time.
一般的には、2つのメカニズムが、応答が新鮮であることを確認するために、クライアントにご利用いただけます。最初は、ナンスを使用し、第二は、時間に基づいています。時間ベースのメカニズムが機能するためには、両方のクライアントおよび応答時間の正確なソースにアクセスしなければなりません。
Because this profile specifies that clients SHOULD NOT include a requestExtensions structure in OCSPRequests (see Section 2.1), clients MUST be able to determine OCSPResponse freshness based on an accurate source of time. Clients that opt to include a nonce in the request SHOULD NOT reject a corresponding OCSPResponse solely on the basis of the nonexistent expected nonce, but MUST fall back to validating the OCSPResponse based on time.
このプロファイルは、クライアントがOCSPRequests（セクション2.1を参照）requestExtensions構造を含むべきではないことを指定するので、クライアントは時間の正確なソースに基づいてOCSPResponse鮮度を決定できなければなりません。要求でnonceを含めることを選ぶクライアントは、単に存在しない、期待ナンスに基づいて対応するOCSPResponseを拒否するべきではありませんが、時間に基づいてOCSPResponseを有効にフォールバックしなければなりません。
Clients that do not include a nonce in the request MUST ignore any nonce that may be present in the response.
要求でnonceを含まないクライアントは応答中に存在する可能性のあるnonceを無視しなければなりません。
Clients MUST check for the existence of the nextUpdate field and MUST ensure the current time, expressed in GMT time as described in Section 2.2.4, falls between the thisUpdate and nextUpdate times. If the nextUpdate field is absent, the client MUST reject the response.
クライアントはnextUpdateのフィールドが存在するかどうかを確認しなければならないと現在の時間を確保しなければならない、2.2.4項で説明したように、GMT時間で表現thisUpdateおよびnextUpdateの時間の間に入ります。 nextUpdateのフィールドが存在しない場合、クライアントは応答を拒絶しなければなりません。
If the nextUpdate field is present, the client MUST ensure that it is not earlier than the current time. If the current time on the client is later than the time specified in the nextUpdate field, the client MUST reject the response as stale. Clients MAY allow configuration of a small tolerance period for acceptance of responses after nextUpdate to handle minor clock differences relative to responders and caches. This tolerance period should be chosen based on the accuracy and precision of time synchronization technology available to the calling application environment. For example, Internet peers with low latency connections typically expect NTP time synchronization to keep them accurate within parts of a second; higher latency environments or where an NTP analogue is not available may have to be more liberal in their tolerance.
nextUpdateのフィールドが存在する場合、クライアントは、それが現在の時刻よりも早くないことを確認する必要があります。クライアントの現在の時刻がnextUpdateのフィールドで指定した時間より後であれば、クライアントは古くなったとして、応答を拒絶しなければなりません。クライアントは、nextUpdateの後の応答の受け入れのための小さな許容差期間の設定が応答し、キャッシュへの相対的なマイナークロック違いを処理することを可能にします。この許容範囲期間は、呼び出し元のアプリケーション環境で使用可能な時刻同期技術の正確さと精度に基づいて選択する必要があります。例えば、低遅延接続でインターネットピアは通常、第二の部分の中に正確にそれらを保つために、NTP時刻同期を期待します。 NTPアナログが利用できない高いレイテンシーの環境や自分の許容範囲でより自由でなければならないことがあります。
See the security considerations in Section 7 for additional details on replay and man-in-the-middle attacks.
リプレイやman-in-the-middle攻撃に関する詳細については、セクション7におけるセキュリティの考慮事項を参照してください。
The OCSP responder MUST support requests and responses over HTTP. When sending requests that are less than or equal to 255 bytes in total (after encoding) including the scheme and delimiters (http://), server name and base64-encoded OCSPRequest structure, clients MUST use the GET method (to enable OCSP response caching). OCSP requests larger than 255 bytes SHOULD be submitted using the POST method. In all cases, clients MUST follow the descriptions in A.1.1 of [OCSP] when constructing these messages.
OCSPレスポンダは、HTTP経由で要求と応答をサポートしなければなりません。以下のスキーム及びデリミタ（HTTP：//）を含む（符号化後）合計255バイトに等しいリクエスト送信時に、サーバ名とbase64エンコードOCSPRequest構造を、クライアントがOCSP応答を有効にする（GETメソッドを使用する必要がありますキャッシング）。 OCSPは、255バイトより大きいが、POSTメソッドを使用して提出することを要求します。すべての場合において、クライアントはこれらのメッセージを作成するときに[OCSP]のA.1.1で説明に従わなければなりません。
When constructing a GET message, OCSP clients MUST base64 encode the OCSPRequest structure and append it to the URI specified in the AIA extension [PKIX]. Clients MUST NOT include CR or LF characters in the base64-encoded string. Clients MUST properly URL-encode the base64 encoded OCSPRequest. For example:
GETメッセージを構築する場合、OCSPクライアントは、Base64はOCSPRequest構造をコードし、AIA拡張[PKIX]で指定されたURIに追加しなければなりません。クライアントは、base64でエンコードされた文字列にCRまたはLF文字を含んではいけません。クライアントは、適切にURLエンコードしなければならないOCSPRequest base64エンコード。例えば：
http://ocsp.example.com/MEowSDBGMEQwQjAKBggqhkiG9w0CBQQQ7sp6GTKpL 2dAdeGaW267owQQqInESWQD0mGeBArSgv%2FBWQIQLJx%2Fg9xF8oySYzol80Mbpg %3D%3D
http：//ossp.eksample.kom/MEovsDVGMEYavkyaKBgggnkiG9v0TsVYaGG7spbGTKpl 2dAdeZhaV267ovkYakInESVKD0mZheBArSzhv％2FVVKIKLZhs 2Fg9hF8ooSIzol80Mbpg ZD ZD %%%
In response to properly formatted OCSPRequests that are cachable (i.e., responses that contain a nextUpdate value), the responder will include the binary value of the DER encoding of the OCSPResponse preceded by the following HTTP [HTTP] headers.
適切にキャッシュ可能（nextUpdateの値を含む、すなわち、応答）であるOCSPRequestsをフォーマットすることに応答して、レスポンダは、以下のHTTP [HTTP]ヘッダーによって先行OCSPResponseのDERエンコーディングのバイナリ値を含むであろう。
content-type: application/ocsp-response content-length: <OCSP response length> last-modified: <producedAt [HTTP] date> ETag: "<strong validator>" expires: <nextUpdate [HTTP] date> cache-control: max-age=<n>, public, no-transform, must-revalidate date: <current [HTTP] date>
コンテンツタイプ：アプリケーション/ OCSP応答のコンテンツ長：<OCSP応答長>最終変更：<producedAt [HTTP]日付>のETag： "<強いバリ>" 有効期限：<nextUpdateの[HTTP]日付>キャッシュコントロール：最大エージング= <n>は、公共、無変換、必要があり、再検証の日付：<現在の[HTTP]日付>
See Section 6.2 for details on the use of these headers.
これらのヘッダの使用の詳細については、セクション6.2を参照してください。
The ability to cache OCSP responses throughout the network is an important factor in high volume OCSP deployments. This section discusses the recommended caching behavior of OCSP clients and HTTP proxies and the steps that should be taken to minimize the number of times that OCSP clients "hit the wire". In addition, the concept of including OCSP responses in protocol exchanges (aka stapling or piggybacking), such as has been defined in TLS, is also discussed.
ネットワーク全体OCSP応答をキャッシュする機能は、大量のOCSPの展開における重要な要因です。このセクションでは、OCSPクライアントとHTTPプロキシおよびOCSPクライアントは「ワイヤを打つ」というの回数を最小限に抑えるように注意する必要がある手順の推奨キャッシュ動作について説明します。加えて、そのようなTLSで定義されているとして（ステープル又はピギーバック別名）プロトコル交換でOCSP応答を含むの概念は、また議論されています。
To minimize bandwidth usage, clients MUST locally cache authoritative OCSP responses (i.e., a response with a signature that has been successfully validated and that indicate an OCSPResponseStatus of 'successful').
帯域幅の使用を最小限に抑えるために、クライアントは、ローカルにキャッシュ権威OCSP応答は、（すなわち、正常に検証されている署名との応答が「成功」のOCSPResponseStatusを示す）しなければなりません。
Most OCSP clients will send OCSPRequests at or near the nextUpdate time (when a cached response expires). To avoid large spikes in responder load that might occur when many clients refresh cached responses for a popular certificate, responders MAY indicate when the client should fetch an updated OCSP response by using the cache-control:max-age directive. Clients SHOULD fetch the updated OCSP Response on or after the max-age time. To ensure that clients receive an updated OCSP response, OCSP responders MUST refresh the OCSP response before the max-age time.
（キャッシュされたレスポンスの有効期限が切れたとき）ほとんどのOCSPクライアントがnextUpdateの時間またはその近くでOCSPRequestsを送信します。 MAX-ageディレクティブ：クライアントがキャッシュコントロールを使用して、更新されたOCSP応答を取得する必要があるとき、多くのクライアントが人気の証明書のキャッシュされた応答を更新するときに発生する可能性がある応答負荷の大きなスパイクを避けるために、応答が示している場合があります。クライアントは、最大エージング時間日以降に更新されOCSP応答を取得すべきです。クライアントが更新されたOCSP応答を受け取ることを保証するために、OCSPレスポンダは、最大エージング時間前にOCSP応答を更新する必要があります。
The responder SHOULD set the HTTP headers of the OCSP response in such a way as to allow for the intelligent use of intermediate HTTP proxy servers. See [HTTP] for the full definition of these headers and the proper format of any date and time values.
レスポンダは、中間HTTPプロキシサーバのインテリジェントな使用を可能にするような方法で、OCSPレスポンスのHTTPヘッダーを設定する必要があります。これらのヘッダーの完全な定義と任意の日付と時刻の値の適切なフォーマットのために[HTTP]を参照してください。
HTTP Header Description
=========== ====================================================
date The date and time at which the OCSP server generated
the HTTP response.
last-modified This value specifies the date and time at which the OCSP responder last modified the response. This date and time will be the same as the thisUpdate timestamp in the request itself.
最終更新この値は、OCSPレスポンダが最後の応答を変更した日付と時刻を指定します。この日時は、要求自体にthisUpdateのタイムスタンプと同じになります。
expires Specifies how long the response is considered fresh. This date and time will be the same as the nextUpdate timestamp in the OCSP response itself.
応答が新鮮とみなされる期間を指定します有効期限が切れます。この日付と時刻がOCSP応答自体にnextUpdateのタイムスタンプと同じになります。
ETag A string that identifies a particular version of the associated data. This profile RECOMMENDS that the ETag value be the ASCII HEX representation of the SHA1 hash of the OCSPResponse structure.
関連データの特定のバージョンを識別する文字列をETAG。このプロファイルは、ETagの値がOCSPResponse構造のSHA1ハッシュのASCIIのHEX表現することをお勧めします。
cache-control Contains a number of caching directives.
キャッシュ制御は、キャッシュディレクティブの数が含まれています。
* max-age=<n> -where n is a time value later than
thisUpdate but earlier than
nextUpdate.
* public -makes normally uncachable response cachable by both shared and nonshared caches.
両方の共有および非共有キャッシュにより、キャッシュ可能*公共-makes通常は非キャッシュ可能な応答。
* no-transform -specifies that a proxy cache cannot change the type, length, or encoding of the object content.
プロキシキャッシュは、タイプ、長さ、またはオブジェクトのコンテンツのエンコーディングを変更することはできません*無変換指定します。
* must-revalidate -prevents caches from intentionally returning stale responses.
*意図的に古くなったレスポンスを返すから-preventsキャッシュを-再検証しなければなりません。
OCSP responders MUST NOT include a "Pragma: no-cache", "Cache-Control: no-cache", or "Cache-Control: no-store" header in authoritative OCSP responses.
、 "のCache-Control：キャッシュなし"、または "のCache-Control：なしストア" 権威OCSP応答のヘッダー：OCSPレスポンダは、 "キャッシュなしプラグマ" を含んではいけません。
OCSP responders SHOULD include one or more of these headers in non-authoritative OCSP responses.
OCSPレスポンダは、権限のないOCSP応答でこれらのヘッダーの1つまたは複数を含むべきです。
For example, assume that an OCSP response has the following timestamp values:
例えば、OCSP応答は、次のタイムスタンプ値を有すると仮定する。
thisUpdate = May 1, 2005 01:00:00 GMT nextUpdate = May 3, 2005 01:00:00 GMT productedAt = May 1, 2005 01:00:00 GMT
thisUpdateの= 2005年5月1日午前1時00分00秒GMTのnextUpdate = 2005年5月3日= 2005年5月1日午前1時00分00秒GMT午前1時00分00秒GMT productedAt
and that an OCSP client requests the response on May 2, 2005 01:00:00 GMT. In this scenario, the HTTP response may look like this:
そして、OCSPクライアントは2005年5月2日1時00分00秒GMTの応答を要求していること。このシナリオでは、HTTPレスポンスは次のようになります。
content-type: application/ocsp-response content-length: 1000 date: Fri, 02 May 2005 01:00:00 GMT last-modified: Thu, 01 May 2005 01:00:00 GMT ETag: "c66c0341abd7b9346321d5470fd0ec7cc4dae713" expires: Sat, 03 May 2005 01:00:00 GMT cache-control: max-age=86000,public,no-transform,must-revalidate <...>
コンテンツタイプ：アプリケーション/ OCSP応答のコンテンツ長：1000日付：最終更新日（金）、2005年5月2日1時00分00秒GMT：木、2005年5月1日1時00分00秒GMTのETagを：「c66c0341abd7b9346321d5470fd0ec7cc4dae713は」期限が切れる：土を、2005年5月3日1時○○分00秒GMTキャッシュコントロール：最大エージング= 86000、国民は、無変換、<...>、再検証する必要があり
OCSP clients MUST NOT include a no-cache header in OCSP request messages, unless the client encounters an expired response which may be a result of an intermediate proxy caching stale data. In this situation, clients SHOULD resend the request specifying that proxies should be bypassed by including an appropriate HTTP header in the request (i.e., Pragma: no-cache or Cache-Control: no-cache).
クライアントは、中間プロキシキャッシング古いデータの結果であり得る期限切れの応答に遭遇しない限り、OCSPクライアントは、OCSP要求メッセージでないキャッシュ・ヘッダを含んではいけません。この状況では、クライアントは、プロキシが、要求（：ノーキャッシュまたはキャッシュ・コントロール：なしキャッシュ即ち、プラグマ）における適切なHTTPヘッダーを含めることによってバイパスされるべきであることを指定する要求を再送信すべきです。
In some scenarios, it is advantageous to include OCSP response information within the protocol being utilized between the client and server. Including OCSP responses in this manner has a few attractive effects.
いくつかのシナリオでは、クライアントとサーバとの間で利用されるプロトコル内OCSPレスポンス情報を含めることが有利です。このように含むOCSP応答は、いくつかの魅力的な効果を持っています。
First, it allows for the caching of OCSP responses on the server, thus lowering the number of hits to the OCSP responder.
まず、それはこのようにOCSPレスポンダにヒット数を下げ、サーバー上のOCSP応答のキャッシングが可能になります。
Second, it enables certificate validation in the event the client is not connected to a network and thus eliminates the need for clients to establish a new HTTP session with the responder.
第二に、それは、クライアントがネットワークに接続されていない場合には、証明書の検証を可能にし、したがって、クライアントが応答して新しいHTTPセッションを確立する必要性がなくなります。
Third, it reduces the number of round trips the client needs to make in order to complete a handshake.
第三に、それは、クライアントがハンドシェイクを完了するために行う必要があるのラウンドトリップの回数を減らします。
Fourth, it simplifies the client-side OCSP implementation by enabling a situation where the client need only the ability to parse and recognize OCSP responses.
第四に、それは、クライアントが唯一のOCSP応答を解析し、認識する能力を必要とする状況を有効にすることで、クライアント側のOCSPの実装を簡素化します。
This functionality has been specified as an extension to the TLS [TLS] protocol in Section 3.6 [TLSEXT], but can be applied to any client-server protocol.
この機能は、セクション3.6 [TLSEXT]でTLS [TLS]プロトコルの拡張として指定されているが、任意のクライアントサーバプロトコルに適用することができます。
This profile RECOMMENDS that both TLS clients and servers implement the certificate status request extension mechanism for TLS.
このプロファイルは、TLSクライアントとサーバの両方が、TLSの証明書のステータス要求拡張メカニズムを実装することをお勧めします。
Further information regarding caching issues can be obtained from RFC 3143 [RFC3143].
キャッシュの問題に関するさらなる情報は、RFC 3143 [RFC3143]から得ることができます。
The following considerations apply in addition to the security considerations addressed in Section 5 of [OCSP].
次の考慮事項は、[OCSP]のセクション5で対処セキュリティの考慮事項に加えて適用されます。
Because the use of nonces in this profile is optional, there is a possibility that an out of date OCSP response could be replayed, thus causing a client to accept a good response when in fact there is a more up-to-date response that specifies the status of revoked. In order to mitigate this attack, clients MUST have access to an accurate source of time and ensure that the OCSP responses they receive are sufficiently fresh.
このプロファイルでナンスの使用は任意であるため、日付OCSP応答のうちは、このように実際には、より最新の応答が指定されていることがある場合に良好な応答を受け入れるようにクライアントを起こし、再生することができてしまう可能性がありますステータスが取り消さ。この攻撃を軽減するために、クライアントは、時間の正確なソースへのアクセスを持って、彼らが受け取るOCSP応答が十分に新鮮であることを確認しなければなりません。
Clients that do not have an accurate source of date and time are vulnerable to service disruption. For example, a client with a sufficiently fast clock may reject a fresh OCSP response. Similarly a client with a sufficiently slow clock may incorrectly accept expired valid responses for certificates that may in fact be revoked.
日付と時刻の正確なソースを持っていないクライアントは、サービスの中断に対して脆弱です。例えば、十分に高速なクロックを持つクライアントは、新鮮なOCSP応答を拒否することができます。同様に十分に遅いクロックを持つクライアントが間違って実際に取り消すことができる証明書の期限切れの有効回答を受け入れることができます。
Future versions of the OCSP protocol may provide a way for the client to know whether the server supports nonces or does not support nonces. If a client can determine that the server supports nonces, it MUST reject a reply that does not contain an expected nonce. Otherwise, clients that opt to include a nonce in the request SHOULD NOT reject a corresponding OCSPResponse solely on the basis of the nonexistent expected nonce, but MUST fall back to validating the OCSPResponse based on time.
OCSPプロトコルの将来のバージョンでは、クライアントは、サーバがナンスをサポートしていますかナンスをサポートしていないかどうかを知るための方法を提供することができます。クライアントは、サーバがナンスをサポートしていることを判断することができれば、それは予想されるnonceを含んでいない回答を拒絶しなければなりません。それ以外の場合は、要求でnonceを含めることを選ぶのクライアントは、単に存在しない、期待ナンスに基づいて対応するOCSPResponseを拒否するべきではありませんが、時間に基づいてOCSPResponseを有効にフォールバックしなければなりません。
To mitigate risk associated with this class of attack, the client must properly validate the signature on the response.
攻撃のこのクラスに関連するリスクを軽減するために、クライアントは適切に応答の署名を検証する必要があります。
The use of signed responses in OCSP serves to authenticate the identity of the OCSP responder and to verify that it is authorized to sign responses on the CA's behalf.
OCSPで署名した応答を使用することは、OCSPレスポンダの身元を認証するために、CAに代わって応答に署名する権限があることを確認するのに役立ちます。
Clients MUST ensure that they are communicating with an authorized responder by the rules described in [OCSP], Section 4.2.2.2.
クライアントは、彼らが[OCSP]、セクション4.2.2.2に記載されたルールによって認可レスポンダと通信していることを確認しなければなりません。
The use of signed responses in OCSP serves to authenticate the identity of OCSP responder.
OCSPで署名した応答を使用することは、OCSPレスポンダのIDを認証するのに役立ちます。
As detailed in [OCSP], clients must properly validate the signature of the OCSP response and the signature on the OCSP response signer certificate to ensure an authorized responder created it.
[OCSP]に詳述されているように、クライアントが適切に作成された認可応答を確実にするために、OCSP応答の署名者証明書にOCSP応答の署名と署名を検証しなければなりません。
OCSP responders should take measures to prevent or mitigate denial-of-service attacks. As this profile specifies the use of unsigned OCSPRequests, access to the responder may be implicitly given to everyone who can send a request to a responder, and thus the ability to mount a denial-of-service attack via a flood of requests may be greater. For example, a responder could limit the rate of incoming requests from a particular IP address if questionable behavior is detected.
OCSPレスポンダは、サービス拒否攻撃を防止または軽減するための措置をとるべきです。このプロファイルは、符号なしOCSPRequestsの使用を指定すると、レスポンダーへのアクセスが暗黙的にレスポンダにリクエストを送ることができるすべての人に与えられることができるので、要求の洪水を経由してサービス拒否攻撃をマウントする能力が大きくてもよいです。疑わしい動作が検出された場合例えば、応答者は、特定のIPアドレスからの着信要求のレートを制限することができます。
Values included in HTTP headers, as described in Sections 5 and 6, are not cryptographically protected; they may be manipulated by an attacker. Clients SHOULD use these values for caching guidance only and ultimately SHOULD rely only on the values present in the signed OCSPResponse. Clients SHOULD NOT rely on cached responses beyond the nextUpdate time.
セクション5および6に記載したように、HTTPヘッダに含まれる値は、暗号で保護されていません。彼らは、攻撃者によって操作することができます。唯一の署名OCSPResponse中に存在する値に依存すべきであるクライアントは、唯一、最終的に指導をキャッシュするため、これらの値を使用すべきです。クライアントはnextUpdateの時間を越えて、キャッシュされた応答に依存すべきではありません。
The suggested use of unsigned requests in this environment removes an option that allows the responder to determine the authenticity of incoming request. Thus, access to the responder may be implicitly given to everyone who can send a request to a responder. Environments where explicit authorization to access the OCSP responder is necessary can utilize other mechanisms to authenticate requestors or restrict or meter service.
この環境では、符号なしのリクエストを示唆した使用は、応答者が着信要求の正当性を決定することを可能にするオプションを削除します。このように、応答者へのアクセスは、暗黙的にレスポンダにリクエストを送ることができるすべての人に与えてもよいです。 OCSPレスポンダにアクセスするための明示的な許可が必要である環境では、リクエスタを認証したり、サービスを制限またはメートルする他の機構を利用することができます。
The authors wish to thank Magnus Nystrom of RSA Security, Inc., Jagjeet Sondh of Vodafone Group R&D, and David Engberg of CoreStreet, Ltd. for their contributions to this specification.
著者は、この仕様書への貢献のためにRSA Security社のマグナスNystrom、ボーダフォン・グループR＆DのJagjeet Sondh、およびCoreStreetのデビッドEngberg、（株）に感謝したいです。
[HTTP] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[HTTP]フィールディング、R.、ゲティス、J.、モーグル、J.、Frystyk、H.、Masinter、L.、リーチ、P.、およびT.バーナーズ - リー、 "ハイパーテキスト転送プロトコル - HTTP / 1.1" 、RFC 2616、1999年6月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[OCSP] 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.
[OCSP]マイヤーズ、M.、Ankney、R.、Malpani、A.、Galperin、S.、およびC.アダムス、 "X.509のインターネットの公開鍵暗号基盤：オンライン証明書状態プロトコル - OCSP"、RFC 2560、1999年6月。
[PKIX] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet Public Key Infrastructure - Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, April 2002.
[PKIX] Housley氏、R.、ポーク、W.、フォード、W.、およびD.ソロ、 "インターネット公開鍵インフラストラクチャ - 証明書と証明書失効リスト（CRL）プロフィール"、RFC 3280、2002年4月。
[TLS] Dierks, T. and E. Rescorla, "The Transport Layer Security Protocol Version 1.1", RFC 4346, April 2006.
[TLS]ダークス、T.およびE.レスコラ、 "トランスポート層セキュリティプロトコルバージョン1.1"、RFC 4346、2006年4月。
[TLSEXT] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., and T. Wright, "Transport Layer Security (TLS) Extensions", RFC 4366, April 2006.
[TLSEXT]ブレイク・ウィルソン、S.、Nystrom、M.、ホップウッド、D.、ミケルセン、J.、およびT.ライト、 "トランスポート層セキュリティ（TLS）拡張機能"、RFC 4366、2006年4月。
[OCSPMP] "OCSP Mobile Profile V1.0", Open Mobile Alliance, www.openmobilealliance.org.
[OCSPMP] "OCSPのモバイルプロファイルV1.0"、オープン・モバイル・アライアンス、www.openmobilealliance.org。
[RFC3143] Cooper, I. and J. Dilley, "Known HTTP Proxy/Caching Problems", RFC 3143, June 2001.
[RFC3143]クーパー、I.およびJ.ディリー、 "既知のHTTPプロキシ/キャッシュの問題"、RFC 3143、2001年6月。
Appendix A. Example OCSP Messages
付録A.例OCSPメッセージ
A.1. OCSP Request
A.1。 OCSPリクエスト
SEQUENCE { SEQUENCE { SEQUENCE { SEQUENCE { SEQUENCE { SEQUENCE { OBJECT IDENTIFIER sha1 (1 3 14 3 2 26) NULL } OCTET STRING C0 FE 02 78 FC 99 18 88 91 B3 F2 12 E9 C7 E1 B2 1A B7 BF C0 OCTET STRING 0D FC 1D F0 A9 E0 F0 1C E7 F2 B2 13 17 7E 6F 8D 15 7C D4 F6 INTEGER 09 34 23 72 E2 3A EF 46 7C 83 2D 07 F8 DC 22 BA } } } } }
SEQUENCE {SEQUENCE {SEQUENCE {SEQUENCE {SEQUENCE {SEQUENCE {オブジェクト識別子SHA1（1 3 14 3 2 26）NULL}オクテット文字列C0 FE 02 78 FC 99 18 88 91 B3 F2 12 E9 C7 E1 B2 1AはB7のBF C0オクテットストリング0D FC 1D F0 A9 E0 F0 1C E7 F2 B2 13 17（e）（f）（d）15 7C D4 F6 INTEGER 09 34 23 72 E2 3A EF 46 7C 83 2D 07 F8 DC 22 BA}}}}}
A.2. OCSP Response
A.2。 OCSP応答
SEQUENCE { ENUMERATED 0 [0] { SEQUENCE { OBJECT IDENTIFIER ocspBasic (1 3 6 1 5 5 7 48 1 1) OCTET STRING, encapsulates { SEQUENCE { SEQUENCE { [0] { INTEGER 0 } [1] { SEQUENCE { SET { SEQUENCE { OBJECT IDENTIFIER organizationName (2 5 4 10) PrintableString 'Example Trust Network' } }
SEQUENCE {ENUMERATED 0 [0] {SEQUENCE {オブジェクト識別子ocspBasic（1 3 6 1 5 7 48 1 1）OCTET STRINGを、封入{SEQUENCE {SEQUENCE {[0] {INTEGER 0} [1] {SEQUENCE {SET {SEQUENCE {OBJECT IDENTIFIER organizationNameの（2 5 4 10）はPrintableString '例信頼ネットワーク'}}
SET {
SEQUENCE {
OBJECT IDENTIFIER
organizationalUnitName (2 5 4 11)
PrintableString 'Example, Inc.'
}
}
SET {
SEQUENCE {
OBJECT IDENTIFIER
organizationalUnitName (2 5 4 11)
PrintableString
'Example OCSP Responder'
}
}
}
}
GeneralizedTime 07/11/2005 23:52:44 GMT
SEQUENCE {
SEQUENCE {
SEQUENCE {
SEQUENCE {
OBJECT IDENTIFIER sha1 (1 3 14 3 2 26)
NULL
}
OCTET STRING
C0 FE 02 78 FC 99 18 88 91 B3 F2 12 E9 C7 E1 B2
1A B7 BF C0
OCTET STRING
0D FC 1D F0 A9 E0 F0 1C E7 F2 B2 13 17 7E 6F 8D
15 7C D4 F6
INTEGER
09 34 23 72 E2 3A EF 46 7C 83 2D 07 F8 DC 22 BA
}
[0]
Error: Object has zero length.
GeneralizedTime 07/11/2005 23:52:44 GMT
[0] {
GeneralizedTime 14/11/2005 23:52:44 GMT
}
}
}
}
SEQUENCE {
OBJECT IDENTIFIER
sha1withRSAEncryption (1 2 840 113549 1 1 5)
NULL
}
BIT STRING 0E 9F F0 52 B1 A7 42 B8 6E C1 35 E1 0E D5 A9 E2 F5 C5 3C 16 B1 A3 A7 A2 03 8A 2B 4D 2C F1 B4 98 8E 19 DB BA 1E 1E 72 FF 32 F4 44 E0 B2 77 1C D7 3C 9E 78 F3 D1 82 68 86 63 12 7F A4 6F F0 4D 84 EA F8 E2 F7 5D E3 48 44 57 28 80 C7 57 3C FE E1 42 0E 5E 17 FC 60 D8 05 D9 EF E2 53 E7 AB 7F 3A A8 84 AA 5E 46 5B E7 B8 1F C6 B1 35 AD FF D1 CC BA 58 7D E8 29 60 79 F7 41 02 EA E0 82 0E A6 30 [0] { SEQUENCE { SEQUENCE { SEQUENCE { [0] { INTEGER 2 } INTEGER 49 4A 02 37 1B 1E 70 67 41 6C 9F 06 2F D8 FE DA SEQUENCE { OBJECT IDENTIFIER sha1withRSAEncryption (1 2 840 113549 1 1 5) NULL } SEQUENCE { SET { SEQUENCE { OBJECT IDENTIFIER organizationName (2 5 4 10) PrintableString 'Example Trust Network' } } SET { SEQUENCE { OBJECT IDENTIFIER organizationalUnitName (2 5 4 11) PrintableString 'Example, Inc.' } } SET { SEQUENCE { OBJECT IDENTIFIER organizationalUnitName (2 5 4 11) PrintableString 'Example CA' } } } SEQUENCE {
ビット列0E 9F F0 52 B1 A7 42 B8 6E C1 35 E1 0E D5 A9 E2 F5 C5 3C 16 B1 A3 A7 A2 03（a）（b）（d）（c）F1 B4 98 8E 19 DB BA 1E 1E 72 FF 32 F4 44 E0 B2 77 1C D7 3C 9E 78 F3 D1 82 68 86 63 12 7F A4 6F F0 4D 84 EA F8 E2 F7 5D E3 48 44 57 28 80 C7 57 3C FE E1 42 0E 5E 17 FC 60 D8 05 D9 EF E2 53 E7 AB 7F 3A A8 84 AA 5E 46 5B E7 B8 1F C6 B1を35 AD FF D1 CC BA 58 7D E8 29 60 79 F7 41 02 EA E0 82 0E A6 30 [0] {SEQUENCE {SEQUENCE {SEQUENCE {[0] {INTEGER 2} INTEGER 49 4A 02 37 1B〜1E 70 67 41 6C 9F 06 2F D8 FE DA SEQUENCE {オブジェクト識別子sha1withRSAEncryption（1 2 840 113549 1 1 5）NULL} SEQUENCE {SET {SEQUENCE {オブジェクト識別子organizationNameの（2 5 4 10）はPrintableString「例信頼ネットワーク'}} SET {SEQUENCE {OBJECT IDENTIFIER organizationalUnitName（2 5 4 11）はPrintableString '例株式会社' }} SET {SEQUENCE {OBJECT IDENTIFIER organizationalUnitName（2 5 4 11）はPrintableString '例CA'}}}列{
UTCTime 08/10/2005 00:00:00 GMT
UTCTime 06/01/2006 23:59:59 GMT
}
SEQUENCE {
SET {
SEQUENCE {
OBJECT IDENTIFIER
organizationName (2 5 4 10)
PrintableString 'Example Trust Network'
}
}
SET {
SEQUENCE {
OBJECT IDENTIFIER
organizationalUnitName (2 5 4 11)
PrintableString 'Example, Inc.'
}
}
SET {
SEQUENCE {
OBJECT IDENTIFIER
organizationalUnitName (2 5 4 11)
PrintableString
'Example OCSP Responder'
}
}
}
SEQUENCE {
SEQUENCE {
OBJECT IDENTIFIER
rsaEncryption (1 2 840 113549 1 1 1)
NULL
}
BIT STRING, encapsulates {
SEQUENCE {
INTEGER
00 AF C9 7A F5 09 CA D1 08 8C 82 6D AC D9 63 4D
D2 64 17 79 CB 1E 1C 1C 0C 6E 28 56 B5 16 4A 4A
00 1A C1 B0 74 D7 B4 55 9D 2A 99 1F 0E 4A E3 5F
81 AF 8D 07 23 C3 30 28 61 3F B0 C8 1D 4E A8 9C
A6 32 B4 D2 63 EC F7 C1 55 7A 73 2A 51 99 00 D5
0F B2 4E 11 5B 83 55 83 4C 0E DD 12 0C BD 7E 41
04 3F 5F D9 2A 65 88 3C 2A BA 20 76 1D 1F 59 3E
D1 85 F7 4B E2 81 50 9C 78 96 1B 37 73 12 1A D2
[ Another 1 bytes skipped ]
INTEGER 65537
}
}
} [3] { SEQUENCE { SEQUENCE { OBJECT IDENTIFIER basicConstraints (2 5 29 19) OCTET STRING, encapsulates { SEQUENCE {} } } SEQUENCE { OBJECT IDENTIFIER extKeyUsage (2 5 29 37) OCTET STRING, encapsulates { SEQUENCE { OBJECT IDENTIFIER ocspSigning (1 3 6 1 5 5 7 3 9) } } } SEQUENCE { OBJECT IDENTIFIER keyUsage (2 5 29 15) OCTET STRING, encapsulates { BIT STRING 7 unused bits '1'B (bit 0) } } SEQUENCE { OBJECT IDENTIFIER ocspNoCheck (1 3 6 1 5 5 7 48 1 5) OCTET STRING, encapsulates { NULL } } } } } SEQUENCE { OBJECT IDENTIFIER sha1withRSAEncryption (1 2 840 113549 1 1 5) NULL } BIT STRING 3A 68 5F 6A F8 87 36 4A E2 22 46 5C C8 F5 0E CE 1A FA F2 25 E1 51 AB 37 BE D4 10 C8 15 93 39 73 C8 59 0F F0 39 67 29 C2 60 20 F7 3F FE A0 37 AB 80 0B F9 3D 38 D4 48 67 E4 FA FD 4E 12 BF 55 29 14 E9 CC CB DD 13 82 E9 C4 4D D3 85 33 C1 35 E5 8F 38 01 A7 F7 FD EB CD DE F2 F7 85 86 AE E3 1B
} [3] {SEQUENCE {SEQUENCE {オブジェクト識別子basicConstraintsの（2 5 29 19）OCTET STRINGを、封入{SEQUENCE {}}}列{OBJECT IDENTIFIER extKeyUsage（2 5 29 37）OCTET STRINGを、{SEQUENCE {OBJECT IDENTIFIER ocspSigning（カプセル化1 3 6 1 5 7 3 9）}}}列{OBJECT IDENTIFIERのkeyUsage（2 5 29 15）OCTET STRINGをカプセル化{ビット列7未使用ビット「1'B（ビット0）}}列{OBJECT IDENTIFIER ocspNoCheck（ 1 3 6 1 5 7 48 1 5）オクテット文字列は、{NULL}}}}} SEQUENCE {オブジェクト識別子sha1withRSAEncryptionをカプセル化（1 2 840 113549 1 1 5）NULL}ビット列3A 68 5F 6AのF8 87 36 4A E2 22 46 5C C8 F5 0E CE 1A FA F2 25 E1 51 ABは37 D4 10 C8 15 93 39 73 C8 59 0F F0 39 67 29 C2 60 20 F7 3F FE A0 37 AB 80 0B F9 3D 38 D4 48 67 E4 FA FD 4E BE 12 BF 55 29 14 E9 CC CB DD 13 82 E9 C4 4D D3 85 33 C1 35 E5 8F 38 01 A7 F7 FD EB CD DE F2 F7 85 86 AE E3 1B
9C FD 1D 07 E5 28 F2 A0 5E AC BF 9E 0B 34 A1 B4 3A A9 0E C5 8A 34 3F 65 D3 10 63 A4 5E 21 71 5A } } } } } } } }
NPP PD 1E 07 28 E5 F2 A0 5E AC BF八重0B ZCH A1 BX綾0E 5 FOR 8AのZCH ZF 65 I 10オメガああ5E 21 71（a）}}}}}}}}
Authors' Addresses
著者のアドレス
Alex Deacon VeriSign, Inc. 487 E. Middlefield Road Mountain View, CA 94043 USA
アレックス・ディーコンベリサイン社487 E.ミドルロード、マウンテンビュー、CA 94043 USA
Phone: 1-650-426-3478 EMail: alex@verisign.com
電話：1-650-426-3478 Eメール：alex@verisign.com
Ryan Hurst Microsoft One Microsoft Way Redmond, WA 98052 USA
ライアン・ハーストマイクロソフト1マイクロソフト道、レッドモンド、ワシントン98052 USA
Phone: 1-425-707-8979 EMail: rmh@microsoft.com
電話：1-425-707-8979 Eメール：rmh@microsoft.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（C）IETFトラスト（2007）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。