[要約] RFC 2560は、OCSP（Online Certificate Status Protocol）に関する規格であり、X.509インターネット公開鍵基盤におけるオンライン証明書の状態を確認するためのプロトコルです。その目的は、証明書の有効性をリアルタイムで確認し、信頼性のある通信を実現することです。
Network Working Group M. Myers
Request for Comments: 2560 VeriSign
Category: Standards Track R. Ankney
CertCo
A. Malpani
ValiCert
S. Galperin
My CFO
C. Adams
Entrust Technologies
June 1999
X.509 Internet Public Key Infrastructure
Online Certificate Status Protocol - OCSP
Status of this Memo
このメモの位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (1999). All Rights Reserved.
著作権（C）インターネット協会（1999）。全著作権所有。
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運用要件に対処追加のメカニズムは別の文書で指定されています。
An overview of the protocol is provided in section 2. Functional requirements are specified in section 4. Details of the protocol are in section 5. We cover security issues with the protocol in section 6. Appendix A defines OCSP over HTTP, appendix B accumulates ASN.1 syntactic elements and appendix C specifies the mime types for the messages.
プロトコルの概要2.機能要件は、我々は6付録Aは、HTTP上OCSPを定義セクションにおけるプロトコルにセキュリティの問題をカバーするプロトコル4.詳細はセクション5にあるセクションで指定されている部分に設けられ、付録Bは、ASNを蓄積します0.1構文要素および付録Cには、メッセージのMIMEタイプを指定します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document (in uppercase, as shown) are to be interpreted as described in [RFC2119].
キーワード "MUST"、 "MUST NOT"、 "REQUIRED"、 "SHALL"、 "SHALL NOT"、（この文書では、 "SHOULD"、 "推奨" "NOT SHOULD"、 "MAY"、および "OPTIONAL" ）に示すように、大文字で、[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 a certificate (cf. [RFC2459], Section 3.3). Examples include high-value funds transfer or large stock trades.
周期CRLに対してチェックする補足の又は代わりに、証明書（参照[RFC2459]、セクション3.3）の失効状態に関するタイムリーな情報を取得する必要があるかもしれません。例としては、高価値の資金移動や大型株式取引が含まれます。
The Online Certificate Status Protocol (OCSP) enables applications to determine the (revocation) state of an identified certificate. 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 certificate 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 a certificate and the server providing that status.
このプロトコルは、証明書とそのステータスを提供するサーバのステータスをチェックするアプリケーション間で交換する必要のあるデータを指定します。
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
- プロトコルバージョン - OCSPレスポンダによって処理することができるオプションの拡張 - サービス要求 - ターゲット証明書識別子
Upon receipt of a request, an OCSP Responder determines if:
要求を受信すると、OCSPレスポンダがあれば決定します。
3. the request contains the information needed by the responder If any one of the prior conditions are 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応答の一つの基本タイプがあります。このセクションの残りの部分は、この基本的な応答のタイプに関係します。
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 -- a Trusted Responder whose public key is trusted by the requester -- a CA Designated Responder (Authorized Responder) who holds a specially marked certificate issued directly by the CA, indicating that the responder may issue OCSP responses for that CA
- 問題の証明書を発行したCA - その公開鍵を要求者に信頼されている信頼レスポンダ - 応答者が可能性があることを示す、CAによって直接発行され、特別にマークされた証明書を保持しているCA指定レスポンダ（認定レスポンダ）そのCAのOCSPレスポンスを発行
A definitive response message is composed of:
決定的な応答メッセージがで構成されています。
-- version of the response syntax -- name of the responder -- responses for each of the certificates in a request -- optional extensions -- signature algorithm OID -- signature computed across hash of the response
- レスポンス構文のバージョン - レスポンダの名前 - 要求内の証明書のそれぞれに対する応答 - 応答のハッシュを横切って計算署名 - オプションの拡張 - 署名アルゴリズムのOID
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 the certificate is not revoked, but 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 positive statement about issuance, validity, etc.
「良い」状態は、ステータス問い合わせに対する肯定的な反応を示しています。最低でも、この肯定応答は、証明書が失効していないことを示しているが、必ずしも証明書がこれまでに発行されたことを意味するか、応答が生成された時間が、証明書の有効期間内であることはありません。レスポンスの拡張機能は、などの発行について肯定文で、妥当性、などの証明書のステータスに関する応答者によってなされた主張の追加情報を伝えるために使用することができます
The "revoked" state indicates that the certificate has been revoked (either permanantly or temporarily (on hold)).
「失効」状態は、証明書は、（いずれかの永続的に又は一時的に（保留））取り消されたことを示しています。
The "unknown" state indicates that the responder doesn't know about the certificate being requested.
「不明」状態は、レスポンダが要求されている証明書について知らないことを示しています。
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 -- internalError -- tryLater -- sigRequired -- unauthorized
- malformedRequest - internalError - tryLater - sigRequired - 不正
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 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.
応答「不正」は、クライアントがこのサーバーには、このクエリを作るために許可されていない場合に返されます。
Responses can contain three times in them - thisUpdate, nextUpdate and producedAt. The semantics of these fields are:
thisUpdateの、nextUpdateのとproducedAt - 応答がそれらで3回を含めることができます。これらのフィールドの意味は以下のとおりです。
- 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 - producedAt: The time at which the OCSP responder signed this response.
- thisUpdateの：ステータスが正しいことが知られて示された時間 - nextUpdateの：新しい情報は、証明書のステータスについて利用可能になる時またはその前に時間 - producedAt：OCSPレスポンダは、この応答を署名した時刻。
If nextUpdate is not set, the responder is indicating that newer revocation information is available all the time.
nextUpdateのが設定されていない場合、応答者は、新しい失効情報が常に利用可能であることを示しています。
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レスポンダは、事前に生成することが指定された時点での証明書のステータスを指定して応答に署名しました。状態が正しいと知られた時間は、応答のthisUpdateのフィールドに反映されなければなりません。応答が生成された時間は、応答のproducedAtフィールドに表示されている間、新しい情報が利用可能になるか、前にする時間は、nextUpdateのフィールドに反映されています。
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 extendedKeyUsage in the OCSP signer's certificate. This certificate MUST be issued directly to the responder by the cognizant CA.
証明書のステータス情報に署名する鍵は、証明書に署名した同じキーである必要はありません。証明書の発行者に明示的代表者は、OCSP署名者の証明書でextendedKeyUsageのためのユニークな値を含む証明書を発行して署名する権限をOCSP。この証明書は、CAによって認識しレスポンダに直接発行する必要があります
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 AuthorityInfoAccess extension (defined in [RFC2459], 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を用いて確認することができる証明書で（[RFC2459]で定義され、セクション4.2.2.1）AuthorityInfoAccess拡張を含めるための機能を提供しなければなりません。あるいは、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 uniformResourceIndicator (URI) accessLocation and the OID value id-ad-ocsp for the accessMethod in the AccessDescription SEQUENCE.
OCSPサービスをサポートするCA、ローカルにホストまたは認定レスポンダによって与えられるいずれかが、uniformResourceIndicator（URI）のaccessLocationとAccessDescription配列中たaccessMethodのOID値ID-AD-OCSPの値の包含を提供しなければなりません。
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 as valid, OCSP clients SHALL confirm that:
有効として署名した応答を受け入れる前に、OCSPクライアントはそのことを確認しなければなりません。
1. The certificate identified in a received response corresponds to that which was identified in the corresponding request;
1.受信した応答に同定証明書は、対応する要求で同定されたものに対応します。
3. The identity of the signer matches the intended recipient of the request.
3.署名者の身元は、要求の意図された受信者と一致します。
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 [RFC2459]. For signature calculation, the data to be signed is encoded using the ASN.1 distinguished encoding rules (DER) [X.690].
[RFC2459]で定義されたASN.1構文の輸入条件。署名の計算のために、署名されるべきデータは、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, CRLReason
他の場所から輸入条件は以下のとおりです。機能拡張、CertificateSerialNumber、SubjectPublicKeyInfoで、名前、の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など）に応じて変化させることができます。
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 Issuers public key
serialNumber CertificateSerialNumber }
issuerNameHash is the hash of the Issuer's distinguished name. The hash shall be calculated over the DER encoding of the issuer's name field in the certificate being checked. 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. The hash algorithm used for both these hashes, is identified in hashAlgorithm. serialNumber is the serial number of the certificate for which status is being requested.
issuerNameHashは、発行者の識別名のハッシュです。ハッシュがチェックされる証明書内の発行者の名前フィールドのDERエンコーディング上で計算しなければなりません。 issuerKeyHashは、発行者の公開鍵のハッシュです。ハッシュは、発行者の証明書のサブジェクトの公開鍵フィールドの値（除くタグと長さ）の上に計算しなければなりません。これらの両方のハッシュのために使用されるハッシュアルゴリズムは、hashAlgorithmで識別されます。 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のいずれかのキーが侵害された場合を除きつの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レスポンダが署名の本命フィールドに要求者の署名を確認するのに役立ち、証明書を含むかもしれません。
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, responseBytes are not set.
最低でOCSP応答は、先行リクエストの処理状態を示すresponseStatusフィールドから成ります。 responseStatusの値がエラー条件のいずれかである場合、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の値は、オブジェクト識別子と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 - 基本となります。
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塩基性応答のタイプの応答を生成することができるものでなければなりません。これに対応して、OCSPクライアントは、ID-PKIX-OCSP塩基性応答のタイプの受信及び処理応答できなければなりません。
The value for response SHALL be the DER encoding of BasicOCSPResponse.
応答の値はBasicOCSPResponseのDER符号化でなければなりません。
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 ResponseData.
署名の値はDERエンコーディングResponseDataのハッシュに基づいて計算されるものとします。
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 -- this can be replaced with an enumeration
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. Responses where the nextUpdate value is not set are equivalent to a CRL with no time for nextUpdate (see Section 2.4).
thisUpdateおよびnextUpdateのフィールドは、推奨有効期間を定義します。この間隔はCRLの中の{thisUpdateの、nextUpdateの間隔}に対応します。そのnextUpdateの値は信頼できないとみなされるべきであるローカルシステム時間値よりも早い応答。そのthisUpdateの時間後にローカルのシステム時刻よりも信頼性が低いとみなされるべきである（SHOULD）される応答。 nextUpdateの値が設定されていないレスポンスはnextUpdateのための時間がない（2.4節を参照）とCRLに相当します。
The producedAt time is the time at which this response was signed.
producedAt時間は、この応答が署名された時間です。
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 either sign the OCSP responses itself or it MUST explicitly designate this authority to another entity. OCSP signing delegation SHALL be designated by the inclusion of id-kp-OCSPSigning in an extendedKeyUsage certificate extension included in the OCSP response signer's certificate. This certificate MUST be issued directly by the CA that issued the certificate in question.
証明書のステータス情報に署名する鍵は、証明書に署名した同じキーである必要はありません。この情報に署名するエンティティがそうすることを許可されていることを保証するために、しかし必要があります。そのため、証明書の発行者はOCSP応答自体に署名しなければならないのいずれか、またはそれが明示的に別のエンティティにこの権限を指定する必要があります。委任署名OCSPは、OCSPレスポンス署名者の証明書に含まれるextendedKeyUsageの証明書拡張のID-KP-OCSPSigningを含めることによって指名します。この証明書は、当該証明書を発行したCAによって直接発行されなければなりません。
id-kp-OCSPSigning OBJECT IDENTIFIER ::= {id-kp 9}
Systems or applications that rely on OCSP responses MUST be capable of detecting and enforcing use of the id-ad-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 fails to meet at least one of the following criteria:
OCSPレスポンスに依存しているシステムやアプリケーションが検出し、上記のように、ID-AD ocspSigning値の使用を強制することができなければなりません。彼らは、ローカル一つ以上の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-ad-ocspSigning in an ExtendedKeyUsage extension and is issued by the CA that issued the certificate in question."
3. extendedKeyUsageの拡張子のid-広告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 should be NULL. CAs issuing such a certificate should realized 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. CA's 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 be checked for revocation. This can be done using CRL Distribution Points if the check should be done using CRLs or CRL Distribution Points, or Authority Information Access if the check should be done in some other way. Details for specifying either of these two mechanisms are available in [RFC2459].
- CAは、レスポンダの証明書が失効をチェックする方法を指定することもできます。チェックは他の方法で行われるべきである場合は、チェックがCRLのか、CRL配布ポイント、または機関情報アクセスを使用して行われるべきである場合、これはCRL配布ポイントを使用して行うことができます。これら二つのメカニズムのいずれかを指定するための詳細は、[RFC2459]で入手可能です。
- 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クライアントのローカルセキュリティポリシーになります。
Clients that request OCSP services SHALL be capable of processing responses signed used DSA keys identified by the DSA sig-alg-oid specified in section 7.2.2 of [RFC2459]. Clients SHOULD also be capable of processing RSA signatures as specified in section 7.2.1 of [RFC2459]. OCSP responders SHALL support the SHA1 hashing algorithm.
OCSPサービスを要求するクライアントは、[RFC2459]のセクション7.2.2で指定されたDSAのSIG-ALG-OIDによって識別に使用されるDSA鍵に署名した処理応答できなければなりません。 [RFC2459]のセクション7.2.1で指定されたクライアントはまた、RSA署名を処理することが可能であるべきです。 OCSPレスポンダは、SHA1ハッシュアルゴリズムをサポートします。
This section defines some standard extensions, based on the extension model employed in X.509 version 3 certificates see [RFC2459]. 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 which are included in the corresponding response.
このセクションでは、X.509バージョン3つの証明書で用いられる拡張モデルに基づいて、いくつかの標準的な拡張は、[RFC2459]を参照して定義しています。すべての拡張機能のサポートは、クライアントと応答の両方のためのオプションです。各拡張のために、定義は、その構文、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.
ナンスは、暗号要求し、リプレイ攻撃を防ぐために、応答をバインドします。応答で、それがresponseExtensionsの一つとして含まれることになる一方、ナンスは、リクエストでrequestExtensionsの一つとして含まれています。 extnValueはナンスの値である要求と応答の両方において、ナンスは、オブジェクトの識別子ID-PKIX-OCSP - ナンスによって識別されます。
id-pkix-ocsp-nonce OBJECT IDENTIFIER ::= { id-pkix-ocsp 2 }
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レスポンダが失効または保留中の証明書が発見されたCRLを示すことが望ましいかもしれません。 OCSPがリポジトリとの間の、また監査メカニズムとして使用される場合、これは有用であり得ます。 CRL番号（CRL番号）または時間（関連CRLが作成された時刻）、URL（CRLが利用可能な時URL）によって指定することができます。これらの拡張機能は、singleExtensionsとして指定されます。値がCrlIDする間、この拡張の識別子は、ID-PKIX-OCSP-CRLあろう。
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応答との延長、および値AcceptableResponsesを使用すべきです。この拡張は、リクエストでrequestExtensionsの一つとして含まれています。このクライアントが受け入れることができる様々な反応タイプのOIDがOIDがAcceptableResponsesに含まれている（例えば、ID-PKIX-OCSP塩基性）。
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塩基性応答のタイプの応答で応答することができるものでなければなりません。これに対応して、OCSPクライアントは、ID-PKIX-OCSP塩基性応答のタイプの受信及び処理応答できなければなりません。
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レスポンダは、証明書の有効期限を越えて失効情報を保持することを選択するかもしれません。応答でproducedAt時間からこの保持期間値を引いた日付が、証明書の「アーカイブカットオフ」日と定義されます。
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 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サーバは、応答のアーカイブカットオフ日付拡張子を含めるべきです。含まれている場合、この値は、ID-PKIX-OCSPアーカイブ・カットオフや構文GeneralizedTimeのので識別されるOCSP singleExtensions拡張機能として提供されなければなりません。
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の値は、（ - 7年T1）になります。
All the extensions specified as CRL Entry Extensions - in Section 5.3 of [RFC2459] - are also supported as singleExtensions.
[RFC2459]の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 which 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の一つとして含まれています。
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.
これらのフィールドの値は、対象の証明書で対応するフィールドから取得されます。
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 denial of service vulnerability 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キャッシングの依存は予期しない結果になることがあります。実装者は、HTTP上でOCSPを展開する際に考慮にHTTPキャッシュメカニズムの信頼性を取ることをお勧めします。
[RFC2459] Housley, R., Ford, W., Polk, W. and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and CRL Profile", RFC 2459, January 1999.
[RFC2459] Housley氏、R.、フォード、W.、ポーク、W.およびD.ソロ、 "インターネットX.509公開鍵暗号基盤証明書とCRLプロファイル"、RFC 2459、1999年1月。
[HTTP] Fielding, R., Gettys, J., Mogul, J., Frystyk, H. and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2068, January 1997.
[HTTP]フィールディング、R.、ゲティス、J.、モーグル、J.、Frystyk、H.、およびT.バーナーズ - リー、 "ハイパーテキスト転送プロトコル - HTTP / 1.1"、RFC 2068、1997年1月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[URL] Berners-Lee, T., Masinter, L. and M. McCahill, "Uniform Resource Locators (URL)", RFC 1738, December 1994.
[URL]バーナーズ=リー、T.、Masinter、LとM. McCahill、 "ユニフォームリソースロケータ（URL）"、RFC 1738、1994年12月。
[X.690] ITU-T Recommendation X.690 (1994) | ISO/IEC 8825-1:1995, Information Technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER).
[X.690] ITU-T勧告X.690（1994）| ISO / IEC 8825から1：1995、情報技術 - ASN.1エンコーディング規則：基本符号化規則（BER）の仕様、Canonicalの符号化規則（CER）、および顕著な符号化規則（DER）。
Michael Myers VeriSign, Inc. 1350 Charleston Road Mountain View, CA 94043
マイケル・マイヤーズベリサイン株式会社1350チャールストンロード、マウンテンビュー、CA 94043
EMail: mmyers@verisign.com
メールアドレス：mmyers@verisign.com
Rich Ankney CertCo, LLC 13506 King Charles Dr. Chantilly, VA 20151
リッチAnkney CERTCO、LLC 13506のキングチャールズ博士シャンティリー
EMail: rankney@erols.com
メールアドレス：rankney@erols.com
Ambarish Malpani ValiCert, Inc. 1215 Terra Bella Ave. Mountain View, CA 94043
Ambarish Malpani Valicert社、株式会社1215テラベラアベニュー。マウンテンビュー、CA 94043
Phone: 650.567.5457 EMail: ambarish@valicert.com
電話：650.567.5457 Eメール：ambarish@valicert.com
Slava Galperin My CFO, Inc. 1945 Charleston Road Mountain View, CA
スラバGalperin私のCFO、Inc.の1945チャールストンロード、マウンテンビュー、カリフォルニア州
EMail: galperin@mycfo.com
メールアドレス：galperin@mycfo.com
Carlisle Adams Entrust Technologies 750 Heron Road, Suite E08 Ottawa, Ontario K1V 1A7 Canada
カーライルアダムスエントラストテクノロジーズ750ヘロン道路、スイートE08オタワ、オンタリオ州K1V 1A7カナダ
EMail: cadams@entrust.com
メールアドレス：cadams@entrust.com
Appendix A.
付録A.
A.1 OCSP over HTTP
A.1 OCSPオーバーHTTP
This section describes the formatting that will be done to the request and response to support HTTP.
このセクションでは、HTTPをサポートするために要求および応答に行われます書式設定を説明します。
A.1.1 Request
A.1.1リクエスト
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 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 TLS/SSL or some other lower layer protocol.
HTTPベースのOCSPリクエストは、彼らの要求を提出するGETまたはPOSTメソッドのいずれかを使用することができます。 HTTPキャッシングを有効にするには、小さな要求は（符号化後255バイト未満であること）、GETを使用して提出することができます。 HTTPキャッシングが重要ではない、または要求が255バイトよりも大きい場合、要求はPOSTを使用して提出してください。プライバシーが要件である場合は、OCSPトランザクションがHTTPを使用して交換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}
GET {URL} / {OCSPRequestのDER符号化のベース64符号化のURLエンコード}
where {url} may be derived from the value of AuthorityInfoAccess or other local configuration of the OCSP client.
ここで、{URL}はOCSPクライアントのAuthorityInfoAccessの値または他のローカルコンフィギュレーションに由来してもよいです。
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.
メッセージの本体はOCSPRequestのDERエンコーディングのバイナリ値であるContent-Typeヘッダの値が「アプリケーション/ OCSP要求」を有する次のようにPOSTメソッドを使用してOCSP要求が構築されます。
A.1.2 Response
A.1.2レスポンス
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応答はOCSPResponseのDERエンコーディングのバイナリ値、続いて適切なHTTPヘッダーで構成されています。 Content-Typeヘッダの値は、「アプリケーション/ OCSP応答」を有します。 Content-Lengthヘッダは、応答の長さを指定する必要があります。その他のHTTPヘッダーが存在してもよく、要求者が理解していない場合は無視してもよいです。
Appendix B. OCSP in ASN.1
ASN.1の付録B. OCSP
OCSP DEFINITIONS EXPLICIT TAGS::=
BEGIN
ベギン
IMPORTS
輸入
-- Directory Authentication Framework (X.509)
Certificate, AlgorithmIdentifier, CRLReason
FROM AuthenticationFramework { joint-iso-itu-t ds(5)
module(1) authenticationFramework(7) 3 }
-- PKIX Certificate Extensions AuthorityInfoAccessSyntax FROM PKIX1Implicit88 {iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-pkix1-implicit-88(2)}
- PKIX1Implicit88 FROM PKIX証明書拡張AuthorityInfoAccessSyntax {ISO（1）同定された組織（3）DOD（6）インターネット（1）セキュリティ（5）メカニズムは、（5）PKIX（7）ID-MOD（0）ID-pkix1、暗黙-88（2）}
Name, GeneralName, CertificateSerialNumber, Extensions,
id-kp, id-ad-ocsp
FROM PKIX1Explicit88 {iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7)
id-mod(0) id-pkix1-explicit-88(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 Issuers 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
--(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 -- this can be replaced with an enumeration
ArchiveCutoff ::= GeneralizedTime
AcceptableResponses ::= SEQUENCE OF OBJECT IDENTIFIER
ServiceLocator ::= SEQUENCE {
issuer Name,
locator AuthorityInfoAccessSyntax }
-- 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 }
END
終わり
Appendix C. MIME registrations
付録C. MIME登録
C.1 application/ocsp-request
C.1アプリケーション/ OCSPリクエスト
To: ietf-types@iana.org Subject: Registration of MIME media type application/ocsp-request
To：ietf-types@iana.org件名：MIMEメディアタイプアプリケーション/ OCSP要求の登録
MIME media type name: application
MIMEメディアタイプ名：application
MIME subtype name: ocsp-request
MIMEサブタイプ名：OCSP要求
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 Draft on Online Certificate Status Protocol - OCSP
公開された仕様：オンライン証明書状態プロトコルのIETF PKIXワーキンググループドラフト - OCSP
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
マジックナンバー（S）：なしファイルの拡張子（S）：.ORQマッキントッシュファイルタイプコード（S）：なし
Person & email address to contact for further information: Ambarish Malpani <ambarish@valicert.com>
人とEメールアドレスは、詳細のために連絡する：Ambarish Malpani <ambarish@valicert.com>
Intended usage: COMMON
意図している用法：COMMON
Author/Change controller: Ambarish Malpani <ambarish@valicert.com>
著者/変更コントローラ：ambarisa malapani <অম্বরীষ@ভ্যালিসার্ট.কম>
C.2 application/ocsp-response
C.2アプリケーション/ OCSP応答
To: ietf-types@iana.org Subject: Registration of MIME media type application/ocsp-response
To：ietf-types@iana.org件名：MIMEメディアタイプアプリケーション/ OCSP応答の登録
MIME media type name: application
MIMEメディアタイプ名：application
MIME subtype name: ocsp-response
MIMEサブタイプ名：OCSP応答
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 Draft on Online Certificate Status Protocol - OCSP
公開された仕様：オンライン証明書状態プロトコルのIETF PKIXワーキンググループドラフト - OCSP
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
マジックナンバー（S）：なしファイルの拡張子（S）：.ORSマッキントッシュファイルタイプコード（S）：なし
Person & email address to contact for further information: Ambarish Malpani <ambarish@valicert.com>
人とEメールアドレスは、詳細のために連絡する：Ambarish Malpani <ambarish@valicert.com>
Intended usage: COMMON
意図している用法：COMMON
Author/Change controller: Ambarish Malpani <ambarish@valicert.com>
著者/変更コントローラ：ambarisa malapani <অম্বরীষ@ভ্যালিসার্ট.কম>
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (1999). All Rights Reserved.
著作権（C）インターネット協会（1999）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の制限は永久で、インターネット学会やその後継者や譲渡者によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。