Network Working Group S. Boeyen
Request for Comments: 4386 Entrust Inc.
Category: Experimental P. Hallam-Baker
VeriSign Inc.
February 2006
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
Internet 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).
版权所有（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
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].
本文件中的关键词“必须”、“不得”、“必需”、“应该”、“不应该”、“建议”、“可以”和“可选”（大写，如图所示）应按照[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
_服务._Proto.Name TTL Class 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中使用时，此名称必须在前面加上一个“\u1”字符。
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\u LDAP HTTP\u HTTP OCSP\u 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.
本例使用虚构的域“example.com”帮助理解证书使用系统对SRV记录的使用。
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是一个电子邮件客户端，需要为收件人提供证书。Alice的客户端系统支持LDAP进行证书检索。假设邮件收件人是Bob，Bob的电子邮件地址是bob@example.com. 假设example.test维护一个“border目录”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的border目录系统。
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存储库，RFC2559中介绍了特定的安全注意事项。
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.
RFC 2782中讨论了一般SRV记录使用的安全问题，这些问题适用于此处定义的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，“互联网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互联网公钥基础设施在线证书状态协议-OCSP”，RFC 25601999年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，“Internet X.509公钥基础设施操作协议：FTP和HTTP”，RFC 25851999年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 SRV）的DNS RR”，RFC 2782，2000年2月。
Authors' Addresses
作者地址
Sharon Boeyen Entrust 1000 Innovation Drive Ottawa, Ontario Canada K2K 3E7
加拿大安大略省渥太华Sharon Boeyn委托1000创新驱动K2K 3E7
EMail: sharon.boeyen@entrust.com
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号280室01880
EMail: pbaker@VeriSign.com
EMail: 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.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
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秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为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.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFC编辑器功能的资金由IETF行政支持活动（IASA）提供。