RFC5019 日本語訳
5019 The Lightweight Online Certificate Status Protocol (OCSP) Profilefor High-Volume Environments. A. Deacon, R. Hurst. September 2007. (Format: TXT=46371 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group A. Deacon
Request for Comments: 5019 VeriSign
Category: Standards Track R. Hurst
Microsoft
September 2007
コメントを求めるワーキンググループA.執事要求をネットワークでつないでください: 5019年のベリサインカテゴリ: 標準化過程R.ハーストマイクロソフト2007年9月
The Lightweight Online Certificate Status Protocol (OCSP) Profile
for High-Volume Environments
大容量環境のための軽量のオンライン証明書状態プロトコル(OCSP)プロフィール
Status of This Memo
このメモの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Abstract
要約
This specification defines a profile of the Online Certificate Status Protocol (OCSP) that addresses the scalability issues inherent when using OCSP in large scale (high volume) Public Key Infrastructure (PKI) environments and/or in PKI environments that require a lightweight solution to minimize communication bandwidth and client- side processing.
この仕様は大規模(高いボリューム)公開鍵暗号基盤(PKI)環境軽量のソリューションがコミュニケーション帯域幅とクライアントサイド処理を最小にするのを必要とするPKI環境でOCSPを使用するときスケーラビリティが問題であると固有の状態で扱うOnline Certificate Statusプロトコル(OCSP)のプロフィールを定義します。
Deacon & Hurst Standards Track [Page 1] RFC 5019 Lightweight OCSP Profile September 2007
OCSPが2007年9月に輪郭を描く執事とハースト標準化過程[1ページ]RFC5019ライト級
Table of Contents
目次
1. Introduction ....................................................3
1.1. Requirements Terminology ...................................4
2. OCSP Message Profile ............................................4
2.1. OCSP Request Profile .......................................4
2.1.1. OCSPRequest Structure ...............................4
2.1.2. Signed OCSPRequests .................................5
2.2. OCSP Response Profile ......................................5
2.2.1. OCSPResponse Structure ..............................5
2.2.2. Signed OCSPResponses ................................6
2.2.3. OCSPResponseStatus Values ...........................6
2.2.4. thisUpdate, nextUpdate, and producedAt ..............7
3. Client Behavior .................................................7
3.1. OCSP Responder Discovery ...................................7
3.2. Sending an OCSP Request ....................................7
4. Ensuring an OCSPResponse Is Fresh ...............................8
5. Transport Profile ...............................................9
6. Caching Recommendations .........................................9
6.1. Caching at the Client .....................................10
6.2. HTTP Proxies ..............................................10
6.3. Caching at Servers ........................................12
7. Security Considerations ........................................12
7.1. Replay Attacks ............................................12
7.2. Man-in-the-Middle Attacks .................................13
7.3. Impersonation Attacks .....................................13
7.4. Denial-of-Service Attacks .................................13
7.5. Modification of HTTP Headers ..............................14
7.6. Request Authentication and Authorization ..................14
8. Acknowledgements ...............................................14
9. References .....................................................14
9.1. Normative References ......................................14
9.2. Informative References ....................................15
Appendix A. Example OCSP Messages .................................16
A.1. OCSP Request ..............................................16
A.2. OCSP Response .............................................16
1. 序論…3 1.1. 要件用語…4 2. OCSPメッセージプロフィール…4 2.1. OCSPはプロフィールを要求します…4 2.1.1. OCSPRequest構造…4 2.1.2. OCSPRequestsであると署名されます…5 2.2. OCSP応答プロフィール…5 2.2.1. OCSPResponse構造…5 2.2.2. OCSPResponsesであると署名されます…6 2.2.3. OCSPResponseStatus値…6の2.2.4thisUpdate、nextUpdate、およびproducedAt…7 3. クライアントの振舞い…7 3.1. OCSP応答者発見…7 3.2. OCSP要求を送ります…7 4. OCSPResponseを確実にするのは新鮮です…8 5. プロフィールを輸送してください…9 6. 推薦をキャッシュします…9 6.1. クライアントでは、キャッシュします。10 6.2. HTTPプロキシ…10 6.3. サーバでは、キャッシュします。12 7. セキュリティ問題…12 7.1. 反射攻撃…12 7.2. 中央の男性は攻撃します…13 7.3. ものまねは攻撃されます…13 7.4. サービス不能攻撃…13 7.5. HTTPヘッダの変更…14 7.6. 認証と承認を要求してください…14 8. 承認…14 9. 参照…14 9.1. 標準の参照…14 9.2. 有益な参照…15 付録A.例のOCSPメッセージ…16 A.1。 OCSP要求…16 A.2。 OCSP応答…16
Deacon & Hurst Standards Track [Page 2] RFC 5019 Lightweight OCSP Profile September 2007
OCSPが2007年9月に輪郭を描く執事とハースト標準化過程[2ページ]RFC5019ライト級
1. Introduction
1. 序論
The Online Certificate Status Protocol [OCSP] specifies a mechanism used to determine the status of digital certificates, in lieu of using Certificate Revocation Lists (CRLs). Since its definition in 1999, it has been deployed in a variety of environments and has proven to be a useful certificate status checking mechanism. (For brevity we refer to OCSP as being used to verify certificate status, but only the revocation status of a certificate is checked via this protocol.)
Online Certificate Statusプロトコル[OCSP]はデジタル証明書の状態を決定するのに使用されるメカニズムを指定します、Certificate Revocation Lists(CRLs)を使用することの代わりに。 1999との定義以来、それは、さまざまな環境で配布されて、役に立つ証明書状態照合メカニズムであると判明しています。 (簡潔さについて、私たちは証明書状態について確かめるのに使用されるとOCSPを呼びますが、証明書の取消し状態だけがこのプロトコルでチェックされます。)
To date, many OCSP deployments have been used to ensure timely and secure certificate status information for high-value electronic transactions or highly sensitive information, such as in the banking and financial environments. As such, the requirement for an OCSP responder to respond in "real time" (i.e., generating a new OCSP response for each OCSP request) has been important. In addition, these deployments have operated in environments where bandwidth usage is not an issue, and have run on client and server systems where processing power is not constrained.
これまで、多くのOCSP展開が高値の電子取引のためのタイムリーで安全な証明書状態情報か非常に機密の情報を確実にするのに使用されました、銀行業や金融環境などのように。 そういうものとして、「リアルタイムで」(すなわち、それぞれのOCSP要求のための新しいOCSP応答を生成する)でOCSP応答者が応じるという要件は重要です。 さらに、これらの展開は、帯域幅用法が問題でない環境で作動して、処理能力が強制的でないクライアントとサーバシステムで動きました。
As the use of PKI continues to grow and move into diverse environments, so does the need for a scalable and cost-effective certificate status mechanism. Although OCSP as currently defined and deployed meets the need of small to medium-sized PKIs that operate on powerful systems on wired networks, there is a limit as to how these OCSP deployments scale from both an efficiency and cost perspective. Mobile environments, where network bandwidth may be at a premium and client-side devices are constrained from a processing point of view, require the careful use of OCSP to minimize bandwidth usage and client-side processing complexity. [OCSPMP]
PKIの使用がさまざまの環境に成長して、移行し続けているとき、スケーラブルで費用対効果に優れた証明書状態メカニズムの必要性もそうします。 現在、定義されていて配布されるとしてのOCSPは有線ネットワークで強力なシステムを作動させる中型のPKIsに小さいことの需要を満たしますが、これらのOCSP展開がどう両方から効率をスケーリングして、見解かかるかに関して限界があります。 変わりやすい環境は、プレミアムにはネットワーク回線容量があるかもしれなくて、クライアントサイドデバイスが処理観点から抑制されるところでOCSPの慎重な使用が帯域幅用法とクライアントサイド処理の複雑さを最小にするのを必要とします。 [OCSPMP]
PKI continues to be deployed into environments where millions if not hundreds of millions of certificates have been issued. In many of these environments, an even larger number of users (also known as relying parties) have the need to ensure that the certificate they are relying upon has not been revoked. As such, it is important that OCSP is used in such a way that ensures the load on OCSP responders and the network infrastructure required to host those responders are kept to a minimum.
PKIは、数百万か何億通もの証明書が発行された環境に配布され続けています。 これらの環境の多くでは、より多くのさえユーザ(また、信用がパーティーへ行くので、知っています)が彼らが当てにしている証明書が取り消されていないのを保証する必要性を持っています。 そういうものとして、OCSPがOCSP応答者の上の負荷とそれらの応答者を接待するのに必要であるネットワークインフラが最小限に保たれるのを確実にするそのような方法で使用されるのは、重要です。
This document addresses the scalability issues inherent when using OCSP in PKI environments described above by defining a message profile and clarifying OCSP client and responder behavior that will permit:
上でメッセージプロフィールを定義して、OCSPクライアントをはっきりさせることによって説明されたPKI環境と可能にする応答者の振舞いにOCSPを使用するとき、このドキュメントは、スケーラビリティが問題であると固有の状態で扱います:
Deacon & Hurst Standards Track [Page 3] RFC 5019 Lightweight OCSP Profile September 2007
OCSPが2007年9月に輪郭を描く執事とハースト標準化過程[3ページ]RFC5019ライト級
1) OCSP response pre-production and distribution. 2) Reduced OCSP message size to lower bandwidth usage. 3) Response message caching both in the network and on the client.
1) OCSP応答試作と分配。 2) 帯域幅用法を下ろすためにOCSPメッセージサイズを減少させました。 3) ネットワークとクライアントの上の応答メッセージキャッシュ。
It is intended that the normative requirements defined in this profile will be adopted by OCSP clients and OCSP responders operating in very large-scale (high-volume) PKI environments or PKI environments that require a lightweight solution to minimize bandwidth and client-side processing power (or both), as described above. As OCSP does not have the means to signal responder capabilities within the protocol, clients needing to differentiate between OCSP responses produced by responders conformant with this profile and those that are not need to rely on out-of-band mechanisms to determine when a responder operates according to this profile and, as such, when the requirements of this profile apply. In the case where out-of-band mechanisms may not be available, this profile ensures that interoperability will still occur between a fully conformant OCSP 2560 client and a responder that is operating in a mode as described in this specification.
このプロフィールで定義された標準の要件が非常に大規模な(大容量)PKI環境か軽量のソリューションが帯域幅を最小にするのを必要とするPKI環境とクライアントサイド処理能力(ともに)で働いているOCSPクライアントとOCSP応答者によって採用されることを意図します、上で説明されるように。 OCSPにプロトコルの中で応答者能力に合図する手段がないとき、このプロフィールで応答者conformantによって起こされたOCSP応答を区別する必要があるクライアントとこのプロフィールとそういうものとしていつに従って応答者がいつこのプロフィールの要件を操作するかを決定するためにバンドの外でメカニズムを当てにする必要性でないそれらは適用されます。 バンドで出ているメカニズムが利用可能でないかもしれない、このプロフィールがその相互運用性を確実にする場合では、2560年のconformant OCSPクライアントとこの仕様で説明されるようにモードで働いている応答者はaの間にまだ完全に起こっているでしょう。
1.1. Requirements Terminology
1.1. 要件用語
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[RFC2119]で説明されるように本書では解釈されることであるべきですか?
2. OCSP Message Profile
2. OCSPメッセージプロフィール
This section defines a subset of OCSPRequest and OCSPResponse functionality as defined in [OCSP].
このセクションは[OCSP]の定義されるとしてのOCSPRequestとOCSPResponseの機能性の部分集合を定義します。
2.1. OCSP Request Profile
2.1. OCSP要求プロフィール
2.1.1. OCSPRequest Structure
2.1.1. OCSPRequest構造
OCSPRequests conformant to this profile MUST include only one Request in the OCSPRequest.RequestList structure.
このプロフィールへのOCSPRequests conformantはOCSPRequest.RequestList構造の1Requestだけを含まなければなりません。
Clients MUST use SHA1 as the hashing algorithm for the CertID.issuerNameHash and the CertID.issuerKeyHash values.
クライアントはCertID.issuerNameHashとCertID.issuerKeyHash値に論じ尽くすアルゴリズムとしてSHA1を使用しなければなりません。
Clients MUST NOT include the singleRequestExtensions structure.
クライアントはsingleRequestExtensions構造を入れてはいけません。
Clients SHOULD NOT include the requestExtensions structure. If a requestExtensions structure is included, this profile RECOMMENDS that it contain only the nonce extension (id-pkix-ocsp-nonce). See Section 4 for issues concerning the use of a nonce in high-volume OCSP environments.
クライアントSHOULD NOTはrequestExtensions構造を含んでいます。 構造はrequestExtensionsであるなら含まれていて、このプロフィールはRECOMMENDSです。それは一回だけの拡大(イドpkix-ocsp一回だけ)だけを含んでいます。 問題に関して大容量OCSP環境における一回だけの使用に関してセクション4を見てください。
Deacon & Hurst Standards Track [Page 4] RFC 5019 Lightweight OCSP Profile September 2007
OCSPが2007年9月に輪郭を描く執事とハースト標準化過程[4ページ]RFC5019ライト級
2.1.2. Signed OCSPRequests
2.1.2. OCSPRequestsであると署名されます。
Clients SHOULD NOT send signed OCSPRequests. Responders MAY ignore the signature on OCSPRequests.
SHOULD NOTが送るクライアントはOCSPRequestsに署名しました。 応答者はOCSPRequestsで署名を無視するかもしれません。
If the OCSPRequest is signed, the client SHALL specify its name in the OCSPRequest.requestorName field; otherwise, clients SHOULD NOT include the requestorName field in the OCSPRequest. OCSP servers MUST be prepared to receive unsigned OCSP requests that contain the requestorName field, but must realize that the provided value is not authenticated.
OCSPRequestが署名されるなら、クライアントSHALLはOCSPRequest.requestorName分野で名前を指定します。 さもなければ、クライアントSHOULD NOTはOCSPRequestのrequestorName分野を含んでいます。 OCSPサーバは、requestorName分野を含む未署名のOCSP要求を受け取るように準備しなければなりませんが、提供された値が認証されないとわからなければなりません。
2.2. OCSP Response Profile
2.2. OCSP応答プロフィール
2.2.1. OCSPResponse Structure
2.2.1. OCSPResponse構造
Responders MUST generate a BasicOCSPResponse as identified by the id-pkix-ocsp-basic OID. Clients MUST be able to parse and accept a BasicOCSPResponse. OCSPResponses conformant to this profile SHOULD include only one SingleResponse in the ResponseData.responses structure, but MAY include additional SingleResponse elements if necessary to improve response pre-generation performance or cache efficiency.
イドpkix-ocsp基礎OIDによって特定されるように応答者はBasicOCSPResponseを生成しなければなりません。 クライアントは、BasicOCSPResponseを分析して、受け入れることができなければなりません。 このプロフィールSHOULDへのOCSPResponses conformantはResponseData.responses構造の1SingleResponseだけを含んでいますが、必要なら、応答プレ世代性能かキャッシュ効率を高めるために追加SingleResponse要素を含むかもしれません。
The responder SHOULD NOT include responseExtensions. As specified in [OCSP], clients MUST ignore unrecognized non-critical responseExtensions in the response.
応答者SHOULD NOTはresponseExtensionsを含んでいます。 [OCSP]で指定されるように、クライアントは応答で認識されていない非臨界responseExtensionsを無視しなければなりません。
In the case where a responder does not have the ability to respond to an OCSP request containing a option not supported by the server, it SHOULD return the most complete response it can. For example, in the case where a responder only supports pre-produced responses and does not have the ability to respond to an OCSP request containing a nonce, it SHOULD return a response that does not include a nonce.
応答者にはサーバで後押しされていないオプションを含むOCSP要求に応じる能力がなくて、それがSHOULDである場合では、そうすることができる中で最も完全な応答を返してください。 例えば、応答者だけがあらかじめ生産された応答をサポートして、一回だけを含むOCSP要求に応じる能力を持たないで、それがSHOULDである場合では、一回だけを含んでいない応答を返してください。
Clients SHOULD attempt to process a response even if the response does not include a nonce. See Section 4 for details on validating responses that do not contain a nonce. See also Section 7 for relevant security considerations.
応答が一回だけを含まないでも、クライアントSHOULDは、応答を処理するのを試みます。 一回だけを含まない応答を有効にすることに関する詳細に関してセクション4を見てください。 また、関連セキュリティ問題に関してセクション7を見てください。
Responders that do not have the ability to respond to OCSP requests that contain an unsupported option such as a nonce MAY forward the request to an OCSP responder capable of doing so.
一回だけなどの非サポート・オプションを含むOCSP要求に応じる能力を持っていない応答者はそうすることができるOCSP応答者に要求を転送するかもしれません。
The responder MAY include the singleResponse.singleResponse extensions structure.
応答者はsingleResponse.singleResponse拡大構造を入れるかもしれません。
Deacon & Hurst Standards Track [Page 5] RFC 5019 Lightweight OCSP Profile September 2007
OCSPが2007年9月に輪郭を描く執事とハースト標準化過程[5ページ]RFC5019ライト級
2.2.2. Signed OCSPResponses
2.2.2. OCSPResponsesであると署名されます。
Clients MUST validate the signature on the returned OCSPResponse.
クライアントは返されたOCSPResponseで署名を有効にしなければなりません。
If the response is signed by a delegate of the issuing certification authority (CA), a valid responder certificate MUST be referenced in the BasicOCSPResponse.certs structure.
応答が権威(カリフォルニア)、有効な応答者証明書がそうしなければならない発行証明の代表によって署名されるなら、BasicOCSPResponse.certs構造で参照をつけられてください。
It is RECOMMENDED that the OCSP responder's certificate contain the id-pkix-ocsp-nocheck extension, as defined in [OCSP], to indicate to the client that it need not check the certificate's status. In addition, it is RECOMMENDED that neither an OCSP authorityInfoAccess (AIA) extension nor cRLDistributionPoints (CRLDP) extension be included in the OCSP responder's certificate. Accordingly, the responder's signing certificate SHOULD be relatively short-lived and renewed regularly.
OCSP応答者の証明書がイド-pkix-ocsp-nocheck拡張子を含んでいるのは、RECOMMENDEDです、証明書の状態をチェックする必要はないのをクライアントに示すために[OCSP]で定義されるように。 さらに、OCSP authorityInfoAccess(AIA)拡張子もcRLDistributionPoints(CRLDP)拡張子もOCSP応答者の証明書に含まれていないのは、RECOMMENDEDです。 それに従って、応答者の署名証明書SHOULDは比較的短命であり、定期的に更新しました。
Clients MUST be able to identify OCSP responder certificates using both the byName and byKey ResponseData.ResponderID choices. Responders SHOULD use byKey to further reduce the size of the response in scenarios where reducing bandwidth is an issue.
クライアントは、byNameとbyKey ResponseData.ResponderID選択の両方を使用することでOCSP応答者証明書を特定できなければなりません。 応答者SHOULDは、帯域幅を減少させるのが、問題であるシナリオの応答のサイズをさらに減少させるのにbyKeyを使用します。
2.2.3. OCSPResponseStatus Values
2.2.3. OCSPResponseStatus値
As long as the OCSP infrastructure has authoritative records for a particular certificate, an OCSPResponseStatus of "successful" will be returned. When access to authoritative records for a particular certificate is not available, the responder MUST return an OCSPResponseStatus of "unauthorized". As such, this profile extends the RFC 2560 [OCSP] definition of "unauthorized" as follows:
OCSPインフラストラクチャに特定の証明書のための正式の記録がある限り、「うまくいくこと」のOCSPResponseStatusを返すでしょう。 特定の証明書のための正式の記録へのアクセスが利用可能でないときに、応答者は「権限のないこと」のOCSPResponseStatusを返さなければなりません。 そういうものとして、このプロフィールは以下の「権限のないこと」のRFC2560[OCSP]定義を広げています:
The response "unauthorized" is returned in cases where the client
is not authorized to make this query to this server or the server
is not capable of responding authoritatively.
クライアントがこの質問をこのサーバにするのは権限を与えられない場合で応答「権限のなさ」を返すことができませんか、サーバが厳然と応じることができません。
For example, OCSP responders that do not have access to authoritative records for a requested certificate, such as those that generate and distribute OCSP responses in advance and thus do not have the ability to properly respond with a signed "successful" yet "unknown" response, will respond with an OCSPResponseStatus of "unauthorized". Also, in order to ensure the database of revocation information does not grow unbounded over time, the responder MAY remove the status records of expired certificates. Requests from clients for certificates whose record has been removed will result in an OCSPResponseStatus of "unauthorized".
例えば、あらかじめ、要求された証明書のためのOCSP応答を生成して、広げるものなどの正式の記録に近づく手段を持っていなくて、またその結果署名している「うまくいっています」が、「未知」の応答で適切に応じる能力を持っていないOCSP応答者が「権限のないこと」のOCSPResponseStatusと共に応じるでしょう。 また、取消し情報に関するデータベースが時間がたつにつれて限りなくならないのを確実にするために、応答者は満期の証明書に関する状態記録を取り除くかもしれません。 記録を取り除いてある証明書のためのクライアントからの要求は「権限のないこと」のOCSPResponseStatusをもたらすでしょう。
Security considerations regarding the use of unsigned responses are discussed in [OCSP].
[OCSP]で未署名の応答の使用に関するセキュリティ問題について議論します。
Deacon & Hurst Standards Track [Page 6] RFC 5019 Lightweight OCSP Profile September 2007
OCSPが2007年9月に輪郭を描く執事とハースト標準化過程[6ページ]RFC5019ライト級
2.2.4. thisUpdate, nextUpdate, and producedAt
2.2.4. thisUpdate、nextUpdate、およびproducedAt
When pre-producing OCSPResponse messages, the responder MUST set the thisUpdate, nextUpdate, and producedAt times as follows:
OCSPResponseメッセージをあらかじめ出すとき、応答者は以下のthisUpdate、nextUpdate、およびproducedAt回を設定しなければなりません:
thisUpdate The time at which the status being indicated is known
to be correct.
thisUpdate、示される状態が正しいのが知られている時。
nextUpdate The time at or before which newer information will be
available about the status of the certificate.
Responders MUST always include this value to aid in
response caching. See Section 6 for additional
information on caching.
利用可能であることにおけるどちらのより新しい情報が証明書の状態に関して利用可能になるかの前の時間のnextUpdate。 応答者は、応答キャッシュで支援するためにいつもこの値を入れなければなりません。 キャッシュの追加情報に関してセクション6を見てください。
producedAt The time at which the OCSP response was signed.
producedAt、OCSP応答が署名された時。
Note: In many cases the value of thisUpdate and producedAt will be the same.
以下に注意してください。 多くの場合、thisUpdateとproducedAtの値は同じになるでしょう。
For the purposes of this profile, ASN.1-encoded GeneralizedTime values such as thisUpdate, nextUpdate, and producedAt MUST be expressed Greenwich Mean Time (Zulu) and MUST include seconds (i.e., times are YYYYMMDDHHMMSSZ), even where the number of seconds is zero. GeneralizedTime values MUST NOT include fractional seconds.
このプロフィールの目的のために、thisUpdateや、nextUpdateや、producedAtなどのASN.1によってコード化されたGeneralizedTime値は、言い表されたグリニッジ標準時でなければならなく(ズールー族)、秒を含まなければなりません(すなわち、回はYYYYMMDDHHMMSSZです)、秒数がゼロでさえあるところで。 GeneralizedTime値は断片的な秒を含んではいけません。
3. Client Behavior
3. クライアントの振舞い
3.1. OCSP Responder Discovery
3.1. OCSP応答者発見
Clients MUST support the authorityInfoAccess extension as defined in [PKIX] and MUST recognize the id-ad-ocsp access method. This enables CAs to inform clients how they can contact the OCSP service.
クライアントは、[PKIX]で定義されるようにauthorityInfoAccessが拡大であるとサポートしなければならなくて、イド広告ocspアクセス法を認めなければなりません。 これは、CAsが、彼らがどうしたらOCSPサービスに連絡できるかをクライアントに知らせるのを可能にします。
In the case where a client is checking the status of a certificate that contains both an authorityInformationAccess (AIA) extension pointing to an OCSP responder and a cRLDistributionPoints extension pointing to a CRL, the client SHOULD attempt to contact the OCSP responder first. Clients MAY attempt to retrieve the CRL if no OCSPResponse is received from the responder after a locally configured timeout and number of retries.
クライアントがOCSP応答者を示すauthorityInformationAccess(AIA)拡張子とCRLを示すcRLDistributionPoints拡張子の両方を含む証明書の状態をチェックしている場合では、クライアントSHOULDは、最初にOCSP応答者に連絡するのを試みます。 局所的に構成されたタイムアウトと数の再試行の後に応答者からOCSPResponseを全く受け取らないなら、クライアントは、CRLを検索するのを試みるかもしれません。
3.2. Sending an OCSP Request
3.2. OCSP要求を送ります。
To avoid needless network traffic, applications MUST verify the signature of signed data before asking an OCSP client to check the status of certificates used to verify the data. If the signature is invalid or the application is not able to verify it, an OCSP check MUST NOT be requested.
不必要なネットワークトラフィックを避けるために、アプリケーションはデータについて確かめるのに使用される証明書の状態をチェックするようにOCSPクライアントに頼む前に、署名しているデータの署名について確かめなければなりません。 署名が無効であるか、またはアプリケーションがそれについて確かめることができないなら、OCSPチェックを要求してはいけません。
Deacon & Hurst Standards Track [Page 7] RFC 5019 Lightweight OCSP Profile September 2007
OCSPが2007年9月に輪郭を描く執事とハースト標準化過程[7ページ]RFC5019ライト級
Similarly, an application MUST validate the signature on certificates in a chain, before asking an OCSP client to check the status of the certificate. If the certificate signature is invalid or the application is not able to verify it, an OCSP check MUST NOT be requested. Clients SHOULD NOT make a request to check the status of expired certificates.
同様に、アプリケーションは証明書の上にチェーンで署名を有効にしなければなりません、証明書の状態をチェックするようにOCSPクライアントに頼む前に。 証明書署名が無効であるか、またはアプリケーションがそれについて確かめることができないなら、OCSPチェックを要求してはいけません。 クライアントSHOULD NOTは満期の証明書の状態をチェックするという要求をします。
4. Ensuring an OCSPResponse Is Fresh
4. OCSPResponseが確実に新鮮になるようにします。
In order to ensure that a client does not accept an out-of-date response that indicates a 'good' status when in fact there is a more up-to-date response that specifies the status of 'revoked', a client must ensure the responses they receive are fresh.
クライアントが'取り消されること'の状態を指定するより最新の応答が事実上あるとき'良い'状態を示す時代遅れな応答を受け入れないのを確実にするために、クライアントはそれらが受ける応答が確実に新鮮になるようにしなければなりません。
In general, two mechanisms are available to clients to ensure a response is fresh. The first uses nonces, and the second is based on time. In order for time-based mechanisms to work, both clients and responders MUST have access to an accurate source of time.
一般に、応答が確実に新鮮になるようにするクライアントにとって、2つのメカニズムが利用可能です。 1番目は一回だけを使用します、そして、2番目は定刻に基づいています。 時間ベースのメカニズムが扱うように、クライアントと応答者の両方が時間の正確な源に近づく手段を持たなければなりません。
Because this profile specifies that clients SHOULD NOT include a requestExtensions structure in OCSPRequests (see Section 2.1), clients MUST be able to determine OCSPResponse freshness based on an accurate source of time. Clients that opt to include a nonce in the request SHOULD NOT reject a corresponding OCSPResponse solely on the basis of the nonexistent expected nonce, but MUST fall back to validating the OCSPResponse based on time.
このプロフィールが、クライアントSHOULD NOTがOCSPRequestsのrequestExtensions構造を含んでいると指定するので(セクション2.1を見てください)、クライアントは時間の正確な源に基づくOCSPResponseの新しさを決定できなければなりません。 要求SHOULD NOTに一回だけを含むように選ぶクライアントは、唯一実在しない予想された一回だけに基づいて対応するOCSPResponseを拒絶しますが、定刻に基づいたOCSPResponseを有効にすることへ後ろへ下がらなければなりません。
Clients that do not include a nonce in the request MUST ignore any nonce that may be present in the response.
要求に一回だけを含んでいないクライアントはどんな応答で存在するかもしれない一回だけも無視しなければなりません。
Clients MUST check for the existence of the nextUpdate field and MUST ensure the current time, expressed in GMT time as described in Section 2.2.4, falls between the thisUpdate and nextUpdate times. If the nextUpdate field is absent, the client MUST reject the response.
クライアントは、nextUpdate分野の存在がないかどうかチェックしなければならなくて、グリニッジ標準時の時間セクション2.2.4で説明されるように言い表された現在の時間がthisUpdateとnextUpdate回の間に下がるのを保証しなければなりません。 nextUpdate分野が欠けるなら、クライアントは応答を拒絶しなければなりません。
If the nextUpdate field is present, the client MUST ensure that it is not earlier than the current time. If the current time on the client is later than the time specified in the nextUpdate field, the client MUST reject the response as stale. Clients MAY allow configuration of a small tolerance period for acceptance of responses after nextUpdate to handle minor clock differences relative to responders and caches. This tolerance period should be chosen based on the accuracy and precision of time synchronization technology available to the calling application environment. For example, Internet peers with low latency connections typically expect NTP time synchronization to keep them accurate within parts of a second; higher latency environments or where an NTP analogue is not available may have to be more liberal in their tolerance.
nextUpdate分野が存在しているなら、クライアントは確実に現在の時間より初期にならないようにしなければなりません。 クライアントの時間時間がnextUpdate分野で指定したより現在の後半であるなら、クライアントは、応答が聞き古したである拒絶しなければなりません。 nextUpdateの後の応答の承認が応答者とキャッシュに比例して小さい方の時計差を扱うように、クライアントは小さい寛容期間の構成を許すかもしれません。 この寛容期間は呼んでいるアプリケーション環境に利用可能な時間同期化技術の精度と精度に基づいて選ばれるべきです。 例えば、低遅延接続のインターネット同輩は、NTP時間同期化が1秒の部品の中で彼らを正確に保つと通常予想します。 それらの寛容では、より高い潜在環境かそれともNTPアナログがどこで入手できるかが、どんなより寛容であってはいけないかもしれません。
Deacon & Hurst Standards Track [Page 8] RFC 5019 Lightweight OCSP Profile September 2007
OCSPが2007年9月に輪郭を描く執事とハースト標準化過程[8ページ]RFC5019ライト級
See the security considerations in Section 7 for additional details on replay and man-in-the-middle attacks.
セクション7で再生と中央の男性攻撃に関する追加詳細に関してセキュリティ問題を見てください。
5. Transport Profile
5. 輸送プロフィール
The OCSP responder MUST support requests and responses over HTTP. When sending requests that are less than or equal to 255 bytes in total (after encoding) including the scheme and delimiters (http://), server name and base64-encoded OCSPRequest structure, clients MUST use the GET method (to enable OCSP response caching). OCSP requests larger than 255 bytes SHOULD be submitted using the POST method. In all cases, clients MUST follow the descriptions in A.1.1 of [OCSP] when constructing these messages.
OCSP応答者はHTTPの上の要求と応答をサポートしなければなりません。 体系、デリミタ(http://)、サーバー名、およびbase64によってコード化されたOCSPRequest構造を含む合計で(コード化の後に)255バイト以下である要求を送るとき、クライアントはGETメソッド(OCSP応答キャッシュを可能にする)を使用しなければなりません。 OCSPは、ポストメソッドを使用することで255バイトより大きいSHOULDを提出するよう要求します。 すべての場合では、これらのメッセージを構成するとき、クライアントは[OCSP]のA.1.1で記述の後をつけなければなりません。
When constructing a GET message, OCSP clients MUST base64 encode the OCSPRequest structure and append it to the URI specified in the AIA extension [PKIX]. Clients MUST NOT include CR or LF characters in the base64-encoded string. Clients MUST properly URL-encode the base64 encoded OCSPRequest. For example:
GETメッセージを構成するOCSPクライアントは追加しなければならないとき、base64がAIA拡張子[PKIX]で指定されたURIに、OCSPRequest構造をコード化して、それを追加します。 クライアントはbase64によってコード化されたストリングでCRかLFキャラクタを入れてはいけません。 クライアントは適切にそうしなければなりません。base64がコード化したURLエンコードOCSPRequest。 例えば:
http://ocsp.example.com/MEowSDBGMEQwQjAKBggqhkiG9w0CBQQQ7sp6GTKpL
2dAdeGaW267owQQqInESWQD0mGeBArSgv%2FBWQIQLJx%2Fg9xF8oySYzol80Mbpg
%3D%3D
http://ocsp.example.com/MEowSDBGMEQwQjAKBggqhkiG9w0CBQQQ7sp6GTKpL 2dAdeGaW267owQQqInESWQD0mGeBArSgv%2FBWQIQLJx%2Fg9xF8oySYzol80Mbpg、%3Dの%3D
In response to properly formatted OCSPRequests that are cachable (i.e., responses that contain a nextUpdate value), the responder will include the binary value of the DER encoding of the OCSPResponse preceded by the following HTTP [HTTP] headers.
キャッシュ可能である適切にフォーマットされたOCSPRequests(すなわち、nextUpdate値を含む応答)に対応して、応答者は以下のHTTP[HTTP]ヘッダーによって先行されたOCSPResponseのDERコード化の2進の値を入れるでしょう。
content-type: application/ocsp-response
content-length: <OCSP response length>
last-modified: <producedAt [HTTP] date>
ETag: "<strong validator>"
expires: <nextUpdate [HTTP] date>
cache-control: max-age=<n>, public, no-transform, must-revalidate
date: <current [HTTP] date>
content type: ocsp-応答アプリケーション/コンテンツの長さ: >が最後に変更した<OCSP応答の長さ: <producedAt[HTTP]は>ETagとデートします: 「<の強いvalidator>」は期限が切れます: <nextUpdate[HTTP]はキャッシュ制御と>をデートします: n>、公衆が変えない最大時代=<、必須-revalidate日付: <の現在[HTTP]の日付>。
See Section 6.2 for details on the use of these headers.
これらのヘッダーの使用に関する詳細に関してセクション6.2を見てください。
6. Caching Recommendations
6. 推薦をキャッシュします。
The ability to cache OCSP responses throughout the network is an important factor in high volume OCSP deployments. This section discusses the recommended caching behavior of OCSP clients and HTTP proxies and the steps that should be taken to minimize the number of times that OCSP clients "hit the wire". In addition, the concept of including OCSP responses in protocol exchanges (aka stapling or piggybacking), such as has been defined in TLS, is also discussed.
ネットワーク中でOCSP応答をキャッシュする能力は高いボリュームOCSP展開で重要な要素です。 このセクションはOCSPクライアントとHTTPプロキシのお勧めのキャッシュの振舞いとOCSPクライアントが「ワイヤを打った」という回の数を最小にするために取られるべきである方法を論じます。 さらに、プロトコルにOCSP応答を含む概念はTLSで定義されて、また、議論するように(別名のとめか便乗)を交換します。
Deacon & Hurst Standards Track [Page 9] RFC 5019 Lightweight OCSP Profile September 2007
OCSPが2007年9月に輪郭を描く執事とハースト標準化過程[9ページ]RFC5019ライト級
6.1. Caching at the Client
6.1. クライアントでのキャッシュ
To minimize bandwidth usage, clients MUST locally cache authoritative OCSP responses (i.e., a response with a signature that has been successfully validated and that indicate an OCSPResponseStatus of 'successful').
帯域幅用法を最小にするために、クライアントは局所的に正式のOCSP応答をキャッシュしなければなりません(すなわち、首尾よく有効にされた署名による応答とそれは'うまくいくこと'のOCSPResponseStatusを示します)。
Most OCSP clients will send OCSPRequests at or near the nextUpdate time (when a cached response expires). To avoid large spikes in responder load that might occur when many clients refresh cached responses for a popular certificate, responders MAY indicate when the client should fetch an updated OCSP response by using the cache- control:max-age directive. Clients SHOULD fetch the updated OCSP Response on or after the max-age time. To ensure that clients receive an updated OCSP response, OCSP responders MUST refresh the OCSP response before the max-age time.
ほとんどのOCSPクライアントが時間かnextUpdate時間の近く間、OCSPRequestsを送るでしょう(キャッシュされた応答が期限が切れると)。 多くのクライアントがリフレッシュするとき起こるかもしれない応答者負荷における大きいスパイクを避けるのはポピュラーな証明書のための応答をキャッシュしました、とクライアントがキャッシュコントロールを使用することによってアップデートされたOCSP応答をとって来るべきであるとき、応答者は示すかもしれません: 最大時代指示。 クライアントSHOULDは時か最大時代時の後にアップデートされたOCSP Responseをとって来ます。 クライアントがアップデートされたOCSP応答を受けるのを保証するために、OCSP応答者は最大時代時の前にOCSP応答をリフレッシュしなければなりません。
6.2. HTTP Proxies
6.2. HTTPプロキシ
The responder SHOULD set the HTTP headers of the OCSP response in such a way as to allow for the intelligent use of intermediate HTTP proxy servers. See [HTTP] for the full definition of these headers and the proper format of any date and time values.
応答者SHOULDはOCSP応答のHTTPヘッダを中間的HTTPプロキシサーバの知的な使用を考慮するほどそのような方法で設定します。 これらのヘッダーの完全な定義とどんな日付と時間的価値の適切な形式に関しても[HTTP]を見てください。
HTTP Header Description
=========== ====================================================
date The date and time at which the OCSP server generated
the HTTP response.
HTTPヘッダ記述=========== ==================================================== OCSPサーバがHTTPが応答であると生成した日時の日付を入れてください。
last-modified This value specifies the date and time at which the
OCSP responder last modified the response. This date
and time will be the same as the thisUpdate timestamp
in the request itself.
最後変更されたThis値はOCSP応答者が最後に応答を変更した日時を指定します。 この日時は要求自体におけるthisUpdateタイムスタンプと同じになるでしょう。
expires Specifies how long the response is considered fresh.
This date and time will be the same as the nextUpdate
timestamp in the OCSP response itself.
Specifiesを吐き出す、どれくらい長い間、応答は新鮮であると考えられますか? この日時はOCSP応答自体におけるnextUpdateタイムスタンプと同じになるでしょう。
ETag A string that identifies a particular version of the
associated data. This profile RECOMMENDS that the
ETag value be the ASCII HEX representation of the
SHA1 hash of the OCSPResponse structure.
関連データの特定のバージョンを特定するETag五弦。 ETagがASCII HEXがOCSPResponse構造のSHA1ハッシュの表現であったなら評価するこのプロフィールRECOMMENDS。
cache-control Contains a number of caching directives.
キャッシュ指示のキャッシュ制御Contains a番号。
* max-age=<n> -where n is a time value later than
thisUpdate but earlier than
nextUpdate.
* 最大時代が<n>と等しい、-、どこ、nはthisUpdateより遅い、しかし、nextUpdateより初期の時間的価値であるか。
Deacon & Hurst Standards Track [Page 10] RFC 5019 Lightweight OCSP Profile September 2007
OCSPが2007年9月に輪郭を描く執事とハースト標準化過程[10ページ]RFC5019ライト級
* public -makes normally uncachable response
cachable by both shared and nonshared
caches.
* 公衆は共有されて非共有の両方にされたキャッシュで通常非キャッシュ可能応答をキャッシュ可能にします。
* no-transform -specifies that a proxy cache cannot
change the type, length, or encoding
of the object content.
* どんな変換も、プロキシキャッシュがオブジェクト含有量のタイプ、長さ、またはコード化を変えることができないと指定しません。
* must-revalidate -prevents caches from intentionally
returning stale responses.
* 必須-revalidateは、キャッシュが故意に聞き古した応答を返すのを防ぎます。
OCSP responders MUST NOT include a "Pragma: no-cache", "Cache- Control: no-cache", or "Cache-Control: no-store" header in authoritative OCSP responses.
OCSP responders MUST NOT include a "Pragma: no-cache", "Cache- Control: no-cache", or "Cache-Control: no-store" header in authoritative OCSP responses.
OCSP responders SHOULD include one or more of these headers in non- authoritative OCSP responses.
OCSP responders SHOULD include one or more of these headers in non- authoritative OCSP responses.
For example, assume that an OCSP response has the following timestamp values:
For example, assume that an OCSP response has the following timestamp values:
thisUpdate = May 1, 2005 01:00:00 GMT
nextUpdate = May 3, 2005 01:00:00 GMT
productedAt = May 1, 2005 01:00:00 GMT
thisUpdate = May 1, 2005 01:00:00 GMT nextUpdate = May 3, 2005 01:00:00 GMT productedAt = May 1, 2005 01:00:00 GMT
and that an OCSP client requests the response on May 2, 2005 01:00:00 GMT. In this scenario, the HTTP response may look like this:
and that an OCSP client requests the response on May 2, 2005 01:00:00 GMT. In this scenario, the HTTP response may look like this:
content-type: application/ocsp-response
content-length: 1000
date: Fri, 02 May 2005 01:00:00 GMT
last-modified: Thu, 01 May 2005 01:00:00 GMT
ETag: "c66c0341abd7b9346321d5470fd0ec7cc4dae713"
expires: Sat, 03 May 2005 01:00:00 GMT
cache-control: max-age=86000,public,no-transform,must-revalidate
<...>
content-type: application/ocsp-response content-length: 1000 date: Fri, 02 May 2005 01:00:00 GMT last-modified: Thu, 01 May 2005 01:00:00 GMT ETag: "c66c0341abd7b9346321d5470fd0ec7cc4dae713" expires: Sat, 03 May 2005 01:00:00 GMT cache-control: max-age=86000,public,no-transform,must-revalidate <...>
OCSP clients MUST NOT include a no-cache header in OCSP request messages, unless the client encounters an expired response which may be a result of an intermediate proxy caching stale data. In this situation, clients SHOULD resend the request specifying that proxies should be bypassed by including an appropriate HTTP header in the request (i.e., Pragma: no-cache or Cache-Control: no-cache).
OCSP clients MUST NOT include a no-cache header in OCSP request messages, unless the client encounters an expired response which may be a result of an intermediate proxy caching stale data. In this situation, clients SHOULD resend the request specifying that proxies should be bypassed by including an appropriate HTTP header in the request (i.e., Pragma: no-cache or Cache-Control: no-cache).
Deacon & Hurst Standards Track [Page 11] RFC 5019 Lightweight OCSP Profile September 2007
Deacon & Hurst Standards Track [Page 11] RFC 5019 Lightweight OCSP Profile September 2007
6.3. Caching at Servers
6.3. Caching at Servers
In some scenarios, it is advantageous to include OCSP response information within the protocol being utilized between the client and server. Including OCSP responses in this manner has a few attractive effects.
In some scenarios, it is advantageous to include OCSP response information within the protocol being utilized between the client and server. Including OCSP responses in this manner has a few attractive effects.
First, it allows for the caching of OCSP responses on the server, thus lowering the number of hits to the OCSP responder.
First, it allows for the caching of OCSP responses on the server, thus lowering the number of hits to the OCSP responder.
Second, it enables certificate validation in the event the client is not connected to a network and thus eliminates the need for clients to establish a new HTTP session with the responder.
Second, it enables certificate validation in the event the client is not connected to a network and thus eliminates the need for clients to establish a new HTTP session with the responder.
Third, it reduces the number of round trips the client needs to make in order to complete a handshake.
Third, it reduces the number of round trips the client needs to make in order to complete a handshake.
Fourth, it simplifies the client-side OCSP implementation by enabling a situation where the client need only the ability to parse and recognize OCSP responses.
Fourth, it simplifies the client-side OCSP implementation by enabling a situation where the client need only the ability to parse and recognize OCSP responses.
This functionality has been specified as an extension to the TLS [TLS] protocol in Section 3.6 [TLSEXT], but can be applied to any client-server protocol.
This functionality has been specified as an extension to the TLS [TLS] protocol in Section 3.6 [TLSEXT], but can be applied to any client-server protocol.
This profile RECOMMENDS that both TLS clients and servers implement the certificate status request extension mechanism for TLS.
This profile RECOMMENDS that both TLS clients and servers implement the certificate status request extension mechanism for TLS.
Further information regarding caching issues can be obtained from RFC 3143 [RFC3143].
Further information regarding caching issues can be obtained from RFC 3143 [RFC3143].
7. Security Considerations
7. Security Considerations
The following considerations apply in addition to the security considerations addressed in Section 5 of [OCSP].
The following considerations apply in addition to the security considerations addressed in Section 5 of [OCSP].
7.1. Replay Attacks
7.1. Replay Attacks
Because the use of nonces in this profile is optional, there is a possibility that an out of date OCSP response could be replayed, thus causing a client to accept a good response when in fact there is a more up-to-date response that specifies the status of revoked. In order to mitigate this attack, clients MUST have access to an accurate source of time and ensure that the OCSP responses they receive are sufficiently fresh.
Because the use of nonces in this profile is optional, there is a possibility that an out of date OCSP response could be replayed, thus causing a client to accept a good response when in fact there is a more up-to-date response that specifies the status of revoked. In order to mitigate this attack, clients MUST have access to an accurate source of time and ensure that the OCSP responses they receive are sufficiently fresh.
Deacon & Hurst Standards Track [Page 12] RFC 5019 Lightweight OCSP Profile September 2007
Deacon & Hurst Standards Track [Page 12] RFC 5019 Lightweight OCSP Profile September 2007
Clients that do not have an accurate source of date and time are vulnerable to service disruption. For example, a client with a sufficiently fast clock may reject a fresh OCSP response. Similarly a client with a sufficiently slow clock may incorrectly accept expired valid responses for certificates that may in fact be revoked.
Clients that do not have an accurate source of date and time are vulnerable to service disruption. For example, a client with a sufficiently fast clock may reject a fresh OCSP response. Similarly a client with a sufficiently slow clock may incorrectly accept expired valid responses for certificates that may in fact be revoked.
Future versions of the OCSP protocol may provide a way for the client to know whether the server supports nonces or does not support nonces. If a client can determine that the server supports nonces, it MUST reject a reply that does not contain an expected nonce. Otherwise, clients that opt to include a nonce in the request SHOULD NOT reject a corresponding OCSPResponse solely on the basis of the nonexistent expected nonce, but MUST fall back to validating the OCSPResponse based on time.
Future versions of the OCSP protocol may provide a way for the client to know whether the server supports nonces or does not support nonces. If a client can determine that the server supports nonces, it MUST reject a reply that does not contain an expected nonce. Otherwise, clients that opt to include a nonce in the request SHOULD NOT reject a corresponding OCSPResponse solely on the basis of the nonexistent expected nonce, but MUST fall back to validating the OCSPResponse based on time.
7.2. Man-in-the-Middle Attacks
7.2. Man-in-the-Middle Attacks
To mitigate risk associated with this class of attack, the client must properly validate the signature on the response.
To mitigate risk associated with this class of attack, the client must properly validate the signature on the response.
The use of signed responses in OCSP serves to authenticate the identity of the OCSP responder and to verify that it is authorized to sign responses on the CA's behalf.
The use of signed responses in OCSP serves to authenticate the identity of the OCSP responder and to verify that it is authorized to sign responses on the CA's behalf.
Clients MUST ensure that they are communicating with an authorized responder by the rules described in [OCSP], Section 4.2.2.2.
Clients MUST ensure that they are communicating with an authorized responder by the rules described in [OCSP], Section 4.2.2.2.
7.3. Impersonation Attacks
7.3. Impersonation Attacks
The use of signed responses in OCSP serves to authenticate the identity of OCSP responder.
The use of signed responses in OCSP serves to authenticate the identity of OCSP responder.
As detailed in [OCSP], clients must properly validate the signature of the OCSP response and the signature on the OCSP response signer certificate to ensure an authorized responder created it.
As detailed in [OCSP], clients must properly validate the signature of the OCSP response and the signature on the OCSP response signer certificate to ensure an authorized responder created it.
7.4. Denial-of-Service Attacks
7.4. Denial-of-Service Attacks
OCSP responders should take measures to prevent or mitigate denial- of-service attacks. As this profile specifies the use of unsigned OCSPRequests, access to the responder may be implicitly given to everyone who can send a request to a responder, and thus the ability to mount a denial-of-service attack via a flood of requests may be greater. For example, a responder could limit the rate of incoming requests from a particular IP address if questionable behavior is detected.
OCSP responders should take measures to prevent or mitigate denial- of-service attacks. As this profile specifies the use of unsigned OCSPRequests, access to the responder may be implicitly given to everyone who can send a request to a responder, and thus the ability to mount a denial-of-service attack via a flood of requests may be greater. For example, a responder could limit the rate of incoming requests from a particular IP address if questionable behavior is detected.
Deacon & Hurst Standards Track [Page 13] RFC 5019 Lightweight OCSP Profile September 2007
Deacon & Hurst Standards Track [Page 13] RFC 5019 Lightweight OCSP Profile September 2007
7.5. Modification of HTTP Headers
7.5. Modification of HTTP Headers
Values included in HTTP headers, as described in Sections 5 and 6, are not cryptographically protected; they may be manipulated by an attacker. Clients SHOULD use these values for caching guidance only and ultimately SHOULD rely only on the values present in the signed OCSPResponse. Clients SHOULD NOT rely on cached responses beyond the nextUpdate time.
Values included in HTTP headers, as described in Sections 5 and 6, are not cryptographically protected; they may be manipulated by an attacker. Clients SHOULD use these values for caching guidance only and ultimately SHOULD rely only on the values present in the signed OCSPResponse. Clients SHOULD NOT rely on cached responses beyond the nextUpdate time.
7.6. Request Authentication and Authorization
7.6. Request Authentication and Authorization
The suggested use of unsigned requests in this environment removes an option that allows the responder to determine the authenticity of incoming request. Thus, access to the responder may be implicitly given to everyone who can send a request to a responder. Environments where explicit authorization to access the OCSP responder is necessary can utilize other mechanisms to authenticate requestors or restrict or meter service.
The suggested use of unsigned requests in this environment removes an option that allows the responder to determine the authenticity of incoming request. Thus, access to the responder may be implicitly given to everyone who can send a request to a responder. Environments where explicit authorization to access the OCSP responder is necessary can utilize other mechanisms to authenticate requestors or restrict or meter service.
8. Acknowledgements
8. Acknowledgements
The authors wish to thank Magnus Nystrom of RSA Security, Inc., Jagjeet Sondh of Vodafone Group R&D, and David Engberg of CoreStreet, Ltd. for their contributions to this specification.
The authors wish to thank Magnus Nystrom of RSA Security, Inc., Jagjeet Sondh of Vodafone Group R&D, and David Engberg of CoreStreet, Ltd. for their contributions to this specification.
9. References
9. References
9.1. Normative References
9.1. Normative References
[HTTP] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter,
L., Leach, P., and T. Berners-Lee, "Hypertext Transfer
Protocol -- HTTP/1.1", RFC 2616, June 1999.
[HTTP] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[OCSP] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C.
Adams, "X.509 Internet Public Key Infrastructure: Online
Certificate Status Protocol - OCSP", RFC 2560, June 1999.
[OCSP] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. Adams, "X.509 Internet Public Key Infrastructure: Online Certificate Status Protocol - OCSP", RFC 2560, June 1999.
[PKIX] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet
Public Key Infrastructure - Certificate and Certificate
Revocation List (CRL) Profile", RFC 3280, April 2002.
[PKIX] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet Public Key Infrastructure - Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, April 2002.
[TLS] Dierks, T. and E. Rescorla, "The Transport Layer Security
Protocol Version 1.1", RFC 4346, April 2006.
[TLS] Dierks, T. and E. Rescorla, "The Transport Layer Security Protocol Version 1.1", RFC 4346, April 2006.
Deacon & Hurst Standards Track [Page 14] RFC 5019 Lightweight OCSP Profile September 2007
Deacon & Hurst Standards Track [Page 14] RFC 5019 Lightweight OCSP Profile September 2007
[TLSEXT] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J.,
and T. Wright, "Transport Layer Security (TLS) Extensions",
RFC 4366, April 2006.
[TLSEXT] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., and T. Wright, "Transport Layer Security (TLS) Extensions", RFC 4366, April 2006.
9.2. Informative References
9.2. Informative References
[OCSPMP] "OCSP Mobile Profile V1.0", Open Mobile Alliance,
www.openmobilealliance.org.
[OCSPMP] "OCSP Mobile Profile V1.0", Open Mobile Alliance, www.openmobilealliance.org.
[RFC3143] Cooper, I. and J. Dilley, "Known HTTP Proxy/Caching
Problems", RFC 3143, June 2001.
[RFC3143] Cooper, I. and J. Dilley, "Known HTTP Proxy/Caching Problems", RFC 3143, June 2001.
Deacon & Hurst Standards Track [Page 15] RFC 5019 Lightweight OCSP Profile September 2007
Deacon & Hurst Standards Track [Page 15] RFC 5019 Lightweight OCSP Profile September 2007
Appendix A. Example OCSP Messages
Appendix A. Example OCSP Messages
A.1. OCSP Request
A.1. OCSP Request
SEQUENCE {
SEQUENCE {
SEQUENCE {
SEQUENCE {
SEQUENCE {
SEQUENCE {
OBJECT IDENTIFIER sha1 (1 3 14 3 2 26)
NULL
}
OCTET STRING
C0 FE 02 78 FC 99 18 88 91 B3 F2 12 E9 C7 E1 B2
1A B7 BF C0
OCTET STRING
0D FC 1D F0 A9 E0 F0 1C E7 F2 B2 13 17 7E 6F 8D
15 7C D4 F6
INTEGER
09 34 23 72 E2 3A EF 46 7C 83 2D 07 F8 DC 22 BA
}
}
}
}
}
SEQUENCE { SEQUENCE { SEQUENCE { SEQUENCE { SEQUENCE { SEQUENCE { OBJECT IDENTIFIER sha1 (1 3 14 3 2 26) NULL } OCTET STRING C0 FE 02 78 FC 99 18 88 91 B3 F2 12 E9 C7 E1 B2 1A B7 BF C0 OCTET STRING 0D FC 1D F0 A9 E0 F0 1C E7 F2 B2 13 17 7E 6F 8D 15 7C D4 F6 INTEGER 09 34 23 72 E2 3A EF 46 7C 83 2D 07 F8 DC 22 BA } } } } }
A.2. OCSP Response
A.2. OCSP Response
SEQUENCE {
ENUMERATED 0
[0] {
SEQUENCE {
OBJECT IDENTIFIER ocspBasic (1 3 6 1 5 5 7 48 1 1)
OCTET STRING, encapsulates {
SEQUENCE {
SEQUENCE {
[0] {
INTEGER 0
}
[1] {
SEQUENCE {
SET {
SEQUENCE {
OBJECT IDENTIFIER organizationName (2 5 4 10)
PrintableString 'Example Trust Network'
}
}
SEQUENCE { ENUMERATED 0 [0] { SEQUENCE { OBJECT IDENTIFIER ocspBasic (1 3 6 1 5 5 7 48 1 1) OCTET STRING, encapsulates { SEQUENCE { SEQUENCE { [0] { INTEGER 0 } [1] { SEQUENCE { SET { SEQUENCE { OBJECT IDENTIFIER organizationName (2 5 4 10) PrintableString 'Example Trust Network' } }
Deacon & Hurst Standards Track [Page 16] RFC 5019 Lightweight OCSP Profile September 2007
Deacon & Hurst Standards Track [Page 16] RFC 5019 Lightweight OCSP Profile September 2007
SET {
SEQUENCE {
OBJECT IDENTIFIER
organizationalUnitName (2 5 4 11)
PrintableString 'Example, Inc.'
}
}
SET {
SEQUENCE {
OBJECT IDENTIFIER
organizationalUnitName (2 5 4 11)
PrintableString
'Example OCSP Responder'
}
}
}
}
GeneralizedTime 07/11/2005 23:52:44 GMT
SEQUENCE {
SEQUENCE {
SEQUENCE {
SEQUENCE {
OBJECT IDENTIFIER sha1 (1 3 14 3 2 26)
NULL
}
OCTET STRING
C0 FE 02 78 FC 99 18 88 91 B3 F2 12 E9 C7 E1 B2
1A B7 BF C0
OCTET STRING
0D FC 1D F0 A9 E0 F0 1C E7 F2 B2 13 17 7E 6F 8D
15 7C D4 F6
INTEGER
09 34 23 72 E2 3A EF 46 7C 83 2D 07 F8 DC 22 BA
}
[0]
Error: Object has zero length.
GeneralizedTime 07/11/2005 23:52:44 GMT
[0] {
GeneralizedTime 14/11/2005 23:52:44 GMT
}
}
}
}
SEQUENCE {
OBJECT IDENTIFIER
sha1withRSAEncryption (1 2 840 113549 1 1 5)
NULL
}
SET { SEQUENCE { OBJECT IDENTIFIER organizationalUnitName (2 5 4 11) PrintableString 'Example, Inc.' } } SET { SEQUENCE { OBJECT IDENTIFIER organizationalUnitName (2 5 4 11) PrintableString 'Example OCSP Responder' } } } } GeneralizedTime 07/11/2005 23:52:44 GMT SEQUENCE { SEQUENCE { SEQUENCE { SEQUENCE { OBJECT IDENTIFIER sha1 (1 3 14 3 2 26) NULL } OCTET STRING C0 FE 02 78 FC 99 18 88 91 B3 F2 12 E9 C7 E1 B2 1A B7 BF C0 OCTET STRING 0D FC 1D F0 A9 E0 F0 1C E7 F2 B2 13 17 7E 6F 8D 15 7C D4 F6 INTEGER 09 34 23 72 E2 3A EF 46 7C 83 2D 07 F8 DC 22 BA } [0] Error: Object has zero length. GeneralizedTime 07/11/2005 23:52:44 GMT [0] { GeneralizedTime 14/11/2005 23:52:44 GMT } } } } SEQUENCE { OBJECT IDENTIFIER sha1withRSAEncryption (1 2 840 113549 1 1 5) NULL }
Deacon & Hurst Standards Track [Page 17] RFC 5019 Lightweight OCSP Profile September 2007
Deacon & Hurst Standards Track [Page 17] RFC 5019 Lightweight OCSP Profile September 2007
BIT STRING
0E 9F F0 52 B1 A7 42 B8 6E C1 35 E1 0E D5 A9 E2
F5 C5 3C 16 B1 A3 A7 A2 03 8A 2B 4D 2C F1 B4 98
8E 19 DB BA 1E 1E 72 FF 32 F4 44 E0 B2 77 1C D7
3C 9E 78 F3 D1 82 68 86 63 12 7F A4 6F F0 4D 84
EA F8 E2 F7 5D E3 48 44 57 28 80 C7 57 3C FE E1
42 0E 5E 17 FC 60 D8 05 D9 EF E2 53 E7 AB 7F 3A
A8 84 AA 5E 46 5B E7 B8 1F C6 B1 35 AD FF D1 CC
BA 58 7D E8 29 60 79 F7 41 02 EA E0 82 0E A6 30
[0] {
SEQUENCE {
SEQUENCE {
SEQUENCE {
[0] {
INTEGER 2
}
INTEGER
49 4A 02 37 1B 1E 70 67 41 6C 9F 06 2F D8 FE DA
SEQUENCE {
OBJECT IDENTIFIER
sha1withRSAEncryption (1 2 840 113549 1 1 5)
NULL
}
SEQUENCE {
SET {
SEQUENCE {
OBJECT IDENTIFIER
organizationName (2 5 4 10)
PrintableString 'Example Trust Network'
}
}
SET {
SEQUENCE {
OBJECT IDENTIFIER
organizationalUnitName (2 5 4 11)
PrintableString 'Example, Inc.'
}
}
SET {
SEQUENCE {
OBJECT IDENTIFIER
organizationalUnitName (2 5 4 11)
PrintableString
'Example CA'
}
}
}
SEQUENCE {
BIT STRING 0E 9F F0 52 B1 A7 42 B8 6E C1 35 E1 0E D5 A9 E2 F5 C5 3C 16 B1 A3 A7 A2 03 8A 2B 4D 2C F1 B4 98 8E 19 DB BA 1E 1E 72 FF 32 F4 44 E0 B2 77 1C D7 3C 9E 78 F3 D1 82 68 86 63 12 7F A4 6F F0 4D 84 EA F8 E2 F7 5D E3 48 44 57 28 80 C7 57 3C FE E1 42 0E 5E 17 FC 60 D8 05 D9 EF E2 53 E7 AB 7F 3A A8 84 AA 5E 46 5B E7 B8 1F C6 B1 35 AD FF D1 CC BA 58 7D E8 29 60 79 F7 41 02 EA E0 82 0E A6 30 [0] { SEQUENCE { SEQUENCE { SEQUENCE { [0] { INTEGER 2 } INTEGER 49 4A 02 37 1B 1E 70 67 41 6C 9F 06 2F D8 FE DA SEQUENCE { OBJECT IDENTIFIER sha1withRSAEncryption (1 2 840 113549 1 1 5) NULL } SEQUENCE { SET { SEQUENCE { OBJECT IDENTIFIER organizationName (2 5 4 10) PrintableString 'Example Trust Network' } } SET { SEQUENCE { OBJECT IDENTIFIER organizationalUnitName (2 5 4 11) PrintableString 'Example, Inc.' } } SET { SEQUENCE { OBJECT IDENTIFIER organizationalUnitName (2 5 4 11) PrintableString 'Example CA' } } } SEQUENCE {
Deacon & Hurst Standards Track [Page 18] RFC 5019 Lightweight OCSP Profile September 2007
Deacon & Hurst Standards Track [Page 18] RFC 5019 Lightweight OCSP Profile September 2007
UTCTime 08/10/2005 00:00:00 GMT
UTCTime 06/01/2006 23:59:59 GMT
}
SEQUENCE {
SET {
SEQUENCE {
OBJECT IDENTIFIER
organizationName (2 5 4 10)
PrintableString 'Example Trust Network'
}
}
SET {
SEQUENCE {
OBJECT IDENTIFIER
organizationalUnitName (2 5 4 11)
PrintableString 'Example, Inc.'
}
}
SET {
SEQUENCE {
OBJECT IDENTIFIER
organizationalUnitName (2 5 4 11)
PrintableString
'Example OCSP Responder'
}
}
}
SEQUENCE {
SEQUENCE {
OBJECT IDENTIFIER
rsaEncryption (1 2 840 113549 1 1 1)
NULL
}
BIT STRING, encapsulates {
SEQUENCE {
INTEGER
00 AF C9 7A F5 09 CA D1 08 8C 82 6D AC D9 63 4D
D2 64 17 79 CB 1E 1C 1C 0C 6E 28 56 B5 16 4A 4A
00 1A C1 B0 74 D7 B4 55 9D 2A 99 1F 0E 4A E3 5F
81 AF 8D 07 23 C3 30 28 61 3F B0 C8 1D 4E A8 9C
A6 32 B4 D2 63 EC F7 C1 55 7A 73 2A 51 99 00 D5
0F B2 4E 11 5B 83 55 83 4C 0E DD 12 0C BD 7E 41
04 3F 5F D9 2A 65 88 3C 2A BA 20 76 1D 1F 59 3E
D1 85 F7 4B E2 81 50 9C 78 96 1B 37 73 12 1A D2
[ Another 1 bytes skipped ]
INTEGER 65537
}
}
UTCTime 08/10/2005 00:00:00 GMT UTCTime 06/01/2006 23:59:59 GMT } SEQUENCE { SET { SEQUENCE { OBJECT IDENTIFIER organizationName (2 5 4 10) PrintableString 'Example Trust Network' } } SET { SEQUENCE { OBJECT IDENTIFIER organizationalUnitName (2 5 4 11) PrintableString 'Example, Inc.' } } SET { SEQUENCE { OBJECT IDENTIFIER organizationalUnitName (2 5 4 11) PrintableString 'Example OCSP Responder' } } } SEQUENCE { SEQUENCE { OBJECT IDENTIFIER rsaEncryption (1 2 840 113549 1 1 1) NULL } BIT STRING, encapsulates { SEQUENCE { INTEGER 00 AF C9 7A F5 09 CA D1 08 8C 82 6D AC D9 63 4D D2 64 17 79 CB 1E 1C 1C 0C 6E 28 56 B5 16 4A 4A 00 1A C1 B0 74 D7 B4 55 9D 2A 99 1F 0E 4A E3 5F 81 AF 8D 07 23 C3 30 28 61 3F B0 C8 1D 4E A8 9C A6 32 B4 D2 63 EC F7 C1 55 7A 73 2A 51 99 00 D5 0F B2 4E 11 5B 83 55 83 4C 0E DD 12 0C BD 7E 41 04 3F 5F D9 2A 65 88 3C 2A BA 20 76 1D 1F 59 3E D1 85 F7 4B E2 81 50 9C 78 96 1B 37 73 12 1A D2 [ Another 1 bytes skipped ] INTEGER 65537 } }
Deacon & Hurst Standards Track [Page 19] RFC 5019 Lightweight OCSP Profile September 2007
Deacon & Hurst Standards Track [Page 19] RFC 5019 Lightweight OCSP Profile September 2007
}
[3] {
SEQUENCE {
SEQUENCE {
OBJECT IDENTIFIER
basicConstraints (2 5 29 19)
OCTET STRING, encapsulates {
SEQUENCE {}
}
}
SEQUENCE {
OBJECT IDENTIFIER extKeyUsage (2 5 29 37)
OCTET STRING, encapsulates {
SEQUENCE {
OBJECT IDENTIFIER
ocspSigning (1 3 6 1 5 5 7 3 9)
}
}
}
SEQUENCE {
OBJECT IDENTIFIER keyUsage (2 5 29 15)
OCTET STRING, encapsulates {
BIT STRING 7 unused bits
'1'B (bit 0)
}
}
SEQUENCE {
OBJECT IDENTIFIER
ocspNoCheck (1 3 6 1 5 5 7 48 1 5)
OCTET STRING, encapsulates {
NULL
}
}
}
}
}
SEQUENCE {
OBJECT IDENTIFIER
sha1withRSAEncryption (1 2 840 113549 1 1 5)
NULL
}
BIT STRING
3A 68 5F 6A F8 87 36 4A E2 22 46 5C C8 F5 0E CE
1A FA F2 25 E1 51 AB 37 BE D4 10 C8 15 93 39 73
C8 59 0F F0 39 67 29 C2 60 20 F7 3F FE A0 37 AB
80 0B F9 3D 38 D4 48 67 E4 FA FD 4E 12 BF 55 29
14 E9 CC CB DD 13 82 E9 C4 4D D3 85 33 C1 35 E5
8F 38 01 A7 F7 FD EB CD DE F2 F7 85 86 AE E3 1B
} [3] { SEQUENCE { SEQUENCE { OBJECT IDENTIFIER basicConstraints (2 5 29 19) OCTET STRING, encapsulates { SEQUENCE {} } } SEQUENCE { OBJECT IDENTIFIER extKeyUsage (2 5 29 37) OCTET STRING, encapsulates { SEQUENCE { OBJECT IDENTIFIER ocspSigning (1 3 6 1 5 5 7 3 9) } } } SEQUENCE { OBJECT IDENTIFIER keyUsage (2 5 29 15) OCTET STRING, encapsulates { BIT STRING 7 unused bits '1'B (bit 0) } } SEQUENCE { OBJECT IDENTIFIER ocspNoCheck (1 3 6 1 5 5 7 48 1 5) OCTET STRING, encapsulates { NULL } } } } } SEQUENCE { OBJECT IDENTIFIER sha1withRSAEncryption (1 2 840 113549 1 1 5) NULL } BIT STRING 3A 68 5F 6A F8 87 36 4A E2 22 46 5C C8 F5 0E CE 1A FA F2 25 E1 51 AB 37 BE D4 10 C8 15 93 39 73 C8 59 0F F0 39 67 29 C2 60 20 F7 3F FE A0 37 AB 80 0B F9 3D 38 D4 48 67 E4 FA FD 4E 12 BF 55 29 14 E9 CC CB DD 13 82 E9 C4 4D D3 85 33 C1 35 E5 8F 38 01 A7 F7 FD EB CD DE F2 F7 85 86 AE E3 1B
Deacon & Hurst Standards Track [Page 20] RFC 5019 Lightweight OCSP Profile September 2007
Deacon & Hurst Standards Track [Page 20] RFC 5019 Lightweight OCSP Profile September 2007
9C FD 1D 07 E5 28 F2 A0 5E AC BF 9E 0B 34 A1 B4
3A A9 0E C5 8A 34 3F 65 D3 10 63 A4 5E 21 71 5A
}
}
}
}
}
}
}
}
9C FD 1D 07 E5 28 F2 A0 5E AC BF 9E 0B 34 A1 B4 3A A9 0E C5 8A 34 3F 65 D3 10 63 A4 5E 21 71 5A } } } } } } } }
Authors' Addresses
Authors' Addresses
Alex Deacon VeriSign, Inc. 487 E. Middlefield Road Mountain View, CA 94043 USA
Alex Deacon VeriSign, Inc. 487 E. Middlefield Road Mountain View, CA 94043 USA
Phone: 1-650-426-3478 EMail: alex@verisign.com
Phone: 1-650-426-3478 EMail: alex@verisign.com
Ryan Hurst Microsoft One Microsoft Way Redmond, WA 98052 USA
Ryan Hurst Microsoft One Microsoft Way Redmond, WA 98052 USA
Phone: 1-425-707-8979 EMail: rmh@microsoft.com
Phone: 1-425-707-8979 EMail: rmh@microsoft.com
Deacon & Hurst Standards Track [Page 21] RFC 5019 Lightweight OCSP Profile September 2007
Deacon & Hurst Standards Track [Page 21] RFC 5019 Lightweight OCSP Profile September 2007
Full Copyright Statement
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
Intellectual Property
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
Deacon & Hurst Standards Track [Page 22]
Deacon & Hurst Standards Track [Page 22]
一覧
スポンサーリンク
