Internet Engineering Task Force (IETF) T. Ito
Request for Comments: 9919 SECOM CO., LTD.
Obsoletes: 5019 C. Wilson
Category: Standards Track Apple, Inc.
ISSN: 2070-1721 C. Bonnell
DigiCert, Inc.
S. Turner
sn3rd
July 2026
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.
この仕様は、大規模 (大容量) 公開キー基盤 (PKI) 環境や、通信帯域幅とクライアント側の処理を最小限に抑えるための軽量ソリューションを必要とする PKI 環境で OCSP を使用する場合に固有のスケーラビリティの問題に対処する、Online Certificate Status Protocol (OCSP) のプロファイルを定義します。
This specification obsoletes RFC 5019. The profile specified in RFC 5019 has been updated to allow and recommend the use of SHA-256 over SHA-1.
この仕様は RFC 5019 を廃止します。RFC 5019 で指定されているプロファイルは、SHA-1 ではなく SHA-256 の使用を許可および推奨するように更新されました。
This is an Internet Standards Track document.
これはインターネット標準化トラックの文書です。
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 7841.
このドキュメントは Internet Engineering Task Force (IETF) の成果物です。これは IETF コミュニティのコンセンサスを表しています。この文書は公開レビューを受け、Internet Engineering Steering Group (IESG) によって公開が承認されています。インターネット標準の詳細については、RFC 7841 のセクション 2 を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9919.
この文書の現在のステータス、正誤表、およびそれに対するフィードバックの提供方法に関する情報は、https://www.rfc-editor.org/info/rfc9919 で入手できます。
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright (c) 2026 IETF Trust および文書の著者として特定された人物。無断転載を禁じます。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
この文書は、BCP 78 およびこの文書の発行日に有効な IETF 文書に関する IETF トラストの法的規定 (https://trustee.ietf.org/license-info) の対象となります。これらの文書には、この文書に関するお客様の権利と制限が記載されているため、注意深くお読みください。このドキュメントから抽出されたコード コンポーネントには、トラスト法的規定のセクション 4.e に記載されている改訂 BSD ライセンス テキストが含まれている必要があり、改訂 BSD ライセンスに記載されているように保証なしで提供されます。
1. Introduction
2. Conventions
3. OCSP Message Profile
3.1. OCSP Request Profile
3.1.1. OCSPRequest Structure
3.1.2. Signed OCSPRequests
3.2. OCSP Response Profile
3.2.1. OCSPResponse Structure
3.2.2. Signed OCSPResponses
3.2.3. OCSPResponseStatus Values
3.2.4. thisUpdate, nextUpdate, and producedAt
4. Client Behavior
4.1. OCSP Responder Discovery
4.2. Sending an OCSP Request
5. Ensuring an OCSPResponse Is Fresh
6. Transport Profile
7. Caching Recommendations
7.1. Caching at the Client
7.2. HTTP Proxies
7.3. Caching at Servers
8. Security Considerations
8.1. Replay Attacks
8.2. On-Path Attacks
8.3. Impersonation Attacks
8.4. Denial-of-Service Attacks
8.5. Modification of HTTP Header Fields
8.6. Request Authentication and Authorization
8.7. Use of SHA-1 for the Calculation of CertID Field Values
9. IANA Considerations
10. References
10.1. Normative References
10.2. Informative References
Appendix A. Differences from RFC 5019
Appendix B. Examples
B.1. Root CA Certificate
B.2. End-Entity Certificate
B.3. OCSP Responder Certificate
B.4. OCSP Request
B.5. OCSP Response
Acknowledgments
Authors' Addresses
The Online Certificate Status Protocol [RFC6960] 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, the term "OCSP" is used herein to denote the verification of certificate status; however, it should be noted that this protocol is employed solely to ascertain the revocation status of a certificate.)
オンライン証明書ステータス プロトコル [RFC6960] は、証明書失効リスト (CRL) を使用する代わりに、デジタル証明書のステータスを決定するために使用されるメカニズムを指定します。1999 年の定義以来、さまざまな環境に導入され、有用な証明書ステータス チェック メカニズムであることが証明されています。(簡潔にするため、ここでは「OCSP」という用語を証明書ステータスの検証を示すために使用します。ただし、このプロトコルは証明書の失効ステータスを確認するためだけに使用されることに注意してください。)
To date, numerous OCSP deployments have been implemented to provide timely and secure certificate status information, crucial for high-value electronic transactions and the handling of highly sensitive information, such as within the banking and financial sectors. Therefore, the requirement for an OCSP responder to respond in "real time" (i.e., generating a new OCSP response for each OCSP request) has been important. In addition, these deployments have operated in environments where bandwidth usage is not an issue and have run on client and server systems where processing power is not constrained.
これまで、銀行や金融部門などでの高額電子取引や機密性の高い情報の取り扱いに不可欠な、タイムリーで安全な証明書ステータス情報を提供するために、多数の OCSP 展開が実装されてきました。したがって、OCSP レスポンダが「リアルタイム」で応答する (つまり、OCSP 要求ごとに新しい OCSP 応答を生成する) という要件が重要でした。さらに、これらの展開は、帯域幅の使用量が問題にならない環境で動作し、処理能力が制限されないクライアントおよびサーバー システムで実行されています。
As the use of PKI continues to grow and move into diverse environments, so does the need for a scalable and cost-effective certificate status mechanism. Although OCSP as currently defined and deployed meets the need of small to medium-sized PKIs that operate on powerful systems on wired networks, there is a limit as to how these OCSP deployments scale from both an efficiency and cost perspective. Mobile environments, where network bandwidth may be at a premium and client-side devices are constrained from a processing point of view, require the careful use of OCSP to minimize bandwidth usage and client-side processing complexity [OCSPMP].
PKI の使用が拡大し、多様な環境に移行するにつれて、スケーラブルでコスト効率の高い証明書ステータス メカニズムの必要性も高まっています。現在定義および展開されている OCSP は、有線ネットワーク上の強力なシステムで動作する中小規模の PKI のニーズを満たしていますが、効率とコストの両方の観点から、これらの OCSP 展開を拡張する方法には限界があります。ネットワーク帯域幅が非常に重要であり、クライアント側デバイスが処理の観点から制約を受けるモバイル環境では、帯域幅の使用量とクライアント側の処理の複雑さを最小限に抑えるために OCSP を慎重に使用する必要があります [OCSPMP]。
PKI continues to be deployed into environments where millions if not hundreds of millions of certificates have been issued. In many of these environments, an even larger number of users (also known as relying parties) have the need to ensure that the certificate they are relying upon has not been revoked. As such, it is important that OCSP is used in such a way that ensures the load on OCSP responders and the network infrastructure required to host those responders are kept to a minimum.
PKI は、数億とは言わないまでも数百万の証明書が発行されている環境に導入され続けています。これらの環境の多くでは、さらに多くのユーザー (証明書利用者とも呼ばれます) が、依存している証明書が失効していないことを確認する必要があります。したがって、OCSP レスポンダーの負荷と、それらのレスポンダーをホストするために必要なネットワーク インフラストラクチャが最小限に抑えられるような方法で OCSP を使用することが重要です。
This document addresses the scalability issues inherent when using OCSP in highly scaled PKI environments by defining a message profile and clarifying OCSP client and responder behavior that will permit:
このドキュメントでは、メッセージ プロファイルを定義し、次のことを可能にする OCSP クライアントとレスポンダの動作を明確にすることで、高度に拡張された PKI 環境で OCSP を使用する場合に固有のスケーラビリティの問題に対処します。
1. OCSP response pre-production and distribution.
1. OCSP 応答の事前制作および配布。
2. Reduced OCSP message size to lower bandwidth usage.
2. OCSP メッセージ サイズを縮小して、帯域幅の使用量を削減しました。
3. Response message caching both in the network and on the client.
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.
このプロファイルで定義された規範要件は、非常に大規模 (大容量) PKI 環境、または前述したように、帯域幅とクライアント側の処理能力 (あるいはその両方) を最小限に抑えるための軽量ソリューションを必要とする PKI 環境で動作する OCSP クライアントと OCSP レスポンダーによって採用されることを目的としています。
OCSP does not have the means to signal responder capabilities within the protocol. Thus, clients may need to use out-of-band mechanisms (e.g., agreed upon arrangements between operators of OCSP responders and OCSP clients) to determine whether a responder conforms to the profile defined in this document. Regardless of the availability of such out-of-band mechanisms, this profile ensures that interoperability will still occur between an OCSP client that fully conforms with [RFC6960] and a responder that is operating in a mode as described in this specification.
OCSP には、プロトコル内でレスポンダーの機能を通知する手段がありません。したがって、クライアントは、レスポンダがこの文書で定義されたプロファイルに準拠しているかどうかを判断するために、アウトオブバンドメカニズム（たとえば、OCSP レスポンダのオペレータと OCSP クライアントの間で合意された取り決め）を使用する必要がある場合があります。このような帯域外メカニズムの可用性に関係なく、このプロファイルは、[RFC6960] に完全に準拠する OCSP クライアントと、この仕様で説明されているモードで動作するレスポンダーとの間で相互運用性が引き続き発生することを保証します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
このドキュメント内のキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、および「OPTIONAL」は、ここに示すようにすべて大文字で表示されている場合にのみ、BCP 14 [RFC2119] [RFC8174] で説明されているように解釈されます。
This section defines a subset of OCSPRequest and OCSPResponse functionality as defined in [RFC6960].
このセクションでは、[RFC6960] で定義されている OCSPRequest および OCSPResponse 機能のサブセットを定義します。
A partial extract of the ASN.1 structure corresponding to the OCSPRequest with the relevant CertID as defined in [RFC6960] is provided here for convenience:
[RFC6960] で定義されている関連する CertID を持つ 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 }
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 }
OCSPRequests that conform to the profile in this document MUST include only one Request in the OCSPRequest.requestList structure.
この文書のプロファイルに準拠する OCSPRequest は、OCSPRequest.requestList 構造にリクエストを 1 つだけ含める必要があります。
The CertID.issuerNameHash and CertID.issuerKeyHash fields contain hashes of the issuer's distinguished name (DN) and public key, respectively. OCSP clients that conform with this profile MUST use SHA-256, as defined in Section 2.2 of [RFC5754], as the hashing algorithm for the CertID.issuerNameHash and the CertID.issuerKeyHash values.
CertID.issuerNameHash フィールドと CertID.issuerKeyHash フィールドには、それぞれ発行者の識別名 (DN) と公開キーのハッシュが含まれています。このプロファイルに準拠する OCSP クライアントは、[RFC5754] のセクション 2.2 で定義されているように、CertID.issuerNameHash および CertID.issuerKeyHash 値のハッシュ アルゴリズムとして SHA-256 を使用しなければなりません (MUST)。
Older OCSP clients that provide backward compatibility with [RFC5019] use SHA-1, as defined in [RFC3174], as the hashing algorithm for the CertID.issuerNameHash and the CertID.issuerKeyHash values. However, these OCSP clients MUST transition from SHA-1 to SHA-256 as soon as practical.
[RFC5019] との下位互換性を提供する古い OCSP クライアントは、[RFC3174] で定義されている SHA-1 を CertID.issuerNameHash および CertID.issuerKeyHash 値のハッシュ アルゴリズムとして使用します。ただし、これらの OCSP クライアントは、できるだけ早く SHA-1 から SHA-256 に移行する必要があります。
Clients MUST NOT include the singleRequestExtensions structure.
クライアントには、singleRequestExtensions 構造を含めてはなりません。
Clients SHOULD NOT include the requestExtensions structure. If a requestExtensions structure is included, it is RECOMMENDED by this profile that the structure contain only the nonce extension (id-pkix-ocsp-nonce). See Section 5 for issues concerning the use of a nonce in high-volume OCSP environments.
クライアントには requestExtensions 構造を含めるべきではありません (SHOULD NOT)。requestExtensions 構造が含まれる場合、このプロファイルでは、その構造に nonce 拡張 (id-pkix-ocsp-nonce) のみが含まれることが推奨されます。大容量 OCSP 環境での nonce の使用に関する問題については、セクション 5 を参照してください。
Clients SHOULD NOT send signed OCSPRequests. Responders MAY ignore the signature on OCSPRequests.
クライアントは署名された OCSPRequest を送信してはなりません。レスポンダーは OCSPRequest の署名を無視してもよい (MAY)。
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 responders MUST handle unsigned OCSP requests that contain the requestorName field, as if the requestorName field were absent.
OCSPRequest が署名されている場合、クライアントは OCSPRequest.requestorName フィールドにその名前を指定する必要があります (SHALL)。それ以外の場合、クライアントは OCSPRequest に requestorName フィールドを含めるべきではありません (SHOULD NOT)。OCSP レスポンダーは、requestorName フィールドが存在しないかのように、requestorName フィールドを含む署名されていない OCSP リクエストを処理しなければなりません (MUST)。
A partial extract of the ASN.1 structure corresponding to the OCSPResponse with the relevant CertID as defined in [RFC6960] is provided here for convenience:
[RFC6960] で定義されている関連する CertID を持つ OCSPResponse に対応する ASN.1 構造の部分的な抜粋を、便宜上ここに提供します。
OCSPResponse ::= SEQUENCE {
responseStatus OCSPResponseStatus,
responseBytes [0] EXPLICIT ResponseBytes OPTIONAL }
ResponseBytes ::= SEQUENCE {
responseType OBJECT IDENTIFIER,
response OCTET STRING }
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 }
ResponseData ::= SEQUENCE {
version [0] EXPLICIT Version DEFAULT v1,
responderID ResponderID,
producedAt GeneralizedTime,
responses SEQUENCE OF SingleResponse,
responseExtensions [1] EXPLICIT Extensions OPTIONAL }
SingleResponse ::= SEQUENCE {
certID CertID,
certStatus CertStatus,
thisUpdate GeneralizedTime,
nextUpdate [0] EXPLICIT GeneralizedTime OPTIONAL,
singleExtensions [1] EXPLICIT Extensions OPTIONAL }
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 that conform 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 and to ensure backward compatibility. For instance, to provide support to OCSP clients that do not yet support the use of SHA-256 for CertID hash calculation, the OCSP responder MAY include two SingleResponse elements in a BasicOCSPResponse. In that BasicOCSPResponse, the CertID of one of the SingleResponse structures uses SHA-1 for the hash calculation, and the CertID in the other SingleResponse uses SHA-256. OCSP responders SHOULD NOT distribute OCSP responses that contain CertIDs that use SHA-1 if the OCSP responder has no clients that require the use of SHA-1. Operators of OCSP responders may consider logging the hash algorithm used by OCSP clients to inform their determination of when it is appropriate to obsolete the distribution of OCSP responses that employ SHA-1 for CertID field hashes. See Section 8.7 for more information on the security considerations for the continued use of SHA-1.
レスポンダーは、id-pkix-ocsp-basic OID で識別される BasicOCSPResponse を生成しなければなりません (MUST)。クライアントは、BasicOCSPResponse を解析して受け入れることができなければなりません。このプロファイルに準拠する OCSPResponse は、ResponseData.responses 構造に SingleResponse を 1 つだけ含めるべきです (SHOULD) が、レスポンス生成前のパフォーマンスやキャッシュ効率を改善し、下位互換性を確保するために、必要に応じて追加の SingleResponse 要素を含めてもよいです (MAY)。たとえば、CertID ハッシュ計算での SHA-256 の使用をまだサポートしていない OCSP クライアントにサポートを提供するために、OCSP レスポンダは BasicOCSPResponse に 2 つの SingleResponse 要素を含めてもよい(MAY)。その BasicOCSPResponse では、SingleResponse 構造の 1 つの CertID はハッシュ計算に SHA-1 を使用し、もう 1 つの SingleResponse 構造の CertID は SHA-256 を使用します。OCSP レスポンダに SHA-1 の使用を必要とするクライアントがない場合、OCSP レスポンダは SHA-1 を使用する CertID を含む OCSP 応答を配布すべきではありません (SHOULD NOT)。OCSP レスポンダのオペレータは、CertID フィールド ハッシュに SHA-1 を使用する OCSP 応答の配布を廃止するのが適切な時期の判断を通知するために、OCSP クライアントが使用するハッシュ アルゴリズムをログに記録することを検討できます。SHA-1 を継続的に使用する場合のセキュリティ上の考慮事項の詳細については、セクション 8.7 を参照してください。
The responder SHOULD NOT include responseExtensions. As specified in [RFC6960], clients MUST ignore unrecognized non-critical responseExtensions in the response.
レスポンダーには、responseExtensions を含めるべきではありません (SHOULD NOT)。[RFC6960] で規定されているように、クライアントは応答内の認識されない非クリティカルな responseExtensions を無視しなければなりません (MUST)。
In the case where a responder does not have the ability to respond to an OCSP request containing an option not supported by the responder, 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 リクエストに応答する能力をレスポンダーが持たない場合、レスポンダーは可能な限り完全な応答を返す必要があります (SHOULD)。たとえば、レスポンダが事前生成された応答のみをサポートし、ノンスを含む OCSP リクエストに応答する能力を持たない場合、レスポンダはノンスを含まない応答を返す必要があります (SHOULD)。
Clients SHOULD attempt to process a response even if the response does not include a nonce. See Section 5 for details on validating responses that do not contain a nonce. See also Section 8 for relevant security considerations.
クライアントは、応答にノンスが含まれていない場合でも、応答の処理を試みるべきです(SHOULD)。nonce を含まない応答の検証の詳細については、セクション 5 を参照してください。関連するセキュリティ上の考慮事項については、セクション 8 も参照してください。
Responders that do not have the ability to respond to OCSP requests that contain an unsupported option such as a nonce MAY forward the request to an OCSP responder capable of doing so.
ノンスなどのサポートされていないオプションを含む OCSP リクエストに応答する能力を持たないレスポンダは、それが可能な OCSP レスポンダにリクエストを転送してもよい(MAY)。
The responder MAY include the SingleResponse.singleExtensions extensions structure.
レスポンダーには、SingleResponse.singleExtensions 拡張構造を含めてもよい (MAY)。
Clients MUST validate the signature on the OCSPResponse.
クライアントは OCSPResponse の署名を検証しなければなりません (MUST)。
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 構造内で参照されなければなりません (MUST)。
It is RECOMMENDED that the OCSP responder's certificate contain the id-pkix-ocsp-nocheck extension, as defined in [RFC6960], to indicate to the client that it need not check the certificate's status. In addition, it is RECOMMENDED that neither an OCSP Authority Information Access (AIA) extension nor CRL Distribution Points (CRLDP) extension be included in the OCSP responder's certificate. Accordingly, the responder's signing certificate SHOULD be relatively short-lived and renewed regularly.
[RFC6960]で定義されているように、証明書のステータスをチェックする必要がないことをクライアントに示すために、OCSP レスポンダの証明書に id-pkix-ocsp-nocheck 拡張子を含めることが推奨されます。さらに、OCSP Authority Information Access (AIA) 拡張機能も CRL Distribution Points (CRLDP) 拡張機能も OCSP レスポンダの証明書に含めないことが推奨されます。したがって、レスポンダーの署名証明書の有効期間は比較的短く、定期的に更新されるべきです(SHOULD)。
Clients MUST be able to identify OCSP responder certificates using the byKey field and SHOULD be able to identify OCSP responder certificates using the byName field of the ResponseData.ResponderID [RFC6960] choices.
クライアントは、byKey フィールドを使用して OCSP レスポンダー証明書を識別できなければならず、ResponseData.ResponderID [RFC6960] の選択肢の byName フィールドを使用して OCSP レスポンダー証明書を識別できる必要があります (SHOULD)。
Older responders that provide backward compatibility with the protocol defined in [RFC5019] MAY use the byName field to represent the ResponderID but should transition to using the byKey field as soon as practical.
[RFC5019] で定義されたプロトコルとの下位互換性を提供する古いレスポンダーは、ResponderID を表すために byName フィールドを使用してもよいですが、できるだけ早く byKey フィールドの使用に移行する必要があります。
Newer responders that conform to this profile MUST use the byKey field to represent the ResponderID to reduce the size of the response.
このプロファイルに準拠する新しいレスポンダーは、応答のサイズを減らすために、byKey フィールドを使用して ResponderID を表す必要があります。
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".
OCSP インフラストラクチャに特定の証明書に対する信頼できるレコードがある限り、「成功」の OCSPResponseStatus が返されます。特定の証明書の信頼できるレコードにアクセスできない場合、レスポンダは「unauthorized」の OCSPResponseStatus を返さなければなりません (MUST)。
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 が「unauthorized」で応答します。また、失効情報のデータベースが時間の経過とともに際限なく増大しないようにするために、レスポンダは期限切れの証明書のステータス レコードを削除してもよい(MAY)。レコードが削除された証明書をクライアントから要求すると、OCSPResponseStatus が「unauthorized」になります。
Security considerations regarding the use of unsigned responses are discussed in [RFC6960].
署名されていない応答の使用に関するセキュリティ上の考慮事項は、[RFC6960] で議論されています。
When pre-producing OCSPResponse messages, the responder MUST set the thisUpdate, nextUpdate, and producedAt times as follows:
OCSPResponse メッセージを事前に生成する場合、レスポンダーは thisUpdate、nextUpdate、および generatedAt を次のように設定しなければなりません。
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. As described in Section 2.4 of [RFC6960], this field is optional. However, this field MUST be included in the profile specified in this document to help clients cache responses. See Section 7 for additional information on caching.
証明書のステータスに関する新しい情報が入手可能になる時刻、またはそれ以前の時刻。[RFC6960] のセクション 2.4 で説明されているように、このフィールドはオプションです。ただし、クライアントが応答をキャッシュできるようにするために、このフィールドはこの文書で指定されたプロファイルに含める必要があります。キャッシュの詳細については、セクション 7 を参照してください。
producedAt:
生産場所:
The time at which the OCSP response was signed.
OCSP 応答が署名された時刻。
Note: The values of thisUpdate, nextUpdate, and producedAt are set as described in Section 2.5 of [RFC6960], and in many cases, the value of thisUpdate and producedAt are the same.
注: thisUpdate、nextUpdate、および generatedAt の値は、[RFC6960] のセクション 2.5 で説明されているように設定され、多くの場合、thisUpdate と generatedAt の値は同じです。
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、productionAt などの ASN.1 でエンコードされた GeneralizedTime 値はグリニッジ標準時 (ズールー) で表現しなければならず、秒数が 0 の場合でも秒を含めなければなりません (つまり、時間は YYYYMMDDHHMMSSZ)。GeneralizedTime 値には小数点以下の秒を含めてはなりません。
Clients MUST support the AIA extension as defined in [RFC5280] and MUST recognize the id-ad-ocsp access method. This enables CAs to inform clients how they can contact the OCSP service.
クライアントは、[RFC5280] で定義されている AIA 拡張をサポートしなければならず (MUST)、id-ad-ocsp アクセス方式を認識しなければなりません (MUST)。これにより、CA はクライアントに OCSP サービスへの接続方法を通知できるようになります。
In the case where a client is checking the status of a certificate that contains both an AIA extension pointing to an OCSP responder and a CRLDP 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 レスポンダーを指す AIA 拡張と CRL を指す CRLDP 拡張の両方を含む証明書のステータスをチェックしている場合、クライアントは最初に OCSP レスポンダーへの接続を試みるべきです(SHOULD)。クライアントは、ローカルに設定されたタイムアウトと再試行回数を超えてもレスポンダから OCSPResponse を受信しない場合、CRL の取得を試みてもよい(MAY)。
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 チェックを要求してはなりません (MUST NOT)。
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 クライアントに証明書のステータスの確認を要求する前に、チェーン内の証明書の署名を検証しなければなりません (MUST)。証明書の署名が無効であるか、アプリケーションがそれを検証できない場合、OCSP チェックを要求してはなりません (MUST NOT)。クライアントは、期限切れの証明書のステータスを確認するリクエストを行ってはなりません。
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 つ目は nonce を使用し、2 つ目は時間に基づきます。時間ベースのメカニズムが機能するためには、クライアントとレスポンダーの両方が正確な時間ソースにアクセスできなければなりません。
Because this profile specifies that clients SHOULD NOT include a requestExtensions structure in OCSPRequests (see Section 3.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 構造体を含めるべきではないことを指定しているため (セクション 3.1 を参照)、クライアントは正確な時間ソースに基づいて OCSPResponse の鮮度を判断できなければなりません (MUST)。リクエストに nonce を含めることを選択したクライアントは、存在しない予期される nonce のみに基づいて対応する OCSPResponse を拒否すべきではありませんが、時間に基づいて OCSPResponse を検証することにフォールバックしなければなりません (MUST)。
Clients that do not include a nonce in the request MUST ignore any nonce that may be present in the response.
リクエストに nonce を含まないクライアントは、応答に存在する可能性のある nonce を無視しなければなりません (MUST)。
Clients MUST check for the existence of the nextUpdate field and MUST ensure the current time, expressed in GMT time as described in Section 3.2.4, falls between the thisUpdate and nextUpdate times. If the nextUpdate field is absent, the client MUST reject the response.
クライアントは nextUpdate フィールドの存在を確認しなければならず (MUST)、セクション 3.2.4 で説明されている GMT 時間で表される現在時刻が thisUpdate 時刻と nextUpdate 時刻の間にあることを確認しなければなりません (MUST)。nextUpdate フィールドが存在しない場合、クライアントは応答を拒否しなければなりません (MUST)。
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 (e.g., allow one day difference).
nextUpdate フィールドが存在する場合、クライアントはそれが現在時刻より前でないことを確認しなければなりません (MUST)。クライアントの現在時刻が nextUpdate フィールドで指定された時刻より後の場合、クライアントは応答を古いものとして拒否しなければなりません (MUST)。クライアントは、レスポンダとキャッシュに対するわずかなクロックの違いを処理するために、nextUpdate 後の応答の受け入れに対して小さな許容期間を設定できるようにしてもよい (MAY)。この許容期間は、呼び出し元のアプリケーション環境で利用できる時刻同期テクノロジの精度と精度に基づいて選択する必要があります。たとえば、低遅延接続のインターネット ピアは通常、NTP 時刻同期によって 1 秒以内に正確さが保たれることを期待します。待ち時間が長い環境や NTP アナログが利用できない環境では、許容範囲をより寛大にする必要がある場合があります (たとえば、1 日の違いを許容する)。
See the security considerations in Section 8 for additional details on replay and on-path attacks.
リプレイ攻撃とオンパス攻撃の詳細については、セクション 8 のセキュリティに関する考慮事項を参照してください。
OCSP clients can send HTTP-based OCSP requests using either the GET or POST method. 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 Appendix A.1 of [RFC6960] when constructing these messages.
OCSP クライアントは、GET メソッドまたは POST メソッドを使用して HTTP ベースの OCSP リクエストを送信できます。OCSP レスポンダは、HTTP 経由のリクエストと応答をサポートしなければなりません (MUST)。スキームと区切り文字 (http://)、サーバー名、base64 でエンコードされた OCSPRequest 構造を含む、合計 255 バイト以下 (エンコード後) のリクエストを送信する場合、クライアントは GET メソッドを使用しなければなりません (OCSP 応答キャッシュを有効にするため)。255 バイトを超える OCSP リクエストは、POST メソッドを使用して送信する必要があります (SHOULD)。どのような場合でも、クライアントはこれらのメッセージを作成する際に、[RFC6960] の付録 A.1 の説明に従わなければなりません (MUST)。
When constructing a GET message, OCSP clients MUST base64-encode the OCSPRequest structure according to Section 4 of [RFC4648]. Clients MUST NOT include whitespace or any other characters that are not part of the base64 character repertoire in the base64-encoded string. Clients MUST properly URL-encode the base64-encoded OCSPRequest according to [RFC3986]. OCSP clients MUST append the base64-encoded OCSPRequest to the URI specified in the AIA extension [RFC5280]. For example:
GET メッセージを構築するとき、OCSP クライアントは [RFC4648] のセクション 4 に従って OCSPRequest 構造を Base64 エンコードしなければなりません (MUST)。クライアントは、base64 でエンコードされた文字列に空白や、base64 文字レパートリーの一部ではないその他の文字を含めてはなりません。クライアントは、[RFC3986] に従って、base64 でエンコードされた OCSPRequest を適切に URL エンコードしなければなりません (MUST)。OCSP クライアントは、AIA 拡張 [RFC5280] で指定された URI に、base64 でエンコードされた OCSPRequest を追加しなければなりません (MUST)。例えば：
http://ocsp.example.com/MEowSDBGMEQwQjAKBggqhkiG9w0CBQQQ7sp6GTKpL2dA
deGaW267owQQqInESWQD0mGeBArSgv%2FBWQIQLJx%2Fg9xF8oySYzol80Mbpg%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 [RFC9110] [RFC9111] header fields.
キャッシュ可能な適切にフォーマットされた OCSPRequest (つまり、nextUpdate 値を含む応答) に応答して、応答側は、次の HTTP [RFC9110] [RFC9111] ヘッダー フィールドの前に、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 7.2 for details on the use of these HTTP header fields.
これらの HTTP ヘッダー フィールドの使用方法の詳細については、セクション 7.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 indicates an OCSPResponseStatus of "successful").
帯域幅の使用量を最小限に抑えるために、クライアントは権限のある OCSP 応答 (つまり、正常に検証され、OCSPResponseStatus が「成功」を示す署名を持つ応答) をローカルにキャッシュしなければなりません (MUST)。
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 を送信します。多くのクライアントが一般的な証明書のキャッシュされた応答を更新するときに発生する可能性のあるレスポンダーの負荷の大幅なスパイクを回避するために、レスポンダーは、クライアントがいつ更新された OCSP 応答をフェッチする必要があるかを、cache-control:max-age ディレクティブを使用して指定してもよい(MAY)。クライアントは、最大経過時間以降に更新された OCSP 応答を取得する必要があります (SHOULD)。クライアントが更新された OCSP 応答を確実に受信できるようにするために、OCSP レスポンダーは max-age time が経過する前に OCSP 応答を更新しなければなりません (MUST)。
The responder SHOULD set the HTTP header fields of the OCSP response in such a way as to allow for the intelligent use of intermediate HTTP proxy servers. See [RFC9110] and [RFC9111] for the full definition of these HTTP header fields and the proper format of any date and time values.
応答側は、中間の HTTP プロキシ サーバーのインテリジェントな使用を可能にするような方法で、OCSP 応答の HTTP ヘッダー フィールドを設定すべきです (SHOULD)。これらの HTTP ヘッダフィールドの完全な定義と日付と時刻の値の適切な形式については、[RFC9110] および [RFC9111] を参照してください。
+===============+===================================================+
| HTTP Header | Description |
| Field | |
+===============+===================================================+
| Date | The date and time at which the OCSP responder |
| | 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. |
+---------------+---------------------------------------------------+
| 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. |
+---------------+---------------------------------------------------+
| ETag | A string that identifies a particular version of |
| | the associated data. It is RECOMMENDED by this |
| | profile that the ETag value be the ASCII HEX |
| | representation of the SHA-256 hash of the |
| | OCSPResponse structure. |
+---------------+---------------------------------------------------+
| Cache-Control | Contains a number of caching directives. |
| | |
| | * max-age = < n > - where n is a time value |
| | later than thisUpdate but earlier than |
| | nextUpdate. |
| | |
| | * public - makes normally uncachable response |
| | cachable by both shared and nonshared caches. |
| | |
| | * no-transform - specifies that a proxy cache |
| | cannot change the type, length, or encoding |
| | of the object content. |
| | |
| | * must-revalidate - prevents caches from |
| | intentionally returning stale responses. |
+---------------+---------------------------------------------------+
Table 1: HTTP Header Fields
表 1: HTTP ヘッダー フィールド
OCSP responders MUST NOT include the "Pragma: no-cache", "Cache-Control: no-cache", or "Cache-Control: no-store" HTTP header fields in authoritative OCSP responses.
OCSP レスポンダーは、権限のある OCSP 応答に「Pragma: no-cache」、「Cache-Control: no-cache」、または「Cache-Control: no-store」HTTP ヘッダー フィールドを含めてはなりません (MUST NOT)。
OCSP responders SHOULD include one or more of these HTTP header fields in non-authoritative OCSP responses.
OCSP レスポンダーは、権限のない OCSP 応答にこれらの HTTP ヘッダー フィールドを 1 つ以上含めるべきです (SHOULD)。
For example, assume that an OCSP response has the following timestamp values:
たとえば、OCSP 応答に次のタイムスタンプ値があるとします。
thisUpdate = March 19, 2023 01:00:00 GMT
nextUpdate = March 21, 2023 01:00:00 GMT
producedAt = March 19, 2023 01:00:00 GMT
and that an OCSP client requests the response on March 20, 2023 01:00:00 GMT. In this scenario, the HTTP response may look like this:
そして、OCSP クライアントが 2023 年 3 月 20 日 01:00:00 GMT に応答を要求するとします。このシナリオでは、HTTP 応答は次のようになります。
Content-Type: application/ocsp-response
Content-Length: 1000
Date: Mon, 20 Mar 2023 01:00:00 GMT
Last-Modified: Sun, 19 Mar 2023 01:00:00 GMT
ETag: "97df3588b5a3f24babc3851b372f0ba7
1a9dcdded43b14b9d06961bfc1707d9d"
Expires: Tue, 21 Mar 2023 01:00:00 GMT
Cache-Control: max-age=86000,public,no-transform,must-revalidate
<...>
OCSP clients MUST NOT include a no-cache HTTP header field 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 field in the request (i.e., Pragma: no-cache or Cache-Control: no-cache).
OCSP クライアントは、中間プロキシの古いデータのキャッシュの結果としてクライアントが期限切れの応答に遭遇しない限り、OCSP 要求メッセージに no-cache HTTP ヘッダー フィールドを含めてはなりません (MUST NOT)。この状況では、クライアントは、リクエストに適切な HTTP ヘッダーフィールド (つまり、Pragma: no-cache または Cache-Control: no-cache) を含めることによって、プロキシをバイパスする必要があることを指定してリクエストを再送信する必要があります (SHOULD)。
In some scenarios, it is advantageous to include OCSP response information within the protocol being utilized between the client and OCSP responder. Including OCSP responses in this manner has a few attractive effects.
一部のシナリオでは、クライアントと OCSP レスポンダーの間で使用されるプロトコル内に OCSP 応答情報を含めると有利です。この方法で OCSP 応答を含めることには、いくつかの魅力的な効果があります。
First, it allows for the caching of OCSP responses on the OCSP responder, thus lowering the number of hits.
まず、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 OCSP responder.
2 番目に、クライアントがネットワークに接続されていない場合に証明書の検証が可能になり、クライアントが OCSP レスポンダーとの新しい HTTP セッションを確立する必要がなくなります。
Third, it reduces the number of round trips the client needs to make in order to complete a handshake.
3 番目に、クライアントがハンドシェイクを完了するために必要な往復回数が減少します。
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 protocol in Section 4.4.2 of [RFC9846] but can be applied to any client-server protocol.
この機能は、[RFC9846] のセクション 4.4.2 で TLS プロトコルの拡張機能として指定されていますが、任意のクライアント/サーバー プロトコルに適用できます。
It is RECOMMENDED by this profile 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 [RFC3143].
キャッシュの問題に関する詳細情報は、[RFC3143] から入手できます。
The following considerations apply in addition to the security considerations addressed in Section 5 of [RFC6960].
[RFC6960] のセクション 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.
このプロファイルでの nonce の使用はオプションであるため、期限切れの 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 OCSP may provide a way for the client to know whether the responder supports nonces or does not support nonces. If a client can determine that the responder supports nonces, it MUST reject a reply that does not contain an expected nonce. Otherwise, clients that opt to include a nonce in the request SHOULD NOT reject a corresponding OCSPResponse solely on the basis of the nonexistent expected nonce but MUST fall back to validating the OCSPResponse based on time.
OCSP の将来のバージョンでは、レスポンダが nonce をサポートしているかサポートしていないかをクライアントが知る方法が提供される可能性があります。クライアントがレスポンダが nonce をサポートしていると判断できる場合、期待される nonce を含まない応答を拒否しなければなりません (MUST)。それ以外の場合、リクエストに nonce を含めることを選択したクライアントは、存在しない予期される nonce のみに基づいて対応する OCSPResponse を拒否すべきではありませんが、時間に基づいて OCSPResponse を検証することにフォールバックしなければなりません (MUST)。
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 Section 4.2.2.2 of [RFC6960].
クライアントは、[RFC6960] のセクション 4.2.2.2 に記載されている規則に従って、承認された応答者と通信していることを確認しなければなりません (MUST)。
The use of signed responses in OCSP serves to authenticate the identity of OCSP responder.
OCSP での署名付き応答の使用は、OCSP レスポンダーの ID を認証するために役立ちます。
As detailed in [RFC6960], 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.
[RFC6960] で詳しく説明されているように、クライアントは 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 レスポンダーは、サービス拒否攻撃を防止または軽減するための措置を講じるべきです(SHOULD)。このプロファイルでは署名されていない OCSPRequest の使用が指定されているため、レスポンダーにリクエストを送信できるすべてのユーザーにレスポンダーへのアクセスが暗黙的に与えられるため、大量のリクエストを介してサービス拒否攻撃を仕掛ける可能性が高くなる可能性があります。たとえば、問題のある動作が検出された場合、レスポンダーは特定の IP アドレスからの受信リクエストのレートを制限できます。
Values included in HTTP header fields, as described in Sections 6 and 7, 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 (Section 4.2.2.1 of [RFC6960]). Clients SHOULD NOT rely on cached responses beyond the nextUpdate time.
セクション 6 と 7 で説明されているように、HTTP ヘッダー フィールドに含まれる値は暗号的に保護されていません。攻撃者によって操作される可能性があります。クライアントはこれらの値をキャッシュのガイダンスとしてのみ使用すべきであり、最終的には署名された OCSPResponse ([RFC6960] のセクション 4.2.2.1) に存在する値のみに依存すべきです。クライアントは、nextUpdate 時間を超えてキャッシュされた応答に依存すべきではありません。
The suggested use of unsigned requests in this environment removes an option that allows the responder to determine the authenticity of incoming requests. 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 レスポンダーにアクセスするための明示的な承認が必要な環境では、他のメカニズムを利用してリクエスターを認証したり、サービスを制限または測定したりできます。
Although the use of SHA-1 for the calculation of CertID field values is not of concern from a cryptographic security standpoint, the continued use of SHA-1 in an ecosystem requires that software that interoperates with the ecosystem maintain support for SHA-1. This increases implementation complexity and potential attack surface for the software in question. Thus, the continued use of SHA-1 in an ecosystem to maintain interoperability with legacy software must be weighed against the increased implementation complexity and potential attack surface.
CertID フィールド値の計算に SHA-1 を使用することは、暗号化セキュリティの観点からは問題ありませんが、エコシステム内で SHA-1 を継続的に使用するには、エコシステムと相互運用するソフトウェアが SHA-1 のサポートを維持する必要があります。これにより、実装が複雑になり、問題のソフトウェアに対する潜在的な攻撃対象領域が増加します。したがって、レガシー ソフトウェアとの相互運用性を維持するためにエコシステム内で SHA-1 を継続的に使用する場合は、実装の複雑さの増加と潜在的な攻撃対象領域とを比較検討する必要があります。
This document has no IANA actions.
この文書には IANA のアクションはありません。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, DOI 10.17487/RFC3986, January 2005,
<https://www.rfc-editor.org/info/rfc3986>.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
<https://www.rfc-editor.org/info/rfc4648>.
[RFC5019] Deacon, A. and R. Hurst, "The Lightweight Online
Certificate Status Protocol (OCSP) Profile for High-Volume
Environments", RFC 5019, DOI 10.17487/RFC5019, September
2007, <https://www.rfc-editor.org/info/rfc5019>.
[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, DOI 10.17487/RFC5280, May 2008,
<https://www.rfc-editor.org/info/rfc5280>.
[RFC5754] Turner, S., "Using SHA2 Algorithms with Cryptographic
Message Syntax", RFC 5754, DOI 10.17487/RFC5754, January
2010, <https://www.rfc-editor.org/info/rfc5754>.
[RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A.,
Galperin, S., and C. Adams, "X.509 Internet Public Key
Infrastructure Online Certificate Status Protocol - OCSP",
RFC 6960, DOI 10.17487/RFC6960, June 2013,
<https://www.rfc-editor.org/info/rfc6960>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC9110] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "HTTP Semantics", STD 97, RFC 9110,
DOI 10.17487/RFC9110, June 2022,
<https://www.rfc-editor.org/info/rfc9110>.
[RFC9111] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "HTTP Caching", STD 98, RFC 9111,
DOI 10.17487/RFC9111, June 2022,
<https://www.rfc-editor.org/info/rfc9111>.
[RFC9846] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 9846, DOI 10.17487/RFC9846, July 2026,
<https://www.rfc-editor.org/info/rfc9846>.
[OCSPMP] Open Mobile Alliance, "Online Certificate Status Protocol
Mobile Profile", Candidate Version V1.0, 27 January 2004,
<https://www.openmobilealliance.org/release/OCSP/
V1_0-20040127-C/OMA-WAP-OCSP-V1_0-20040127-C.pd>.
[RFC3143] Cooper, I. and J. Dilley, "Known HTTP Proxy/Caching
Problems", RFC 3143, DOI 10.17487/RFC3143, June 2001,
<https://www.rfc-editor.org/info/rfc3143>.
[RFC3174] Eastlake 3rd, D. and P. Jones, "US Secure Hash Algorithm 1
(SHA1)", RFC 3174, DOI 10.17487/RFC3174, September 2001,
<https://www.rfc-editor.org/info/rfc3174>.
[RFC9500] Gutmann, P. and C. Bonnell, "Standard Public Key
Cryptography (PKC) Test Keys", RFC 9500,
DOI 10.17487/RFC9500, December 2023,
<https://www.rfc-editor.org/info/rfc9500>.
This document obsoletes [RFC5019]. [RFC5019] defines a lightweight profile for OCSP that makes the protocol more suitable for use in high-volume environments. The lightweight profile specifies the mandatory use of SHA-1 when calculating the values of several fields in OCSP requests and responses. In recent years, weaknesses have been demonstrated with the SHA-1 algorithm. As a result, SHA-1 is increasingly falling out of use even for non-security-relevant use cases. This document obsoletes the lightweight profile as specified in [RFC5019] to instead recommend the use of SHA-256 where SHA-1 was previously required. An OCSP client compliant with [RFC5019] is still able to use SHA-1, but the use of SHA-1 may become obsolete in the future.
この文書は [RFC5019] を廃止します。[RFC5019] は、プロトコルを大容量環境での使用により適したものにする OCSP の軽量プロファイルを定義しています。軽量プロファイルは、OCSP 要求および応答のいくつかのフィールドの値を計算するときに SHA-1 の使用を必須にすることを指定します。近年、SHA-1 アルゴリズムの弱点が明らかになりました。その結果、SHA-1 はセキュリティ関連以外のユースケースでも使用されなくなりつつあります。この文書は、[RFC5019] で指定されている軽量プロファイルを廃止し、以前は SHA-1 が必要であった代わりに SHA-256 の使用を推奨します。[RFC5019] に準拠した OCSP クライアントは引き続き SHA-1 を使用できますが、SHA-1 の使用は将来廃止される可能性があります。
Substantive changes to RFC 5019:
RFC 5019 への実質的な変更:
* Section 3.1.1 requires new OCSP clients to use SHA-256 to support migration for OCSP clients.
* セクション 3.1.1 では、新しい OCSP クライアントが SHA-256 を使用して OCSP クライアントの移行をサポートすることを要求しています。
* Section 3.2.2 requires new OCSP responders to use the byKey field and support migration from byName fields.
* セクション 3.2.2 では、新しい OCSP レスポンダーが byKey フィールドを使用し、byName フィールドからの移行をサポートすることを要求しています。
* Section 6 clarifies that OCSP clients MUST NOT include whitespace or any other characters that are not part of the base64 character repertoire in the base64-encoded string.
* セクション 6 では、OCSP クライアントが、base64 でエンコードされた文字列に空白文字や、base64 文字レパートリーの一部ではないその他の文字を含めてはいけないことを明確にしています。
This is a self-signed certificate for the CA that issued the end-entity certificate and OCSP-delegated responder example certificates below.
これは、エンドエンティティ証明書と以下の OCSP 委任レスポンダーのサンプル証明書を発行した CA の自己署名証明書です。
The key pair for the CA is the "testECCP521" key from Section 2.3 of [RFC9500].
CA の鍵ペアは、[RFC9500] のセクション 2.3 の「testECCP521」鍵です。
-----BEGIN CERTIFICATE-----
MIICKDCCAYqgAwIBAgIBATAKBggqhkjOPQQDBDA4MQswCQYDVQQGEwJYWDEUMBIG
A1UECgwLQ2VydHMgJ3IgVXMxEzARBgNVBAMMCklzc3VpbmcgQ0EwHhcNMjQwNDAy
MTIzNzQ3WhcNMjUwNDAyMTIzNzQ3WjA4MQswCQYDVQQGEwJYWDEUMBIGA1UECgwL
Q2VydHMgJ3IgVXMxEzARBgNVBAMMCklzc3VpbmcgQ0EwgZswEAYHKoZIzj0CAQYF
K4EEACMDgYYABAHQ/XJXqEx0f1YldcBzhdvr8vUr6lgIPbgv3RUx2KrjzIdf8C/3
+i2iYNjrYtbS9dZJJ44yFzagYoy7swMItuYY2wD2KtIExkYDWbyBiriWG/Dw/A7F
quikKBc85W8A3psVfB5cgsZPVi/K3vxKTCj200LPPvYW/ILTO3KFySHyvzb92KNC
MEAwHQYDVR0OBBYEFI7CFAlgduqQOOk5rhttUsQXfZ++MA8GA1UdEwEB/wQFMAMB
Af8wDgYDVR0PAQH/BAQDAgIEMAoGCCqGSM49BAMEA4GLADCBhwJBbr/1SJiHCgXG
EJ7R+3er1LdWqrdZHgtCwyT7+wFBIJmVswEiom2LGh/oMuu5mD+u/+o1m07vmmZj
/+ipGp8TIwkCQgCoZ4bHte6XkFm7hUXascLN7vkv7qKwXyTsCvIDpEDTRCX8dUFe
73jGebitkumRHjVhlBJLo7n3FMJrFHNoeblMbw==
-----END CERTIFICATE-----
0 552: SEQUENCE {
4 394: SEQUENCE {
8 3: [0] {
10 1: INTEGER 2
: }
13 1: INTEGER 1
16 10: SEQUENCE {
18 8: OBJECT IDENTIFIER ecdsaWithSHA512 (1 2 840 10045 4 3 4)
: }
28 56: SEQUENCE {
30 11: SET {
32 9: SEQUENCE {
34 3: OBJECT IDENTIFIER countryName (2 5 4 6)
39 2: PrintableString 'XX'
: }
: }
43 20: SET {
45 18: SEQUENCE {
47 3: OBJECT IDENTIFIER organizationName (2 5 4 10)
52 11: UTF8String 'Certs 'r Us'
: }
: }
65 19: SET {
67 17: SEQUENCE {
69 3: OBJECT IDENTIFIER commonName (2 5 4 3)
74 10: UTF8String 'Issuing CA'
: }
: }
: }
86 30: SEQUENCE {
88 13: UTCTime 02/04/2024 12:37:47 GMT
103 13: UTCTime 02/04/2025 12:37:47 GMT
: }
118 56: SEQUENCE {
120 11: SET {
122 9: SEQUENCE {
124 3: OBJECT IDENTIFIER countryName (2 5 4 6)
129 2: PrintableString 'XX'
: }
: }
133 20: SET {
135 18: SEQUENCE {
137 3: OBJECT IDENTIFIER organizationName (2 5 4 10)
142 11: UTF8String 'Certs 'r Us'
: }
: }
155 19: SET {
157 17: SEQUENCE {
159 3: OBJECT IDENTIFIER commonName (2 5 4 3)
164 10: UTF8String 'Issuing CA'
: }
: }
: }
176 155: SEQUENCE {
179 16: SEQUENCE {
181 7: OBJECT IDENTIFIER ecPublicKey (1 2 840 10045 2 1)
190 5: OBJECT IDENTIFIER secp521r1 (1 3 132 0 35)
: }
197 134: BIT STRING
: 04 01 D0 FD 72 57 A8 4C 74 7F 56 25 75 C0 73 85
: DB EB F2 F5 2B EA 58 08 3D B8 2F DD 15 31 D8 AA
: E3 CC 87 5F F0 2F F7 FA 2D A2 60 D8 EB 62 D6 D2
: F5 D6 49 27 8E 32 17 36 A0 62 8C BB B3 03 08 B6
: E6 18 DB 00 F6 2A D2 04 C6 46 03 59 BC 81 8A B8
: 96 1B F0 F0 FC 0E C5 AA E8 A4 28 17 3C E5 6F 00
: DE 9B 15 7C 1E 5C 82 C6 4F 56 2F CA DE FC 4A 4C
: 28 F6 D3 42 CF 3E F6 16 FC 82 D3 3B 72 85 C9 21
: F2 BF 36 FD D8
: }
334 66: [3] {
336 64: SEQUENCE {
338 29: SEQUENCE {
340 3: OBJECT IDENTIFIER subjectKeyIdentifier (2 5 29 14)
345 22: OCTET STRING, encapsulates {
347 20: OCTET STRING
: 8E C2 14 09 60 76 EA 90 38 E9 39 AE 1B 6D 52 C4
: 17 7D 9F BE
: }
: }
369 15: SEQUENCE {
371 3: OBJECT IDENTIFIER basicConstraints (2 5 29 19)
376 1: BOOLEAN TRUE
379 5: OCTET STRING, encapsulates {
381 3: SEQUENCE {
383 1: BOOLEAN TRUE
: }
: }
: }
386 14: SEQUENCE {
388 3: OBJECT IDENTIFIER keyUsage (2 5 29 15)
393 1: BOOLEAN TRUE
396 4: OCTET STRING, encapsulates {
398 2: BIT STRING 2 unused bits
: '100000'B (bit 5)
: }
: }
: }
: }
: }
402 10: SEQUENCE {
404 8: OBJECT IDENTIFIER ecdsaWithSHA512 (1 2 840 10045 4 3 4)
: }
414 139: BIT STRING, encapsulates {
418 135: SEQUENCE {
421 65: INTEGER
: 6E BF F5 48 98 87 0A 05 C6 10 9E D1 FB 77 AB D4
: B7 56 AA B7 59 1E 0B 42 C3 24 FB FB 01 41 20 99
: 95 B3 01 22 A2 6D 8B 1A 1F E8 32 EB B9 98 3F AE
: FF EA 35 9B 4E EF 9A 66 63 FF E8 A9 1A 9F 13 23
: 09
488 66: INTEGER
: 00 A8 67 86 C7 B5 EE 97 90 59 BB 85 45 DA B1 C2
: CD EE F9 2F EE A2 B0 5F 24 EC 0A F2 03 A4 40 D3
: 44 25 FC 75 41 5E EF 78 C6 79 B8 AD 92 E9 91 1E
: 35 61 94 12 4B A3 B9 F7 14 C2 6B 14 73 68 79 B9
: 4C 6F
: }
: }
: }
This is an end-entity certificate whose status is requested and returned in the OCSP request and response examples below.
これは、以下の OCSP 要求と応答の例でステータスが要求および返されるエンドエンティティ証明書です。
The key pair for the end-entity certificate is the "testECCP256" key from Section 2.3 of [RFC9500].
エンドエンティティ証明書の鍵ペアは、[RFC9500] のセクション 2.3 の「testECCP256」鍵です。
-----BEGIN CERTIFICATE-----
MIIB2zCCATygAwIBAgIEAarwDTAKBggqhkjOPQQDBDA4MQswCQYDVQQGEwJYWDEU
MBIGA1UECgwLQ2VydHMgJ3IgVXMxEzARBgNVBAMMCklzc3VpbmcgQ0EwHhcNMjQw
NDAyMTIzNzQ3WhcNMjUwNDAyMTIzNzQ3WjAcMRowGAYDVQQDDBF4bi0tMThqNGQu
ZXhhbXBsZTBZMBMGByqGSM49AgEGCCqGSM49AwEHA0IABEIlSPiPt4L/teyjdERS
xyoeVY+9b3O+XkjpMjLMRcWxbEzRDEy41bihcTnpSILImSVymTQl9BQZq36QpCpJ
QnKjUDBOMB0GA1UdDgQWBBRbcKeYF/ef9jfS9+PcRGwhCde71DAfBgNVHSMEGDAW
gBSOwhQJYHbqkDjpOa4bbVLEF32fvjAMBgNVHRMBAf8EAjAAMAoGCCqGSM49BAME
A4GMADCBiAJCAIot8SYNFkScrcsY5T81HSmNzhP/0GC87N3WI849CN0qmNa0nMXW
8HnDKGR5nv/D9x+T8uLMBlpFUWmHQmXAJPN8AkIBW8A0XsiyPJyZfaZieODmtnoI
obZP+eTLNWkGUFL6uCtLtQmYtrXpLAJfvkE6WYVqCUl495Kx9l6M9TBLK5X6V3w=
-----END CERTIFICATE-----
0 475: SEQUENCE {
4 316: SEQUENCE {
8 3: [0] {
10 1: INTEGER 2
: }
13 4: INTEGER 27979789
19 10: SEQUENCE {
21 8: OBJECT IDENTIFIER ecdsaWithSHA512 (1 2 840 10045 4 3 4)
: }
31 56: SEQUENCE {
33 11: SET {
35 9: SEQUENCE {
37 3: OBJECT IDENTIFIER countryName (2 5 4 6)
42 2: PrintableString 'XX'
: }
: }
46 20: SET {
48 18: SEQUENCE {
50 3: OBJECT IDENTIFIER organizationName (2 5 4 10)
55 11: UTF8String 'Certs 'r Us'
: }
: }
68 19: SET {
70 17: SEQUENCE {
72 3: OBJECT IDENTIFIER commonName (2 5 4 3)
77 10: UTF8String 'Issuing CA'
: }
: }
: }
89 30: SEQUENCE {
91 13: UTCTime 02/04/2024 12:37:47 GMT
106 13: UTCTime 02/04/2025 12:37:47 GMT
: }
121 28: SEQUENCE {
123 26: SET {
125 24: SEQUENCE {
127 3: OBJECT IDENTIFIER commonName (2 5 4 3)
132 17: UTF8String 'xn--18j4d.example'
: }
: }
: }
151 89: SEQUENCE {
153 19: SEQUENCE {
155 7: OBJECT IDENTIFIER ecPublicKey (1 2 840 10045 2 1)
164 8: OBJECT IDENTIFIER prime256v1 (1 2 840 10045 3 1 7)
: }
174 66: BIT STRING
: 04 42 25 48 F8 8F B7 82 FF B5 EC A3 74 44 52 C7
: 2A 1E 55 8F BD 6F 73 BE 5E 48 E9 32 32 CC 45 C5
: B1 6C 4C D1 0C 4C B8 D5 B8 A1 71 39 E9 48 82 C8
: 99 25 72 99 34 25 F4 14 19 AB 7E 90 A4 2A 49 42
: 72
: }
242 80: [3] {
244 78: SEQUENCE {
246 29: SEQUENCE {
248 3: OBJECT IDENTIFIER subjectKeyIdentifier (2 5 29 14)
253 22: OCTET STRING, encapsulates {
255 20: OCTET STRING
: 5B 70 A7 98 17 F7 9F F6 37 D2 F7 E3 DC 44 6C 21
: 09 D7 BB D4
: }
: }
277 31: SEQUENCE {
279 3: OBJECT IDENTIFIER authorityKeyIdentifier (2 5 29 35)
284 24: OCTET STRING, encapsulates {
286 22: SEQUENCE {
288 20: [0]
: 8E C2 14 09 60 76 EA 90 38 E9 39 AE 1B 6D 52 C4
: 17 7D 9F BE
: }
: }
: }
310 12: SEQUENCE {
312 3: OBJECT IDENTIFIER basicConstraints (2 5 29 19)
317 1: BOOLEAN TRUE
320 2: OCTET STRING, encapsulates {
322 0: SEQUENCE {}
: }
: }
: }
: }
: }
324 10: SEQUENCE {
326 8: OBJECT IDENTIFIER ecdsaWithSHA512 (1 2 840 10045 4 3 4)
: }
336 140: BIT STRING, encapsulates {
340 136: SEQUENCE {
343 66: INTEGER
: 00 8A 2D F1 26 0D 16 44 9C AD CB 18 E5 3F 35 1D
: 29 8D CE 13 FF D0 60 BC EC DD D6 23 CE 3D 08 DD
: 2A 98 D6 B4 9C C5 D6 F0 79 C3 28 64 79 9E FF C3
: F7 1F 93 F2 E2 CC 06 5A 45 51 69 87 42 65 C0 24
: F3 7C
411 66: INTEGER
: 01 5B C0 34 5E C8 B2 3C 9C 99 7D A6 62 78 E0 E6
: B6 7A 08 A1 B6 4F F9 E4 CB 35 69 06 50 52 FA B8
: 2B 4B B5 09 98 B6 B5 E9 2C 02 5F BE 41 3A 59 85
: 6A 09 49 78 F7 92 B1 F6 5E 8C F5 30 4B 2B 95 FA
: 57 7C
: }
: }
: }
This is a certificate for the OCSP-delegated response that signed the OCSP response example below.
これは、以下の OCSP 応答例に署名した OCSP 委任応答の証明書です。
The key pair for the OCSP responder certificate is the "testECCP384" key from Section 2.3 of [RFC9500].
OCSP レスポンダ証明書の鍵ペアは、[RFC9500] のセクション 2.3 の「testECCP384」鍵です。
-----BEGIN CERTIFICATE-----
MIICSzCCAa6gAwIBAgIBATAKBggqhkjOPQQDBDA4MQswCQYDVQQGEwJYWDEUMBIG
A1UECgwLQ2VydHMgJ3IgVXMxEzARBgNVBAMMCklzc3VpbmcgQ0EwHhcNMjQwNDAy
MTIzNzQ3WhcNMjUwNDAyMTIzNzQ3WjA8MQswCQYDVQQGEwJYWDEUMBIGA1UECgwL
Q2VydHMgJ3IgVXMxFzAVBgNVBAMMDk9DU1AgUmVzcG9uZGVyMHYwEAYHKoZIzj0C
AQYFK4EEACIDYgAEWwkBuIUjKW65GdUP+hqcs3S8TUCVhigr/soRsdla27VHNK9X
C/grcijPImvPTCXdvP47GjrTlDDv92Ph1o0uFR2Rcgt3lbWNprNGOWE6j7m1qNpI
xnRxF/mRnoQk837Io4GHMIGEMB0GA1UdDgQWBBQK46D+ndQldpi163Lrygznvz31
8TAfBgNVHSMEGDAWgBSOwhQJYHbqkDjpOa4bbVLEF32fvjAMBgNVHRMBAf8EAjAA
MA4GA1UdDwEB/wQEAwIHgDATBgNVHSUEDDAKBggrBgEFBQcDCTAPBgkrBgEFBQcw
AQUEAgUAMAoGCCqGSM49BAMEA4GKADCBhgJBFCqM1gpsZcd0Zd8RW8H/+L4OIbTa
GtpT2QY0pd6JBw91lFqNCxj+F1k9XJrKSQAVVAa/b3JaZOsRrH6vihlO3MYCQUkL
C0mmLubTRDH2v+6A1aycIVKIpR3G6+PuaD2Um3PSF7FElkoU4NYkbl1SH/8FzbDy
/LCBhih25e7hAtyg/XsI
-----END CERTIFICATE-----
0 587: SEQUENCE {
4 430: SEQUENCE {
8 3: [0] {
10 1: INTEGER 2
: }
13 1: INTEGER 1
16 10: SEQUENCE {
18 8: OBJECT IDENTIFIER ecdsaWithSHA512 (1 2 840 10045 4 3 4)
: }
28 56: SEQUENCE {
30 11: SET {
32 9: SEQUENCE {
34 3: OBJECT IDENTIFIER countryName (2 5 4 6)
39 2: PrintableString 'XX'
: }
: }
43 20: SET {
45 18: SEQUENCE {
47 3: OBJECT IDENTIFIER organizationName (2 5 4 10)
52 11: UTF8String 'Certs 'r Us'
: }
: }
65 19: SET {
67 17: SEQUENCE {
69 3: OBJECT IDENTIFIER commonName (2 5 4 3)
74 10: UTF8String 'Issuing CA'
: }
: }
: }
86 30: SEQUENCE {
88 13: UTCTime 02/04/2024 12:37:47 GMT
103 13: UTCTime 02/04/2025 12:37:47 GMT
: }
118 60: SEQUENCE {
120 11: SET {
122 9: SEQUENCE {
124 3: OBJECT IDENTIFIER countryName (2 5 4 6)
129 2: PrintableString 'XX'
: }
: }
133 20: SET {
135 18: SEQUENCE {
137 3: OBJECT IDENTIFIER organizationName (2 5 4 10)
142 11: UTF8String 'Certs 'r Us'
: }
: }
155 23: SET {
157 21: SEQUENCE {
159 3: OBJECT IDENTIFIER commonName (2 5 4 3)
164 14: UTF8String 'OCSP Responder'
: }
: }
: }
180 118: SEQUENCE {
182 16: SEQUENCE {
184 7: OBJECT IDENTIFIER ecPublicKey (1 2 840 10045 2 1)
193 5: OBJECT IDENTIFIER secp384r1 (1 3 132 0 34)
: }
200 98: BIT STRING
: 04 5B 09 01 B8 85 23 29 6E B9 19 D5 0F FA 1A 9C
: B3 74 BC 4D 40 95 86 28 2B FE CA 11 B1 D9 5A DB
: B5 47 34 AF 57 0B F8 2B 72 28 CF 22 6B CF 4C 25
: DD BC FE 3B 1A 3A D3 94 30 EF F7 63 E1 D6 8D 2E
: 15 1D 91 72 0B 77 95 B5 8D A6 B3 46 39 61 3A 8F
: B9 B5 A8 DA 48 C6 74 71 17 F9 91 9E 84 24 F3 7E
: C8
: }
300 135: [3] {
303 132: SEQUENCE {
306 29: SEQUENCE {
308 3: OBJECT IDENTIFIER subjectKeyIdentifier (2 5 29 14)
313 22: OCTET STRING, encapsulates {
315 20: OCTET STRING
: 0A E3 A0 FE 9D D4 25 76 98 B5 EB 72 EB CA 0C E7
: BF 3D F5 F1
: }
: }
337 31: SEQUENCE {
339 3: OBJECT IDENTIFIER authorityKeyIdentifier (2 5 29 35)
344 24: OCTET STRING, encapsulates {
346 22: SEQUENCE {
348 20: [0]
: 8E C2 14 09 60 76 EA 90 38 E9 39 AE 1B 6D 52 C4
: 17 7D 9F BE
: }
: }
: }
370 12: SEQUENCE {
372 3: OBJECT IDENTIFIER basicConstraints (2 5 29 19)
377 1: BOOLEAN TRUE
380 2: OCTET STRING, encapsulates {
382 0: SEQUENCE {}
: }
: }
384 14: SEQUENCE {
386 3: OBJECT IDENTIFIER keyUsage (2 5 29 15)
391 1: BOOLEAN TRUE
394 4: OCTET STRING, encapsulates {
396 2: BIT STRING 7 unused bits
: '1'B (bit 0)
: }
: }
400 19: SEQUENCE {
402 3: OBJECT IDENTIFIER extKeyUsage (2 5 29 37)
407 12: OCTET STRING, encapsulates {
409 10: SEQUENCE {
411 8: OBJECT IDENTIFIER ocspSigning (1 3 6 1 5 5 7 3 9)
: }
: }
: }
421 15: SEQUENCE {
423 9: OBJECT IDENTIFIER ocspNoCheck (1 3 6 1 5 5 7 48 1 5)
434 2: OCTET STRING, encapsulates {
436 0: NULL
: }
: }
: }
: }
: }
438 10: SEQUENCE {
440 8: OBJECT IDENTIFIER ecdsaWithSHA512 (1 2 840 10045 4 3 4)
: }
450 138: BIT STRING, encapsulates {
454 134: SEQUENCE {
457 65: INTEGER
: 14 2A 8C D6 0A 6C 65 C7 74 65 DF 11 5B C1 FF F8
: BE 0E 21 B4 DA 1A DA 53 D9 06 34 A5 DE 89 07 0F
: 75 94 5A 8D 0B 18 FE 17 59 3D 5C 9A CA 49 00 15
: 54 06 BF 6F 72 5A 64 EB 11 AC 7E AF 8A 19 4E DC
: C6
524 65: INTEGER
: 49 0B 0B 49 A6 2E E6 D3 44 31 F6 BF EE 80 D5 AC
: 9C 21 52 88 A5 1D C6 EB E3 EE 68 3D 94 9B 73 D2
: 17 B1 44 96 4A 14 E0 D6 24 6E 5D 52 1F FF 05 CD
: B0 F2 FC B0 81 86 28 76 E5 EE E1 02 DC A0 FD 7B
: 08
: }
: }
: }
This is a base64-encoded OCSP request for the end-entity certificate above.
これは、上記のエンドエンティティ証明書に対する Base64 でエンコードされた OCSP リクエストです。
MGEwXzBdMFswWTANBglghkgBZQMEAgEFAAQgOplGd1aAc6cHv95QGGNF5M1hNNsI
Xrqh0QQl8DtvCOoEIEdKbKMB8j3J9/cHhwThx/X8lucWdfbtiC56tlw/WEVDAgQB
qvAN
0 97: SEQUENCE {
2 95: SEQUENCE {
4 93: SEQUENCE {
6 91: SEQUENCE {
8 89: SEQUENCE {
10 13: SEQUENCE {
12 9: OBJECT IDENTIFIER sha-256 (2 16 840 1 101 3 4 2 1)
23 0: NULL
: }
25 32: OCTET STRING
: 3A 99 46 77 56 80 73 A7 07 BF DE 50 18 63 45 E4
: CD 61 34 DB 08 5E BA A1 D1 04 25 F0 3B 6F 08 EA
59 32: OCTET STRING
: 47 4A 6C A3 01 F2 3D C9 F7 F7 07 87 04 E1 C7 F5
: FC 96 E7 16 75 F6 ED 88 2E 7A B6 5C 3F 58 45 43
93 4: INTEGER 27979789
: }
: }
: }
: }
: }
This is a base64-encoded OCSP response for the end-entity certificate above.
これは、上記のエンドエンティティ証明書に対する Base64 でエンコードされた OCSP 応答です。
MIIDnwoBAKCCA5gwggOUBgkrBgEFBQcwAQEEggOFMIIDgTCBsKIWBBQK46D+ndQl
dpi163Lrygznvz318RgPMjAyNDA0MDIxMjM3NDdaMIGEMIGBMFkwDQYJYIZIAWUD
BAIBBQAEIDqZRndWgHOnB7/eUBhjReTNYTTbCF66odEEJfA7bwjqBCBHSmyjAfI9
yff3B4cE4cf1/JbnFnX27YguerZcP1hFQwIEAarwDYAAGA8yMDI0MDQwMzEyMzc0
N1qgERgPMjAyNDA0MTAxMjM3NDdaMAoGCCqGSM49BAMDA2kAMGYCMQDRmVmiIb4D
m9yEXiv2XtoeQi6ftpjLmlBqqRIi+3htfF/OyjdHnFuh38cQKYqqrWYCMQDKiPct
Vu7SQs587d2ZBEHQH20j5AFiGGsbI1b3+C9ZK6NIzgD6DnWlDwpSfilEarOgggJT
MIICTzCCAkswggGuoAMCAQICAQEwCgYIKoZIzj0EAwQwODELMAkGA1UEBhMCWFgx
FDASBgNVBAoMC0NlcnRzICdyIFVzMRMwEQYDVQQDDApJc3N1aW5nIENBMB4XDTI0
MDQwMjEyMzc0N1oXDTI1MDQwMjEyMzc0N1owPDELMAkGA1UEBhMCWFgxFDASBgNV
BAoMC0NlcnRzICdyIFVzMRcwFQYDVQQDDA5PQ1NQIFJlc3BvbmRlcjB2MBAGByqG
SM49AgEGBSuBBAAiA2IABFsJAbiFIyluuRnVD/oanLN0vE1AlYYoK/7KEbHZWtu1
RzSvVwv4K3IozyJrz0wl3bz+Oxo605Qw7/dj4daNLhUdkXILd5W1jaazRjlhOo+5
tajaSMZ0cRf5kZ6EJPN+yKOBhzCBhDAdBgNVHQ4EFgQUCuOg/p3UJXaYtety68oM
57899fEwHwYDVR0jBBgwFoAUjsIUCWB26pA46TmuG21SxBd9n74wDAYDVR0TAQH/
BAIwADAOBgNVHQ8BAf8EBAMCB4AwEwYDVR0lBAwwCgYIKwYBBQUHAwkwDwYJKwYB
BQUHMAEFBAIFADAKBggqhkjOPQQDBAOBigAwgYYCQRQqjNYKbGXHdGXfEVvB//i+
DiG02hraU9kGNKXeiQcPdZRajQsY/hdZPVyaykkAFVQGv29yWmTrEax+r4oZTtzG
AkFJCwtJpi7m00Qx9r/ugNWsnCFSiKUdxuvj7mg9lJtz0hexRJZKFODWJG5dUh//
Bc2w8vywgYYoduXu4QLcoP17CA==
0 927: SEQUENCE {
4 1: ENUMERATED 0
7 920: [0] {
11 916: SEQUENCE {
15 9: OBJECT IDENTIFIER ocspBasic (1 3 6 1 5 5 7 48 1 1)
26 901: OCTET STRING, encapsulates {
30 897: SEQUENCE {
34 176: SEQUENCE {
37 22: [2] {
39 20: OCTET STRING
: 0A E3 A0 FE 9D D4 25 76 98 B5 EB 72 EB CA 0C E7
: BF 3D F5 F1
: }
61 15: GeneralizedTime 02/04/2024 12:37:47 GMT
78 132: SEQUENCE {
81 129: SEQUENCE {
84 89: SEQUENCE {
86 13: SEQUENCE {
88 9: OBJECT IDENTIFIER
: sha-256 (2 16 840 1 101 3 4 2 1)
99 0: NULL
: }
101 32: OCTET STRING
: 3A 99 46 77 56 80 73 A7 07 BF DE 50 18 63 45 E4
: CD 61 34 DB 08 5E BA A1 D1 04 25 F0 3B 6F 08 EA
135 32: OCTET STRING
: 47 4A 6C A3 01 F2 3D C9 F7 F7 07 87 04 E1 C7 F5
: FC 96 E7 16 75 F6 ED 88 2E 7A B6 5C 3F 58 45 43
169 4: INTEGER 27979789
: }
175 0: [0]
177 15: GeneralizedTime 03/04/2024 12:37:47 GMT
194 17: [0] {
196 15: GeneralizedTime 10/04/2024 12:37:47 GMT
: }
: }
: }
: }
213 10: SEQUENCE {
215 8: OBJECT IDENTIFIER
: ecdsaWithSHA384 (1 2 840 10045 4 3 3)
: }
225 105: BIT STRING, encapsulates {
228 102: SEQUENCE {
230 49: INTEGER
: 00 D1 99 59 A2 21 BE 03 9B DC 84 5E 2B F6 5E DA
: 1E 42 2E 9F B6 98 CB 9A 50 6A A9 12 22 FB 78 6D
: 7C 5F CE CA 37 47 9C 5B A1 DF C7 10 29 8A AA AD
: 66
281 49: INTEGER
: 00 CA 88 F7 2D 56 EE D2 42 CE 7C ED DD 99 04 41
: D0 1F 6D 23 E4 01 62 18 6B 1B 23 56 F7 F8 2F 59
: 2B A3 48 CE 00 FA 0E 75 A5 0F 0A 52 7E 29 44 6A
: B3
: }
: }
332 595: [0] {
336 591: SEQUENCE {
340 587: SEQUENCE {
344 430: SEQUENCE {
348 3: [0] {
350 1: INTEGER 2
: }
353 1: INTEGER 1
356 10: SEQUENCE {
358 8: OBJECT IDENTIFIER
: ecdsaWithSHA512 (1 2 840 10045 4 3 4)
: }
368 56: SEQUENCE {
370 11: SET {
372 9: SEQUENCE {
374 3: OBJECT IDENTIFIER countryName (2 5 4 6)
379 2: PrintableString 'XX'
: }
: }
383 20: SET {
385 18: SEQUENCE {
387 3: OBJECT IDENTIFIER
: organizationName (2 5 4 10)
392 11: UTF8String 'Certs 'r Us'
: }
: }
405 19: SET {
407 17: SEQUENCE {
409 3: OBJECT IDENTIFIER commonName (2 5 4 3)
414 10: UTF8String 'Issuing CA'
: }
: }
: }
426 30: SEQUENCE {
428 13: UTCTime 02/04/2024 12:37:47 GMT
443 13: UTCTime 02/04/2025 12:37:47 GMT
: }
458 60: SEQUENCE {
460 11: SET {
462 9: SEQUENCE {
464 3: OBJECT IDENTIFIER countryName (2 5 4 6)
469 2: PrintableString 'XX'
: }
: }
473 20: SET {
475 18: SEQUENCE {
477 3: OBJECT IDENTIFIER
: organizationName (2 5 4 10)
482 11: UTF8String 'Certs 'r Us'
: }
: }
495 23: SET {
497 21: SEQUENCE {
499 3: OBJECT IDENTIFIER commonName (2 5 4 3)
504 14: UTF8String 'OCSP Responder'
: }
: }
: }
520 118: SEQUENCE {
522 16: SEQUENCE {
524 7: OBJECT IDENTIFIER
: ecPublicKey (1 2 840 10045 2 1)
533 5: OBJECT IDENTIFIER
: secp384r1 (1 3 132 0 34)
: }
540 98: BIT STRING
: 04 5B 09 01 B8 85 23 29 6E B9 19 D5 0F FA 1A 9C
: B3 74 BC 4D 40 95 86 28 2B FE CA 11 B1 D9 5A DB
: B5 47 34 AF 57 0B F8 2B 72 28 CF 22 6B CF 4C 25
: DD BC FE 3B 1A 3A D3 94 30 EF F7 63 E1 D6 8D 2E
: 15 1D 91 72 0B 77 95 B5 8D A6 B3 46 39 61 3A 8F
: B9 B5 A8 DA 48 C6 74 71 17 F9 91 9E 84 24 F3 7E
: C8
: }
640 135: [3] {
643 132: SEQUENCE {
646 29: SEQUENCE {
648 3: OBJECT IDENTIFIER
: subjectKeyIdentifier (2 5 29 14)
653 22: OCTET STRING, encapsulates {
655 20: OCTET STRING
: 0A E3 A0 FE 9D D4 25 76 98 B5 EB 72 EB CA 0C E7
: BF 3D F5 F1
: }
: }
677 31: SEQUENCE {
679 3: OBJECT IDENTIFIER
: authorityKeyIdentifier (2 5 29 35)
684 24: OCTET STRING, encapsulates {
686 22: SEQUENCE {
688 20: [0]
: 8E C2 14 09 60 76 EA 90 38 E9 39 AE 1B 6D 52 C4
: 17 7D 9F BE
: }
: }
: }
710 12: SEQUENCE {
712 3: OBJECT IDENTIFIER
: basicConstraints (2 5 29 19)
717 1: BOOLEAN TRUE
720 2: OCTET STRING, encapsulates {
722 0: SEQUENCE {}
: }
: }
724 14: SEQUENCE {
726 3: OBJECT IDENTIFIER keyUsage (2 5 29 15)
731 1: BOOLEAN TRUE
734 4: OCTET STRING, encapsulates {
736 2: BIT STRING 7 unused bits
: '1'B (bit 0)
: }
: }
740 19: SEQUENCE {
742 3: OBJECT IDENTIFIER
: extKeyUsage (2 5 29 37)
747 12: OCTET STRING, encapsulates {
749 10: SEQUENCE {
751 8: OBJECT IDENTIFIER
: ocspSigning (1 3 6 1 5 5 7 3 9)
: }
: }
: }
761 15: SEQUENCE {
763 9: OBJECT IDENTIFIER
: ocspNoCheck (1 3 6 1 5 5 7 48 1 5)
774 2: OCTET STRING, encapsulates {
776 0: NULL
: }
: }
: }
: }
: }
778 10: SEQUENCE {
780 8: OBJECT IDENTIFIER
: ecdsaWithSHA512 (1 2 840 10045 4 3 4)
: }
790 138: BIT STRING, encapsulates {
794 134: SEQUENCE {
797 65: INTEGER
: 14 2A 8C D6 0A 6C 65 C7 74 65 DF 11 5B C1 FF F8
: BE 0E 21 B4 DA 1A DA 53 D9 06 34 A5 DE 89 07 0F
: 75 94 5A 8D 0B 18 FE 17 59 3D 5C 9A CA 49 00 15
: 54 06 BF 6F 72 5A 64 EB 11 AC 7E AF 8A 19 4E DC
: C6
864 65: INTEGER
: 49 0B 0B 49 A6 2E E6 D3 44 31 F6 BF EE 80 D5 AC
: 9C 21 52 88 A5 1D C6 EB E3 EE 68 3D 94 9B 73 D2
: 17 B1 44 96 4A 14 E0 D6 24 6E 5D 52 1F FF 05 CD
: B0 F2 FC B0 81 86 28 76 E5 EE E1 02 DC A0 FD 7B
: 08
: }
: }
: }
: }
: }
: }
: }
: }
: }
: }
The authors of this version of the document wish to thank Alex Deacon and Ryan Hurst for their work to produce the original version of the lightweight profile for OCSP.
このバージョンのドキュメントの作成者は、OCSP 用の軽量プロファイルのオリジナル バージョンを作成した Alex Deacon と Ryan Hurst に感謝の意を表します。
The authors of this version of the document wish to thank Paul Kyzivat, Russ Housley, Rob Stradling, Roman Danyliw, and Wendy Brown for their reviews, feedback, and suggestions.
このバージョンのドキュメントの著者は、レビュー、フィードバック、および提案をいただいた Paul Kyzivat、Russ Housley、Rob Stradling、Roman Danyliw、および Wendy Brown に感謝の意を表します。
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 the original [RFC5019] specification. Listed organizational affiliations reflect the authors' affiliations at the time RFC 5019 was published.
著者らは、オリジナルの [RFC5019] 仕様への貢献について、RSA Security, Inc. の Magnus Nystrom、Vodafone Group R&D の Jagjeet Sondh、および CoreStreet, Ltd.の David Engberg に感謝したいと思います。リストされている組織の所属は、RFC 5019 が発行された時点での著者の所属を反映しています。
Tadahiko Ito
SECOM CO., LTD.
Email: tadahiko.ito.public@gmail.com
Additional contact information:
伊藤 忠彦
SECOM CO., LTD.
Clint Wilson
Apple, Inc.
Email: clintw@apple.com
Corey Bonnell
DigiCert, Inc.
Email: corey.bonnell@digicert.com
Sean Turner
sn3rd
Email: sean@sn3rd.com