[要約] RFC 4386は、インターネットX.509公開鍵基盤リポジトリロケーターサービスに関する規格です。その目的は、クライアントが公開鍵証明書を効率的に検索し、信頼できるリポジトリを見つけることです。
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
インターネットX.509公開キーインフラストラクチャリポジトリロケーターサービス
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.
このメモは、インターネットコミュニティの実験プロトコルを定義します。いかなる種類のインターネット標準を指定しません。改善のための議論と提案が要求されます。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（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.
多くのRFC（[RFC2559]、[RFC2560]、および[RFC2585]を含む）は、PKIリポジトリからの公開証明書や取り消し情報を含むPKIデータを取得するための運用プロトコルを指定しています。これらのRFCは、証明書使用システムには、特定のプロトコルを使用してPKIリポジトリを特定、検索、および接続するために必要な情報があると想定しています。一部のツールは、ディレクトリシステムでの知識リファレンスなど、この目的のためにプロトコル固有の環境で利用できますが、これらは単一のプロトコルで使用するために制限されており、共通の出版手段を共有していません。このドキュメントは、DNSでのサービスレコード（SRV）リソースレコード（RRS）を使用することにより、この問題の解決策を提供します。このソリューションは、ドメイン名のみが利用可能な環境で特に役立つと予想されます。他の状況（たとえば、必要な情報を含む証明書が利用可能な場合）では、そのような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リポジトリロケーターサービスのSRVレコードを定義して、PKIクライアントが必要な情報を取得してドメインのPKIリポジトリに接続できるようにします。このドキュメントには、このサービスの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].
「必須」、「必要」、「必須」、「必要」、「必要はない」、「推奨」、「5月」、および「オプション」（図のように大文字で）は次のとおりです。[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タイプコードが33であるSRV RRの形式は次のとおりです。
_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 RRSに含めることができるプロトコルは次のとおりです。
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.
アリスは、受信者の証明書が必要な電子メールクライアントであると仮定します。Aliceのクライアントシステムは、証明書取得のLDAPをサポートしています。メッセージ受信者がボブであり、ボブのメールアドレスがbob@example.comであると仮定します。Example.Testが「Border Directory」PKIリポジトリを維持し、Bobの証明書がLDAPを介してそのディレクトリ「border.example.com」から入手可能であると仮定します。
Alice's client system retrieves, via DNS, the SRV record for _PKIXREP._LDAP.example.com.
Aliceのクライアントシステムは、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があります。
- 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.
結果には、たとえばcom.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.
「_PKIXREP」とそれぞれの基礎となるサービスとの関連性が決定的であることを保証するために、IANAは新しいレジストリを作成しました：PKIX SRVプロトコルラベル。
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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、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.、Howes、T。、およびP. Richard、「Internet 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] Myers、M.、Ankney、R.、Malpani、A.、Galperin、S.、およびC. Adams、「X.509インターネット公開キーインフラオンライン証明書ステータスプロトコル」、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. Hoffman、「インターネット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
シャロン・ボイエンは1000イノベーションドライブドライブオタワ、オンタリオカナダK2K 3E7
EMail: sharon.boeyen@entrust.com
Phillip M. Hallam-Baker VeriSign Inc. 401 Edgewater Place, Suite 280 Wakefield MA 01880
Phillip M. Hallam-Baker Verisign Inc. 401 Edgewater Place、Suite 280 Wakefield MA 01880
EMail: pbaker@VeriSign.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。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）によって提供されます。