RFC2560 日本語訳
2560 X.509 Internet Public Key Infrastructure Online CertificateStatus Protocol - OCSP. M. Myers, R. Ankney, A. Malpani, S. Galperin,C. Adams. June 1999. (Format: TXT=43243 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
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
コメントを求めるワーキンググループM.マイアーズの要求をネットワークでつないでください: 2560年のベリサインカテゴリ: 私の最高財務責任者のC.アダムスが技術1999年6月にゆだねるStandards道のR.Ankney CertCo A.Malpani ValiCert S.ガリペリン
X.509 Internet Public Key Infrastructure
Online Certificate Status Protocol - OCSP
X.509のインターネットの公開鍵暗号基盤のオンライン証明書状態プロトコル--OCSP
Status of this Memo
この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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright(C)インターネット協会(1999)。 All rights reserved。
1. Abstract
1. 要約
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.
このドキュメントはCRLsを必要としないでデジタル証明書の現在の状態を決定する際に役に立つプロトコルを指定します。 操作上の要件を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に提供します。 機能条件書はセクション4で指定されます。 プロトコルの詳細がセクション5にあります。 私たちはセクション6でプロトコルの安全保障問題をカバーします。 付録AはHTTPの上でOCSPを定義します、そして、付録BはASN.1の構文の要素を蓄積します、そして、付録Cはパントマイムタイプをメッセージに指定します。
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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、このドキュメント(中で大文字してください、示されるように)で「5月」の、そして、「任意」のNOTは[RFC2119]で説明されるように解釈されることであるべきですか?
Myers, et al. Standards Track [Page 1] RFC 2560 PKIX OCSP June 1999
マイアーズ、他 規格はPKIX OCSP1999年6月にRFC2560を追跡します[1ページ]。
2. Protocol Overview
2. プロトコル概要
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に対してチェックすることへの補足として、証明書の取消し状態に関する時宜を得た情報を得るのが必要であるかもしれません。(Cf。 [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.
Online Certificate Statusプロトコル(OCSP)は、アプリケーションが特定された証明書の(取消し)状態を決定するのを可能にします。 OCSPは、CRLsで可能であり、また、使用されるかもしれないよりタイムリーな取消し情報を提供すると追加状態情報が得られるという操作上の要件のいくつかを満たすのに使用されるかもしれません。 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.
このプロトコルは状態であるなら証明書の状態をチェックするアプリケーションとサーバの間で交換される必要があるデータを指定します。
2.1 Request
2.1 要求
An OCSP request contains the following data:
OCSP要求は以下のデータを含んでいます:
-- protocol version -- service request -- target certificate identifier -- optional extensions which MAY be processed by the OCSP Responder
-- プロトコルバージョン--サービスのリクエスト--目標証明書識別子--OCSP Responderによって処理されるかもしれない任意の拡大
Upon receipt of a request, an OCSP Responder determines if:
要求を受け取り次第、OCSP Responderは確認します:
1. the message is well formed
1. メッセージは整形式です。
2. the responder is configured to provide the requested service and
そして2. 応答者が要求されたサービスを提供するために構成される。
3. the request contains the information needed by the responder If any one of the prior conditions are not met, the OCSP responder produces an error message; otherwise, it returns a definitive response.
3. 要求は応答者Ifが必要であることで、先の状態のいずれも満たされないで、OCSP応答者がエラーメッセージを作り出すという情報を含んでいます。 さもなければ、それは決定的な応答を返します。
2.2 Response
2.2 応答
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サーバとクライアントがサポートしなければならない1人の基本型のOCSP応答があります。 このセクションの残りはこの基本的な応答タイプだけに関係します。
Myers, et al. Standards Track [Page 2] RFC 2560 PKIX OCSP June 1999
マイアーズ、他 規格はPKIX OCSP1999年6月にRFC2560を追跡します[2ページ]。
All definitive response messages SHALL be digitally signed. The key used to sign the response MUST belong to one of the following:
署名されて、すべての決定的な応答メッセージSHALLがデジタルなそうです。 応答に署名するのに使用されるキーは以下の1つに属さなければなりません:
-- 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
-- 問題の証明書を発行したカリフォルニア--公開鍵がリクエスタによって信じられるTrusted Responder--応答者がそのカリフォルニアのためにOCSPに応答を発行するかもしれないのを示して、直接カリフォルニアが特に著しい証明書を発行するように主張するカリフォルニアDesignated Responder(Responderを認可します)
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
aの要求が成るそれぞれの証明書のための応答
-- 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)).
「取り消された」州は、証明書が取り消されたのを(permanantlyか一時的(保持で))示します。
The "unknown" state indicates that the responder doesn't know about the certificate being requested.
「未知」の州は、応答者が要求されている証明書に関して知らないのを示します。
Myers, et al. Standards Track [Page 3] RFC 2560 PKIX OCSP June 1999
マイアーズ、他 規格はPKIX OCSP1999年6月にRFC2560を追跡します[3ページ]。
2.3 Exception Cases
2.3 例外ケース
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 Responderはエラーメッセージを返すかもしれません。 これらのメッセージは署名されません。 以下のタイプには誤りがあることができます:
-- 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.
クライアントがこの質問をこのサーバにするのは権限を与えられない場合で応答「権限のなさ」を返します。
2.4 Semantics of thisUpdate, nextUpdate and producedAt
2.4 thisUpdate、nextUpdate、およびproducedAtの意味論
Responses can contain three times in them - thisUpdate, nextUpdate and producedAt. The semantics of these fields are:
応答はそれらに3回を含むことができます--thisUpdate、nextUpdate、およびproducedAt。 これらの分野の意味論は以下の通りです。
- 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が用意ができていないなら、応答者は、より新しい取消し情報が絶えず利用可能であることを示しています。
Myers, et al. Standards Track [Page 4] RFC 2560 PKIX OCSP June 1999
マイアーズ、他 規格はPKIX OCSP1999年6月にRFC2560を追跡します[4ページ]。
2.5 Response Pre-production
2.5 応答試作
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応答者5月のプレ生産物は指定の時間に証明書の状態を指定する応答に署名しました。 状態が反射したコネが応答のthisUpdate分野であったなら正しいSHALLであることが知られていた時。 ことであることにおけるどちらのより新しい情報が応答のproducedAt分野でことになるかの利用可能であるのが、nextUpdate分野で反射していて、応答が起こされた時である現れるということであるという前の時間。
2.6 OCSP Signature Authority Delegation
2.6 OCSP署名権威委譲
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.
署名した同じキーが証明書でなければならなかったなら証明書の状態が情報であると署名するキー。 証明書の発行人は、extendedKeyUsageのためにOCSP署名者の証明書でユニークな値を含む証明書を発行することによって、明らかにOCSP署名権威を代表として派遣します。 認識力があるカリフォルニアは直接応答者にこの証明書を発行しなければなりません。
2.7 CA Key Compromise
2.7 カリフォルニアの主要な感染
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の秘密鍵が感染されたのを知っているなら、それはそのカリフォルニアによって発行されたすべての証明書のために取り消された状態を返すかもしれません。
3. Functional Requirements
3. 機能条件書
3.1 Certificate Content
3.1 証明書内容
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クライアントに伝えるために、CAs SHALLはOCSPを使用することでチェックできる証明書にAuthorityInfoAccess拡張子([RFC2459]、セクション4.2.2では、.1を定義する)を含む能力を提供します。 あるいはまた、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.
局所的に主催されたか、またはAuthorized Responderによって提供されたOCSPサービスをサポートするCAsはAccessDescription SEQUENCEのaccessMethodのためにaccessLocationとOID値のイド広告ocspをuniformResourceIndicator(URI)のための価値の包含に提供しなければなりません。
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)を含むかもしれません。
Myers, et al. Standards Track [Page 5] RFC 2560 PKIX OCSP June 1999
マイアーズ、他 規格はPKIX OCSP1999年6月にRFC2560を追跡します[5ページ]。
3.2 Signed Response Acceptance Requirements
3.2は、応答承認が要件であると署名しました。
Prior to accepting a signed response as valid, OCSP clients SHALL confirm that:
署名している応答が有効であると受け入れる前に、OCSPクライアントSHALLは、以下のことと確認します。
1. The certificate identified in a received response corresponds to that which was identified in the corresponding request;
1. 容認された応答で特定された証明書は対応する要求で特定されたそれに一致しています。
2. The signature on the response is valid;
2. 応答の署名は有効です。
3. The identity of the signer matches the intended recipient of the request.
3. 署名者のアイデンティティは要求の意図している受取人に合っています。
4. The signer is currently authorized to sign the response.
4. 現在、署名者が応答に署名するのが認可されます。
5. The time at which the status being indicated is known to be correct (thisUpdate) is sufficiently recent.
5. 示される状態が正しいのが知られている時間(thisUpdate)は十分最近です。
6. When available, the time at or before which newer information will be available about the status of the certificate (nextUpdate) is greater than the current time.
6. 利用可能であるときに、利用可能であることにおけるどちらのより新しい情報が証明書(nextUpdate)の状態に関して利用可能になるかの前の時間は現在の時間より大きいです。
4. Detailed Protocol
4. 詳細なプロトコル
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].
ASN.1構文は[RFC2459]で定義された用語を意味します。 署名計算において、署名されるデータは、規則(DER)[X.690]をコード化しながら区別されたASN.1を使用することでコード化されます。
ASN.1 EXPLICIT tagging is used as a default unless specified otherwise.
別の方法で指定されない場合、ASN.1EXPLICITタグ付けはデフォルトとして使用されます。
The terms imported from elsewhere are: Extensions, CertificateSerialNumber, SubjectPublicKeyInfo, Name, AlgorithmIdentifier, CRLReason
ほかの場所からインポートされた用語は以下の通りです。 拡大、CertificateSerialNumber、SubjectPublicKeyInfo、名前、AlgorithmIdentifier、CRLReason
4.1 Requests
4.1 要求
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など)によって、メッセージの実際の形式は異なることができました。
4.1.1 Request Syntax
4.1.1 構文を要求してください。
OCSPRequest ::= SEQUENCE {
tbsRequest TBSRequest,
optionalSignature [0] EXPLICIT Signature OPTIONAL }
OCSPRequest:、:= 系列tbsRequest TBSRequestで、optionalSignatureの[0]の明白な署名任意です。
TBSRequest ::= SEQUENCE {
TBSRequest:、:= 系列
Myers, et al. Standards Track [Page 6] RFC 2560 PKIX OCSP June 1999
マイアーズ、他 規格はPKIX OCSP1999年6月にRFC2560を追跡します[6ページ]。
version [0] EXPLICIT Version DEFAULT v1,
requestorName [1] EXPLICIT GeneralName OPTIONAL,
requestList SEQUENCE OF Request,
requestExtensions [2] EXPLICIT Extensions OPTIONAL }
バージョン[0]EXPLICITバージョン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}
署名:、:= 系列signatureAlgorithm AlgorithmIdentifier、署名BIT STRING、本命[0]EXPLICIT SEQUENCE OF Certificate OPTIONAL
Version ::= INTEGER { v1(0) }
バージョン:、:= 整数v1(0)
Request ::= SEQUENCE {
reqCert CertID,
singleRequestExtensions [0] EXPLICIT Extensions OPTIONAL }
以下を要求してください:= 系列reqCert CertID、singleRequestExtensionsの[0]の明白な拡張子、任意
CertID ::= SEQUENCE {
hashAlgorithm AlgorithmIdentifier,
issuerNameHash OCTET STRING, -- Hash of Issuer's DN
issuerKeyHash OCTET STRING, -- Hash of Issuers public key
serialNumber CertificateSerialNumber }
CertID:、:= 系列hashAlgorithm AlgorithmIdentifier、issuerNameHash OCTET STRING--IssuerのDN issuerKeyHash OCTET STRINGのハッシュ--Issuers公開鍵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はIssuerの分類名のハッシュです。 ハッシュはチェックされる証明書における、発行人の名前欄のDERコード化に関して計算されるものとします。issuerKeyHashはIssuerの公開鍵のハッシュです。 ハッシュは発行人の証明書の対象の公開鍵分野の値(タグと長さを除いた)に関して計算されるものとします。 これらのハッシュの両方に使用されるハッシュアルゴリズムはhashAlgorithm. serialNumberで特定されているのが、状態が要求されている証明書の通し番号であるということです。
4.1.2 Notes on the Request Syntax
4.1.2 要求構文に関する注
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の公開鍵のハッシュを使用して、発行人を特定するプライマリ理由は2CAsが、同じNameを使用するのを選ぶのが(Nameのユニークさは励行されることができない推薦です)、可能であるということです。 しかしながら、2CAsには、CAsが、彼らの秘密鍵を共有すると明らかに決めたか、またはCAsの1つのキーが感染されなかったなら、同じ公開鍵が決してないでしょう。
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).
どんな特定の拡大のサポートもOPTIONALです。 重要はSHOULD NOTに旗を揚げさせます。それらのいずれにも設定されます。 セクション4.4はいくつかの役に立つ拡大を示します。 追加拡大は追加RFCsで定義されるかもしれません。 認識されていない拡大を無視しなければなりません(それらが重要な旗を設定させて、理解されている場合)。
Myers, et al. Standards Track [Page 7] RFC 2560 PKIX OCSP June 1999
マイアーズ、他 規格はPKIX OCSP1999年6月にRFC2560を追跡します[7ページ]。
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構造で計算されます。 要求が署名されるなら、要請者SHALLはrequestorName分野で名前を指定します。 また、署名している要求のために、要請者はOCSP応答者がSignatureの本命分野で要請者の署名について確かめるのを助ける証明書を入れるかもしれません。
4.2 Response Syntax
4.2応答構文
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など)によって、メッセージの実際の形式は異なることができました。
4.2.1 ASN.1 Specification of the OCSP Response
4.2.1 OCSP応答のASN.1仕様
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の値がエラー条件の1つであるなら、responseBytesは用意ができていません。
OCSPResponse ::= SEQUENCE {
responseStatus OCSPResponseStatus,
responseBytes [0] EXPLICIT ResponseBytes OPTIONAL }
OCSPResponse:、:= 系列responseStatus OCSPResponseStatusで、[0]の明白なresponseBytes ResponseBytes任意です。
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
}
OCSPResponseStatus:、:= 列挙されます。{応答には有効な確認malformedRequest(1)があるという(4)が中古のsigRequired(5)でないという不法な確認要求internalError(2)(発行人tryLater(3)の内部エラー)が後で再び試みるうまくいっている(0)は、要求が権限のない(6)であると署名しなければなりません--要求権限のない}です。
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によって特定されたOBJECT IDENTIFIERと応答構文から成ります。
ResponseBytes ::= SEQUENCE {
responseType OBJECT IDENTIFIER,
response OCTET STRING }
ResponseBytes:、:= 系列responseType OBJECT IDENTIFIER、応答OCTET STRING
For a basic OCSP responder, responseType will be id-pkix-ocsp-basic.
responseTypeは基本的なOCSP応答者にとっての、イドpkix-ocsp基礎になるでしょう。
id-pkix-ocsp OBJECT IDENTIFIER ::= { id-ad-ocsp }
id-pkix-ocsp-basic OBJECT IDENTIFIER ::= { id-pkix-ocsp 1 }
イド-pkix-ocsp OBJECT IDENTIFIER:、:= イド広告ocspイドpkix-ocsp基礎OBJECT IDENTIFIER:、:= イド-pkix-ocsp1
Myers, et al. Standards Track [Page 8] RFC 2560 PKIX OCSP June 1999
マイアーズ、他 規格はPKIX OCSP1999年6月にRFC2560を追跡します[8ページ]。
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応答者SHALL、イドのpkix-ocsp基本的な応答タイプの応答を起こすことができてください。 受信ができてイド-pkix-ocsp基本的な応答の応答を処理しているOCSPクライアントSHALLは対応する、タイプします。
The value for response SHALL be the DER encoding of BasicOCSPResponse.
応答には、DERがBasicOCSPResponseのコード化であったならSHALLを評価してください。
BasicOCSPResponse ::= SEQUENCE {
tbsResponseData ResponseData,
signatureAlgorithm AlgorithmIdentifier,
signature BIT STRING,
certs [0] EXPLICIT SEQUENCE OF Certificate OPTIONAL }
BasicOCSPResponse:、:= 系列tbsResponseData ResponseData、signatureAlgorithm AlgorithmIdentifier、署名BIT STRING、本命[0]EXPLICIT SEQUENCE OF Certificate OPTIONAL
The value for signature SHALL be computed on the hash of the DER encoding ResponseData.
署名のためにSHALLを評価してください。ResponseDataをコード化しながら、DERのハッシュで計算されてください。
ResponseData ::= SEQUENCE {
version [0] EXPLICIT Version DEFAULT v1,
responderID ResponderID,
producedAt GeneralizedTime,
responses SEQUENCE OF SingleResponse,
responseExtensions [1] EXPLICIT Extensions OPTIONAL }
ResponseData:、:= 系列バージョン[0]EXPLICITバージョンDEFAULT v1、responderID ResponderID、producedAt GeneralizedTime、応答SEQUENCE OF SingleResponse、responseExtensions[1]EXPLICIT Extensions OPTIONAL
ResponderID ::= CHOICE {
byName [1] Name,
byKey [2] KeyHash }
ResponderID:、:= 選択別名[1]名、byKey[2]KeyHash
KeyHash ::= OCTET STRING -- SHA-1 hash of responder's public key (excluding the tag and length fields)
KeyHash:、:= OCTET STRING--応答者の公開鍵のSHA-1ハッシュ(タグと長さの分野を除きます)
SingleResponse ::= SEQUENCE {
certID CertID,
certStatus CertStatus,
thisUpdate GeneralizedTime,
nextUpdate [0] EXPLICIT GeneralizedTime OPTIONAL,
singleExtensions [1] EXPLICIT Extensions OPTIONAL }
SingleResponse:、:= 系列certID CertID、certStatus CertStatus、thisUpdate GeneralizedTime、nextUpdateの[0]の明白なGeneralizedTime任意の、そして、singleExtensions[1]明白な拡張子、任意
CertStatus ::= CHOICE {
good [0] IMPLICIT NULL,
revoked [1] IMPLICIT RevokedInfo,
unknown [2] IMPLICIT UnknownInfo }
CertStatus:、:= 選択利益[0]IMPLICIT NULL、取り消された[1]IMPLICIT RevokedInfo、未知[2]のIMPLICIT UnknownInfo
RevokedInfo ::= SEQUENCE {
revocationTime GeneralizedTime,
revocationReason [0] EXPLICIT CRLReason OPTIONAL }
RevokedInfo:、:= 系列revocationTime GeneralizedTimeで、[0]の明白なrevocationReason CRLReason任意です。
UnknownInfo ::= NULL -- this can be replaced with an enumeration
UnknownInfo:、:= NULL--これを列挙に取り替えることができます。
Myers, et al. Standards Track [Page 9] RFC 2560 PKIX OCSP June 1999
マイアーズ、他 規格はPKIX OCSP1999年6月にRFC2560を追跡します[9ページ]。
4.2.2 Notes on OCSP Responses
4.2.2 OCSP応答に関する注
4.2.2.1 Time
4.2.2.1時間
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分野はお勧めの正当性間隔を定義します。 この間隔が相当している、thisUpdate、nextUpdate、CRLsの間隔。 頼り無い状態で考えられて、nextUpdate値がローカルシステム時間的価値SHOULDより初期である応答。 頼り無い状態で考えられて、thisUpdate時間がローカルシステム時間SHOULDより遅い応答。 nextUpdate値が設定されないところで応答はnextUpdateのための時間なしでCRLに同等です(セクション2.4を見てください)。
The producedAt time is the time at which this response was signed.
producedAt時間はこの応答が署名された時です。
4.2.2.2 Authorized Responders
4.2.2.2 認可された応答者
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、委譲がSHALLであると署名して、OCSP応答署名者の証明書に証明書拡張子を含んでいて、extendedKeyUsageでのイド-kp-OCSPSigningの包含で指定されてください。 直接問題の証明書を発行したカリフォルニアはこの証明書を発行しなければなりません。
id-kp-OCSPSigning OBJECT IDENTIFIER ::= {id-kp 9}
イド-kp-OCSPSigningオブジェクト識別子:、:= イド-kp9
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応答に依存するシステムかアプリケーションが実施できなければならない、イド広告ocspSigning、上で説明される値。 彼らは局所的に1つ以上のOCSP署名当局を構成して、それぞれの署名権威が信じられるCAsのセットを指定する手段を提供するかもしれません。 応答のときに署名を有効にしなければならなかった証明書が少なくとも以下の評価基準の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. 問題の証明書を発行したカリフォルニアの証明書です。 または
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. 「値を含んでいる、イド広告ocspSigning、ExtendedKeyUsage拡張子、問題の証明書を発行したカリフォルニアによって発行される、」
Myers, et al. Standards Track [Page 10] RFC 2560 PKIX OCSP June 1999
マイアーズ、他 規格はPKIX OCSP1999年6月にRFC2560を追跡します[10ページ]。
Additional acceptance or rejection criteria may apply to either the response itself or to the certificate used to validate the signature on the response.
追加承認か拒絶評価基準が応答のときに応答自体、または、署名を有効にするのに使用される証明書に適用されるかもしれません。
4.2.2.2.1 Revocation Checking of an Authorized Responder
4.2.2.2.1 認可された応答者の取消しの照合
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:
Authorized OCSP応答者が1CAsのための状態情報を提供するので、OCSPクライアントは、認可された応答者の証明書が取り消されていないのをチェックする方法を知る必要があります。 CAsは、3つの方法の1つでこの問題に対処するのを選ぶかもしれません:
- 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.
- カリフォルニアは、OCSPクライアントが応答者の証明書の生涯のための応答者を信じることができると指定するかもしれません。 カリフォルニアは、拡大イド-pkix-ocsp-nocheckを含んでいることによって、そうします。 このSHOULD、非臨界拡大になってください。 拡大の値はNULLであるべきです。 少なくともカリフォルニアキーの感染が以前はよくCRLsに署名していたこの証明書の有効期間の間、そのような証明書を発行するのがそうするべきであるCAsは、応答者のキーの感染が同じくらい重大であるとわかりました。 CAのものは、非常に短い生涯でこのタイプの証明書を発行して、頻繁にそれを更新するのを選ぶかもしれません。
id-pkix-ocsp-nocheck OBJECT IDENTIFIER ::= { id-pkix-ocsp 5 }
イド-pkix-ocsp-nocheck OBJECT IDENTIFIER:、:= イド-pkix-ocsp5
- 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].
- カリフォルニアがその方法を指定するかもしれない、応答者の証明書、取消しがないかどうかチェックされてください。 これはチェックがCRLs、CRL Distribution Points、またはAuthority情報Accessを使用し終わっているならチェックがある他の方法で完了しているならCRL Distribution Pointsを使用し終わることができます。 これらの2つのメカニズムのどちらかを指定するための詳細は[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.
- カリフォルニアは、取消しが応答者の証明書がないかどうかチェックする少しのメソッドも指定しないのを選ぶかもしれません、その場合、その証明書が取消しがないかどうかチェックされるべきであるかどうか決めるのがOCSPクライアントのローカルの安全保障政策まで達しているでしょう。
4.3 Mandatory and Optional Cryptographic Algorithms
4.3 義務的で任意の暗号アルゴリズム
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サービスSHALLはDSA sig-alg-oidによって特定された中古のDSAキーであると署名される処理応答ができるよう要求するクライアントが.2セクション7.2[RFC2459]で指定しました。 クライアントSHOULD、また、.1セクション7.2[RFC2459]における指定されるとしての処理RSA署名ができてください。 OCSP応答者SHALLはアルゴリズムを論じ尽くすSHA1をサポートします。
4.4 Extensions
4.4 拡大
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
このセクションは証明書が見るX.509バージョン3[RFC2459]で雇われた拡大モデルに基づいていくつかの標準の拡大を定義します。 クライアントと応答者の両方に、すべての拡大のサポートは任意です。 for
Myers, et al. Standards Track [Page 11] RFC 2560 PKIX OCSP June 1999
マイアーズ、他 規格はPKIX OCSP1999年6月にRFC2560を追跡します[11ページ]。
each extension, the definition indicates its syntax, processing performed by the OCSP Responder, and any extensions which are included in the corresponding response.
各拡大、定義は構文、OCSP Responderによって実行された処理、および対応する応答に含まれているどんな拡大も示します。
4.4.1 Nonce
4.4.1 一回だけ
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.
一回だけは、反射攻撃を防ぐために暗号で要求と応答を縛ります。 一回だけはrequestExtensionsの1つとして要求に含まれています、それがresponseExtensionsの1つとして応答に含まれているでしょうが。 要求と応答の両方では、一回だけはオブジェクト識別子イドpkix-ocsp一回だけによって特定されるでしょう、extnValueが一回だけの値ですが。
id-pkix-ocsp-nonce OBJECT IDENTIFIER ::= { id-pkix-ocsp 2 }
イドpkix-ocsp一回だけOBJECT IDENTIFIER:、:= イド-pkix-ocsp2
4.4.2 CRL References
4.4.2 CRL参照
It may be desirable for the OCSP responder to indicate the CRL on which a revoked or onHold certificate is found. This can be useful where OCSP is used between repositories, and also as an auditing mechanism. The CRL may be specified by a URL (the URL at which the CRL is available), a number (CRL number) or a time (the time at which the relevant CRL was created). These extensions will be specified as singleExtensions. The identifier for this extension will be id-pkix- ocsp-crl, while the value will be CrlID.
OCSP応答者が取り消されるかonHold証明書が見つけられるCRLを示すのは、望ましいかもしれません。 これはOCSPが倉庫の間と、そして、監査のメカニズムとしても使用されるところで役に立つ場合があります。 CRLはURL(CRLが利用可能であるURL)、数(CRL番号)または時間(関連CRLが作成された時)までに指定されるかもしれません。 これらの拡大はsingleExtensionsとして指定されるでしょう。 この拡大のための識別子はイド-pkix- ocsp-crlでしょうが、値はCrlIDになるでしょう。
id-pkix-ocsp-crl OBJECT IDENTIFIER ::= { id-pkix-ocsp 3 }
イド-pkix-ocsp-crl OBJECT IDENTIFIER:、:= イド-pkix-ocsp3
CrlID ::= SEQUENCE {
crlUrl [0] EXPLICIT IA5String OPTIONAL,
crlNum [1] EXPLICIT INTEGER OPTIONAL,
crlTime [2] EXPLICIT GeneralizedTime OPTIONAL }
CrlID:、:= 系列crlUrlの[0]の明白なIA5String任意の、そして、crlNum[1]明白な整数任意であって、[2]の明白なcrlTime GeneralizedTime任意です。
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が発行された時を示すでしょう。
4.4.3 Acceptable Response Types
4.4.3 許容応答タイプ
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クライアントはそれが理解している応答タイプの種類を指定したがっているかもしれません。 そのように、それをするために、SHOULDはOIDイドのpkix-ocsp-応答、および値のAcceptableResponsesとの拡張子を使用します。 この拡大はrequestExtensionsの1つとして要求に含まれています。 AcceptableResponsesに含まれていたOIDsはこのクライアントが受け入れることができる様々な応答タイプ(例えば、イド-pkix-ocsp基礎)のOIDsです。
Myers, et al. Standards Track [Page 12] RFC 2560 PKIX OCSP June 1999
マイアーズ、他 規格はPKIX OCSP1999年6月にRFC2560を追跡します[12ページ]。
id-pkix-ocsp-response OBJECT IDENTIFIER ::= { id-pkix-ocsp 4 }
イドpkix-ocsp応答OBJECT IDENTIFIER:、:= イド-pkix-ocsp4
AcceptableResponses ::= SEQUENCE OF OBJECT IDENTIFIER
AcceptableResponses:、:= オブジェクト識別子の系列
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応答者SHALLでイドpkix-ocsp基礎応答タイプの応答で応じることができるように注意するので。 対応、受信できて、イドpkix-ocsp基礎応答の応答を処理するとタイプされるOCSPクライアントSHALL。
4.4.4 Archive Cutoff
4.4.4 アーカイブ締切り
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.
そのような歴史上の記述SHOULDのサポートを提供するOCSPサーバが応答におけるアーカイブ締め日の拡張子を含んでいます。 含まれているなら、これはあって、OCSP singleExtensions拡張子としてイドpkix-ocspアーカイブ締切りによって特定されていて、SHALLを評価して、構文GeneralizedTimeについて含まれています。
id-pkix-ocsp-archive-cutoff OBJECT IDENTIFIER ::= { id-pkix-ocsp 6 }
イドpkix-ocspアーカイブ締切りのOBJECT IDENTIFIER:、:= イド-pkix-ocsp6
ArchiveCutoff ::= GeneralizedTime
ArchiveCutoff:、:= GeneralizedTime
To illustrate, if a server is operated with a 7-year retention interval policy and status was produced at time t1 then the value for ArchiveCutoff in the response would be (t1 - 7 years).
例証するために、サーバが7年の保有間隔方針で操作されて、状態が時間t1に作り出されるなら、応答におけるArchiveCutoffのための値はこと(t1--7年)でしょうに。
4.4.5 CRL Entry Extensions
4.4.5 CRLエントリー拡張子
All the extensions specified as CRL Entry Extensions - in Section 5.3 of [RFC2459] - are also supported as singleExtensions.
また、[RFC2459]のセクション5.3におけるCRL Entry ExtensionsがsingleExtensionsとしてサポートされるので、すべての拡大が指定しました。
4.4.6 Service Locator
4.4.6 サービスロケータ
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の1つとして要求に含まれています。
Myers, et al. Standards Track [Page 13] RFC 2560 PKIX OCSP June 1999
マイアーズ、他 規格はPKIX OCSP1999年6月にRFC2560を追跡します[13ページ]。
id-pkix-ocsp-service-locator OBJECT IDENTIFIER ::= { id-pkix-ocsp 7 }
イドpkix-ocspサービスロケータOBJECT IDENTIFIER:、:= イド-pkix-ocsp7
ServiceLocator ::= SEQUENCE {
issuer Name,
locator AuthorityInfoAccessSyntax OPTIONAL }
ServiceLocator:、:= 系列発行人Name、ロケータAuthorityInfoAccessSyntax OPTIONAL
Values for these fields are obtained from the corresponding fields in the subject certificate.
対象の証明書の対応する分野からこれらの分野への値を得ます。
5. Security Considerations
5. セキュリティ問題
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キャッシュメカニズムの信頼性を考慮に入れるようにアドバイスされます。
Myers, et al. Standards Track [Page 14] RFC 2560 PKIX OCSP June 1999
マイアーズ、他 規格はPKIX OCSP1999年6月にRFC2560を追跡します[14ページ]。
6. References
6. 参照
[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.と一人で生活して、「インターネットX.509公開鍵基盤の証明書とCRLは輪郭を描く」D.、RFC2459、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.、Gettys、J.、ムガール人、J.、Frystyk、H.、およびT.バーナーズ・リー、「HTTP/1.1インチ、RFC2068、1997年ハイパーテキスト転送プロトコル--1月」。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、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、「Uniform Resource Locator(URL)」、RFC1738、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/IEC8825-1: 1995、情報Technology--ASN.1符号化規則: 基本的なコード化の仕様は(BER)、正準な符号化規則(CER)、および顕著な符号化規則(DER)を統治します。
Myers, et al. Standards Track [Page 15] RFC 2560 PKIX OCSP June 1999
マイアーズ、他 規格はPKIX OCSP1999年6月にRFC2560を追跡します[15ページ]。
7. Authors' Addresses
7. 作者のアドレス
Michael Myers VeriSign, Inc. 1350 Charleston Road Mountain View, CA 94043
マウンテンビュー、マイケルマイアーズベリサインInc.1350チャールストンRoadカリフォルニア 94043
EMail: mmyers@verisign.com
メール: mmyers@verisign.com
Rich Ankney CertCo, LLC 13506 King Charles Dr. Chantilly, VA 20151
豊かなAnkney CertCo、LLC13506キングチャールズ・シャンティイ博士、ヴァージニア 20151
EMail: rankney@erols.com
メール: rankney@erols.com
Ambarish Malpani ValiCert, Inc. 1215 Terra Bella Ave. Mountain View, CA 94043
Ambarish Malpani ValiCert Inc.1215大地ベラAve。 マウンテンビュー、カリフォルニア 94043
Phone: 650.567.5457 EMail: ambarish@valicert.com
以下に電話をしてください。 650.567.5457 メールしてください: ambarish@valicert.com
Slava Galperin My CFO, Inc. 1945 Charleston Road Mountain View, CA
スラバ・ガリペリン、私の最高財務責任者Inc.1945チャールストン道路山の眺望、カリフォルニア
EMail: galperin@mycfo.com
メール: galperin@mycfo.com
Carlisle Adams Entrust Technologies 750 Heron Road, Suite E08 Ottawa, Ontario K1V 1A7 Canada
カーライルアダムスは技術750サギの道路、08スイートEのオタワ、オンタリオK1V 1A7カナダをゆだねます。
EMail: cadams@entrust.com
メール: cadams@entrust.com
Myers, et al. Standards Track [Page 16] RFC 2560 PKIX OCSP June 1999
マイアーズ、他 規格はPKIX OCSP1999年6月にRFC2560を追跡します[16ページ]。
Appendix A.
付録A。
A.1 OCSP over HTTP
HTTPの上のA.1 OCSP
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.
ベースのOCSPが要求するHTTPは彼らの要求を提出するGETかポストメソッドのどちらかを使用できます。 HTTPのキャッシュしていて、小さい要求(コード化の後のそれは255バイト未満である)、5月を可能にするには、GETを使用することで、提出してください。 ポストを使用することで、提出してください。HTTPキャッシュが重要でないなら、要求は、255バイト以上、プライバシーが要件であるところと、OCSPトランザクションが保護された使用がTLS/SSLであったかもしれないなら使用HTTPを交換したという要求SHOULDまたはある他の下位層プロトコルです。
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}
/をurlに手に入れてください。OCSPRequestのDERコード化のベース-64コード化のurl-コード化
where {url} may be derived from the value of AuthorityInfoAccess or
other local configuration of the OCSP client.
urlがAuthorityInfoAccessの値かOCSPクライアントの他の地方の構成から得られるかもしれないところ。
An OCSP request using the POST method is constructed as follows: The Content-Type header has the value "application/ocsp-request" while the body of the message is the binary value of the DER encoding of the OCSPRequest.
ポストメソッドを使用するOCSP要求は以下の通り構成されます: コンテントタイプヘッダーには、メッセージ欄はOCSPRequestのDERコード化の2進の値ですが、値の「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コード化の2進の値があとに続いた適切なHTTPヘッダで構成されます。 コンテントタイプヘッダーには、値の「ocspアプリケーション/応答」があります。 Content-長さのヘッダーSHOULDは応答の長さを指定します。 他のHTTPヘッダは、存在しているかもしれなくて、無視されるか、または要請者に解釈されるかもしれません。
Myers, et al. Standards Track [Page 17] RFC 2560 PKIX OCSP June 1999
マイアーズ、他 規格はPKIX OCSP1999年6月にRFC2560を追跡します[17ページ]。
Appendix B. OCSP in ASN.1
ASN.1の付録B.OCSP
OCSP DEFINITIONS EXPLICIT TAGS::=
OCSP定義、明白なタグ:、:=
BEGIN
始まってください。
IMPORTS
輸入
-- Directory Authentication Framework (X.509)
Certificate, AlgorithmIdentifier, CRLReason
FROM AuthenticationFramework { joint-iso-itu-t ds(5)
module(1) authenticationFramework(7) 3 }
-- AuthenticationFrameworkからのディレクトリ認証フレームワーク(X.509)証明書、AlgorithmIdentifier、CRLReason共同iso-itu t ds(5)モジュール(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からのPKIX証明書拡大AuthorityInfoAccessSyntaxiso(1)の特定された組織(3)のdod(6)インターネット(1)セキュリティ(5)メカニズム(5)pkix(7)イドモッズ(0)のイドの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)};
名前、GeneralName、CertificateSerialNumber、Extensions、イド-kp、イド広告ocsp FROM PKIX1Explicit88、iso(1)の特定された組織(3)のdod(6)インターネット(1)セキュリティ(5)メカニズム(5)pkix(7)イドモッズ(0)のイドのpkix1の明白な88(1)。
OCSPRequest ::= SEQUENCE {
tbsRequest TBSRequest,
optionalSignature [0] EXPLICIT Signature OPTIONAL }
OCSPRequest:、:= 系列tbsRequest TBSRequestで、optionalSignatureの[0]の明白な署名任意です。
TBSRequest ::= SEQUENCE {
version [0] EXPLICIT Version DEFAULT v1,
requestorName [1] EXPLICIT GeneralName OPTIONAL,
requestList SEQUENCE OF Request,
requestExtensions [2] EXPLICIT Extensions OPTIONAL }
TBSRequest:、:= 系列バージョン[0]EXPLICITバージョン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 }
署名:、:= 系列signatureAlgorithm AlgorithmIdentifier、署名BIT STRING、本命[0]EXPLICIT SEQUENCE OF Certificate OPTIONAL
Version ::= INTEGER { v1(0) }
バージョン:、:= 整数v1(0)
Request ::= SEQUENCE {
reqCert CertID,
singleRequestExtensions [0] EXPLICIT Extensions OPTIONAL }
以下を要求してください:= 系列reqCert CertID、singleRequestExtensionsの[0]の明白な拡張子、任意
Myers, et al. Standards Track [Page 18] RFC 2560 PKIX OCSP June 1999
マイアーズ、他 規格はPKIX OCSP1999年6月にRFC2560を追跡します[18ページ]。
CertID ::= SEQUENCE {
hashAlgorithm AlgorithmIdentifier,
issuerNameHash OCTET STRING, -- Hash of Issuer's DN
issuerKeyHash OCTET STRING, -- Hash of Issuers public key
serialNumber CertificateSerialNumber }
CertID:、:= 系列hashAlgorithm AlgorithmIdentifier、issuerNameHash OCTET STRING--IssuerのDN issuerKeyHash OCTET STRINGのハッシュ--Issuers公開鍵serialNumber CertificateSerialNumberのハッシュ
OCSPResponse ::= SEQUENCE {
responseStatus OCSPResponseStatus,
responseBytes [0] EXPLICIT ResponseBytes OPTIONAL }
OCSPResponse:、:= 系列responseStatus OCSPResponseStatusで、[0]の明白なresponseBytes ResponseBytes任意です。
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
}
OCSPResponseStatus:、:= 列挙されます。{応答には有効な確認malformedRequest(1)があるという(4)が中古のsigRequired(5)でないという不法な確認要求internalError(2)(発行人tryLater(3)の内部エラー)が後で再び試みるうまくいっている(0)は、要求が権限のない(6)であると署名しなければなりません--要求権限のない}です。
ResponseBytes ::= SEQUENCE {
responseType OBJECT IDENTIFIER,
response OCTET STRING }
ResponseBytes:、:= 系列responseType OBJECT IDENTIFIER、応答OCTET STRING
BasicOCSPResponse ::= SEQUENCE {
tbsResponseData ResponseData,
signatureAlgorithm AlgorithmIdentifier,
signature BIT STRING,
certs [0] EXPLICIT SEQUENCE OF Certificate OPTIONAL }
BasicOCSPResponse:、:= 系列tbsResponseData ResponseData、signatureAlgorithm AlgorithmIdentifier、署名BIT STRING、本命[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 }
ResponseData:、:= 系列バージョン[0]EXPLICITバージョンDEFAULT v1、responderID ResponderID、producedAt GeneralizedTime、応答SEQUENCE OF SingleResponse、responseExtensions[1]EXPLICIT Extensions OPTIONAL
ResponderID ::= CHOICE {
byName [1] Name,
byKey [2] KeyHash }
ResponderID:、:= 選択別名[1]名、byKey[2]KeyHash
KeyHash ::= OCTET STRING --SHA-1 hash of responder's public key
--(excluding the tag and length fields)
KeyHash:、:= 応答者の公開鍵のOCTET STRING --SHA-1ハッシュ--(タグと長さの分野を除きます)
SingleResponse ::= SEQUENCE {
certID CertID,
certStatus CertStatus,
thisUpdate GeneralizedTime,
SingleResponse:、:= 系列、certID CertID、certStatus CertStatus、thisUpdate GeneralizedTime
Myers, et al. Standards Track [Page 19] RFC 2560 PKIX OCSP June 1999
マイアーズ、他 規格はPKIX OCSP1999年6月にRFC2560を追跡します[19ページ]。
nextUpdate [0] EXPLICIT GeneralizedTime OPTIONAL, singleExtensions [1] EXPLICIT Extensions OPTIONAL }
任意の状態で[0] 明白なGeneralizedTime任意の、そして、singleExtensions[1]明白な拡張子をnextUpdateします。
CertStatus ::= CHOICE {
good [0] IMPLICIT NULL,
revoked [1] IMPLICIT RevokedInfo,
unknown [2] IMPLICIT UnknownInfo }
CertStatus:、:= 選択利益[0]IMPLICIT NULL、取り消された[1]IMPLICIT RevokedInfo、未知[2]のIMPLICIT UnknownInfo
RevokedInfo ::= SEQUENCE {
revocationTime GeneralizedTime,
revocationReason [0] EXPLICIT CRLReason OPTIONAL }
RevokedInfo:、:= 系列revocationTime GeneralizedTimeで、[0]の明白なrevocationReason CRLReason任意です。
UnknownInfo ::= NULL -- this can be replaced with an enumeration
UnknownInfo:、:= NULL--これを列挙に取り替えることができます。
ArchiveCutoff ::= GeneralizedTime
ArchiveCutoff:、:= GeneralizedTime
AcceptableResponses ::= SEQUENCE OF OBJECT IDENTIFIER
AcceptableResponses:、:= オブジェクト識別子の系列
ServiceLocator ::= SEQUENCE {
issuer Name,
locator AuthorityInfoAccessSyntax }
ServiceLocator:、:= 系列発行人Name、ロケータ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 }
イド-kp-OCSPSigningオブジェクト識別子:、:= イド-kp9、イド-pkix-ocsp OBJECT IDENTIFIER:、:= イド広告ocspイドpkix-ocsp基礎OBJECT IDENTIFIER:、:= イド-pkix-ocsp1イドpkix-ocsp一回だけOBJECT IDENTIFIER:、:= イド-pkix-ocsp2、イド-pkix-ocsp-crl OBJECT IDENTIFIER:、:= イド-pkix-ocsp3イドpkix-ocsp応答OBJECT IDENTIFIER:、:= イド-pkix-ocsp4、イド-pkix-ocsp-nocheck OBJECT IDENTIFIER:、:= イド-pkix-ocsp5イドpkix-ocspアーカイブ締切りのOBJECT IDENTIFIER:、:= イド-pkix-ocsp6イドpkix-ocspサービスロケータOBJECT IDENTIFIER:、:= イド-pkix-ocsp7
END
終わり
Myers, et al. Standards Track [Page 20] RFC 2560 PKIX OCSP June 1999
マイアーズ、他 規格はPKIX OCSP1999年6月にRFC2560を追跡します[20ページ]。
Appendix C. MIME registrations
付録C.MIME登録証明書
C.1 application/ocsp-request
C.1ocspアプリケーション/要求
To: ietf-types@iana.org Subject: Registration of MIME media type application/ocsp-request
To: ietf-types@iana.org Subject: MIMEメディアの登録はocspアプリケーション/要求をタイプします。
MIME media type name: application
MIMEメディア型名: アプリケーション
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): なにも、File拡張子: .ORQマッキントッシュファイルタイプは(s)をコード化します: なし
Person & email address to contact for further information: Ambarish Malpani <ambarish@valicert.com>
詳細のために連絡する人とEメールアドレス: Ambarish Malpani <ambarish@valicert.com 、gt。
Intended usage: COMMON
意図している用法: 一般的
Author/Change controller: Ambarish Malpani <ambarish@valicert.com>
コントローラを書くか、または変えてください: Ambarish Malpani <ambarish@valicert.com 、gt。
C.2 application/ocsp-response
C.2ocspアプリケーション/応答
To: ietf-types@iana.org Subject: Registration of MIME media type application/ocsp-response
To: ietf-types@iana.org Subject: MIMEメディアの登録はocspアプリケーション/応答をタイプします。
MIME media type name: application
MIMEメディア型名: アプリケーション
Myers, et al. Standards Track [Page 21] RFC 2560 PKIX OCSP June 1999
マイアーズ、他 規格はPKIX OCSP1999年6月にRFC2560を追跡します[21ページ]。
MIME subtype name: ocsp-response
MIME「副-タイプ」は以下を命名します。 ocsp-応答
Required parameters: None
必要なパラメタ: なし
Optional parameters: None Encoding considerations: binary
任意のパラメタ: なにも、Encoding問題: バイナリー
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): なにも、File拡張子: .ORSマッキントッシュファイルタイプは(s)をコード化します: なし
Person & email address to contact for further information: Ambarish Malpani <ambarish@valicert.com>
詳細のために連絡する人とEメールアドレス: Ambarish Malpani <ambarish@valicert.com 、gt。
Intended usage: COMMON
意図している用法: 一般的
Author/Change controller: Ambarish Malpani <ambarish@valicert.com>
コントローラを書くか、または変えてください: Ambarish Malpani <ambarish@valicert.com 、gt。
Myers, et al. Standards Track [Page 22] RFC 2560 PKIX OCSP June 1999
マイアーズ、他 規格はPKIX OCSP1999年6月にRFC2560を追跡します[22ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright(C)インターネット協会(1999)。 All rights reserved。
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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
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機能のための基金は現在、インターネット協会によって提供されます。
Myers, et al. Standards Track [Page 23]
マイアーズ、他 標準化過程[23ページ]
一覧
スポンサーリンク
