Network Working Group R. Housley
Request for Comments: 2585 SPYRUS
Category: Standards Track P. Hoffman
IMC
May 1999
Network Working Group R. Housley
Request for Comments: 2585 SPYRUS
Category: Standards Track P. Hoffman
IMC
May 1999
Internet X.509 Public Key Infrastructure Operational Protocols: FTP and HTTP
Internet X.509公钥基础设施操作协议：FTP和HTTP
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.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (1999). All Rights Reserved.
版权所有（C）互联网协会（1999年）。版权所有。
Abstract
摘要
The protocol conventions described in this document satisfy some of the operational requirements of the Internet Public Key Infrastructure (PKI). This document specifies the conventions for using the File Transfer Protocol (FTP) and the Hypertext Transfer Protocol (HTTP) to obtain certificates and certificate revocation lists (CRLs) from PKI repositories. Additional mechanisms addressing PKIX operational requirements are specified in separate documents.
本文档中描述的协议约定满足Internet公钥基础设施（PKI）的一些操作要求。本文档指定了使用文件传输协议（FTP）和超文本传输协议（HTTP）从PKI存储库获取证书和证书吊销列表（CRL）的约定。解决PKIX操作要求的其他机制在单独的文件中规定。
1 Introduction
1导言
This specification is part of a multi-part standard for the Internet Public Key Infrastructure (PKI) using X.509 certificates and certificate revocation lists (CRLs). This document specifies the conventions for using the File Transfer Protocol (FTP) and the Hypertext Transfer Protocol (HTTP) to obtain certificates and CRLs from PKI repositories. Additional mechanisms addressing PKI repository access are specified in separate documents.
本规范是使用X.509证书和证书撤销列表（CRL）的互联网公钥基础设施（PKI）多部分标准的一部分。本文档指定了使用文件传输协议（FTP）和超文本传输协议（HTTP）从PKI存储库获取证书和CRL的约定。解决PKI存储库访问的其他机制在单独的文档中指定。
The following is a simplified view of the architectural model assumed by the Internet PKI specifications.
以下是Internet PKI规范假定的体系结构模型的简化视图。
+---+
| C | +------------+
| e | <-------------------->| End entity |
| r | Operational +------------+
| t | transactions ^
| | and management | Management
| / | transactions | transactions
| | | PKI users
| C | v
| R | -------------------+--+-----------+-----------------
| L | ^ ^
| | | | PKI management
| | v | entities
| R | +------+ |
| e | <---------------------| RA | <---+ |
| p | Publish certificate +------+ | |
| o | | |
| s | | |
| I | v v
| t | +------------+
| o | <------------------------------| CA |
| r | Publish certificate +------------+
| y | Publish CRL ^
| | |
+---+ Management |
transactions |
v
+------+
| CA |
+------+
+---+
| C | +------------+
| e | <-------------------->| End entity |
| r | Operational +------------+
| t | transactions ^
| | and management | Management
| / | transactions | transactions
| | | PKI users
| C | v
| R | -------------------+--+-----------+-----------------
| L | ^ ^
| | | | PKI management
| | v | entities
| R | +------+ |
| e | <---------------------| RA | <---+ |
| p | Publish certificate +------+ | |
| o | | |
| s | | |
| I | v v
| t | +------------+
| o | <------------------------------| CA |
| r | Publish certificate +------------+
| y | Publish CRL ^
| | |
+---+ Management |
transactions |
v
+------+
| CA |
+------+
The components in this model are:
该模型中的组件包括：
End Entity: user of PKI certificates and/or end user system that is the subject of a certificate;
最终实体：PKI证书的用户和/或作为证书主体的最终用户系统；
CA: certification authority;
CA：证书颁发机构；
RA: registration authority, i.e., an optional system to which a CA delegates certain management functions;
RA：注册机构，即CA授权某些管理功能的可选系统；
Repository: a system or collection of distributed systems that store certificates and CRLs and serves as a means of distributing these certificates and CRLs to end entities.
存储库：存储证书和CRL的分布式系统的系统或集合，用作将这些证书和CRL分发给终端实体的手段。
Some CAs mandate the use of on-line validation services, while others distribute CRLs to allow certificate users to perform certificate validation themselves. In general, CAs make CRLs available to certificate users by publishing them in the Directory. The Directory is also the normal distribution mechanism for certificates. However, Directory Services are not available in many parts of the Internet today. The File Transfer Protocol (FTP) defined in RFC 959 and the Hypertext Transfer Protocol (HTTP) defined in RFC 2068 offer alternate methods for certificate and CRL distribution.
一些CA强制使用在线验证服务，而另一些CA分发CRL以允许证书用户自己执行证书验证。一般来说，CA通过在目录中发布CRL来向证书用户提供CRL。目录也是证书的正态分布机制。然而，如今在互联网的许多地方都没有目录服务。RFC 959中定义的文件传输协议（FTP）和RFC 2068中定义的超文本传输协议（HTTP）为证书和CRL分发提供了替代方法。
End entities and CAs may retrieve certificates and CRLs from the repository using FTP or HTTP. End entities may publish their own certificate in the repository using FTP or HTTP, and RAs and CAs may publish certificates and CRLs in the repository using FTP or HTTP.
终端实体和CA可以使用FTP或HTTP从存储库中检索证书和CRL。终端实体可以使用FTP或HTTP在存储库中发布自己的证书，而RAs和CAs可以使用FTP或HTTP在存储库中发布证书和CRL。
2 FTP Conventions
2 FTP协议
Within certificate extensions and CRL extensions, the URI form of GeneralName is used to specify the location where issuer certificates and CRLs may be obtained. For instance, a URI identifying the subject of a certificate may be carried in subjectAltName certificate extension. An IA5String describes the use of anonymous FTP to fetch certificate or CRL information. For example:
在证书扩展和CRL扩展中，GeneralName的URI形式用于指定可以获取颁发者证书和CRL的位置。例如，可以在subjectAltName证书扩展中携带标识证书主题的URI。IA5String描述使用匿名FTP获取证书或CRL信息。例如：
ftp://ftp.netcom.com/sp/spyrus/housley.cer
ftp://ftp.your.org/pki/id48.cer
ftp://ftp.your.org/pki/id48.no42.crl
ftp://ftp.netcom.com/sp/spyrus/housley.cer
ftp://ftp.your.org/pki/id48.cer
ftp://ftp.your.org/pki/id48.no42.crl
Internet users may publish the URI reference to a file that contains their certificate on their business card. This practice is useful when there is no Directory entry for that user. FTP is widely deployed, and anonymous FTP are accommodated by many firewalls. Thus, FTP is an attractive alternative to Directory access protocols for certificate and CRL distribution. While this service satisfies the requirement to retrieve information related to a certificate which is already identified by a URI, it is not intended to satisfy the more general problem of finding a certificate for a user about whom some other information, such as their electronic mail address or corporate affiliation, is known.
Internet用户可以将URI引用发布到名片上包含其证书的文件。当该用户没有目录条目时，这种做法很有用。FTP被广泛部署，许多防火墙都支持匿名FTP。因此，FTP是证书和CRL分发目录访问协议的一个有吸引力的替代方案。虽然此服务满足检索与已由URI标识的证书相关的信息的要求，但它并不打算满足为已知某些其他信息（例如其电子邮件地址或公司从属关系）的用户查找证书的更一般问题。
For convenience, the names of files that contain certificates should have a suffix of ".cer". Each ".cer" file contains exactly one certificate, encoded in DER format. Likewise, the names of files that contain CRLs should have a suffix of ".crl". Each ".crl" file contains exactly one CRL, encoded in DER format.
为方便起见，包含证书的文件名的后缀应为“.cer”。每个“.cer”文件只包含一个以DER格式编码的证书。同样，包含crl的文件名的后缀应为“.crl”。每个“.crl”文件只包含一个以DER格式编码的crl。
3 HTTP Conventions
3个HTTP约定
Within certificate extensions and CRL extensions, the URI form of GeneralName is used to specify the location where issuer certificates and CRLs may be obtained. For instance, a URI identifying the subject of a certificate may be carried in subjectAltName certificate extension. An IA5String describes the use of HTTP to fetch certificate or CRL information. For example:
在证书扩展和CRL扩展中，GeneralName的URI形式用于指定可以获取颁发者证书和CRL的位置。例如，可以在subjectAltName证书扩展中携带标识证书主题的URI。IA5String描述了如何使用HTTP获取证书或CRL信息。例如：
http://www.netcom.com/sp/spyrus/housley.cer
http://www.your.org/pki/id48.cer
http://www.your.org/pki/id48.no42.crl
http://www.netcom.com/sp/spyrus/housley.cer
http://www.your.org/pki/id48.cer
http://www.your.org/pki/id48.no42.crl
Internet users may publish the URI reference to a file that contains their certificate on their business card. This practice is useful when there is no Directory entry for that user. HTTP is widely deployed, and HTTP is accommodated by many firewalls. Thus, HTTP is an attractive alternative to Directory access protocols for certificate and CRL distribution. While this service satisfies the requirement to retrieve information related to a certificate which is already identified by a URI, it is not intended to satisfy the more general problem of finding a certificate for a user about whom some other information, such as their electronic mail address or corporate affiliation, is known.
Internet用户可以将URI引用发布到名片上包含其证书的文件。当该用户没有目录条目时，这种做法很有用。HTTP被广泛部署，许多防火墙都支持HTTP。因此，对于证书和CRL分发，HTTP是目录访问协议的一个有吸引力的替代方案。虽然此服务满足检索与已由URI标识的证书相关的信息的要求，但它并不打算满足为已知某些其他信息（例如其电子邮件地址或公司从属关系）的用户查找证书的更一般问题。
For convenience, the names of files that contain certificates should have a suffix of ".cer". Each ".cer" file contains exactly one certificate, encoded in DER format. Likewise, the names of files that contain CRLs should have a suffix of ".crl". Each ".crl" file contains exactly one CRL, encoded in DER format.
为方便起见，包含证书的文件名的后缀应为“.cer”。每个“.cer”文件只包含一个以DER格式编码的证书。同样，包含crl的文件名的后缀应为“.crl”。每个“.crl”文件只包含一个以DER格式编码的crl。
4 MIME registrations
4个MIME注册
Two MIME types are defined to support the transfer of certificates and CRLs. They are:
定义了两种MIME类型以支持证书和CRL的传输。他们是：
application/pkix-cert application/pkix-crl
应用程序/pkix证书应用程序/pkix crl
To: ietf-types@iana.org
Subject: Registration of MIME media type application/pkix-cert
To: ietf-types@iana.org
Subject: Registration of MIME media type application/pkix-cert
MIME media type name: application
MIME媒体类型名称：应用程序
MIME subtype name: pkix-cert
MIME子类型名称：pkix证书
Required parameters: None
所需参数：无
Optional parameters: version (default value is "1")
可选参数：版本（默认值为“1”）
Encoding considerations: will be none for 8-bit transports and most likely Base64 for SMTP or other 7-bit transports
编码注意事项：对于8位传输将为none，对于SMTP或其他7位传输最有可能为Base64
Security considerations: Carries a cryptographic certificate
安全注意事项：携带加密证书
Interoperability considerations: None
互操作性注意事项：无
Published specification: draft-ietf-pkix-ipki-part1
发布规范：草案-ietf-pkix-ipki-part1
Applications which use this media type: Any MIME-complaint transport
使用此媒体类型的应用程序：任何MIME传输
Additional information:
Magic number(s): None
File extension(s): .CER
Macintosh File Type Code(s): none
Additional information:
Magic number(s): None
File extension(s): .CER
Macintosh File Type Code(s): none
Person & email address to contact for further information:
Russ Housley <housley@spyrus.com>
Person & email address to contact for further information:
Russ Housley <housley@spyrus.com>
Intended usage: COMMON
预期用途：普通
Author/Change controller:
Russ Housley <housley@spyrus.com>
Author/Change controller:
Russ Housley <housley@spyrus.com>
To: ietf-types@iana.org
Subject: Registration of MIME media type application/pkix-crl
To: ietf-types@iana.org
Subject: Registration of MIME media type application/pkix-crl
MIME media type name: application
MIME媒体类型名称：应用程序
MIME subtype name: pkix-crl
MIME子类型名称：pkix crl
Required parameters: None
所需参数：无
Optional parameters: version (default value is "1")
可选参数：版本（默认值为“1”）
Encoding considerations: will be none for 8-bit transports and most likely Base64 for SMTP or other 7-bit transports
编码注意事项：对于8位传输将为none，对于SMTP或其他7位传输最有可能为Base64
Security considerations: Carries a cryptographic certificate revocation list
安全注意事项：携带加密证书吊销列表
Interoperability considerations: None
互操作性注意事项：无
Published specification: draft-ietf-pkix-ipki-part1
发布规范：草案-ietf-pkix-ipki-part1
Applications which use this media type: Any MIME-complaint transport
使用此媒体类型的应用程序：任何MIME传输
Additional information:
Magic number(s): None
File extension(s): .CRL
Macintosh File Type Code(s): none
Additional information:
Magic number(s): None
File extension(s): .CRL
Macintosh File Type Code(s): none
Person & email address to contact for further information:
Russ Housley <housley@spyrus.com>
Person & email address to contact for further information:
Russ Housley <housley@spyrus.com>
Intended usage: COMMON
预期用途：普通
Author/Change controller:
Russ Housley <housley@spyrus.com>
Author/Change controller:
Russ Housley <housley@spyrus.com>
References
工具书类
[RFC 959] Postel, J. and J. Reynolds, "File Transfer Protocol (FTP)", STD 5, RFC 959, October 1985.
[RFC 959]Postel，J.和J.Reynolds，“文件传输协议（FTP）”，标准5，RFC 959，1985年10月。
[RFC 1738] Berners-Lee, T., Masinter, L. and M. McCahill, "Uniform Resource Locators (URL)", RFC 1738, December 1994.
[RFC 1738]Berners Lee，T.，Masinter，L.和M.McCahill，“统一资源定位器（URL）”，RFC 17381994年12月。
[RFC 2068] Fielding, R., Gettys, J., Mogul, J., Frystyk, H. and T. Berners-Lee; "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2068, January 1997.
[RFC 2068]R.菲尔丁、J.盖蒂、J.莫卧儿、Frystyk、H.和T.伯纳斯·李；“超文本传输协议——HTTP/1.1”，RFC2068，1997年1月。
Security Considerations
安全考虑
Since certificates and CRLs are digitally signed, no additional integrity service is necessary. Neither certificates nor CRLs need be kept secret, and anonymous access to certificates and CRLs is generally acceptable. Thus, no privacy service is necessary.
由于证书和CRL是数字签名的，因此不需要额外的完整性服务。证书和CRL都不需要保密，对证书和CRL的匿名访问通常是可以接受的。因此，不需要隐私服务。
HTTP caching proxies are common on the Internet, and some proxies do not check for the latest version of an object correctly. If an HTTP request for a certificate or CRL goes through a misconfigured or otherwise broken proxy, the proxy may return an out-of-date response.
HTTP缓存代理在Internet上很常见，有些代理无法正确检查对象的最新版本。如果证书或CRL的HTTP请求通过配置错误或已损坏的代理，该代理可能会返回过期响应。
Operators of FTP sites and World Wide Web servers should authenticate end entities who publish certificates as well as CAs and RAs who publish certificates and CRLs. However, authentication is not necessary to retrieve certificates and CRLs.
FTP站点和万维网服务器的运营商应验证发布证书的终端实体以及发布证书和CRL的CA和RAs。但是，检索证书和CRL不需要身份验证。
Authors' Addresses
作者地址
Russell Housley SPYRUS 381 Elden Street, Suite 1120 Herndon, VA 20170 USA
拉塞尔·霍斯利·斯皮罗斯美国弗吉尼亚州埃尔登街381号赫恩登1120室，邮编20170
EMail: housley@spyrus.com
EMail: housley@spyrus.com
Paul Hoffman Internet Mail Consortium 127 Segre Place Santa Cruz, CA 95060 USA
保罗·霍夫曼互联网邮件联盟127塞格雷广场圣克鲁斯，加利福尼亚州95060
EMail: phoffman@imc.org
EMail: phoffman@imc.org
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (1999). All Rights Reserved.
版权所有（C）互联网协会（1999年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。