Network Working Group J. Schaad
Request for Comments: 5273 Soaring Hawk Consulting
Category: Standards Track M. Myers
TraceRoute Security, Inc.
June 2008
Network Working Group J. Schaad
Request for Comments: 5273 Soaring Hawk Consulting
Category: Standards Track M. Myers
TraceRoute Security, Inc.
June 2008
Certificate Management over CMS (CMC): Transport Protocols
CMS上的证书管理（CMC）：传输协议
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）。本备忘录的分发不受限制。
Abstract
摘要
This document defines a number of transport mechanisms that are used to move CMC (Certificate Management over CMS (Cryptographic Message Syntax)) messages. The transport mechanisms described in this document are HTTP, file, mail, and TCP.
本文档定义了许多用于移动CMC（CMS上的证书管理（加密消息语法））消息的传输机制。本文档中描述的传输机制包括HTTP、文件、邮件和TCP。
This document defines a number of transport methods that are used to move CMC messages (defined in [CMC-STRUCT]). The transport mechanisms described in this document are HTTP, file, mail, and TCP.
本文档定义了许多用于移动CMC消息的传输方法（在[CMC-STRUCT]中定义）。本文档中描述的传输机制包括HTTP、文件、邮件和TCP。
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 [MUST].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[必须]中所述进行解释。
Enrollment messages and responses may be transferred between clients and servers using file-system-based mechanisms, such as when enrollment is performed for an off-line client. When files are used to transport binary, Full PKI Request or Full PKI Response messages, there MUST be only one instance of a request or response message in a single file. The following file type extensions SHOULD be used:
注册消息和响应可以使用基于文件系统的机制在客户机和服务器之间传输，例如当为离线客户机执行注册时。当文件用于传输二进制、完整PKI请求或完整PKI响应消息时，单个文件中必须只有一个请求或响应消息实例。应使用以下文件类型扩展名：
+---------------------+----------------+
| Message Type | File Extension |
+---------------------+----------------+
| Simple PKI Request | .p10 |
| Full PKI Request | .crq |
| Simple PKI Response | .p7c |
| Full PKI Response | .crp |
+---------------------+----------------+
+---------------------+----------------+
| Message Type | File Extension |
+---------------------+----------------+
| Simple PKI Request | .p10 |
| Full PKI Request | .crq |
| Simple PKI Response | .p7c |
| Full PKI Response | .crp |
+---------------------+----------------+
File PKI Request/Response Identification
文件PKI请求/响应标识
MIME wrapping is defined for those environments that are MIME native. The basic mime wrapping in this section is taken from [SMIMEV3]. When using a mail-based protocol, MIME wrapping between the layers of CMS wrapping is optional. Note that this is different from the standard S/MIME (Secure MIME) message.
MIME包装是为MIME本机环境定义的。本节中的基本mime包装来自[SMIMEV3]。使用基于邮件的协议时，CMS包装层之间的MIME包装是可选的。请注意，这与标准S/MIME（安全MIME）消息不同。
Simple enrollment requests are encoded using the "application/pkcs10" content type. A file name MUST be included either in a content-type or a content-disposition statement. The extension for the file MUST be ".p10".
简单的注册请求使用“application/pkcs10”内容类型进行编码。文件名必须包含在内容类型或内容处置语句中。文件的扩展名必须为“.p10”。
Simple enrollment response messages MUST be encoded as content type "application/pkcs7-mime". An smime-type parameter MUST be on the content-type statement with a value of "certs-only". A file name with the ".p7c" extension MUST be specified as part of the content-type or content-disposition statement.
简单注册响应消息必须编码为内容类型“application/pkcs7 mime”。smime类型参数必须位于值为“certs only”的content type语句上。必须将扩展名为“.p7c”的文件名指定为内容类型或内容处置语句的一部分。
Full enrollment request messages MUST be encoded as content type "application/pkcs7-mime". The smime-type parameter MUST be included with a value of "CMC-Request". A file name with the ".p7m" extension MUST be specified as part of the content-type or content-disposition statement.
完整注册请求消息必须编码为内容类型“application/pkcs7 mime”。smime类型参数的值必须为“CMC请求”。扩展名为“.p7m”的文件名必须指定为内容类型或内容处置语句的一部分。
Full enrollment response messages MUST be encoded as content type "application/pkcs7-mime". The smime-type parameter MUST be included with a value of "CMC-response". A file name with the ".p7m" extension MUST be specified as part of the content-type or content-disposition statement.
完整注册响应消息必须编码为内容类型“application/pkcs7 mime”。smime类型参数必须包含值“CMC response”。扩展名为“.p7m”的文件名必须指定为内容类型或内容处置语句的一部分。
+--------------+------------------------+------------+--------------+
| Item | MIME Type | File | SMIME Type |
| | | Extension | |
+--------------+------------------------+------------+--------------+
| Simple PKI | application/pkcs10 | .p10 | N/A |
| Request | | | |
| Full PKI | application/pkcs7-mime | .p7m | CMC-request |
| Request | | | |
| Simple PKI | application/pkcs7-mime | .p7c | certs-only |
| Response | | | |
| Full PKI | application/pkcs7-mime | .p7m | CMC-response |
| Response | | | |
+--------------+------------------------+------------+--------------+
+--------------+------------------------+------------+--------------+
| Item | MIME Type | File | SMIME Type |
| | | Extension | |
+--------------+------------------------+------------+--------------+
| Simple PKI | application/pkcs10 | .p10 | N/A |
| Request | | | |
| Full PKI | application/pkcs7-mime | .p7m | CMC-request |
| Request | | | |
| Simple PKI | application/pkcs7-mime | .p7c | certs-only |
| Response | | | |
| Full PKI | application/pkcs7-mime | .p7m | CMC-response |
| Response | | | |
+--------------+------------------------+------------+--------------+
Table 1: MIME PKI Request/Response Identification
表1:MIME PKI请求/响应标识
This section describes the conventions for use of HTTP [HTTP] as a transport layer. In most circumstances, the use of HTTP over TLS [TLS] provides any necessary content protection from eavesdroppers.
本节介绍将HTTP[HTTP]用作传输层的约定。在大多数情况下，使用HTTP over TLS[TLS]可以提供任何必要的内容保护，以防被窃听。
In order for CMC clients and servers using HTTP to interoperate, the following rules apply.
为了使使用HTTP的CMC客户端和服务器能够互操作，以下规则适用。
Clients MUST use the POST method to submit their requests.
客户端必须使用POST方法提交其请求。
Servers MUST use the 200 response code for successful responses.
服务器必须使用200响应代码才能成功响应。
Clients MAY attempt to send HTTP requests using TLS 1.0 [TLS] or later, although servers are not required to support TLS.
客户机可以尝试使用TLS 1.0[TLS]或更高版本发送HTTP请求，但不要求服务器支持TLS。
Servers MUST NOT assume client support for any type of HTTP authentication such as cookies, Basic authentication, or Digest authentication.
服务器不得假定客户端支持任何类型的HTTP身份验证，如cookie、基本身份验证或摘要身份验证。
Clients and servers are expected to follow the other rules and restrictions in [HTTP]. Note that some of those rules are for HTTP methods other than POST; clearly, only the rules that apply to POST are relevant for this specification.
客户端和服务器应遵循[HTTP]中的其他规则和限制。注意，其中一些规则是针对HTTP方法而不是POST；显然，只有适用于POST的规则与本规范相关。
A PKI Request using the POST method is constructed as follows:
使用POST方法的PKI请求构造如下：
The Content-Type header MUST have the appropriate value from Table 1.
内容类型标题必须具有表1中的适当值。
The body of the message is the binary value of the encoding of the PKI Request.
消息体是PKI请求编码的二进制值。
An HTTP-based PKI Response is composed of the appropriate HTTP headers, followed by the binary value of the BER (Basic Encoding Rules) encoding of either a Simple or Full PKI Response.
基于HTTP的PKI响应由适当的HTTP头组成，后跟简单或完整PKI响应的BER（基本编码规则）编码的二进制值。
The Content-Type header MUST have the appropriate value from Table 1.
内容类型标题必须具有表1中的适当值。
When CMC messages are sent over a TCP-based connection, no wrapping is required of the message. Messages are sent in their binary encoded form.
通过基于TCP的连接发送CMC消息时，不需要对消息进行包装。消息以二进制编码的形式发送。
The client closes a connection after receiving a response, or it issues another request to the server using the same connection. Reusing one connection for multiple successive requests, instead of opening multiple connections that are only used for a single request, is RECOMMENDED for performance and resource conservation reasons. A server MAY close a connection after it has been idle for some period of time; this timeout would typically be several minutes long.
客户端在收到响应后关闭连接，或者使用同一连接向服务器发出另一个请求。出于性能和资源节约的考虑，建议对多个连续请求重用一个连接，而不是打开仅用于单个请求的多个连接。服务器在空闲一段时间后可能会关闭连接；此超时通常长达几分钟。
There is no specific port that is to be used when doing TCP-based transport. Only the Private Ports 49152-65535 may be used in this manner (without registration). The ports in the range of 1-49151 SHOULD NOT be used. The port to be used is configured out of band.
在执行基于TCP的传输时，没有要使用的特定端口。只能以这种方式使用专用端口49152-65535（无需注册）。不应使用1-49151范围内的端口。要使用的端口配置为带外。
Mechanisms for thwarting replay attacks may be required in particular implementations of this protocol depending on the operational environment. In cases where the Certification Authority (CA) maintains significant state information, replay attacks may be detectable without the inclusion of the optional nonce mechanisms. Implementers of this protocol need to carefully consider environmental conditions before choosing whether or not to implement the senderNonce and recipientNonce attributes described in Section 6.6 of [CMC-STRUCT]. Developers of state-constrained PKI clients are strongly encouraged to incorporate the use of these attributes.
在本协议的特定实现中，可能需要阻止重播攻击的机制，具体取决于操作环境。在证书颁发机构（CA）维护重要状态信息的情况下，在不包含可选的nonce机制的情况下，可以检测到重放攻击。该协议的实现者需要仔细考虑环境条件，然后选择是否实现[CMC-StReT]的第6.6节中描述的StordNoice和RelixNoice属性。强烈鼓励受状态约束的PKI客户端的开发人员使用这些属性。
Initiation of a secure communications channel between an end-entity and a CA or Registration Authority (RA) -- and, similarly, between an RA and another RA or CA -- necessarily requires an out-of-band trust initiation mechanism. For example, a secure channel may be constructed between the end-entity and the CA via IPsec [IPsec] or
在终端实体和CA或注册机构（RA）之间，以及类似地，在RA和另一个RA或CA之间启动安全通信通道，必然需要带外信任启动机制。例如，可以通过IPsec[IPsec]或ip在终端实体和CA之间构建安全信道
TLS [TLS]. Many such schemes exist, and the choice of any particular scheme for trust initiation is outside the scope of this document. Implementers of this protocol are strongly encouraged to consider generally accepted principles of secure key management when integrating this capability within an overall security architecture.
TLS[TLS]。存在许多这样的方案，并且选择任何特定的方案来发起信任超出了本文的范围。该协议的实施者被强烈鼓励考虑在整体安全体系结构中集成该能力时普遍接受的安全密钥管理原则。
In some instances, no prior out-of-band trust will have been initiated prior to use of this protocol. This can occur when the protocol itself is being used to download onto the system the set of trust anchors to be used for these protocols. In these instances, the Enveloped Data content type (Section 3.2.1.3.3 in [CMC-STRUCT]) must be used to provide the same shrouding that TLS would have provided.
在某些情况下，在使用此协议之前，不会启动带外信任。当协议本身用于将用于这些协议的信任锚集下载到系统上时，可能会发生这种情况。在这些情况下，必须使用封装数据内容类型（“CMC-STRUCT”）中的第3.2.1.3.3节来提供与TLS相同的覆盖。
The authors and the PKIX Working Group are grateful for the participation of Xiaoyi Liu and Jeff Weinstein in helping to author the original versions of this document.
作者和PKIX工作组感谢刘晓义和杰夫·温斯坦参与编写本文件的原始版本。
The authors would like to thank Brian LaMacchia for his work in developing and writing up many of the concepts presented in this document. The authors would also like to thank Alex Deacon and Barb Fox for their contributions.
作者要感谢Brian LaMacchia，感谢他在开发和撰写本文中提出的许多概念方面所做的工作。作者还要感谢Alex执事和Barb Fox的贡献。
[CMC-STRUCT] Schaad, J. and M. Myers, "Certificate Management over CMS (CMC)", RFC 5272, June 2008.
[CMC-STRUCT]Schaad，J.和M.Myers，“CMS上的证书管理（CMC）”，RFC 52722008年6月。
[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]菲尔丁，R.，盖蒂斯，J.，莫卧儿，J.，弗莱斯蒂克，H.，马斯特，L.，利奇，P.，和T.伯纳斯李，“超文本传输协议——HTTP/1.1”，RFC2616，1999年6月。
[IPsec] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[IPsec]Kent，S.和K.Seo，“互联网协议的安全架构”，RFC 43012005年12月。
[MUST] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, BCP 14, March 1997.
[必须]Bradner，S.，“RFC中用于表示需求水平的关键词”，RFC 2119，BCP 14，1997年3月。
[SMIMEV3] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification", RFC 3851, July 2004.
[SMIMEV3]Ramsdell，B.，“安全/多用途Internet邮件扩展（S/MIME）版本3.1消息规范”，RFC 3851，2004年7月。
[TLS] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, April 2006.
[TLS]Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.1”，RFC 4346，2006年4月。
Authors' Addresses
作者地址
Jim Schaad Soaring Hawk Consulting PO Box 675 Gold Bar, WA 98251
Jim Schaad Smalling Hawk咨询公司华盛顿金条675号邮政信箱98251
Phone: (425) 785-1031 EMail: jimsch@nwlink.com
电话：（425）785-1031电子邮件：jimsch@nwlink.com
Michael Myers TraceRoute Security, Inc.
迈克尔·迈尔斯追踪路线安全公司。
EMail: mmyers@fastq.com
EMail: mmyers@fastq.com
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2008).
版权所有（C）IETF信托基金（2008年）。
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, 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.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
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.