Network Working Group S. Boeyen
Request for Comments: 4386 Entrust Inc.
Category: Experimental P. Hallam-Baker
VeriSign Inc.
February 2006
Internet X.509 Public Key Infrastructure
Repository Locator Service
Status of This Memo
このメモのステータス
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。それはどんな種類のインターネット標準を指定しません。改善のための議論や提案が要求されています。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2006).
著作権（C）インターネット協会（2006）。
Abstract
抽象
This document defines a Public Key Infrastructure (PKI) repository locator service. The service makes use of DNS SRV records defined in accordance with RFC 2782. The service enables certificate-using systems to locate PKI repositories.
この文書は、公開鍵基盤（PKI）倉庫ロケータサービスを定義します。サービスは、RFC 2782.に従って定義されたDNS SRVレコードを利用したサービスは、PKIリポジトリを検索するために証明書を使用するシステムを可能にします。
Table of Contents
目次
1. Overview ........................................................2
1.1. Conventions Used in This Document ..........................2
2. SRV RR Definition ...............................................2
2.1. Assignment of New Protocol Prefixes ........................3
2.2. Use of Multiple Repositories ...............................3
2.3. SRV RR Example .............................................3
3. Security Considerations .........................................4
4. IANA Considerations .............................................4
5. Informative References ..........................................4
A number of RFCs (including [RFC2559], [RFC2560], and [RFC2585]) have specified operational protocols for retrieval of PKI data, including public-key certificates and revocation information, from PKI repositories. These RFCs assume that a certificate-using system has the information necessary to identify, locate, and connect to the PKI repository with a specific protocol. Although some tools are available in protocol-specific environments for this purpose, such as knowledge references in directory systems, these are restricted for use with a single protocol and do not share a common means of publication. This document provides a solution to this problem through the use of Service Record (SRV) Resource Records (RRs) in DNS. This solution is expected to be particularly useful in environments where only a domain name is available. In other situations (e.g., where a certificate is available that contains the required information), such a DNS lookup is not needed.
（[RFC2559]、[RFC2560]及び[RFC2585]を含む）RFCの数は、PKIリポジトリから、公開鍵証明書の失効情報を含む、PKIデータの検索のための動作プロトコルが指定されています。これらのRFCは、証明書に使用するシステムは、特定探し、特定のプロトコルとPKIリポジトリに接続するために必要な情報を持っていると仮定する。いくつかのツールは、そのようなディレクトリシステムにおけるナレッジ参照として、この目的のためのプロトコル固有の環境で利用可能であるが、これらは、単一のプロトコルで使用するために制限され、出版物の一般的な手段を共有していません。この文書では、DNSでサービスレコード（SRV）リソースレコード（RR）を使用して、この問題に対する解決策を提供します。このソリューションは、ドメイン名のみが利用できる環境では特に有用であると期待されています。 （証明書が必要な情報が含まれて入手可能である例えば、）他の状況では、そのようなDNSルックアップは必要ありません。
[RFC2782] defines a DNS RR for specifying the location of services (SRV). This document defines SRV records for a PKI repository locator service to enable PKI clients to obtain the necessary information to connect to a domain's PKI repository, including information about each protocol that is supported by that domain for access to its repository. This document includes the definition of an SRV RR format for this service and an example of its potential use in an email environment.
[RFC2782]は、サービス（SRV）の位置を特定するためのDNS RRを定義します。この文書では、そのリポジトリへのアクセスのためにそのドメインによってサポートされている各プロトコルに関する情報を含め、ドメインのPKIリポジトリに接続するために必要な情報を得るために、PKIクライアントを有効にするには、PKI倉庫ロケータサービスのSRVレコードを定義します。この文書では、このサービスのSRV RR形式と電子メール環境におけるその潜在的な使用の例の定義を含んでいます。
The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document (in uppercase, as shown) are to be interpreted as described in [RFC2119].
キーワード "MUST"、 "MUST NOT"、 "REQUIRED"、（図示のように、大文字で）この文書では、 "SHOULD"、 "推奨" "NOT SHOULD"、 "MAY"、 "OPTIONAL" は可能になっています[RFC2119]で説明されるように解釈されます。
In examples, "C:" and "S:" indicate lines sent by the client and server, respectively.
実施例において、「C：」および「S：」は、それぞれ、クライアントとサーバによって送信されたラインを示します。
The format of the SRV RR, whose DNS type code is 33, is:
DNSタイプコードのSRV RRの形式は、33です。
_Service._Proto.Name TTL Class SRV Priority Weight Port Target
_Service._Proto.Name TTLクラスSRV優先重ポートターゲット
For the PKI repository locator service, this document uses the symbolic name "PKIXREP". Note that when used in an SRV RR, this name MUST be prepended with an "_" character.
PKIリポジトリロケータサービスについては、このドキュメントでは、シンボル名「PKIXREP」を使用しています。 SRVのRRで使用する場合、この名前は、「_」文字で先頭に追加しなければならないことに注意してください。
The protocols that can be included in PKIXREP SRV RRs are:
PKIXREP SRV RRの中に含ませることができるプロトコルは、次のとおりです。
Protocol SRV Prefix
プロトコルSRVプレフィックス
LDAP _LDAP HTTP _HTTP OCSP _OCSP
LDAP _ldap HTTP _HTTP OCSP _OCSP
Protocol prefix assignments for new PKIX repository protocols SHOULD be defined in the document that specifies the protocol.
新しいPKIXリポジトリプロトコルのプロトコルプレフィックスの割り当ては、プロトコルを指定したドキュメントで定義する必要があります。
The existence of multiple repositories MAY be determined by making separate DNS queries for each of the protocols supported by the client.
複数のリポジトリの存在は、クライアントがサポートしているプロトコルごとに別々のDNSクエリを行うことによって決定することができます。
If this approach is found to be unacceptably inefficient due to a proliferation of repository protocols at a future date, the service discovery protocol could be extended to allow the repository to advertise the protocols supported.
このアプローチは、将来の日付に起因するリポジトリプロトコルの増殖を許容できないほど非効率的であることが判明した場合、サービス発見プロトコルは、リポジトリがサポートされているプロトコルを宣伝できるように拡張することができます。
This example uses the fictional domain "example.com" as an aid in understanding the use of SRV records by a certificate-using system.
この例では、証明書を使用してシステムにより、SRVレコードの使用を理解する上で助けとして架空のドメイン「example.com」を使用しています。
Assume that Alice is an email client that needs a certificate for a recipient. Alice's client system supports LDAP for certificate retrieval. Assume the message recipient is Bob and that Bob's email address is bob@example.com. Assume that example.test maintains a "border directory" PKI repository and that Bob's certificate is available from that directory, "border.example.com", via LDAP.
アリスは、受信者の証明書を必要とする電子メールクライアントであると仮定する。アリスのクライアントシステムは、証明書取得のためのLDAPをサポートしています。メッセージの受信者がボブであるとボブのメールアドレスがbob@example.comであると仮定する。 LDAPを経由して、「border.example.com」、そのexample.testは「国境ディレクトリ」PKIリポジトリを維持し、ボブの証明書は、そのディレクトリから利用可能であることを前提としています。
Alice's client system retrieves, via DNS, the SRV record for _PKIXREP._LDAP.example.com.
アリスのクライアントシステムはDNS、_PKIXREP._LDAP.example.comのためのSRVレコードを経由して、取得します。
- The QNAME of the DNS query is _PKIXREP._LDAP.example.com.
- DNSクエリのQNAMEは_PKIXREP._LDAP.example.comです。
- The QCLASS of the DNS query is IN.
- DNSクエリのQCLASSはINです。
- The QTYPE of the DNS query is SRV.
- DNSクエリのQTYPEはSRVです。
The result SHOULD include the host address for example.com's border directory system.
結果は、example.comの国境ディレクトリシステムのホストアドレスを含むべきです。
Note that if example.com operated its service on a number of hosts, more than one SRV RR would be returned. In this case, RFC 2782 defines the procedure to be followed in determining which of these should be accessed first.
example.comは、ホストの数にそのサービスを運営している場合、複数のSRV RRが返されることに注意してください。この場合には、RFC 2782が最初にアクセスされるべきこれらのかを決定に従うべき手順を規定します。
Security issues regarding PKI repositories themselves are outside the scope of this document. For LDAP repositories, for example, specific security considerations are addressed in RFC 2559.
PKIリポジトリに関するセキュリティ上の問題自体は、このドキュメントの範囲外です。 LDAPリポジトリの場合は、例えば、特定のセキュリティ上の考慮事項は、RFC 2559で対処されています。
Security issues with respect to the use of SRV records in general are addressed in RFC 2782, and these issues apply to the use of SRV records in the context of the PKIXREP service defined here.
一般的に、SRVレコードの使用に関するセキュリティ上の問題は、RFC 2782で対処されており、これらの問題は、ここで定義されPKIXREPサービスのコンテキストでSRVレコードの使用に適用されます。
This document reserves the use of "_PKIXREP" service label. Since this relates to a service that may pass messages over a number of different message transports, each message must be associated with a specific transport.
この文書では、「_PKIXREP」サービスラベルの使用を留保します。これは、異なるメッセージトランスポートの数を介してメッセージを渡すことができるサービスに関係するので、各メッセージは、特定のトランスポートに関連付けられなければなりません。
In order to ensure that the association between "_PKIXREP" and their respective underlying services is deterministic, the IANA has created a new registry: PKIX SRV Protocol Labels.
PKIX SRVプロトコルラベル：「_PKIXREP」とそれぞれの基本的なサービス間の関連付けが決定的であることを確実にするために、IANAは、新しいレジストリを作成しました。
For this registry, an entry shall consist of a label name and a pointer to a specification describing how the protocol named in the label uses SRV. Specifications should conform to the requirements listed in [RFC2434] for "specification required".
このレジストリのために、エントリはラベル名とラベルで指定されたプロトコルはSRVを使用する方法を記述した仕様へのポインタで構成されなければなりません。仕様は、「要求仕様」のために[RFC2434]に記載されている要件に適合しなければなりません。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[RFC2434] Narten氏、T.とH. Alvestrand、 "RFCsにIANA問題部に書くためのガイドライン"、BCP 26、RFC 2434、1998年10月。
[RFC2559] Boeyen, S., Howes, T., and P. Richard, "Internet X.509 Public Key Infrastructure Operational Protocols - LDAPv2", RFC 2559, April 1999.
[RFC2559] Boeyen、S.、ハウズ、T.、およびP.リチャード、 "インターネットX.509公開鍵基盤運用プロトコル - のLDAPv2"、RFC 2559、1999年4月。
[RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. Adams, "X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP", RFC 2560, June 1999.
[RFC2560]マイヤーズ、M.、Ankney、R.、Malpani、A.、Galperin、S.、およびC.アダムス、 "X.509のインターネット公開鍵暗号基盤のオンライン証明書状態プロトコル - OCSP"、RFC 2560、1999年6月。
[RFC2585] Housley, R. and P. Hoffman, "Internet X.509 Public Key Infrastructure Operational Protocols: FTP and HTTP", RFC 2585, May 1999.
[RFC2585] Housley氏、R.とP.ホフマン、 "インターネットX.509公開鍵基盤運用プロトコル：FTPやHTTP"、RFC 2585、1999年5月。
[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000.
[RFC2782] Gulbrandsenの、A.、いるVixie、P.、およびL. Esibov、 "サービスの場所を特定するためのDNS RR（DNSのSRV）"、RFC 2782、2000年2月。
Authors' Addresses
著者のアドレス
Sharon Boeyen Entrust 1000 Innovation Drive Ottawa, Ontario Canada K2K 3E7
シャロンBoeyenエントラスト1000年イノベーションドライブオタワ、オンタリオカナダK2K 3E7
EMail: sharon.boeyen@entrust.com
メールアドレス：sharon.boeyen@entrust.com
Phillip M. Hallam-Baker VeriSign Inc. 401 Edgewater Place, Suite 280 Wakefield MA 01880
フィリップM.ハラム - ベイカーベリサイン株式会社401エッジウォータープレイス、スイート280ウェイクフィールドMA 01880
EMail: pbaker@VeriSign.com
メールアドレス：pbaker@VeriSign.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
著作権（C）インターネット協会（2006）。
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.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
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 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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
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.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78および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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンライン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.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディタ機能のための資金は、IETF管理サポート活動（IASA）によって提供されます。