[要約] RFC 5019は、高容量環境向けの軽量なオンライン証明書ステータスプロトコル（OCSP）プロファイルに関するものです。このRFCの目的は、高負荷環境でのOCSPの効率的な運用を可能にするためのガイドラインを提供することです。
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を大規模（大量）公開キーインフラストラクチャ（PKI）環境で使用する場合、および/または最小化するために軽量ソリューションを必要とするPKI環境で、OCSPを使用する場合に固有のスケーラビリティの問題に対処するオンライン証明書ステータスプロトコル（OCSP）のプロファイルを定義します。通信帯域幅とクライアント側の処理。
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レスポンダーの負荷を保証するような方法で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: 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.
このドキュメントは、メッセージプロファイルを定義し、OCSPクライアントと応答行動を許可することにより、上記のPKI環境で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.
このプロファイルで定義されている規範的要件は、OCSPクライアントと非常に大規模な（大量の）PKI環境または帯域幅とクライアント側の処理電源を最小限に抑えるための軽量ソリューションを必要とするPKI環境で動作する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].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「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構造に1つのリクエストのみを含める必要があります。
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構造が含まれている場合、このプロファイルは、nonce拡張機能（id-pkix-ocsp-nonce）のみを含むことを推奨しています。大量のOCSP環境でのNonCEの使用に関する問題については、セクション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-BASIC OIDによって識別されるように、BasicOcSpresponseを生成する必要があります。クライアントは、BasicocsSpresponseを解析して受け入れることができる必要があります。このプロファイルに適合しているOCSPONSESは、ResponseData.Responses構造に1つのSingleresponseのみを含める必要がありますが、必要に応じて、応答前の生成前のパフォーマンスまたはキャッシュ効率を改善するために追加のSingleresponse要素を含めることができます。
The responder SHOULD NOT include responseExtensions. As specified in [OCSP], clients MUST ignore unrecognized non-critical responseExtensions in the response.
応答者には、ResponseExtensionsを含めるべきではありません。[OCSP]で指定されているように、クライアントは、応答における認識されていない非批判的な応答エクステンションを無視する必要があります。
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リクエストに応答する能力がない場合、NonCEを含まない応答を返す必要があります。
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.
クライアントは、応答にNONCEが含まれていない場合でも、応答を処理しようとする必要があります。NonCEを含まない回答の検証の詳細については、セクション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.
NONCEなどのサポートされていないオプションを含む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 Responderの証明書には、証明書のステータスを確認する必要がないことをクライアントに示すために、ID-PKIX-OCSP-Nocheck拡張機能を含めることをお勧めします。さらに、OCSP AuthoridInfoAccess（AIA）拡張機能も、OCSP Responderの証明書にcrldistributionPoints（CRLDP）拡張を含めないことをお勧めします。したがって、レスポンダーの署名証明書は比較的短命であり、定期的に更新されるべきです。
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レスポンダー証明書を識別できる必要があります。レスポンダーは、帯域幅を減らすことが問題であるシナリオで応答のサイズをさらに削減するために、Keyがキーを使用する必要があります。
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、および作成時間を設定する必要があります。
thisUpdate The time at which the status being indicated is known to be correct.
これにより、示されているステータスが正しいことが知られている時間がわかっています。
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.
NextDate証明書のステータスに関する新しい情報が利用可能になる時間以前に。応答者は、応答キャッシュを支援するために、常にこの価値を含める必要があります。キャッシュに関する追加情報については、セクション6を参照してください。
producedAt The time at which the OCSP response was signed.
OCSP応答が署名された時間で生成されました。
Note: In many cases the value of thisUpdate and producedAt will be the same.
注：多くの場合、Thisupdateと生産の値は同じになります。
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、および生産などのAsn.1がエンコードされた一般化された時間値は、グリニッジ平均時間（Zulu）を表現する必要があり、秒数（つまり、時間はyyyymmdhhmmsz）を含めなければなりません。ゼロ。一般化された時間値は、分数秒を含めてはなりません。
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アクセス方法を認識する必要があります。これにより、CASはクライアントにOCSPサービスに連絡する方法を通知できます。
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 Responderを指すAuthorityInformationAccess（AIA）拡張機能とCRLを指すCRLDISSTRIBUTIONPOINS拡張の両方を含む証明書のステータスをチェックしている場合、クライアントは最初にOCSP Responderに連絡しようとする必要があります。ローカルで構成されたタイムアウトとRETRIESの数の後、クライアントはResponderから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つのメカニズムを利用でき、応答が新鮮であることを確認します。1つ目はNoncesを使用し、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にRequestExtensions構造を含めるべきではないことを指定しているため（セクション2.1を参照）、クライアントは正確な時間源に基づいてOCSSpresponseの新鮮さを決定できる必要があります。リクエストにNonCeを含めることを選択したクライアントは、存在しない予想されるNonCEに基づいて対応するOCSSpresponseを拒否すべきではなく、時間に基づいて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.
クライアントは、[次のアップデート]フィールドの存在を確認する必要があり、セクション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の時間同期が1秒以内にそれらを正確に保つことを期待しています。より高いレイテンシ環境またはNTPアナログが利用できない場合、それらの耐性においてよりリベラルでなければならないかもしれません。
See the security considerations in Section 7 for additional details on replay and man-in-the-middle attacks.
リプレイと中間攻撃の詳細については、セクション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：//）、サーバー名、base64エンコードのocsprequest構造を含む合計255バイト以下（エンコード後）を送信する場合、クライアントはgetメソッドを使用する必要があります（OCSP応答を有効にするにはキャッシング）。OCSP要求は、POSTメソッドを使用して255バイトを超える要求を提出する必要があります。すべての場合において、クライアントはこれらのメッセージを作成するときに[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クライアントはOCSPRequest構造をBase64ベースでエンコードし、AIA拡張機能[PKIX]で指定されたURIに追加する必要があります。クライアントは、Base64エンコード文字列にCRまたはLF文字を含めてはなりません。クライアントは、base64エンコードされたocsprequestを適切にurl-encodeする必要があります。例えば：
http://ocsp.example.com/MEowSDBGMEQwQjAKBggqhkiG9w0CBQQQ7sp6GTKpL 2dAdeGaW267owQQqInESWQD0mGeBArSgv%2FBWQIQLJx%2Fg9xF8oySYzol80Mbpg %3D%3D
http://ocsp.example.com/meowsdbgmeqwqwqjakbggggig9w0cbqq7sp6gtkpl 2dadegaw267owqqqineswqd0mgebarsgv％2fbwqiqljx％2fg9xf8oyzol80mbpg％3d％3d％3d％3d％3d％3d％3d％3d
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.
キャッシュ可能な適切にフォーマットされた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>
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応答をローカルにキャッシュする必要があります（つまり、「成功」のOCSSPONSESTUSを示す署名を含む応答）。
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時間またはその近くでOCSPRequestを送信します（キャッシュされた応答が期限切れになった場合）。多くのクライアントが一般的な証明書のキャッシュされた応答を更新したときに発生する可能性のあるレスポンダー負荷の大規模なスパイクを回避するために、レスポンダーは、クライアントがキャッシュコントロール：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.
LASTMODIFIEDこの値は、OCSP Responderが最後に応答を変更した日時を指定します。この日付と時刻は、リクエスト自体の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.
* max -age = <n> -here nは、nextdateよりも早くnは時間値です。
* public -makes normally uncachable response cachable by both shared and nonshared caches.
* 一般的なメイクは、通常、共有キャッシュと非シャレッドキャッシュの両方でキャッシュ可能なキャッシュ可能です。
* no-transform -specifies that a proxy cache cannot change the type, length, or encoding of the object content.
* transform-プロキシキャッシュがオブジェクトコンテンツのタイプ、長さ、またはエンコードを変更できないことを指定します。
* must-revalidate -prevents caches from intentionally returning stale responses.
* 必要に応じて、意図的に戻ってきた古い応答からのキャッシュを再評価する必要があります。
OCSP responders MUST NOT include a "Pragma: no-cache", "Cache-Control: no-cache", or "Cache-Control: no-store" header in authoritative OCSP responses.
OCSPレスポンダーは、「プラグマ：ノーキャッシュ」、「キャッシュコントロール：ノーキャッシュ」、または「キャッシュコントロール：ノーストア」ヘッダーを権威あるOCSP応答に含めてはなりません。
OCSP responders SHOULD include one or more of these headers in non-authoritative OCSP responses.
OCSPレスポンダーは、これらのヘッダーの1つ以上を非認証OCSP応答に含める必要があります。
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
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日01: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 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ヘッダーを含めることにより、プロキシをバイパスする必要があることを指定するリクエストを再送信する必要があります（つまり、Pragma：No-CacheまたはCache-Control：No-Cache）。
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.
第4に、クライアントが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.
このプロファイルでのNoncesの使用はオプションであるため、時代遅れの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プロトコルの将来のバージョンは、クライアントがサーバーがNoncesをサポートしているか、Noncesをサポートしていないかを知る方法を提供する場合があります。クライアントがサーバーがnoncesをサポートしていることを判断できる場合、予想されるNonCEを含まない返信を拒否する必要があります。それ以外の場合、リクエストにNonCEを含めることを選択したクライアントは、存在しない予想されるNonCEに基づいて対応するOCSSPRESPONSEを拒否すべきではなく、時間に基づいて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レスポンダーのIDを認証し、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.
著者は、Vodafone Group R＆DのJagjeet SondhのRSA Security、Inc.のMagnus Nystromと、この仕様への貢献についてCorestreetのDavid 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] Fielding、R.、Gettys、J.、Mogul、J.、Frystyk、H.、Masinter、L.、Leach、P。、およびT. Berners-Lee、「ハイパーテキスト転送プロトコル-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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、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] Myers、M.、Ankney、R.、Malpani、A.、Galperin、S.、およびC. Adams、「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.、Polk、W.、Ford、W.、およびD. Solo、「インターネット公開キーインフラストラクチャ - 証明書および証明書取消リスト（CRL）プロファイル」、RFC 3280、2002年4月。
[TLS] Dierks, T. and E. Rescorla, "The Transport Layer Security Protocol Version 1.1", RFC 4346, April 2006.
[TLS] Dierks、T。およびE. Rescorla、「The Transport Layer Security Protocolバージョン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] Blake-Wilson、S.、Nystrom、M.、Hopwood、D.、Mikkelsen、J。、およびT. Wright、「Transport Layer Security（TLS）Extensions」、RFC 4366、2006年4月。
[OCSPMP] "OCSP Mobile Profile V1.0", Open Mobile Alliance, www.openmobilealliance.org.
[OCSPMP] "OCSP Mobile Profile v1.0"、Open Mobile Alliance、www.openmobilealliance.org。
[RFC3143] Cooper, I. and J. Dilley, "Known HTTP Proxy/Caching Problems", RFC 3143, June 2001.
[RFC3143] Cooper、I。およびJ. Dilley、「既知のHTTPプロキシ/キャッシュ問題」、RFC 3143、2001年6月。
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 {
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'
}
}
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 {
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
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
}
}
}
}
}
}
}
}
Authors' Addresses
著者のアドレス
Alex Deacon VeriSign, Inc. 487 E. Middlefield Road Mountain View, CA 94043 USA
Alex Deacon Verisign、Inc。487 E. Middlefield Road Mountain View、CA 94043 USA
Phone: 1-650-426-3478 EMail: alex@verisign.com
電話：1-650-426-3478メール：alex@verisign.com
Ryan Hurst Microsoft One Microsoft Way Redmond, WA 98052 USA
ライアンハーストマイクロソフトワンマイクロソフトウェイレドモンド、ワシントン州98052 USA
Phone: 1-425-707-8979 EMail: rmh@microsoft.com
電話：1-425-707-8979メール：rmh@microsoft.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（c）The IETF Trust（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。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への情報をお問い合わせください。