[要約] RFC 6960は、X.509証明書の有効性をリアルタイムで確認するためのプロトコルであるOnline Certificate Status Protocol (OCSP) に関するものです。このプロトコルは、証明書の失効情報を迅速に取得することを可能にし、セキュリティの強化と効率的な証明書管理を実現します。OCSPは、WebサーバーのSSL/TLS証明書の検証など、デジタル証明書が広く使用される場面で利用されます。関連するRFCには、RFC 5280 (X.509証明書とCRLのプロファイル) やRFC 2560 (OCSPの先行バージョン) などがあります。
Internet Engineering Task Force (IETF) S. Santesson
Request for Comments: 6960 3xA Security
Obsoletes: 2560, 6277 M. Myers
Updates: 5912 TraceRoute Security
Category: Standards Track R. Ankney
ISSN: 2070-1721
A. Malpani
CA Technologies
S. Galperin
A9
C. Adams
University of Ottawa
June 2013
X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP
X.509インターネット公開鍵インフラストラクチャのオンライン証明書ステータスプロトコル-OCSP
Abstract
概要
This document specifies a protocol useful in determining the current status of a digital certificate without requiring Certificate Revocation Lists (CRLs). Additional mechanisms addressing PKIX operational requirements are specified in separate documents. This document obsoletes RFCs 2560 and 6277. It also updates RFC 5912.
このドキュメントでは、証明書失効リスト（CRL）を必要とせずに、デジタル証明書の現在のステータスを判別するのに役立つプロトコルを規定しています。 PKIXの運用要件に対処する追加のメカニズムは、別のドキュメントで指定されています。このドキュメントはRFC 2560と6277を廃止します。また、RFC 5912を更新します。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6960.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6960で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2013 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................4
1.1. Requirements Language ......................................5
2. Protocol Overview ...............................................5
2.1. Request ....................................................5
2.2. Response ...................................................6
2.3. Exception Cases ............................................8
2.4. Semantics of thisUpdate, nextUpdate, and producedAt ........9
2.5. Response Pre-Production ....................................9
2.6. OCSP Signature Authority Delegation .......................10
2.7. CA Key Compromise .........................................10
3. Functional Requirements ........................................10
3.1. Certificate Content .......................................10
3.2. Signed Response Acceptance Requirements ...................10
4. Details of the Protocol ........................................11
4.1. Request Syntax ............................................11
4.1.1. ASN.1 Specification of the OCSP Request ............11
4.1.2. Notes on OCSP Requests .............................13
4.2. Response Syntax ...........................................14
4.2.1. ASN.1 Specification of the OCSP Response ...........14
4.2.2. Notes on OCSP Responses ............................16
4.2.2.1. Time ......................................16
4.2.2.2. Authorized Responders .....................16
4.2.2.2.1. Revocation Checking of
an Authorized Responder ........17
4.2.2.3. Basic Response ............................18
4.3. Mandatory and Optional Cryptographic Algorithms ...........19
4.4. Extensions ................................................19
4.4.1. Nonce ..............................................20
4.4.2. CRL References .....................................20
4.4.3. Acceptable Response Types ..........................20
4.4.4. Archive Cutoff .....................................21
4.4.5. CRL Entry Extensions ...............................21
4.4.6. Service Locator ....................................22
4.4.7. Preferred Signature Algorithms .....................22
4.4.7.1. Extension Syntax ..........................23
4.4.7.2. Responder Signature Algorithm Selection ...24
4.4.7.2.1. Dynamic Response ...............24
4.4.7.2.2. Static Response ................25
4.4.8. Extended Revoked Definition ........................25
5. Security Considerations ........................................26
5.1. Preferred Signature Algorithms ............................27
5.1.1. Use of Insecure Algorithms .........................27
5.1.2. Man-in-the-Middle Downgrade Attack .................27
5.1.3. Denial-of-Service Attack ...........................28
6. IANA Considerations ............................................28
7. References .....................................................28
7.1. Normative References ......................................28
7.2. Informative References ....................................29
8. Acknowledgements ...............................................29
Appendix A. OCSP over HTTP ........................................30
A.1. Request ....................................................30
A.2. Response ...................................................30
Appendix B. ASN.1 Modules .........................................30
B.1. OCSP in ASN.1 - 1998 Syntax ................................31
B.2. OCSP in ASN.1 - 2008 Syntax ................................34
Appendix C. MIME Registrations ....................................39
C.1. application/ocsp-request ...................................39
C.2. application/ocsp-response ..................................40
This document specifies a protocol useful in determining the current status of a digital certificate without requiring CRLs. Additional mechanisms addressing PKIX operational requirements are specified in separate documents.
このドキュメントでは、CRLを必要とせずにデジタル証明書の現在のステータスを判断するのに役立つプロトコルを規定しています。 PKIXの運用要件に対処する追加のメカニズムは、別のドキュメントで指定されています。
This specification obsoletes [RFC2560] and [RFC6277]. The primary reason for the publication of this document is to address ambiguities that have been found since the publication of RFC 2560. This document differs from RFC 2560 in only a few areas:
この仕様は[RFC2560]と[RFC6277]を廃止しました。このドキュメントを公開する主な理由は、RFC 2560の公開以降に発見されたあいまいさを解決するためです。このドキュメントは、RFC 2560といくつかの点でのみ異なります。
o Section 2.2 extends the use of the "revoked" response to allow this response status for certificates that have never been issued.
o セクション2.2は、「失効した」応答の使用を拡張して、発行されたことのない証明書に対してこの応答ステータスを許可します。
o Section 2.3 extends the use of the "unauthorized" error response, as specified in [RFC5019].
o 2.3節では、[RFC5019]で指定されている「不正な」エラー応答の使用を拡張しています。
o Sections 4.2.1 and 4.2.2.3 state that a response may include revocation status information for certificates that were not included in the request, as permitted in [RFC5019].
o セクション4.2.1および4.2.2.3は、[RFC5019]で許可されているように、要求に含まれていなかった証明書の失効ステータス情報が応答に含まれる場合があることを述べています。
o Section 4.2.2.2 clarifies when a responder is considered an Authorized Responder.
o セクション4.2.2.2は、レスポンダが承認されたレスポンダと見なされる場合を明確にします。
o Section 4.2.2.3 clarifies that the ResponderID field corresponds to the OCSP responder signer certificate.
o セクション4.2.2.3では、ResponderIDフィールドがOCSPレスポンダー署名者証明書に対応することを明確にしています。
o Section 4.3 changes the set of cryptographic algorithms that clients must support and the set of cryptographic algorithms that clients should support as specified in [RFC6277].
o セクション4.3は、[RFC6277]で指定されているように、クライアントがサポートする必要がある暗号化アルゴリズムのセットとクライアントがサポートする必要がある暗号化アルゴリズムのセットを変更します。
o Section 4.4.1 specifies, for the nonce extension, ASN.1 syntax that was missing in RFC 2560.
o セクション4.4.1は、ノンス拡張について、RFC 2560で欠落していたASN.1構文を指定しています。
o Section 4.4.7 specifies a new extension that may be included in a request message to specify signature algorithms the client would prefer the server use to sign the response as specified in [RFC6277].
o セクション4.4.7は、リクエストメッセージに含めることができる新しい拡張を指定して、[RFC6277]で指定されているように、クライアントがサーバーが応答に署名するために使用することを好む署名アルゴリズムを指定します。
o Section 4.4.8 specifies a new extension that indicates that the responder supports the extended use of the "revoked" response for non-issued certificates defined in Section 2.2.
o セクション4.4.8は、レスポンダがセクション2.2で定義された発行されていない証明書に対する「取り消された」応答の拡張された使用をサポートすることを示す新しい拡張を指定します。
o Appendix B.2 provides an ASN.1 module using the 2008 syntax of ASN.1, which updates [RFC5912].
o 付録B.2は、ASN.1の2008構文を使用して[RFC5912]を更新するASN.1モジュールを提供します。
An overview of the protocol is provided in Section 2. Functional requirements are specified in Section 3. Details of the protocol are discussed in Section 4. We cover security issues with the protocol in Section 5. Appendix A defines OCSP over HTTP, Appendix B provides ASN.1 syntactic elements, and Appendix C specifies the MIME types for the messages.
プロトコルの概要はセクション2で提供されています。機能要件はセクション3で指定されています。プロトコルの詳細はセクション4で説明されています。プロトコルのセキュリティ問題はセクション5で取り上げます。付録AはOCSP over HTTPを定義し、付録BはASN.1構文要素、および付録Cでは、メッセージのMIMEタイプを指定しています。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 RFC 2119 [RFC2119]で説明されているように解釈されます。
In lieu of, or as a supplement to, checking against a periodic CRL, it may be necessary to obtain timely information regarding the revocation status of certificates (cf. [RFC5280], Section 3.3). Examples include high-value funds transfers or large stock trades.
定期的なCRLをチェックする代わりに、またはその補足として、証明書の失効ステータスに関するタイムリーな情報を入手する必要がある場合があります（[RFC5280]、セクション3.3を参照）。例としては、高額の資金移動や大規模な株式取引などがあります。
The Online Certificate Status Protocol (OCSP) enables applications to determine the (revocation) state of identified certificates. OCSP may be used to satisfy some of the operational requirements of providing more timely revocation information than is possible with CRLs and may also be used to obtain additional status information. An OCSP client issues a status request to an OCSP responder and suspends acceptance of the certificates in question until the responder provides a response.
オンライン証明書ステータスプロトコル（OCSP）を使用すると、アプリケーションは識別された証明書の（失効）状態を判断できます。 OCSPは、CRLで可能なものよりもタイムリーな失効情報を提供するという運用要件の一部を満たすために使用でき、追加のステータス情報を取得するためにも使用できます。 OCSPクライアントは、OCSPレスポンダにステータス要求を発行し、レスポンダが応答を提供するまで、問題の証明書の受け入れを一時停止します。
This protocol specifies the data that needs to be exchanged between an application checking the status of one or more certificates and the server providing the corresponding status.
このプロトコルは、1つ以上の証明書のステータスをチェックするアプリケーションと、対応するステータスを提供するサーバーとの間で交換する必要があるデータを指定します。
An OCSP request contains the following data:
OCSP要求には、次のデータが含まれています。
- protocol version
- プロトコルバージョン
- service request
- サービス要求
- target certificate identifier
- ターゲット証明書識別子
- optional extensions, which MAY be processed by the OCSP responder Upon receipt of a request, an OCSP responder determines if:
- OCSPレスポンダーによって処理される可能性があるオプションの拡張機能要求を受信すると、OCSPレスポンダーは次のことを判断します。
1. the message is well formed,
1. メッセージは整形式であり、
2. the responder is configured to provide the requested service, and
2. レスポンダは、要求されたサービスを提供するように構成されています。
3. the request contains the information needed by the responder.
3. リクエストには、レスポンダが必要とする情報が含まれています。
If any one of these conditions is not met, the OCSP responder produces an error message; otherwise, it returns a definitive response.
これらの条件のいずれかが満たされない場合、OCSPレスポンダはエラーメッセージを生成します。それ以外の場合は、最終的な応答を返します。
OCSP responses can be of various types. An OCSP response consists of a response type and the bytes of the actual response. There is one basic type of OCSP response that MUST be supported by all OCSP servers and clients. The rest of this section pertains only to this basic response type.
OCSP応答にはさまざまなタイプがあります。 OCSP応答は、応答タイプと実際の応答のバイトで構成されます。すべてのOCSPサーバーおよびクライアントでサポートする必要があるOCSP応答の基本的なタイプが1つあります。このセクションの残りの部分は、この基本的な応答タイプにのみ関係します。
All definitive response messages SHALL be digitally signed. The key used to sign the response MUST belong to one of the following:
すべての明確な応答メッセージはデジタル署名される必要があります。応答の署名に使用されるキーは、次のいずれかに属している必要があります。
- the CA who issued the certificate in question
- 問題の証明書を発行したCA
- a Trusted Responder whose public key is trusted by the requestor
- 公開キーが要求者によって信頼されている信頼できるレスポンダ
- a CA Designated Responder (Authorized Responder, defined in Section 4.2.2.2) who holds a specially marked certificate issued directly by the CA, indicating that the responder may issue OCSP responses for that CA
- CAが直接発行した特別にマークされた証明書を保持し、レスポンダがそのCAに対してOCSP応答を発行できることを示すCA指定レスポンダ（セクション4.2.2.2で定義された承認レスポンダ）
A definitive response message is composed of:
明確な応答メッセージは、次のもので構成されます。
- version of the response syntax
- 応答構文のバージョン
- identifier of the responder
- レスポンダの識別子
- time when the response was generated
- 応答が生成された時間
- responses for each of the certificates in a request
- リクエスト内の各証明書の応答
- optional extensions
- オプションの拡張機能
- signature algorithm OID
- 署名アルゴリズムOID
- signature computed across a hash of the response The response for each of the certificates in a request consists of:
- 応答のハッシュ全体で計算された署名要求内の各証明書の応答は、以下で構成されます。
- target certificate identifier
- ターゲット証明書識別子
- certificate status value
- 証明書ステータス値
- response validity interval
- 応答の有効期間
- optional extensions
- オプションの拡張機能
This specification defines the following definitive response indicators for use in the certificate status value:
この仕様では、証明書のステータス値で使用するための次の決定的な応答インジケータを定義しています。
- good
- 良い
- revoked
- 取り消された
- unknown
- わからない
The "good" state indicates a positive response to the status inquiry. At a minimum, this positive response indicates that no certificate with the requested certificate serial number currently within its validity interval is revoked. This state does not necessarily mean that the certificate was ever issued or that the time at which the response was produced is within the certificate's validity interval. Response extensions may be used to convey additional information on assertions made by the responder regarding the status of the certificate, such as a positive statement about issuance, validity, etc.
「良好」な状態は、ステータスの問い合わせに対する肯定的な応答を示します。少なくとも、この肯定応答は、要求された証明書のシリアル番号が現在有効期間内にある証明書が取り消されていないことを示しています。この状態は、証明書が発行されたこと、または応答が生成された時間が証明書の有効期間内であることを必ずしも意味しません。応答拡張を使用して、発行者、有効性などに関する肯定的な声明など、証明書のステータスに関してレスポンダが作成したアサーションに関する追加情報を伝えることができます。
The "revoked" state indicates that the certificate has been revoked, either temporarily (the revocation reason is certificateHold) or permanently. This state MAY also be returned if the associated CA has no record of ever having issued a certificate with the certificate serial number in the request, using any current or previous issuing key (referred to as a "non-issued" certificate in this document).
「失効」状態は、証明書が一時的に（失効理由はcertificateHoldである）または永続的に失効したことを示します。この状態は、関連付けられたCAが、現在または以前の発行キー（このドキュメントでは「未発行」の証明書と呼ばれる）を使用して、証明書シリアル番号を持つ証明書を発行したという記録がない場合にも返される場合があります。 。
The "unknown" state indicates that the responder doesn't know about the certificate being requested, usually because the request indicates an unrecognized issuer that is not served by this responder.
「不明」状態は、通常、リクエストがこのレスポンダが対応していない認識できない発行者を示しているため、レスポンダがリクエストされている証明書を認識していないことを示します。
NOTE: The "revoked" status indicates that a certificate with the requested serial number should be rejected, while the "unknown" status indicates that the status could not be determined by this responder, thereby allowing the client to decide whether it wants to try another source of status information (such as a CRL). This makes the "revoked" response suitable for non-issued certificates (as defined above) where the intention of the responder is to cause the client to reject the certificate rather than trying another source of status information. The "revoked" status is still optional for non-issued certificates in order to maintain backwards compatibility with deployments of RFC 2560. For example, the responder may not have any knowledge about whether a requested serial number has been assigned to any issued certificate, or the responder may provide pre-produced responses in accordance with RFC 5019 and, for that reason, is not capable of providing a signed response for all non-issued certificate serial numbers.
注：「失効」ステータスは、要求されたシリアル番号を持つ証明書を拒否する必要があることを示し、「不明」ステータスは、このレスポンダでステータスを判別できなかったことを示します。これにより、クライアントは別の試行を行うかどうかを決定できます。ステータス情報のソース（CRLなど）。これにより、「失効した」応答が発行されていない証明書（上記で定義）に適しており、レスポンダの目的は、ステータス情報の別のソースを試すのではなく、クライアントに証明書を拒否させることです。 RFC 2560の展開との下位互換性を維持するために、発行されていない証明書の「失効」ステータスはオプションです。たとえば、レスポンダは、要求されたシリアル番号が発行された証明書に割り当てられているかどうか、またはレスポンダは、RFC 5019に従って事前に作成された応答を提供する場合があり、そのため、発行されていないすべての証明書のシリアル番号に対して署名付き応答を提供することはできません。
When a responder sends a "revoked" response to a status request for a non-issued certificate, the responder MUST include the extended revoked definition response extension (Section 4.4.8) in the response, indicating that the OCSP responder supports the extended definition of the "revoked" state to also cover non-issued certificates. In addition, the SingleResponse related to this non-issued certificate:
レスポンダが発行されていない証明書のステータス要求に「取り消された」応答を送信する場合、レスポンダは拡張失効定義応答拡張（セクション4.4.8）を応答に含めなければなりません。これは、OCSPレスポンダが発行されていない証明書も対象とする「取り消された」状態。さらに、この発行されていない証明書に関連するSingleResponse：
- MUST specify the revocation reason certificateHold (6),
- 失効理由のcertificateHold（6）を指定する必要があります。
- MUST specify the revocationTime January 1, 1970, and
- 1970年1月1日のrevocationTimeを指定する必要があります。
- MUST NOT include a CRL references extension (Section 4.4.2) or any CRL entry extensions (Section 4.4.5).
- CRL参照拡張（セクション4.4.2）またはCRLエントリ拡張（セクション4.4.5）を含めてはなりません（MUST NOT）。
In case of errors, the OCSP responder may return an error message. These messages are not signed. Errors can be of the following types:
エラーが発生した場合、OCSPレスポンダはエラーメッセージを返すことがあります。これらのメッセージは署名されていません。エラーには次のタイプがあります。
- malformedRequest
- malformedRequest
- internalError
- 内部エラー
- tryLater
- tryLater
- sigRequired
- sigRequired
- unauthorized
- 無許可
A server produces the "malformedRequest" response if the request received does not conform to the OCSP syntax.
受信した要求がOCSP構文に準拠していない場合、サーバーは「malformedRequest」応答を生成します。
The response "internalError" indicates that the OCSP responder reached an inconsistent internal state. The query should be retried, potentially with another responder.
「internalError」という応答は、OCSPレスポンダが一貫性のない内部状態に達したことを示しています。クエリを再試行する必要があります。別のレスポンダを使用する可能性があります。
In the event that the OCSP responder is operational but unable to return a status for the requested certificate, the "tryLater" response can be used to indicate that the service exists but is temporarily unable to respond.
OCSPレスポンダーは動作しているが、要求された証明書のステータスを返すことができない場合、「tryLater」応答を使用して、サービスは存在するが一時的に応答できないことを示すことができます。
The response "sigRequired" is returned in cases where the server requires that the client sign the request in order to construct a response.
「sigRequired」という応答は、サーバーがクライアントが応答を作成するために要求に署名することを要求する場合に返されます。
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 (cf. [RFC5019], Section 2.2.3).
クライアントがこのサーバーに対してこのクエリを実行することを承認されていない場合、またはサーバーが正式に応答できない場合は、「unauthorized」という応答が返されます（[RFC5019]、セクション2.2.3を参照）。
Responses defined in this document can contain four times -- thisUpdate, nextUpdate, producedAt, and revocationTime. The semantics of these fields are:
このドキュメントで定義されている応答は、thisUpdate、nextUpdate、producedAt、およびrevocationTimeの4回を含むことができます。これらのフィールドのセマンティクスは次のとおりです。
thisUpdate The most recent time at which the status being indicated is known by the responder to have been correct.
thisUpdate示されているステータスが応答者によって正しいと認識された最新の時刻。
nextUpdate The time at or before which newer information will be available about the status of the certificate.
nextUpdate証明書のステータスに関する新しい情報が利用できるようになるまでの時間。
producedAt The time at which the OCSP responder signed this response.
generatedAt OCSPレスポンダーがこの応答に署名した時刻。
revocationTime The time at which the certificate was revoked or placed on hold.
revocationTime証明書が取り消された、または保留された時刻。
OCSP responders MAY pre-produce signed responses specifying the status of certificates at a specified time. The time at which the status was known to be correct SHALL be reflected in the thisUpdate field of the response. The time at or before which newer information will be available is reflected in the nextUpdate field, while the time at which the response was produced will appear in the producedAt field of the response.
OCSPレスポンダーは、指定された時刻の証明書のステータスを指定する署名付きの応答を事前に作成してもよい（MAY）。ステータスが正しいことがわかった時刻は、応答のthisUpdateフィールドに反映される必要があります。より新しい情報が利用できるようになるまでの時間はnextUpdateフィールドに反映されますが、応答が生成された時間は応答のgeneratedAtフィールドに表示されます。
The key that signs a certificate's status information need not be the same key that signed the certificate. A certificate's issuer explicitly delegates OCSP signing authority by issuing a certificate containing a unique value for the extended key usage extension (defined in [RFC5280], Section 4.2.1.12) in the OCSP signer's certificate. This certificate MUST be issued directly to the responder by the cognizant CA. See Section 4.2.2.2 for details.
証明書のステータス情報に署名するキーは、証明書に署名したキーと同じである必要はありません。証明書の発行者は、OCSP署名者の証明書に拡張キー使用法拡張（[RFC5280]で定義、セクション4.2.1.12）の一意の値を含む証明書を発行することにより、OCSP署名機関を明示的に委任します。この証明書は、認識CAからレスポンダに直接発行する必要があります。詳細については、4.2.2.2項を参照してください。
If an OCSP responder knows that a particular CA's private key has been compromised, it MAY return the "revoked" state for all certificates issued by that CA.
OCSPレスポンダは、特定のCAの秘密鍵が危険にさらされていることを知っている場合、そのCAによって発行されたすべての証明書の「取り消された」状態を返す場合があります。
In order to convey to OCSP clients a well-known point of information access, CAs SHALL provide the capability to include the authority information access extension (defined in [RFC5280], Section 4.2.2.1) in certificates that can be checked using OCSP. Alternatively, the accessLocation for the OCSP provider may be configured locally at the OCSP client.
OCSPクライアントに既知の情報アクセスポイントを伝達するために、CAはOCSPを使用してチェックできる証明書に機関情報アクセス拡張（[RFC5280]で定義、セクション4.2.2.1）を含める機能を提供する必要があります（SHALL）。または、OCSPプロバイダーのaccessLocationは、OCSPクライアントでローカルに構成できます。
CAs that support an OCSP service, either hosted locally or provided by an Authorized Responder, MUST provide for the inclusion of a value for a Uniform Resource Identifier (URI) [RFC3986] accessLocation and the OID value id-ad-ocsp for the accessMethod in the AccessDescription SEQUENCE.
ローカルでホストされているか、承認済みレスポンダによって提供されているOCSPサービスをサポートするCAは、Uniform Resource Identifier（URI）[RFC3986]の値と、accessMethodのOID値id-ad-ocspを含める必要があります。 AccessDescription SEQUENCE。
The value of the accessLocation field in the subject certificate defines the transport (e.g., HTTP) used to access the OCSP responder and may contain other transport-dependent information (e.g., a URL).
サブジェクト証明書のaccessLocationフィールドの値は、OCSPレスポンダーにアクセスするために使用されるトランスポート（HTTPなど）を定義し、他のトランスポート依存情報（URLなど）を含む場合があります。
Prior to accepting a signed response for a particular certificate as valid, OCSP clients SHALL confirm that:
特定の証明書の署名済み応答を有効であると受け入れる前に、OCSPクライアントは次のことを確認する必要があります。
1. The certificate identified in a received response corresponds to the certificate that was identified in the corresponding request;
1. 受信した応答で識別された証明書は、対応する要求で識別された証明書に対応します。
2. The signature on the response is valid;
2. 応答の署名は有効です。
3. The identity of the signer matches the intended recipient of the request;
3. 署名者のIDは、リクエストの意図された受信者と一致します。
4. The signer is currently authorized to provide a response for the certificate in question;
4. 署名者は現在、問題の証明書に対する応答を提供することを許可されています。
5. The time at which the status being indicated is known to be correct (thisUpdate) is sufficiently recent;
5. 示されているステータスが正しいことがわかっている時刻（thisUpdate）は十分に新しいものです。
6. When available, the time at or before which newer information will be available about the status of the certificate (nextUpdate) is greater than the current time.
6. 利用可能な場合、証明書のステータス（nextUpdate）に関する新しい情報が利用可能になるまでの時間は、現在の時間よりも長くなります。
The ASN.1 syntax imports terms defined in [RFC5280]. For signature calculation, the data to be signed is encoded using the ASN.1 distinguished encoding rules (DER) [X.690].
ASN.1構文は、[RFC5280]で定義された用語をインポートします。署名計算では、署名されるデータは、ASN.1識別符号化規則（DER）[X.690]を使用して符号化されます。
ASN.1 EXPLICIT tagging is used as a default unless specified otherwise.
特に指定のない限り、ASN.1 EXPLICITタギングがデフォルトとして使用されます。
The terms imported from elsewhere are Extensions, CertificateSerialNumber, SubjectPublicKeyInfo, Name, AlgorithmIdentifier, and CRLReason.
他の場所からインポートされた用語は、Extensions、CertificateSerialNumber、SubjectPublicKeyInfo、Name、AlgorithmIdentifier、およびCRLReasonです。
This section specifies the ASN.1 specification for a confirmation request. The actual formatting of the message could vary, depending on the transport mechanism used (HTTP, SMTP, LDAP, etc.).
このセクションでは、確認要求のASN.1仕様を指定します。メッセージの実際のフォーマットは、使用されるトランスポートメカニズム（HTTP、SMTP、LDAPなど）によって異なります。
The ASN.1 structure corresponding to the OCSPRequest is:
OCSPRequestに対応するASN.1構造は次のとおりです。
OCSPRequest ::= SEQUENCE {
tbsRequest TBSRequest,
optionalSignature [0] EXPLICIT Signature OPTIONAL }
TBSRequest ::= SEQUENCE {
version [0] EXPLICIT Version DEFAULT v1,
requestorName [1] EXPLICIT GeneralName OPTIONAL,
requestList SEQUENCE OF Request,
requestExtensions [2] EXPLICIT Extensions OPTIONAL }
Signature ::= SEQUENCE {
signatureAlgorithm AlgorithmIdentifier,
signature BIT STRING,
certs [0] EXPLICIT SEQUENCE OF Certificate
OPTIONAL}
Version ::= INTEGER { v1(0) }
Request ::= SEQUENCE {
reqCert CertID,
singleRequestExtensions [0] EXPLICIT Extensions OPTIONAL }
CertID ::= SEQUENCE {
hashAlgorithm AlgorithmIdentifier,
issuerNameHash OCTET STRING, -- Hash of issuer's DN
issuerKeyHash OCTET STRING, -- Hash of issuer's public key
serialNumber CertificateSerialNumber }
The fields in OCSPRequest have the following meanings:
OCSPRequestのフィールドには次の意味があります。
o tbsRequest is the optionally signed OCSP request.
o tbsRequestは、オプションで署名されたOCSP要求です。
o optionalSignature contains the algorithm identifier and any associated algorithm parameters in signatureAlgorithm; the signature value in signature; and, optionally, certificates the server needs to verify the signed response (normally up to but not including the client's root certificate).
o optionalSignatureには、signatureAlgorithmにアルゴリズム識別子と関連するアルゴリズムパラメータが含まれています。署名の署名値。また、オプションで、サーバーが署名付きの応答を検証するために必要な証明書（通常は、クライアントのルート証明書まで）が含まれます。
The contents of TBSRequest include the following fields:
TBSRequestの内容には、次のフィールドが含まれます。
o version indicates the version of the protocol, which for this document is v1(0).
o versionはプロトコルのバージョンを示し、このドキュメントではv1（0）です。
o requestorName is OPTIONAL and indicates the name of the OCSP requestor.
o requestorNameはオプションであり、OCSPリクエスターの名前を示します。
o requestList contains one or more single certificate status requests.
o requestListには、1つ以上の単一の証明書ステータス要求が含まれています。
o requestExtensions is OPTIONAL and includes extensions applicable to the requests found in reqCert. See Section 4.4.
o requestExtensionsはオプションであり、reqCertにある要求に適用できる拡張機能が含まれています。セクション4.4を参照してください。
The contents of Request include the following fields:
リクエストの内容には、次のフィールドが含まれます。
o reqCert contains the identifier of a target certificate.
o reqCertには、ターゲット証明書の識別子が含まれています。
o singleRequestExtensions is OPTIONAL and includes extensions applicable to this single certificate status request. See Section 4.4.
o singleRequestExtensionsはオプションであり、この単一の証明書ステータス要求に適用できる拡張機能が含まれています。セクション4.4を参照してください。
The contents of CertID include the following fields:
CertIDの内容には、次のフィールドが含まれます。
o hashAlgorithm is the hash algorithm used to generate the issuerNameHash and issuerKeyHash values.
o hashAlgorithmは、issuerNameHashおよびissuerKeyHashの値を生成するために使用されるハッシュアルゴリズムです。
o issuerNameHash is the hash of the issuer's distinguished name (DN). The hash shall be calculated over the DER encoding of the issuer's name field in the certificate being checked.
o issuerNameHashは、発行者の識別名（DN）のハッシュです。ハッシュは、チェックされている証明書の発行者の名前フィールドのDERエンコーディングで計算されます。
o issuerKeyHash is the hash of the issuer's public key. The hash shall be calculated over the value (excluding tag and length) of the subject public key field in the issuer's certificate.
o issuerKeyHashは、発行者の公開鍵のハッシュです。ハッシュは、発行者の証明書のサブジェクト公開キーフィールドの値（タグと長さを除く）に対して計算されます。
o serialNumber is the serial number of the certificate for which status is being requested.
o serialNumberは、ステータスが要求されている証明書のシリアル番号です。
The primary reason to use the hash of the CA's public key in addition to the hash of the CA's name to identify the issuer is that it is possible that two CAs may choose to use the same Name (uniqueness in the Name is a recommendation that cannot be enforced). Two CAs will never, however, have the same public key unless the CAs either explicitly decided to share their private key or the key of one of the CAs was compromised.
CAの名前のハッシュに加えてCAの公開鍵のハッシュを使用して発行者を識別する主な理由は、2つのCAが同じ名前を使用することを選択する可能性があるためです（名前の一意性は、強制される）。ただし、CAが明示的に秘密鍵を共有することを決定した場合、またはいずれかのCAの鍵が侵害された場合を除き、2つのCAが同じ公開鍵を持つことは決してありません。
Support for any specific extension is OPTIONAL. The critical flag SHOULD NOT be set for any of them. Section 4.4 suggests several useful extensions. Additional extensions MAY be defined in additional RFCs. Unrecognized extensions MUST be ignored (unless they have the critical flag set and are not understood).
特定の拡張子のサポートはオプションです。クリティカルフラグはそれらのいずれにも設定しないでください。セクション4.4では、いくつかの便利な拡張機能を提案しています。追加の拡張機能は、追加のRFCで定義される場合があります。認識されない拡張機能は無視する必要があります（クリティカルフラグが設定されていて、理解されていない場合を除く）。
The requestor MAY choose to sign the OCSP request. In that case, the signature is computed over the tbsRequest structure. If the request is signed, the requestor SHALL specify its name in the requestorName field. Also, for signed requests, the requestor MAY include certificates that help the OCSP responder verify the requestor's signature in the certs field of Signature.
リクエスタは、OCSPリクエストに署名することを選択できます。その場合、署名はtbsRequest構造に対して計算されます。リクエストが署名されている場合、リクエスタはrequestorNameフィールドにその名前を指定する必要があります。また、署名付きリクエストの場合、リクエスタはOCSPレスポンダがリクエスタの署名を署名のcertsフィールドに確認するのに役立つ証明書を含めることができます。
This section specifies the ASN.1 specification for a confirmation response. The actual formatting of the message could vary, depending on the transport mechanism used (HTTP, SMTP, LDAP, etc.).
このセクションでは、確認応答のASN.1仕様を指定します。メッセージの実際のフォーマットは、使用されるトランスポートメカニズム（HTTP、SMTP、LDAPなど）によって異なります。
An OCSP response at a minimum consists of a responseStatus field indicating the processing status of the prior request. If the value of responseStatus is one of the error conditions, the responseBytes field is not set.
少なくともOCSP応答は、前の要求の処理ステータスを示すresponseStatusフィールドで構成されています。 responseStatusの値がエラー条件の1つである場合、responseBytesフィールドは設定されません。
OCSPResponse ::= SEQUENCE {
responseStatus OCSPResponseStatus,
responseBytes [0] EXPLICIT ResponseBytes OPTIONAL }
OCSPResponseStatus ::= ENUMERATED {
successful (0), -- Response has valid confirmations
malformedRequest (1), -- Illegal confirmation request
internalError (2), -- Internal error in issuer
tryLater (3), -- Try again later
-- (4) is not used
sigRequired (5), -- Must sign the request
unauthorized (6) -- Request unauthorized
}
The value for responseBytes consists of an OBJECT IDENTIFIER and a response syntax identified by that OID encoded as an OCTET STRING.
responseBytesの値は、OBJECT IDENTIFIERと、OCTET STRINGとしてエンコードされたそのOIDによって識別される応答構文で構成されます。
ResponseBytes ::= SEQUENCE {
responseType OBJECT IDENTIFIER,
response OCTET STRING }
For a basic OCSP responder, responseType will be id-pkix-ocsp-basic.
基本的なOCSPレスポンダーの場合、responseTypeはid-pkix-ocsp-basicになります。
id-pkix-ocsp OBJECT IDENTIFIER ::= { id-ad-ocsp }
id-pkix-ocsp-basic OBJECT IDENTIFIER ::= { id-pkix-ocsp 1 }
OCSP responders SHALL be capable of producing responses of the id-pkix-ocsp-basic response type. Correspondingly, OCSP clients SHALL be capable of receiving and processing responses of the id-pkix-ocsp-basic response type.
OCSPレスポンダーは、id-pkix-ocsp-basic応答タイプの応答を生成できる必要があります（SHALL）。同様に、OCSPクライアントは、id-pkix-ocsp-basic応答タイプの応答を受信して処理できる必要があります（SHALL）。
The value for response SHALL be the DER encoding of BasicOCSPResponse.
応答の値は、BasicOCSPResponseのDERエンコードにする必要があります（SHALL）。
BasicOCSPResponse ::= SEQUENCE {
tbsResponseData ResponseData,
signatureAlgorithm AlgorithmIdentifier,
signature BIT STRING,
certs [0] EXPLICIT SEQUENCE OF Certificate OPTIONAL }
The value for signature SHALL be computed on the hash of the DER encoding of ResponseData. The responder MAY include certificates in the certs field of BasicOCSPResponse that help the OCSP client verify the responder's signature. If no certificates are included, then certs SHOULD be absent.
署名の値は、ResponseDataのDERエンコーディングのハッシュで計算する必要があります。レスポンダは、OCSPクライアントがレスポンダの署名を確認するのに役立つBasicOCSPResponseのcertsフィールドに証明書を含めることができます。証明書が含まれていない場合、証明書は存在しない必要があります（SHOULD）。
ResponseData ::= SEQUENCE {
version [0] EXPLICIT Version DEFAULT v1,
responderID ResponderID,
producedAt GeneralizedTime,
responses SEQUENCE OF SingleResponse,
responseExtensions [1] EXPLICIT Extensions OPTIONAL }
ResponderID ::= CHOICE {
byName [1] Name,
byKey [2] KeyHash }
KeyHash ::= OCTET STRING -- SHA-1 hash of responder's public key
(excluding the tag and length fields)
SingleResponse ::= SEQUENCE {
certID CertID,
certStatus CertStatus,
thisUpdate GeneralizedTime,
nextUpdate [0] EXPLICIT GeneralizedTime OPTIONAL,
singleExtensions [1] EXPLICIT Extensions OPTIONAL }
CertStatus ::= CHOICE {
good [0] IMPLICIT NULL,
revoked [1] IMPLICIT RevokedInfo,
unknown [2] IMPLICIT UnknownInfo }
RevokedInfo ::= SEQUENCE {
revocationTime GeneralizedTime,
revocationReason [0] EXPLICIT CRLReason OPTIONAL }
UnknownInfo ::= NULL
Responses can contain four times -- thisUpdate, nextUpdate, producedAt, and revocationTime. The semantics of these fields are defined in Section 2.4. The format for GeneralizedTime is as specified in Section 4.1.2.5.2 of [RFC5280].
応答には、thisUpdate、nextUpdate、producedAt、およびrevocationTimeの4回を含めることができます。これらのフィールドのセマンティクスは、セクション2.4で定義されています。 GeneralizedTimeの形式は、[RFC5280]のセクション4.1.2.5.2で指定されています。
The thisUpdate and nextUpdate fields define a recommended validity interval. This interval corresponds to the {thisUpdate, nextUpdate} interval in CRLs. Responses whose nextUpdate value is earlier than the local system time value SHOULD be considered unreliable. Responses whose thisUpdate time is later than the local system time SHOULD be considered unreliable.
thisUpdateおよびnextUpdateフィールドは、推奨される有効期間を定義します。この間隔は、CRLの{thisUpdate、nextUpdate}間隔に対応しています。 nextUpdateの値がローカルシステムの時刻の値よりも早い応答は、信頼できないと見なされるべきです（SHOULD）。 thisUpdate時刻がローカルシステム時刻よりも遅い応答は、信頼できないと見なされるべきです。
If nextUpdate is not set, the responder is indicating that newer revocation information is available all the time.
nextUpdateが設定されていない場合、レスポンダは、新しい失効情報が常に利用可能であることを示しています。
The key that signs a certificate's status information need not be the same key that signed the certificate. It is necessary, however, to ensure that the entity signing this information is authorized to do so. Therefore, a certificate's issuer MUST do one of the following:
証明書のステータス情報に署名するキーは、証明書に署名したキーと同じである必要はありません。ただし、この情報に署名するエンティティにそうする権限があることを確認する必要があります。したがって、証明書の発行者は次のいずれかを実行する必要があります。
- sign the OCSP responses itself, or
- OCSP応答自体に署名する、または
- explicitly designate this authority to another entity
- この権限を別のエンティティに明示的に指定する
OCSP signing delegation SHALL be designated by the inclusion of id-kp-OCSPSigning in an extended key usage certificate extension included in the OCSP response signer's certificate. This certificate MUST be issued directly by the CA that is identified in the request.
OCSP署名の委任は、OCSP応答の署名者の証明書に含まれる拡張キー使用法証明書の拡張にid-kp-OCSPSigningを含めることによって指定する必要があります（SHALL）。この証明書は、リクエストで識別されるCAによって直接発行される必要があります。
The CA SHOULD use the same issuing key to issue a delegation certificate as that used to sign the certificate being checked for revocation. Systems relying on OCSP responses MUST recognize a delegation certificate as being issued by the CA that issued the certificate in question only if the delegation certificate and the certificate being checked for revocation were signed by the same key.
CAは、失効がチェックされている証明書の署名に使用されたものと同じ発行鍵を使用して、委任証明書を発行する必要があります（SHOULD）。 OCSP応答に依存しているシステムは、委任証明書と失効をチェックされている証明書が同じ鍵で署名されている場合にのみ、問題の証明書を発行したCAが発行したものとして委任証明書を認識しなければなりません。
Note: For backwards compatibility with RFC 2560 [RFC2560], it is not prohibited to issue a certificate for an Authorized Responder using a different issuing key than the key used to issue the certificate being checked for revocation. However, such a practice is strongly discouraged, since clients are not required to recognize a responder with such a certificate as an Authorized Responder.
注：RFC 2560 [RFC2560]との下位互換性のために、失効チェックの対象となる証明書の発行に使用されたキーとは異なる発行キーを使用して、Authorized Responderに証明書を発行することは禁止されていません。ただし、クライアントは承認されたレスポンダなどの証明書を持つレスポンダを認識する必要がないため、このような方法はお勧めできません。
id-kp-OCSPSigning OBJECT IDENTIFIER ::= {id-kp 9}
Systems or applications that rely on OCSP responses MUST be capable of detecting and enforcing the use of the id-kp-OCSPSigning value as described above. They MAY provide a means of locally configuring one or more OCSP signing authorities and specifying the set of CAs for which each signing authority is trusted. They MUST reject the response if the certificate required to validate the signature on the response does not meet at least one of the following criteria:
OCSP応答に依存するシステムまたはアプリケーションは、上記のid-kp-OCSPSigning値の使用を検出および強制できる必要があります。それらは、1つ以上のOCSP署名機関をローカルに構成し、各署名機関が信頼されるCAのセットを指定する手段を提供する場合があります。応答の署名を検証するために必要な証明書が次の基準の少なくとも1つを満たさない場合、応答を拒否する必要があります。
1. Matches a local configuration of OCSP signing authority for the certificate in question, or
1. 問題の証明書のOCSP署名機関のローカル構成に一致する、または
2. Is the certificate of the CA that issued the certificate in question, or
2. 問題の証明書を発行したCAの証明書、または
3. Includes a value of id-kp-OCSPSigning in an extended key usage extension and is issued by the CA that issued the certificate in question as stated above.
3. id-kp-OCSPSigningの値が拡張キー使用法拡張に含まれ、上記のように問題の証明書を発行したCAによって発行されます。
Additional acceptance or rejection criteria may apply to either the response itself or to the certificate used to validate the signature on the response.
追加の受け入れ基準または拒否基準が、応答自体または応答の署名の検証に使用される証明書のいずれかに適用される場合があります。
Since an authorized OCSP responder provides status information for one or more CAs, OCSP clients need to know how to check that an Authorized Responder's certificate has not been revoked. CAs may choose to deal with this problem in one of three ways:
承認されたOCSPレスポンダは1つ以上のCAのステータス情報を提供するため、OCSPクライアントは、承認されたレスポンダの証明書が取り消されていないことを確認する方法を知る必要があります。 CAは、次の3つの方法のいずれかでこの問題に対処することを選択できます。
- A CA may specify that an OCSP client can trust a responder for the lifetime of the responder's certificate. The CA does so by including the extension id-pkix-ocsp-nocheck. This SHOULD be a non-critical extension. The value of the extension SHALL be NULL. CAs issuing such a certificate should realize that a compromise of the responder's key is as serious as the compromise of a CA key used to sign CRLs, at least for the validity period of this certificate. CAs may choose to issue this type of certificate with a very short lifetime and renew it frequently.
- CAは、OCSPクライアントがレスポンダの証明書の有効期間中、レスポンダを信頼できることを指定する場合があります。 CAは、拡張機能id-pkix-ocsp-nocheckを含めることでこれを行います。これは重要ではない拡張であるべきです。拡張の値はNULLでなければなりません。このような証明書を発行するCAは、レスポンダーのキーの侵害が、少なくともこの証明書の有効期間中、CRLの署名に使用されるCAキーの侵害と同じくらい深刻であることを認識する必要があります。 CAは、このタイプの証明書を非常に短い期間で発行し、頻繁に更新することを選択できます。
id-pkix-ocsp-nocheck OBJECT IDENTIFIER ::= { id-pkix-ocsp 5 }
- A CA may specify how the responder's certificate is to be checked for revocation. This can be done by using CRL Distribution Points if the check should be done using CRLs, or by using Authority Information Access if the check should be done in some other way. Details for specifying either of these two mechanisms are available in [RFC5280].
- CAは、レスポンダの証明書の失効チェック方法を指定できます。これは、CRLを使用してチェックを実行する必要がある場合はCRL配布ポイントを使用するか、チェックを他の方法で実行する必要がある場合は機関情報アクセスを使用して実行できます。これらの2つのメカニズムのどちらかを指定するための詳細は[RFC5280]で利用できます。
- A CA may choose not to specify any method of revocation checking for the responder's certificate, in which case it would be up to the OCSP client's local security policy to decide whether that certificate should be checked for revocation or not.
- CAはレスポンダの証明書の失効確認方法を指定しないことを選択できます。その場合、その証明書の失効を確認するかどうかはOCSPクライアントのローカルセキュリティポリシー次第です。
The basic response type contains:
基本的な応答タイプには以下が含まれます。
o the version of the response syntax, which MUST be v1 (value is 0) for this version of the basic response syntax;
o 応答構文のバージョン。これは、このバージョンの基本応答構文のv1（値は0）でなければなりません。
o either the name of the responder or a hash of the responder's public key as the ResponderID;
o レスポンダの名前、またはレスポンダIDとしてのレスポンダの公開鍵のハッシュ。
o the time at which the response was generated;
o 応答が生成された時間。
o responses for each of the certificates in a request;
o リクエスト内の各証明書に対する応答。
o optional extensions;
o オプションの拡張機能。
o a signature computed across a hash of the response; and
o 応答のハッシュ全体で計算された署名。そして
o the signature algorithm OID.
o 署名アルゴリズムOID。
The purpose of the ResponderID information is to allow clients to find the certificate used to sign a signed OCSP response. Therefore, the information MUST correspond to the certificate that was used to sign the response.
ResponderID情報の目的は、署名されたOCSP応答の署名に使用される証明書をクライアントが見つけられるようにすることです。したがって、情報は、応答の署名に使用された証明書に対応している必要があります。
The responder MAY include certificates in the certs field of BasicOCSPResponse that help the OCSP client verify the responder's signature.
レスポンダは、OCSPクライアントがレスポンダの署名を確認するのに役立つBasicOCSPResponseのcertsフィールドに証明書を含めることができます。
The response for each of the certificates in a request consists of:
要求内の各証明書の応答は、以下で構成されます。
o an identifier of the certificate for which revocation status information is being provided (i.e., the target certificate);
o 失効ステータス情報が提供されている証明書の識別子（ターゲット証明書）。
o the revocation status of the certificate (good, revoked, or unknown); if revoked, it indicates the time at which the certificate was revoked and, optionally, the reason why it was revoked;
o 証明書の失効ステータス（良好、失効、または不明）;取り消された場合は、証明書が取り消された時刻と、オプションで、証明書が取り消された理由を示します。
o the validity interval of the response; and
o 応答の有効期間。そして
o optional extensions.
o オプションの拡張機能。
The response MUST include a SingleResponse for each certificate in the request. The response SHOULD NOT include any additional SingleResponse elements, but, for example, OCSP responders that pre-generate status responses might include additional SingleResponse elements if necessary to improve response pre-generation performance or cache efficiency (according to [RFC5019], Section 2.2.1).
応答には、要求内の各証明書のSingleResponseを含める必要があります。応答には追加のSingleResponse要素を含めるべきではありませんが、たとえば、ステータス応答を事前生成するOCSPレスポンダには、必要に応じて追加のSingleResponse要素が含まれ、応答の生成前のパフォーマンスまたはキャッシュ効率が向上します（[RFC5019]、セクション2.2に従って）。 1）。
Clients that request OCSP services SHALL be capable of processing responses signed using RSA with SHA-256 (identified by the sha256WithRSAEncryption OID specified in [RFC4055]). Clients SHOULD also be capable of processing responses signed using RSA with SHA-1 (identified by the sha1WithRSAEncryption OID specified in [RFC3279]) and the Digital Signature Algorithm (DSA) with SHA-1 (identified by the id-dsa-with-sha1 OID specified in [RFC3279]). Clients MAY support other algorithms.
OCSPサービスを要求するクライアントは、RSAとSHA-256（[RFC4055]で指定されているsha256WithRSAEncryption OIDで識別）を使用して署名された応答を処理できる必要があります（SHALL）。クライアントは、SHA-1（[RFC3279]で指定されているsha1WithRSAEncryption OIDで識別）を使用したRSAと、SHA-1（id-dsa-with-sha1で識別）を使用したデジタル署名アルゴリズム（DSA）を使用して署名された応答を処理できる必要があります（SHOULD）。 [RFC3279]で指定されたOID）。クライアントは他のアルゴリズムをサポートしてもよい（MAY）。
This section defines some standard extensions, based on the extension model employed in X.509 version 3 certificates (see [RFC5280]). Support for all extensions is optional for both clients and responders. For each extension, the definition indicates its syntax, processing performed by the OCSP responder, and any extensions that are included in the corresponding response.
このセクションでは、X.509バージョン3証明書（[RFC5280]を参照）で採用されている拡張モデルに基づいて、いくつかの標準拡張を定義します。すべての拡張機能のサポートは、クライアントとレスポンダーの両方でオプションです。各拡張について、定義はその構文、OCSPレスポンダによって実行される処理、および対応する応答に含まれる拡張を示します。
The nonce cryptographically binds a request and a response to prevent replay attacks. The nonce is included as one of the requestExtensions in requests, while in responses it would be included as one of the responseExtensions. In both the request and the response, the nonce will be identified by the object identifier id-pkix-ocsp-nonce, while the extnValue is the value of the nonce.
nonceは、要求と応答を暗号でバインドして、リプレイアタックを防止します。 nonceはリクエストのrequestExtensionsの1つとして含まれていますが、レスポンスではresponseExtensionsの1つとして含まれます。リクエストとレスポンスの両方で、ナンスはオブジェクト識別子id-pkix-ocsp-nonceによって識別されますが、extnValueはナンスの値です。
id-pkix-ocsp OBJECT IDENTIFIER ::= { id-ad-ocsp }
id-pkix-ocsp-nonce OBJECT IDENTIFIER ::= { id-pkix-ocsp 2 }
Nonce ::= OCTET STRING
It may be desirable for the OCSP responder to indicate the CRL on which a revoked or onHold certificate is found. This can be useful where OCSP is used between repositories, and also as an auditing mechanism. The CRL may be specified by a URL (the URL at which the CRL is available), a number (CRL number), or a time (the time at which the relevant CRL was created). These extensions will be specified as singleExtensions. The identifier for this extension will be id-pkix-ocsp-crl, while the value will be CrlID.
OCSPレスポンダーが、失効した証明書またはonHold証明書が見つかったCRLを示すことが望ましい場合があります。これは、リポジトリ間でOCSPを使用する場合や、監査メカニズムとしても役立ちます。 CRLは、URL（CRLが使用可能なURL）、番号（CRL番号）、または時刻（関連するCRLが作成された時刻）で指定できます。これらの拡張機能は、singleExtensionsとして指定されます。この拡張の識別子はid-pkix-ocsp-crlで、値はCrlIDになります。
id-pkix-ocsp-crl OBJECT IDENTIFIER ::= { id-pkix-ocsp 3 }
CrlID ::= SEQUENCE {
crlUrl [0] EXPLICIT IA5String OPTIONAL,
crlNum [1] EXPLICIT INTEGER OPTIONAL,
crlTime [2] EXPLICIT GeneralizedTime OPTIONAL }
For the choice crlUrl, the IA5String will specify the URL at which the CRL is available. For crlNum, the INTEGER will specify the value of the CRL number extension of the relevant CRL. For crlTime, the GeneralizedTime will indicate the time at which the relevant CRL was issued.
選択肢crlUrlの場合、IA5StringはCRLが利用可能なURLを指定します。 crlNumの場合、INTEGERは関連するCRLのCRL番号拡張の値を指定します。 crlTimeの場合、GeneralizedTimeは関連するCRLが発行された時刻を示します。
An OCSP client MAY wish to specify the kinds of response types it understands. To do so, it SHOULD use an extension with the OID id-pkix-ocsp-response and the value AcceptableResponses. This extension is included as one of the requestExtensions in requests. The OIDs included in AcceptableResponses are the OIDs of the various response types this client can accept (e.g., id-pkix-ocsp-basic).
OCSPクライアントは、それが理解する応答タイプの種類を指定したいと思うかもしれません。そのためには、OID id-pkix-ocsp-responseと値AcceptableResponsesを持つ拡張機能を使用する必要があります（SHOULD）。この拡張機能は、requestExtensionsの1つとしてリクエストに含まれています。 AcceptableResponsesに含まれるOIDは、このクライアントが受け入れることができるさまざまな応答タイプのOIDです（例：id-pkix-ocsp-basic）。
id-pkix-ocsp-response OBJECT IDENTIFIER ::= { id-pkix-ocsp 4 }
AcceptableResponses ::= SEQUENCE OF OBJECT IDENTIFIER
As noted in Section 4.2.1, OCSP responders SHALL be capable of responding with responses of the id-pkix-ocsp-basic response type. Correspondingly, OCSP clients SHALL be capable of receiving and processing responses of the id-pkix-ocsp-basic response type.
セクション4.2.1で述べたように、OCSPレスポンダは、id-pkix-ocsp-basic応答タイプの応答で応答できる必要があります（SHALL）。同様に、OCSPクライアントは、id-pkix-ocsp-basic応答タイプの応答を受信して処理できる必要があります（SHALL）。
An OCSP responder MAY choose to retain revocation information beyond a certificate's expiration. The date obtained by subtracting this retention interval value from the producedAt time in a response is defined as the certificate's "archive cutoff" date.
OCSPレスポンダは、証明書の有効期限を超えて失効情報を保持することを選択できます。応答のgeneratedAt時間からこの保持間隔の値を引いた日付は、証明書の「アーカイブカットオフ」日付として定義されます。
OCSP-enabled applications would use an OCSP archive cutoff date to contribute to a proof that a digital signature was (or was not) reliable on the date it was produced even if the certificate needed to validate the signature has long since expired.
OCSP対応アプリケーションは、OCSPアーカイブの締切日を使用して、署名の検証に必要な証明書が期限切れになった後でも、デジタル署名が作成された日付で信頼できる（または信頼できない）ことを証明します。
OCSP servers that provide support for such a historical reference SHOULD include an archive cutoff date extension in responses. If included, this value SHALL be provided as an OCSP singleExtensions extension identified by id-pkix-ocsp-archive-cutoff and of syntax GeneralizedTime.
このような履歴参照のサポートを提供するOCSPサーバーは、応答にアーカイブの締切日の拡張を含める必要があります（SHOULD）。含まれている場合、この値は、id-pkix-ocsp-archive-cutoffによって識別され、構文GeneralizedTimeのOCSP singleExtensions拡張として提供される必要があります（SHALL）。
id-pkix-ocsp-archive-cutoff OBJECT IDENTIFIER ::= {id-pkix-ocsp 6}
ArchiveCutoff ::= GeneralizedTime
To illustrate, if a server is operated with a 7-year retention interval policy and status was produced at time t1, then the value for ArchiveCutoff in the response would be (t1 - 7 years).
たとえば、サーバーが7年の保存間隔ポリシーで運用され、時刻t1にステータスが生成された場合、応答のArchiveCutoffの値は（t1-7年）になります。
All the extensions specified as CRL entry extensions -- in Section 5.3 of [RFC5280] -- are also supported as singleExtensions.
[RFC5280]のセクション5.3でCRLエントリ拡張として指定されているすべての拡張も、singleExtensionsとしてサポートされています。
An OCSP server may be operated in a mode whereby the server receives a request and routes it to the OCSP server that is known to be authoritative for the identified certificate. The serviceLocator request extension is defined for this purpose. This extension is included as one of the singleRequestExtensions in requests.
OCSPサーバーは、サーバーが要求を受信し、それを、識別された証明書に対して信頼できることがわかっているOCSPサーバーにルーティングするモードで操作できます。 serviceLocatorリクエスト拡張はこの目的のために定義されています。この拡張機能は、リクエストのsingleRequestExtensionsの1つとして含まれています。
id-pkix-ocsp-service-locator OBJECT IDENTIFIER ::= {id-pkix-ocsp 7}
ServiceLocator ::= SEQUENCE {
issuer Name,
locator AuthorityInfoAccessSyntax OPTIONAL }
Values for these fields are obtained from the corresponding fields in the subject certificate.
これらのフィールドの値は、サブジェクト証明書の対応するフィールドから取得されます。
Since algorithms other than the mandatory-to-implement algorithms are allowed, and since a client currently has no mechanism to indicate its algorithm preferences, there is always a risk that a server choosing a non-mandatory algorithm will generate a response that the client may not support.
必須から実装までのアルゴリズム以外のアルゴリズムが許可されており、クライアントには現在そのアルゴリズムの設定を示すメカニズムがないため、サーバーが非必須アルゴリズムを選択すると、クライアントが応答を生成する可能性があるというリスクが常にありますサポートしません。
While an OCSP responder may apply rules for algorithm selection, e.g., using the signature algorithm employed by the CA for signing CRLs and certificates, such rules may fail in common situations:
OCSPレスポンダは、CRLと証明書に署名するためにCAで採用されている署名アルゴリズムを使用するなど、アルゴリズムの選択にルールを適用できますが、このようなルールは一般的な状況で失敗することがあります。
o The algorithm used to sign the CRLs and certificates may not be consistent with the key pair being used by the OCSP responder to sign responses.
o CRLと証明書の署名に使用されるアルゴリズムは、OCSPレスポンダが応答の署名に使用するキーペアと一致しない場合があります。
o A request for an unknown certificate provides no basis for a responder to select from among multiple algorithm options.
o 不明な証明書の要求は、レスポンダが複数のアルゴリズムオプションの中から選択するための基礎を提供しません。
The last criterion cannot be resolved through the information available from in-band signaling using the RFC 2560 [RFC2560] protocol without modifying the protocol.
最後の基準は、プロトコルを変更せずにRFC 2560 [RFC2560]プロトコルを使用したインバンドシグナリングから入手できる情報では解決できません。
In addition, an OCSP responder may wish to employ different signature algorithms than the one used by the CA to sign certificates and CRLs for two reasons:
さらに、OCSPレスポンダは、次の2つの理由により、証明書とCRLに署名するためにCAが使用するものとは異なる署名アルゴリズムを採用したい場合があります。
o The responder may employ an algorithm for certificate status response that is less computationally demanding than for signing the certificate itself.
o レスポンダは、証明書自体に署名するためのアルゴリズムよりも、コンピュータの要求が少ない証明書ステータス応答のアルゴリズムを使用できます。
o An implementation may wish to guard against the possibility of a compromise resulting from a signature algorithm compromise by employing two separate signature algorithms.
o 実装では、2つの別々の署名アルゴリズムを使用することにより、署名アルゴリズムの侵害に起因する侵害の可能性を防ぐことができます。
This section describes:
このセクションでは、以下について説明します。
o An extension that allows a client to indicate the set of preferred signature algorithms.
o クライアントが優先署名アルゴリズムのセットを示すことを可能にする拡張。
o Rules for signature algorithm selection that maximize the probability of successful operation in the case that no supported preferred algorithm(s) are specified.
o サポートされている優先アルゴリズムが指定されていない場合に、操作が成功する確率を最大にする署名アルゴリズム選択のルール。
A client MAY declare a preferred set of algorithms in a request by including a preferred signature algorithms extension in requestExtensions of the OCSPRequest.
クライアントは、OCSPRequestのrequestExtensionsに優先署名アルゴリズム拡張を含めることにより、リクエストに優先アルゴリズムのセットを宣言できます（MAY）。
id-pkix-ocsp-pref-sig-algs OBJECT IDENTIFIER ::= { id-pkix-ocsp 8 }
PreferredSignatureAlgorithms ::= SEQUENCE OF
PreferredSignatureAlgorithm
PreferredSignatureAlgorithm ::= SEQUENCE {
sigIdentifier AlgorithmIdentifier,
pubKeyAlgIdentifier SMIMECapability OPTIONAL
}
The syntax of AlgorithmIdentifier is defined in Section 4.1.1.2 of RFC 5280 [RFC5280]. The syntax of SMIMECapability is defined in RFC 5751 [RFC5751].
AlgorithmIdentifierの構文は、RFC 5280 [RFC5280]のセクション4.1.1.2で定義されています。 SMIMECapabilityの構文はRFC 5751 [RFC5751]で定義されています。
sigIdentifier specifies the signature algorithm the client prefers, e.g., algorithm=ecdsa-with-sha256. Parameters are absent for most common signature algorithms.
sigIdentifierは、クライアントが好む署名アルゴリズムを指定します（例えば、algorithm = ecdsa-with-sha256）。ほとんどの一般的な署名アルゴリズムにはパラメーターがありません。
pubKeyAlgIdentifier specifies the subject public key algorithm identifier the client prefers in the server's certificate used to validate the OCSP response, e.g., algorithm=id-ecPublicKey and parameters= secp256r1.
pubKeyAlgIdentifierは、OCSP応答の検証に使用されるサーバーの証明書でクライアントが優先するサブジェクトの公開鍵アルゴリズム識別子を指定します（たとえば、algorithm = id-ecPublicKeyおよびparameters = secp256r1）。
pubKeyAlgIdentifier is OPTIONAL and provides a means to specify parameters necessary to distinguish among different usages of a particular algorithm, e.g., it may be used by the client to specify what curve it supports for a given elliptic curve algorithm.
pubKeyAlgIdentifierはオプションであり、特定のアルゴリズムのさまざまな使用法を区別するために必要なパラメーターを指定する手段を提供します。たとえば、クライアントは、特定の楕円曲線アルゴリズムでサポートする曲線を指定するために使用できます。
The client MUST support each of the specified preferred signature algorithms, and the client MUST specify the algorithms in the order of preference, from the most preferred to the least preferred.
クライアントは指定された優先署名アルゴリズムのそれぞれをサポートしなければならず（MUST）、クライアントは優先度の高いものから最も優先度の低いものまでアルゴリズムを優先順に指定しなければなりません（MUST）。
Section 4.4.7.2 of this document describes how a server selects an algorithm for signing OCSP responses to the requesting client.
このドキュメントのセクション4.4.7.2では、サーバーが要求側クライアントへのOCSP応答に署名するためのアルゴリズムを選択する方法について説明します。
RFC 2560 [RFC2560] did not specify a mechanism for deciding the signature algorithm to be used in an OCSP response. This does not provide a sufficient degree of certainty as to the algorithm selected to facilitate interoperability.
RFC 2560 [RFC2560]は、OCSP応答で使用される署名アルゴリズムを決定するメカニズムを指定していません。これは、相互運用性を促進するために選択されたアルゴリズムに関して十分な確実性を提供しません。
A responder MAY maximize the potential for ensuring interoperability by selecting a supported signature algorithm using the following order of precedence, as long as the selected algorithm meets all security requirements of the OCSP responder, where the first selection mechanism has the highest precedence:
選択されたアルゴリズムがOCSPレスポンダーのすべてのセキュリティ要件を満たし、最初の選択メカニズムが最高の優先順位である限り、レスポンダは、次の優先順位を使用してサポートされる署名アルゴリズムを選択することにより、相互運用性を保証する可能性を最大化できます（MAY）。
1. Select an algorithm specified as a preferred signature algorithm in the client request.
1. クライアント要求で優先署名アルゴリズムとして指定されたアルゴリズムを選択します。
2. Select the signature algorithm used to sign a certificate revocation list (CRL) issued by the certificate issuer providing status information for the certificate specified by CertID.
2. CertIDで指定された証明書のステータス情報を提供する証明書発行者が発行した証明書失効リスト（CRL）の署名に使用される署名アルゴリズムを選択します。
3. Select the signature algorithm used to sign the OCSPRequest.
3. OCSPRequestの署名に使用される署名アルゴリズムを選択します。
4. Select a signature algorithm that has been advertised as being the default signature algorithm for the signing service using an out-of-band mechanism.
4. アウトオブバンドメカニズムを使用して、署名サービスのデフォルトの署名アルゴリズムであると宣伝されている署名アルゴリズムを選択します。
5. Select a mandatory or recommended signature algorithm specified for the version of OCSP in use.
5. 使用中のOCSPのバージョンに指定された必須または推奨の署名アルゴリズムを選択します。
A responder SHOULD always apply the lowest-numbered selection mechanism that results in the selection of a known and supported algorithm that meets the responder's criteria for cryptographic algorithm strength.
レスポンダは常に暗号化アルゴリズムの強度に関するレスポンダの基準を満たす既知のサポートされているアルゴリズムの選択をもたらす最小番号の選択メカニズムを適用する必要があります。
For purposes of efficiency, an OCSP responder is permitted to generate static responses in advance of a request. The case may not permit the responder to make use of the client request data during the response generation; however, the responder SHOULD still use the client request data during the selection of the pre-generated response to be returned. Responders MAY use the historical client requests as part of the input to the decisions of what different algorithms should be used to sign the pre-generated responses.
効率を上げるために、OCSPレスポンダは、リクエストの前に静的な応答を生成することが許可されています。このケースでは、応答の生成中に応答者がクライアント要求データを利用することを許可しない場合があります。ただし、レスポンダは、返される事前に生成された応答の選択中に、クライアント要求データを使用する必要があります（SHOULD）。レスポンダは、事前に生成された応答に署名するためにどのようなアルゴリズムを使用する必要があるかを決定するための入力の一部として、履歴クライアント要求を使用できます。
This extension indicates that the responder supports the extended definition of the "revoked" status to also include non-issued certificates according to Section 2.2. One of its main purposes is to allow audits to determine the responder's type of operation. Clients do not have to parse this extension in order to determine the status of certificates in responses.
この拡張は、レスポンダがセクション2.2に従って発行されていない証明書も含めるように「取り消し」ステータスの拡張定義をサポートしていることを示しています。その主な目的の1つは、監査者が応答者の操作のタイプを判別できるようにすることです。クライアントは、応答の証明書のステータスを判別するためにこの拡張を解析する必要はありません。
This extension MUST be included in the OCSP response when that response contains a "revoked" status for a non-issued certificate. This extension MAY be present in other responses to signal that the responder implements the extended revoked definition. When included, this extension MUST be placed in responseExtensions, and it MUST NOT appear in singleExtensions.
発行されていない証明書の「取り消された」ステータスが応答に含まれている場合、この拡張をOCSP応答に含める必要があります。この拡張は、レスポンダが拡張された無効化された定義を実装することを通知するために、他の応答に存在してもよい（MAY）。含まれる場合、この拡張機能はresponseExtensionsに配置する必要があり、singleExtensionsに表示することはできません。
This extension is identified by the object identifier id-pkix-ocsp-extended-revoke.
この拡張は、オブジェクト識別子id-pkix-ocsp-extended-revokeによって識別されます。
id-pkix-ocsp-extended-revoke OBJECT IDENTIFIER ::= {id-pkix-ocsp 9}
The value of the extension SHALL be NULL. This extension MUST NOT be marked critical.
拡張の値はNULLでなければなりません。この拡張機能は、重要としてマークしてはなりません。
For this service to be effective, certificate-using systems must connect to the certificate status service provider. In the event such a connection cannot be obtained, certificate-using systems could implement CRL processing logic as a fall-back position.
このサービスを有効にするには、証明書を使用するシステムが証明書ステータスサービスプロバイダーに接続する必要があります。このような接続を取得できない場合、証明書を使用するシステムは、CRL処理ロジックをフォールバック位置として実装できます。
A vulnerability to denial of service is evident with respect to a flood of queries. The production of a cryptographic signature significantly affects response generation cycle time, thereby exacerbating the situation. Unsigned error responses open up the protocol to another denial-of-service attack, where the attacker sends false error responses.
大量のクエリに関して、サービス拒否攻撃に対する脆弱性は明らかです。暗号署名の生成は、応答生成サイクルタイムに大きな影響を与え、それにより状況が悪化します。署名されていないエラー応答により、プロトコルは別のサービス拒否攻撃にさらされ、攻撃者は偽のエラー応答を送信します。
The use of precomputed responses allows replay attacks in which an old (good) response is replayed prior to its expiration date but after the certificate has been revoked. Deployments of OCSP should carefully evaluate the benefit of precomputed responses against the probability of a replay attack and the costs associated with its successful execution.
事前に計算された応答を使用すると、古い（正常な）応答が有効期限の前に再生され、証明書が取り消された後に再生攻撃が可能になります。 OCSPの展開では、事前計算された応答の利点を、リプレイアタックの確率とその実行の成功に関連するコストに対して慎重に評価する必要があります。
Requests do not contain the responder they are directed to. This allows an attacker to replay a request to any number of OCSP responders.
リクエストには、転送先のレスポンダは含まれていません。これにより、攻撃者は任意の数のOCSPレスポンダーへの要求を再生できます。
The reliance of HTTP caching in some deployment scenarios may result in unexpected results if intermediate servers are incorrectly configured or are known to possess cache management faults. Implementors are advised to take the reliability of HTTP cache mechanisms into account when deploying OCSP over HTTP.
一部の展開シナリオでHTTPキャッシングに依存していると、中間サーバーが正しく構成されていないか、キャッシュ管理に障害があることがわかっている場合、予期しない結果が生じる可能性があります。実装者は、OCSP over HTTPを展開する際に、HTTPキャッシュメカニズムの信頼性を考慮することをお勧めします。
Responding with a "revoked" state to a certificate that has never been issued may enable someone to obtain a revocation response for a certificate that is not yet issued, but soon will be issued, if the certificate serial number of the certificate that will be issued can be predicted or guessed by the requestor. Such a prediction is easy for a CA that issues certificates using sequential certificate serial number assignment. This risk is handled in the specification by requiring compliant implementations to use the certificateHold reason code, which avoids permanently revoking the serial number. For CAs that support "revoked" responses to status requests for non-issued certificates, one way to completely avoid this issue is to assign random certificate serial number values with high entropy.
発行されていない証明書に「失効」状態で応答すると、まだ発行されていない証明書の失効応答を誰かが取得できる可能性がありますが、発行される証明書の証明書シリアル番号が発行されるとすぐに発行されます要求者が予測または推測できます。このような予測は、連続した証明書のシリアル番号割り当てを使用して証明書を発行するCAにとっては簡単です。このリスクは、仕様に準拠しており、certificateHold理由コードを使用するように要求することで処理されます。これにより、シリアル番号が永続的に取り消されることが回避されます。発行されていない証明書のステータス要求に対する「取り消された」応答をサポートするCAの場合、この問題を完全に回避する1つの方法は、高いエントロピーを持つランダムな証明書シリアル番号値を割り当てることです。
The mechanism used to choose the response signing algorithm MUST be considered to be sufficiently secure against cryptanalytic attack for the intended application.
応答署名アルゴリズムを選択するために使用されるメカニズムは、意図されたアプリケーションに対する暗号解読攻撃に対して十分に安全であると考えられなければなりません（MUST）。
In most applications, it is sufficient for the signing algorithm to be at least as secure as the signing algorithm used to sign the original certificate whose status is being queried. However, this criterion may not hold in long-term archival applications, in which the status of a certificate is being queried for a date in the distant past, long after the signing algorithm has ceased being considered trustworthy.
ほとんどのアプリケーションでは、署名アルゴリズムは、ステータスが照会される元の証明書の署名に使用される署名アルゴリズムと少なくとも同じくらい安全であれば十分です。ただし、この基準は、署名アルゴリズムが信頼できると見なされなくなってからずっと後に、証明書のステータスが遠い過去の日付で照会される長期のアーカイブアプリケーションには適用されない場合があります。
It is not always possible for a responder to generate a response that the client is expected to understand and that meets contemporary standards for cryptographic security. In such cases, an OCSP responder operator MUST balance the risk of employing a compromised security solution and the cost of mandating an upgrade, including the risk that the alternative chosen by end users will offer even less security or no security.
レスポンダが、クライアントが理解することが期待され、暗号化セキュリティの現在の標準を満たす応答を生成することが常に可能であるとは限りません。このような場合、OCSPレスポンダーオペレーターは、セキュリティが侵害されたセキュリティソリューションを採用するリスクと、エンドユーザーが選択した代替案が提供するセキュリティがさらに低い、またはないというリスクを含め、アップグレードを強制するコストのバランスをとる必要があります。
In archival applications, it is quite possible that an OCSP responder might be asked to report the validity of a certificate on a date in the distant past. Such a certificate might employ a signing method that is no longer considered acceptably secure. In such circumstances, the responder MUST NOT generate a signature using a signing mechanism that is not considered acceptably secure.
アーカイブアプリケーションでは、OCSPレスポンダが遠い過去の日付の証明書の有効性を報告するように求められる可能性がかなりあります。このような証明書は、もはや安全とは考えられない署名方法を採用している可能性があります。そのような状況では、レスポンダは、許容できるほど安全であると見なされていない署名メカニズムを使用して署名を生成してはなりません（MUST NOT）。
A client MUST accept any signing algorithm in a response that it specified as a preferred signing algorithm in the request. It follows, therefore, that a client MUST NOT specify as a preferred signing algorithm any algorithm that is either not supported or not considered acceptably secure.
クライアントは、リクエストで優先署名アルゴリズムとして指定した応答で、署名アルゴリズムを受け入れる必要があります。したがって、クライアントは、サポートされていないか、安全に許容できると見なされていないアルゴリズムを優先署名アルゴリズムとして指定してはなりません（MUST NOT）。
The mechanism to support client indication of preferred signature algorithms is not protected against a man-in-the-middle downgrade attack. This constraint is not considered to be a significant security concern, since the OCSP responder MUST NOT sign OCSP responses using weak algorithms even if requested by the client. In addition, the client can reject OCSP responses that do not meet its own criteria for acceptable cryptographic security no matter what mechanism is used to determine the signing algorithm of the response.
優先署名アルゴリズムのクライアント表示をサポートするメカニズムは、中間者ダウングレード攻撃から保護されていません。 OCSPレスポンダは、クライアントから要求された場合でも、弱いアルゴリズムを使用してOCSP応答に署名してはならないため（MUST NOT）、この制約は重大なセキュリティ問題とは見なされません。さらに、クライアントは、どのメカニズムを使用して応答の署名アルゴリズムを決定するかに関係なく、許容可能な暗号セキュリティの独自の基準を満たさないOCSP応答を拒否できます。
Algorithm agility mechanisms defined in this document introduce a slightly increased attack surface for denial-of-service attacks where the client request is altered to require algorithms that are not supported by the server. Denial-of-service considerations as discussed in RFC 4732 [RFC4732] are relevant for this document.
このドキュメントで定義されているアルゴリズムの俊敏性メカニズムは、サーバーでサポートされていないアルゴリズムを要求するようにクライアント要求が変更されるサービス拒否攻撃の攻撃面をわずかに増やしています。 RFC 4732 [RFC4732]で説明されているサービス拒否の考慮事項は、このドキュメントに関連しています。
This document includes media type registrations (in Appendix C) for ocsp-request and ocsp-response that were registered when RFC 2560 was published. Because this document obsoletes RFC 2560, IANA has updated the references in the "Application Media Types" registry for ocsp-request and ocsp-response to point to this document.
このドキュメントには、RFC 2560の公開時に登録されたocsp-requestおよびocsp-responseのメディアタイプ登録（付録C）が含まれています。このドキュメントはRFC 2560を廃止するため、IANAは「アプリケーションメディアタイプ」レジストリ内のocsp-requestおよびocsp-responseの参照を更新して、このドキュメントを示しています。
[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月。
[RFC2616] 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.
[RFC2616] Fielding、R.、Gettys、J.、Mogul、J.、Frystyk、H.、Masinter、L.、Leach、P。、およびT. Berners-Lee、「Hypertext Transfer Protocol-HTTP / 1.1」 、RFC 2616、1999年6月。
[RFC3279] Bassham, L., Polk, W., and R. Housley, "Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3279, April 2002.
[RFC3279] Bassham、L.、Polk、W.、and R. Housley、 "Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List（CRL）Profile"、RFC 3279、April 2002。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[RFC3986] Berners-Lee、T.、Fielding、R。、およびL. Masinter、「Uniform Resource Identifier（URI）：Generic Syntax」、STD 66、RFC 3986、2005年1月。
[RFC4055] Schaad, J., Kaliski, B., and R. Housley, "Additional Algorithms and Identifiers for RSA Cryptography for use in the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 4055, June 2005.
[RFC4055] Schaad、J.、Kaliski、B。、およびR. Housley、「インターネットX.509公開鍵インフラストラクチャ証明書および証明書失効リスト（CRL）プロファイルで使用するためのRSA暗号化の追加のアルゴリズムと識別子」、RFC 4055 、2005年6月。
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008.
[RFC5280] Cooper、D.、Santesson、S.、Farrell、S.、Boeyen、S.、Housley、R。、およびW. Polk、「Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List（CRL）Profile "、RFC 5280、2008年5月。
[RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification", RFC 5751, January 2010.
[RFC5751] Ramsdell、B。およびS. Turner、「Secure / Multipurpose Internet Mail Extensions（S / MIME）Version 3.2 Message Specification」、RFC 5751、2010年1月。
[RFC6277] Santesson, S. and P. Hallam-Baker, "Online Certificate Status Protocol Algorithm Agility", RFC 6277, June 2011.
[RFC6277] Santesson、S.およびP. Hallam-Baker、「Online Certificate Status Protocol Algorithm Agility」、RFC 6277、2011年6月。
[X.690] ITU-T Recommendation X.690 (2008) | ISO/IEC 8825-1:2008, "Information Technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)", November 2008.
[X.690] ITU-T勧告X.690（2008）| ISO / IEC 8825-1：2008、「Information Technology-ASN.1 encoding rules：Specification of Basic Encoding Rules（BER）、Canonical Encoding Rules（CER）and Distinguished Encoding Rules（DER）」、2008年11月。
[RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. Adams, "X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP", RFC 2560, June 1999.
[RFC2560]マイヤーズ、M。、アンクニー、R。、マルパニ、A。、ガルペリン、S。、およびC.アダムス、「X.509インターネット公開鍵インフラストラクチャオンライン証明書ステータスプロトコル-OCSP」、RFC 2560、1999年6月。
[RFC4732] Handley, M., Ed., Rescorla, E., Ed., and IAB, "Internet Denial-of-Service Considerations", RFC 4732, December 2006.
[RFC4732] Handley、M.、Ed。、Rescorla、E.、Ed。、およびIAB、「インターネットサービス拒否の考慮事項」、RFC 4732、2006年12月。
[RFC5019] Deacon, A. and R. Hurst, "The Lightweight Online Certificate Status Protocol (OCSP) Profile for High-Volume Environments", RFC 5019, September 2007.
[RFC5019]ディーコンA.およびR.ハースト、「大量環境向けの軽量オンライン証明書ステータスプロトコル（OCSP）プロファイル」、RFC 5019、2007年9月。
[RFC5912] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the Public Key Infrastructure Using X.509 (PKIX)", RFC 5912, June 2010.
[RFC5912] Hoffman、P。およびJ. Schaad、「X.509（PKIX）を使用した公開鍵インフラストラクチャ用の新しいASN.1モジュール」、RFC 5912、2010年6月。
Development of this document has been made possible thanks to extensive inputs from members of the PKIX working group.
このドキュメントの開発は、PKIXワーキンググループのメンバーからの広範な意見のおかげで可能になりました。
Jim Schaad provided valuable support by compiling and checking the ASN.1 modules of this specification.
Jim Schaadは、この仕様のASN.1モジュールをコンパイルおよびチェックすることにより、貴重なサポートを提供しました。
This section describes the formatting that will be done to the request and response to support HTTP [RFC2616].
このセクションでは、HTTP [RFC2616]をサポートするために要求と応答に対して行われるフォーマットについて説明します。
HTTP-based OCSP requests can use either the GET or the POST method to submit their requests. To enable HTTP caching, small requests (that after encoding are less than 255 bytes) MAY be submitted using GET. If HTTP caching is not important or if the request is greater than 255 bytes, the request SHOULD be submitted using POST. Where privacy is a requirement, OCSP transactions exchanged using HTTP MAY be protected using either Transport Layer Security/Secure Socket Layer (TLS/SSL) or some other lower-layer protocol.
HTTPベースのOCSP要求は、GETまたはPOSTメソッドを使用して要求を送信できます。 HTTPキャッシングを有効にするには、小さなリクエスト（エンコード後は255バイト未満）がGETを使用して送信される場合があります。 HTTPキャッシングが重要でない場合、またはリクエストが255バイトを超える場合、リクエストはPOSTを使用して送信する必要があります（SHOULD）。プライバシーが必要な場合、HTTPを使用して交換されるOCSPトランザクションは、トランスポート層セキュリティ/ Secure Socket Layer（TLS / SSL）またはその他の下位層プロトコルを使用して保護される場合があります。
An OCSP request using the GET method is constructed as follows:
GETメソッドを使用したOCSP要求は、次のように構成されます。
GET {url}/{url-encoding of base-64 encoding of the DER encoding of
the OCSPRequest}
where {url} may be derived from the value of the authority information access extension in the certificate being checked for revocation, or other local configuration of the OCSP client.
ここで、{url}は、失効がチェックされている証明書の機関情報アクセス拡張機能の値、またはOCSPクライアントの他のローカル構成から取得できます。
An OCSP request using the POST method is constructed as follows: The Content-Type header has the value "application/ocsp-request", while the body of the message is the binary value of the DER encoding of the OCSPRequest.
POSTメソッドを使用するOCSPリクエストは次のように構成されます。Content-Typeヘッダーの値は「application / ocsp-request」で、メッセージの本文はOCSPRequestのDERエンコードのバイナリ値です。
An HTTP-based OCSP response is composed of the appropriate HTTP headers, followed by the binary value of the DER encoding of the OCSPResponse. The Content-Type header has the value "application/ocsp-response". The Content-Length header SHOULD specify the length of the response. Other HTTP headers MAY be present and MAY be ignored if not understood by the requestor.
HTTPベースのOCSP応答は、適切なHTTPヘッダーで構成され、その後にOCSPResponseのDERエンコードのバイナリ値が続きます。 Content-Typeヘッダーの値は「application / ocsp-response」です。 Content-Lengthヘッダーは、応答の長さを指定する必要があります（SHOULD）。他のHTTPヘッダーが存在してもよいし、要求者が理解しなければ無視してもよい[MAY]。
This appendix includes the ASN.1 modules for OCSP. Appendix B.1 includes an ASN.1 module that conforms to the 1998 version of ASN.1 for all syntax elements of OCSP, including the preferred signature algorithms extension that was defined in [RFC6277]. This module replaces the modules in Appendix B of [RFC2560] and Appendix A.2 of [RFC6277]. Appendix B.2 includes an ASN.1 module, corresponding to the module present in B.1, that conforms to the 2008 version of ASN.1. This module replaces the modules in Section 12 of [RFC5912] and Appendix A.1 of [RFC6277]. Although a 2008 ASN.1 module is provided, the module in Appendix B.1 remains the normative module as per the policy of the PKIX working group.
この付録には、OCSP用のASN.1モジュールが含まれています。付録B.1には、[RFC6277]で定義された優先署名アルゴリズム拡張を含む、OCSPのすべての構文要素について、1998バージョンのASN.1に準拠するASN.1モジュールが含まれています。このモジュールは、[RFC2560]の付録Bおよび[RFC6277]の付録A.2のモジュールを置き換えます。付録B.2には、ASN.1の2008バージョンに準拠するB.1にあるモジュールに対応するASN.1モジュールが含まれています。このモジュールは、[RFC5912]のセクション12と[RFC6277]の付録A.1のモジュールを置き換えます。 2008 ASN.1モジュールが提供されていますが、付録B.1のモジュールは、PKIXワーキンググループのポリシーに従って、標準モジュールのままです。
OCSP-2013-88
{iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-ocsp-2013-88(81)}
DEFINITIONS EXPLICIT TAGS ::=
BEGIN
ベギン
IMPORTS
輸入
-- PKIX Certificate Extensions
AuthorityInfoAccessSyntax, CRLReason, GeneralName
FROM PKIX1Implicit88 { iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7)
id-mod(0) id-pkix1-implicit(19) }
Name, CertificateSerialNumber, Extensions,
id-kp, id-ad-ocsp, Certificate, AlgorithmIdentifier
FROM PKIX1Explicit88 { iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7)
id-mod(0) id-pkix1-explicit(18) };
OCSPRequest ::= SEQUENCE {
tbsRequest TBSRequest,
optionalSignature [0] EXPLICIT Signature OPTIONAL }
TBSRequest ::= SEQUENCE {
version [0] EXPLICIT Version DEFAULT v1,
requestorName [1] EXPLICIT GeneralName OPTIONAL,
requestList SEQUENCE OF Request,
requestExtensions [2] EXPLICIT Extensions OPTIONAL }
Signature ::= SEQUENCE {
signatureAlgorithm AlgorithmIdentifier,
signature BIT STRING,
certs [0] EXPLICIT SEQUENCE OF Certificate OPTIONAL }
Version ::= INTEGER { v1(0) } Request ::= SEQUENCE {
reqCert CertID,
singleRequestExtensions [0] EXPLICIT Extensions OPTIONAL }
CertID ::= SEQUENCE {
hashAlgorithm AlgorithmIdentifier,
issuerNameHash OCTET STRING, -- Hash of issuer's DN
issuerKeyHash OCTET STRING, -- Hash of issuer's public key
serialNumber CertificateSerialNumber }
OCSPResponse ::= SEQUENCE {
responseStatus OCSPResponseStatus,
responseBytes [0] EXPLICIT ResponseBytes OPTIONAL }
OCSPResponseStatus ::= ENUMERATED {
successful (0), -- Response has valid confirmations
malformedRequest (1), -- Illegal confirmation request
internalError (2), -- Internal error in issuer
tryLater (3), -- Try again later
-- (4) is not used
sigRequired (5), -- Must sign the request
unauthorized (6) -- Request unauthorized
}
ResponseBytes ::= SEQUENCE {
responseType OBJECT IDENTIFIER,
response OCTET STRING }
BasicOCSPResponse ::= SEQUENCE {
tbsResponseData ResponseData,
signatureAlgorithm AlgorithmIdentifier,
signature BIT STRING,
certs [0] EXPLICIT SEQUENCE OF Certificate OPTIONAL }
ResponseData ::= SEQUENCE {
version [0] EXPLICIT Version DEFAULT v1,
responderID ResponderID,
producedAt GeneralizedTime,
responses SEQUENCE OF SingleResponse,
responseExtensions [1] EXPLICIT Extensions OPTIONAL }
ResponderID ::= CHOICE {
byName [1] Name,
byKey [2] KeyHash }
KeyHash ::= OCTET STRING -- SHA-1 hash of responder's public key
-- (i.e., the SHA-1 hash of the value of the
-- BIT STRING subjectPublicKey [excluding
-- the tag, length, and number of unused
-- bits] in the responder's certificate)
SingleResponse ::= SEQUENCE {
certID CertID,
certStatus CertStatus,
thisUpdate GeneralizedTime,
nextUpdate [0] EXPLICIT GeneralizedTime OPTIONAL,
singleExtensions [1] EXPLICIT Extensions OPTIONAL }
CertStatus ::= CHOICE {
good [0] IMPLICIT NULL,
revoked [1] IMPLICIT RevokedInfo,
unknown [2] IMPLICIT UnknownInfo }
RevokedInfo ::= SEQUENCE {
revocationTime GeneralizedTime,
revocationReason [0] EXPLICIT CRLReason OPTIONAL }
UnknownInfo ::= NULL
ArchiveCutoff ::= GeneralizedTime
AcceptableResponses ::= SEQUENCE OF OBJECT IDENTIFIER
ServiceLocator ::= SEQUENCE {
issuer Name,
locator AuthorityInfoAccessSyntax }
CrlID ::= SEQUENCE {
crlUrl [0] EXPLICIT IA5String OPTIONAL,
crlNum [1] EXPLICIT INTEGER OPTIONAL,
crlTime [2] EXPLICIT GeneralizedTime OPTIONAL }
PreferredSignatureAlgorithms ::= SEQUENCE OF PreferredSignatureAlgorithm
PreferredSignatureAlgorithm ::= SEQUENCE {
sigIdentifier AlgorithmIdentifier,
certIdentifier AlgorithmIdentifier OPTIONAL }
-- Object Identifiers
-オブジェクト識別子
id-kp-OCSPSigning OBJECT IDENTIFIER ::= { id-kp 9 }
id-pkix-ocsp OBJECT IDENTIFIER ::= { id-ad-ocsp }
id-pkix-ocsp-basic OBJECT IDENTIFIER ::= { id-pkix-ocsp 1 }
id-pkix-ocsp-nonce OBJECT IDENTIFIER ::= { id-pkix-ocsp 2 }
id-pkix-ocsp-crl OBJECT IDENTIFIER ::= { id-pkix-ocsp 3 }
id-pkix-ocsp-response OBJECT IDENTIFIER ::= { id-pkix-ocsp 4 }
id-pkix-ocsp-nocheck OBJECT IDENTIFIER ::= { id-pkix-ocsp 5 }
id-pkix-ocsp-archive-cutoff OBJECT IDENTIFIER ::= { id-pkix-ocsp 6 }
id-pkix-ocsp-service-locator OBJECT IDENTIFIER ::= { id-pkix-ocsp 7 }
id-pkix-ocsp-pref-sig-algs OBJECT IDENTIFIER ::= { id-pkix-ocsp 8 }
id-pkix-ocsp-extended-revoke OBJECT IDENTIFIER ::= { id-pkix-ocsp 9 }
END
終わり
OCSP-2013-08
{iso(1) identified-organization(3) dod(6) internet(1) security(5)
mechanisms(5) pkix(7) id-mod(0) id-mod-ocsp-2013-08(82)}
DEFINITIONS EXPLICIT TAGS ::=
BEGIN
ベギン
IMPORTS
輸入
Extensions{}, EXTENSION, ATTRIBUTE
FROM PKIX-CommonTypes-2009 -- From [RFC5912]
{iso(1) identified-organization(3) dod(6) internet(1) security(5)
mechanisms(5) pkix(7) id-mod(0) id-mod-pkixCommon-02(57)}
AlgorithmIdentifier{}, DIGEST-ALGORITHM, SIGNATURE-ALGORITHM, PUBLIC-KEY
FROM AlgorithmInformation-2009 -- From [RFC5912]
{iso(1) identified-organization(3) dod(6) internet(1) security(5)
mechanisms(5) pkix(7) id-mod(0)
id-mod-algorithmInformation-02(58)}
AuthorityInfoAccessSyntax, GeneralName, CrlEntryExtensions
FROM PKIX1Implicit-2009 -- From [RFC5912]
{iso(1) identified-organization(3) dod(6) internet(1) security(5)
mechanisms(5) pkix(7) id-mod(0) id-mod-pkix1-implicit-02(59)}
Name, CertificateSerialNumber, id-kp, id-ad-ocsp, Certificate
FROM PKIX1Explicit-2009 -- From [RFC5912]
{iso(1) identified-organization(3) dod(6) internet(1) security(5)
mechanisms(5) pkix(7) id-mod(0) id-mod-pkix1-explicit-02(51)}
sa-dsaWithSHA1, sa-rsaWithMD2, sa-rsaWithMD5, sa-rsaWithSHA1
FROM PKIXAlgs-2009 -- From [RFC5912]
{iso(1) identified-organization(3) dod(6) internet(1) security(5)
mechanisms(5) pkix(7) id-mod(0)
id-mod-pkix1-algorithms2008-02(56)};
OCSPRequest ::= SEQUENCE {
tbsRequest TBSRequest,
optionalSignature [0] EXPLICIT Signature OPTIONAL }
TBSRequest ::= SEQUENCE {
version [0] EXPLICIT Version DEFAULT v1,
requestorName [1] EXPLICIT GeneralName OPTIONAL,
requestList SEQUENCE OF Request,
requestExtensions [2] EXPLICIT Extensions {{re-ocsp-nonce |
re-ocsp-response, ...,
re-ocsp-preferred-signature-algorithms}} OPTIONAL }
Signature ::= SEQUENCE {
signatureAlgorithm AlgorithmIdentifier
{ SIGNATURE-ALGORITHM, {...}},
signature BIT STRING,
certs [0] EXPLICIT SEQUENCE OF Certificate OPTIONAL }
Version ::= INTEGER { v1(0) }
Request ::= SEQUENCE {
reqCert CertID,
singleRequestExtensions [0] EXPLICIT Extensions
{ {re-ocsp-service-locator,
...}} OPTIONAL }
CertID ::= SEQUENCE {
hashAlgorithm AlgorithmIdentifier
{DIGEST-ALGORITHM, {...}},
issuerNameHash OCTET STRING, -- Hash of issuer's DN
issuerKeyHash OCTET STRING, -- Hash of issuer's public key
serialNumber CertificateSerialNumber }
OCSPResponse ::= SEQUENCE {
responseStatus OCSPResponseStatus,
responseBytes [0] EXPLICIT ResponseBytes OPTIONAL }
OCSPResponseStatus ::= ENUMERATED {
successful (0), -- Response has valid confirmations
malformedRequest (1), -- Illegal confirmation request
internalError (2), -- Internal error in issuer
tryLater (3), -- Try again later
-- (4) is not used
sigRequired (5), -- Must sign the request
unauthorized (6) -- Request unauthorized
}
RESPONSE ::= TYPE-IDENTIFIER
ResponseSet RESPONSE ::= {basicResponse, ...}
ResponseBytes ::= SEQUENCE {
responseType RESPONSE.
&id ({ResponseSet}),
response OCTET STRING (CONTAINING RESPONSE.
&Type({ResponseSet}{@responseType}))}
basicResponse RESPONSE ::=
{ BasicOCSPResponse IDENTIFIED BY id-pkix-ocsp-basic }
BasicOCSPResponse ::= SEQUENCE {
tbsResponseData ResponseData,
signatureAlgorithm AlgorithmIdentifier{SIGNATURE-ALGORITHM,
{sa-dsaWithSHA1 | sa-rsaWithSHA1 |
sa-rsaWithMD5 | sa-rsaWithMD2, ...}},
signature BIT STRING,
certs [0] EXPLICIT SEQUENCE OF Certificate OPTIONAL }
ResponseData ::= SEQUENCE {
version [0] EXPLICIT Version DEFAULT v1,
responderID ResponderID,
producedAt GeneralizedTime,
responses SEQUENCE OF SingleResponse,
responseExtensions [1] EXPLICIT Extensions
{{re-ocsp-nonce, ...,
re-ocsp-extended-revoke}} OPTIONAL }
ResponderID ::= CHOICE {
byName [1] Name,
byKey [2] KeyHash }
KeyHash ::= OCTET STRING -- SHA-1 hash of responder's public key
-- (excluding the tag and length fields)
SingleResponse ::= SEQUENCE {
certID CertID,
certStatus CertStatus,
thisUpdate GeneralizedTime,
nextUpdate [0] EXPLICIT GeneralizedTime OPTIONAL,
singleExtensions [1] EXPLICIT Extensions{{re-ocsp-crl |
re-ocsp-archive-cutoff |
CrlEntryExtensions, ...}
} OPTIONAL }
CertStatus ::= CHOICE {
good [0] IMPLICIT NULL,
revoked [1] IMPLICIT RevokedInfo,
unknown [2] IMPLICIT UnknownInfo }
RevokedInfo ::= SEQUENCE {
revocationTime GeneralizedTime,
revocationReason [0] EXPLICIT CRLReason OPTIONAL }
UnknownInfo ::= NULL
ArchiveCutoff ::= GeneralizedTime
AcceptableResponses ::= SEQUENCE OF RESPONSE.&id({ResponseSet})
ServiceLocator ::= SEQUENCE {
issuer Name,
locator AuthorityInfoAccessSyntax }
CrlID ::= SEQUENCE {
crlUrl [0] EXPLICIT IA5String OPTIONAL,
crlNum [1] EXPLICIT INTEGER OPTIONAL,
crlTime [2] EXPLICIT GeneralizedTime OPTIONAL }
PreferredSignatureAlgorithms ::= SEQUENCE OF PreferredSignatureAlgorithm
PreferredSignatureAlgorithm ::= SEQUENCE {
sigIdentifier AlgorithmIdentifier{SIGNATURE-ALGORITHM, {...}},
certIdentifier AlgorithmIdentifier{PUBLIC-KEY, {...}} OPTIONAL
}
-- Certificate Extensions
-証明書拡張
ext-ocsp-nocheck EXTENSION ::= { SYNTAX NULL IDENTIFIED
BY id-pkix-ocsp-nocheck }
-- Request Extensions
-拡張のリクエスト
re-ocsp-nonce EXTENSION ::= { SYNTAX OCTET STRING IDENTIFIED
BY id-pkix-ocsp-nonce }
re-ocsp-response EXTENSION ::= { SYNTAX AcceptableResponses IDENTIFIED
BY id-pkix-ocsp-response }
re-ocsp-service-locator EXTENSION ::= { SYNTAX ServiceLocator
IDENTIFIED BY
id-pkix-ocsp-service-locator }
re-ocsp-preferred-signature-algorithms EXTENSION ::= {
SYNTAX PreferredSignatureAlgorithms
IDENTIFIED BY id-pkix-ocsp-pref-sig-algs }
-- Response Extensions
-応答拡張
re-ocsp-crl EXTENSION ::= { SYNTAX CrlID IDENTIFIED BY
id-pkix-ocsp-crl }
re-ocsp-archive-cutoff EXTENSION ::= { SYNTAX ArchiveCutoff
IDENTIFIED BY
id-pkix-ocsp-archive-cutoff }
re-ocsp-extended-revoke EXTENSION ::= { SYNTAX NULL IDENTIFIED BY
id-pkix-ocsp-extended-revoke }
-- Object Identifiers
-オブジェクト識別子
id-kp-OCSPSigning OBJECT IDENTIFIER ::= { id-kp 9 }
id-pkix-ocsp OBJECT IDENTIFIER ::= id-ad-ocsp
id-pkix-ocsp-basic OBJECT IDENTIFIER ::= { id-pkix-ocsp 1 }
id-pkix-ocsp-nonce OBJECT IDENTIFIER ::= { id-pkix-ocsp 2 }
id-pkix-ocsp-crl OBJECT IDENTIFIER ::= { id-pkix-ocsp 3 }
id-pkix-ocsp-response OBJECT IDENTIFIER ::= { id-pkix-ocsp 4 }
id-pkix-ocsp-nocheck OBJECT IDENTIFIER ::= { id-pkix-ocsp 5 }
id-pkix-ocsp-archive-cutoff OBJECT IDENTIFIER ::= { id-pkix-ocsp 6 }
id-pkix-ocsp-service-locator OBJECT IDENTIFIER ::= { id-pkix-ocsp 7 }
id-pkix-ocsp-pref-sig-algs OBJECT IDENTIFIER ::= { id-pkix-ocsp 8 }
id-pkix-ocsp-extended-revoke OBJECT IDENTIFIER ::= { id-pkix-ocsp 9 }
END
終わり
To: ietf-types@iana.org
Subject: Registration of MIME media type application/ocsp-request
MIME media type name: application
MIMEメディアタイプ名：アプリケーション
MIME subtype name: ocsp-request
MIMEサブタイプ名：ocsp-request
Required parameters: None
必須パラメーター：なし
Optional parameters: None
オプションのパラメーター：なし
Encoding considerations: binary
エンコーディングに関する考慮事項：バイナリ
Security considerations: Carries a request for information. This request may optionally be cryptographically signed.
セキュリティに関する考慮事項：情報の要求を実行します。この要求には、オプションで暗号で署名することができます。
Interoperability considerations: None
相互運用性に関する考慮事項：なし
Published specification: IETF PKIX Working Group document on the Online Certificate Status Protocol - OCSP
公開された仕様：Online Certificate Status Protocol-OCSPに関するIETF PKIXワーキンググループのドキュメント
Applications which use this media type: OCSP clients
このメディアタイプを使用するアプリケーション：OCSPクライアント
Additional information:
追加情報：
Magic number(s): None
File extension(s): .ORQ
Macintosh File Type Code(s): none
Person & email address to contact for further information:
Stefan Santesson <sts@aaa-sec.com>
Intended usage: COMMON
使用目的：COMMON
Author/Change controller: IETF
作成者/変更コントローラ：IETF
To: ietf-types@iana.org
Subject: Registration of MIME media type application/ocsp-response
MIME media type name: application
MIMEメディアタイプ名：アプリケーション
MIME subtype name: ocsp-response
MIMEサブタイプ名：ocsp-response
Required parameters: None
必須パラメーター：なし
Optional parameters: None
オプションのパラメーター：なし
Encoding considerations: binary
エンコーディングに関する考慮事項：バイナリ
Security considerations: Carries a cryptographically signed response.
セキュリティに関する考慮事項：暗号で署名された応答を実行します。
Interoperability considerations: None
相互運用性に関する考慮事項：なし
Published specification: IETF PKIX Working Group document on the Online Certificate Status Protocol - OCSP
公開された仕様：Online Certificate Status Protocol-OCSPに関するIETF PKIXワーキンググループのドキュメント
Applications which use this media type: OCSP servers
このメディアタイプを使用するアプリケーション：OCSPサーバー
Additional information:
追加情報：
Magic number(s): None
File extension(s): .ORS
Macintosh File Type Code(s): none
Person & email address to contact for further information:
Stefan Santesson <sts@aaa-sec.com>
Intended usage: COMMON
使用目的：COMMON
Author/Change controller: IETF
作成者/変更コントローラ：IETF
Authors' Addresses
著者のアドレス
Stefan Santesson 3xA Security AB Scheelev. 17 223 70 Lund Sweden
Stefan Santesson 3xA Security AB Scheelev。 17223 70ルンドスウェーデン
EMail: sts@aaa-sec.com
メール：sts@aaa-sec.com
Michael Myers TraceRoute Security
Michael Myers TraceRouteのセキュリティ
EMail: mmyers@fastq.com
メール：mmyers@fastq.com
Rich Ankney
リッチアンクニー
Ambarish Malpani CA Technologies 455 West Maude Ave. Suite 210 Sunnyvale, CA 94085 United States
Ambarish Malpani CA Technologies 455 West MaudeAve。 Suite 210 Sunnyvale、CA 94085アメリカ合衆国
EMail: ambarish@gmail.com
メール：ambarish@gmail.com
Slava Galperin A9.com Inc. 130 Lytton Ave. Suite 300 Palo Alto, CA 94301 United States
Slava Galperin A9.com Inc. 130 Lytton Ave. Suite 300 Palo Alto、CA 94301アメリカ合衆国
EMail: slava.galperin@gmail.com
メール：slava.galperin@gmail.com
Carlisle Adams University of Ottawa 800 King Edward Avenue Ottawa ON K1N 6N5 Canada
カーライルアダムス大学オタワ800キングエドワードアベニューオタワON K1N 6N5カナダ
EMail: cadams@eecs.uottawa.ca
メール：cadams@eecs.uottawa.ca