Network Working Group P. Hoffman
Request for Comments: 3854 IMC
Category: Standards Track C. Bonatti
IECA
A. Eggen
FFI
July 2004
Network Working Group P. Hoffman
Request for Comments: 3854 IMC
Category: Standards Track C. Bonatti
IECA
A. Eggen
FFI
July 2004
Securing X.400 Content with Secure/Multipurpose Internet Mail Extensions (S/MIME)
使用安全/多用途Internet邮件扩展（S/MIME）保护X.400内容
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 (2004).
版权所有（C）互联网协会（2004年）。
Abstract
摘要
This document describes a protocol for adding cryptographic signature and encryption services to X.400 content with Secure/Multipurpose Internet Mail Extensions (S/MIME).
本文档描述了一种协议，用于向具有安全/多用途Internet邮件扩展（S/MIME）的X.400内容添加加密签名和加密服务。
The techniques described in the Cryptographic Message Syntax [CMS] specification are general enough to support many different content types. The [CMS] specification thus provides many options for providing different security mechanisms. In order to ensure interoperability of systems within the X.400 community, it is necessary to specify the use of CMS features to protect X.400 content (called "CMS-X.400" in this document).
加密消息语法[CMS]规范中描述的技术非常通用，足以支持许多不同的内容类型。[CMS]规范因此为提供不同的安全机制提供了许多选项。为了确保X.400社区内系统的互操作性，有必要指定使用CMS功能来保护X.400内容（本文档中称为“CMS-X.400”）。
This document is intended to be similar to the S/MIME Version 3.1 Message Specification [MSG] except that it is tailored to the requirements of X.400 content rather than Multipurpose Internet Mail Extensions (MIME).
本文档旨在与S/MIME版本3.1消息规范[MSG]相似，只是它是根据X.400内容而不是多用途Internet邮件扩展（MIME）的要求定制的。
This document defines how to create an X.400 content type that has been cryptographically enhanced according to [CMS]. In order to create S/MIME messages carrying X.400 content, an S/MIME agent has to follow specifications in this document, as well as the specifications listed in [CMS]. This memo also defines new parameter values for the application/pkcs7-mime MIME type that can be used to transport those body parts.
本文档定义了如何创建根据[CMS]加密增强的X.400内容类型。为了创建承载X.400内容的S/MIME消息，S/MIME代理必须遵循本文档中的规范以及[CMS]中列出的规范。此备忘录还为可用于传输这些身体部位的application/pkcs7 mime mime类型定义了新的参数值。
Throughout this document, there are requirements and recommendations made for how receiving agents handle incoming messages. There are separate requirements and recommendations for how sending agents create outgoing messages. In general, the best strategy is to "be liberal in what you receive and conservative in what you send". Most of the requirements are placed on the handling of incoming messages while the recommendations are mostly on the creation of outgoing messages.
在本文档中，有关于接收代理如何处理传入消息的要求和建议。对于发送代理如何创建传出消息，有单独的要求和建议。总的来说，最好的策略是“在你收到的东西上自由，在你发送的东西上保守”。大多数需求放在传入消息的处理上，而建议主要放在传出消息的创建上。
This document does not address transport of CMS-X.400 content. It is assumed that CMS-X.400 content would be transported by Internet mail systems, X.400, or other suitable transport.
本文件不涉及CMS-X.400内容的传输。假设CMS-X.400内容将通过互联网邮件系统、X.400或其他合适的传输方式进行传输。
This document describes applying security services to the content of entire X.400 messages, which may or may not be IPMS messages. These objects can be carried by several means, including SMTP-based mail and X.400 mail. Note that cooperating S/MIME agents must support common forms of message content in order to achieve interoperability.
本文档描述了将安全服务应用于整个X.400消息的内容，这些消息可能是也可能不是IPMS消息。这些对象可以通过多种方式携带，包括基于SMTP的邮件和X.400邮件。请注意，为了实现互操作性，协作的S/MIME代理必须支持常见形式的消息内容。
If the CMS objects are sent as parts of an RFC 822 message, a standard MIXER gateway [MIXER] will most likely choose to encapsulate the message. This is not likely to be a format that is usable by an X.400 recipient. MIXER is specifically focused on translation between X.420 Interpersonal Messages and non-secure RFC822/MIME messages. The discussion of security-related body parts in sections 7.3 and 7.4 of [BODYMAP] is relevant to CMS messages.
如果CMS对象作为RFC 822消息的一部分发送，则标准混合器网关[MIXER]很可能会选择封装消息。这不太可能是X.400收件人可以使用的格式。MIXER特别关注X.420人际消息和非安全RFC822/MIME消息之间的转换。[BODYMAP]第7.3节和第7.4节中有关安全相关身体部位的讨论与CMS消息有关。
Definition of gateway services to support relay of CMS object between X.400 and SMTP environments is beyond the scope of this document.
支持X.400和SMTP环境之间CMS对象中继的网关服务的定义超出了本文档的范围。
The key words "MUST", "SHALL", "REQUIRED", "SHOULD", "RECOMMENDED", and "MAY" in this document are to be interpreted as described in BCP 14, RFC 2119 [MUSTSHOULD].
本文件中的关键词“必须”、“应”、“要求”、“应”、“建议”和“可能”应按照BCP 14、RFC 2119[必须]中的说明进行解释。
For the purposes of this document, the following definitions apply.
在本文件中，以下定义适用。
ASN.1: Abstract Syntax Notation One, as defined in ISO/IEC 8824.
ASN.1:ISO/IEC 8824中定义的抽象语法符号1。
BER: Basic Encoding Rules for ASN.1, as defined in ISO/IEC 8825-1.
BER：ISO/IEC 8825-1中定义的ASN.1的基本编码规则。
Certificate: A type that binds an entity's distinguished name to a public key with a digital signature.
证书：用数字签名将实体的可分辨名称绑定到公钥的类型。
DER: Distinguished Encoding Rules for ASN.1, as defined in ISO/IEC 8825-1.
DER:ISO/IEC 8825-1中定义的ASN.1的特殊编码规则。
7-bit data: Text data with lines less than 998 characters long, where none of the characters have the 8th bit set, and there are no NULL characters. <CR> and <LF> occur only as part of a <CR><LF> end of line delimiter.
7位数据：行长度小于998个字符的文本数据，其中没有字符设置为第8位，也没有空字符<CR>和<LF>仅作为<CR><LF>行尾分隔符的一部分出现。
8-bit data: Text data with lines less than 998 characters, and where none of the characters are NULL characters. <CR> and <LF> occur only as part of a <CR><LF> end of line delimiter.
8位数据：行数小于998个字符的文本数据，其中所有字符都不是空字符<CR>和<LF>仅作为<CR><LF>行尾分隔符的一部分出现。
Binary data: Arbitrary data.
二进制数据：任意数据。
Transfer Encoding: A reversible transformation made on data so 8-bit or binary data may be sent via a channel that only transmits 7-bit data.
传输编码：对数据进行的可逆转换，因此8位或二进制数据可以通过仅传输7位数据的通道发送。
Receiving agent: Software that interprets and processes S/MIME CMS objects.
接收代理：解释和处理S/MIME CMS对象的软件。
Sending agent: Software that creates S/MIME CMS objects.
发送代理：创建S/MIME CMS对象的软件。
S/MIME agent: User software that is a receiving agent, a sending agent, or both.
S/MIME代理：作为接收代理、发送代理或两者兼有的用户软件。
There are believed to be no existing X.400 implementations that support S/MIME version 2. Further, signed interoperability between X.400 and MIME systems that support S/MIME version 2 is not believed
据信，现有的X.400实现不支持S/MIME版本2。此外，不相信X.400和支持S/MIME版本2的MIME系统之间的签名互操作性
to be easily achievable. Therefore backward compatibility with S/MIME version 2 is not considered to be a requirement for this document.
容易实现。因此，本文档不要求与S/MIME版本2向后兼容。
It is a goal of this document to, if possible, maintain backward compatibility with existing X.400 implementations that employ S/MIME v3.1 wrappers.
本文档的目标是，如果可能的话，保持与使用S/MIME v3.1包装器的现有X.400实现的向后兼容性。
CMS allows for a wide variety of options in content and algorithm support. This section puts forth a number of support requirements and recommendations in order to achieve a base level of interoperability among all CMS-X.400 implementations. [CMS] provides additional details regarding the use of the cryptographic algorithms.
CMS允许在内容和算法支持方面有多种选择。本节提出了一些支持要求和建议，以实现所有CMS-X.400实现之间的基本互操作性。[CMS]提供了有关加密算法使用的其他详细信息。
Sending and receiving agents MUST support SHA-1 [CMSALG].
发送和接收代理必须支持SHA-1[CMSALG]。
Receiving agents MUST support id-dsa-with-sha1 defined in [CMSALG]. The algorithm parameters MUST be absent (not encoded as NULL). Receiving agents MUST support rsaEncryption, defined in [CMSALG].
接收代理必须支持[CMSALG]中定义的id-dsa-with-sha1。算法参数必须不存在（不编码为NULL）。接收代理必须支持[CMSALG]中定义的RSA加密。
Sending agents MUST support either id-dsa-with-sha1 or rsaEncryption.
发送代理必须支持id-dsa-with-sha1或RSA加密。
Sending and receiving agents MUST support rsaEncryption, defined in [CMSALG].
发送和接收代理必须支持[CMSALG]中定义的RSA加密。
Sending and receiving agents SHOULD support Diffie-Hellman defined in [CMSALG].
发送和接收代理应支持[CMSALG]中定义的Diffie Hellman。
The general syntax of CMS objects consist of an instance of the ContentInfo structure containing one of several defined CMS content types. CMS defines multiple content types. Of these, only the SignedData and EnvelopedData content types are used for CMS-X.400.
CMS对象的通用语法由ContentInfo结构的一个实例组成，该实例包含几个已定义的CMS内容类型之一。CMS定义了多种内容类型。其中，CMS-X.400仅使用SignedData和EnvelopedData内容类型。
Sending agents MUST use the signedData content type to apply a digital signature to a message or, in a degenerate case where there is no signature information, to convey certificates.
发送代理必须使用signedData内容类型对消息应用数字签名，或者在没有签名信息的退化情况下传递证书。
Senders MUST use the envelopedData content type to apply privacy protection to a message. A sender needs to have access to a public key for each intended message recipient to use this service. This content type does not provide authentication.
发件人必须使用envelopedData内容类型对邮件应用隐私保护。要使用此服务，发件人需要访问每个预期邮件收件人的公钥。此内容类型不提供身份验证。
The SignerInfo type allows the inclusion of unsigned and signed attributes to be included along with a signature.
SignerInfo类型允许将未签名和已签名属性与签名一起包含。
Receiving agents MUST be able to handle zero or one instance of each of the signed attributes listed here. Sending agents SHOULD generate one instance of each of the following signed attributes in each CMS-X400 message:
接收代理必须能够处理此处列出的每个已签名属性的零个或一个实例。发送代理应在每个CMS-X400消息中生成以下每个签名属性的一个实例：
- signingTime - sMIMECapabilities - sMIMEEncryptionKeyPreference
- 签名时间-sMIMECapabilities-sMIMEEncryptionKeyPreference
Requirements for processing of these attributes MUST be in accordance with the S/MIME Message Specification [MSG]. Handling of the signingTime attribute MUST comply with clause 2.5.1 of [MSG]. Handling of the sMIMECapabilities attribute MUST comply with clause 2.5.2 of [MSG]. Handling of the sMIMEEncryptionKeyPreference attribute MUST comply with clause 2.5.3 of [MSG].
处理这些属性的要求必须符合S/MIME消息规范[MSG]。signingTime属性的处理必须符合[MSG]第2.5.1条的规定。sMIMECapabilities属性的处理必须符合[MSG]第2.5.2条的规定。sMIMEEncryptionKeyPreference属性的处理必须符合[MSG]第2.5.3条的规定。
Further, receiving agents SHOULD be able to handle zero or one instance in the signed attributes of the signingCertificate attribute [ESS].
此外，接收代理应该能够处理signingCertificate属性[ESS]的签名属性中的零个或一个实例。
Sending agents SHOULD generate one instance of the signingCertificate signed attribute in each CMS-X400 message.
发送代理应在每个CMS-X400消息中生成signingCertificate signed属性的一个实例。
Additional attributes and values for these attributes may be defined in the future. Receiving agents SHOULD handle attributes or values that they do not recognize in a graceful manner.
将来可能会定义这些属性的其他属性和值。接收代理应该以优雅的方式处理它们无法识别的属性或值。
Sending agents that include signed attributes that are not listed here SHOULD display those attributes to the user, so that the user is aware of all of the data being signed.
发送包含此处未列出的已签名属性的代理时，应向用户显示这些属性，以便用户知道正在签名的所有数据。
Sending and receiving agents MUST support encryption and decryption with DES EDE3 CBC, hereinafter called "tripleDES" [CMSALG]. Sending and receiving agents SHOULD support encryption and decryption with AES [CMSAES] at a key size of 128, 192 and 256 bits.
发送和接收代理必须支持DES EDE3 CBC的加密和解密，以下称为“tripleDES”[CMSALG]。发送和接收代理应支持密钥大小为128、192和256位的AES[CMSAES]加密和解密。
This section describes the S/MIME message formats and how they can be used to secure X.400 contents. The S/MIME messages are a combination of X.400 contents and CMS objects (i.e., a ContentInfo structure containing one of the CMS-defined content types). The X.400 content and other data, such as certificates and algorithm identifiers, are given to CMS processing facilities which produces a CMS object. This document also describes how nested, secured S/MIME messages should be formatted when encapsulating an X.400 content, and provides an example of how a triple-wrapped S/MIME message over X.400 content should be created if backwards compatibility with S/MIME version 2 is of no concern.
本节介绍S/MIME消息格式以及如何使用这些格式保护X.400内容。S/MIME消息是X.400内容和CMS对象（即，包含CMS定义的内容类型之一的ContentInfo结构）的组合。将X.400内容和其他数据（如证书和算法标识符）提供给CMS处理设施，该设施生成CMS对象。本文档还描述了在封装X.400内容时应如何格式化嵌套的安全S/MIME消息，并提供了一个示例，说明在不考虑与S/MIME版本2的向后兼容性的情况下，应如何在X.400内容上创建三重包装的S/MIME消息。
S/MIME provides one format for enveloped-only data, several formats for signed-only data, and several formats for signed and enveloped data. The different formats are required to accommodate several environments, in particular for signed messages. Only one of these signed formats is applicable to X.400.
S/MIME为仅封装数据提供了一种格式，为仅签名数据提供了几种格式，为签名和封装数据提供了几种格式。需要不同的格式来适应多种环境，特别是对于签名消息。这些签名格式中只有一种适用于X.400。
Note that canonicalization is not required for X.400 content because it is a binary rather than text encoding, and only the "embedded" content version is used. These dramatically simplify the description of S/MIME productions.
请注意，X.400内容不需要规范化，因为它是二进制编码而不是文本编码，并且只使用“嵌入式”内容版本。这些大大简化了S/MIME产品的描述。
The reader of this section is expected to understand X.400 as described in [X.400] and S/MIME as described in [CMS] and [ESS].
本节读者应理解[X.400]中所述的X.400以及[CMS]和[ESS]中所述的S/MIME。
This section reviews the X.400 message format. An X.400 message has two parts, the envelope and the content, as described in X.402 [X.400]:
本节回顾X.400消息格式。X.400消息有两部分，信封和内容，如X.402[X.400]所述：
Envelope -- An information object whose composition varies from one transmittal step to another and that variously identifies the message's originator and potential recipients, documents its previous conveyance and directs its subsequent conveyance by the Message Transfer System (MTS), and characterizes its content.
信封——一种信息对象，其组成在不同的传输步骤中有所不同，它以不同的方式标识消息的发起者和潜在接收者，记录其先前的传输，并通过消息传输系统（MTS）指示其后续传输，并描述其内容。
Content -- The content is the piece of information that the originating User Agent wants to be delivered to one or more recipients. The MTS neither examines nor modifies the content, except for conversion, during its conveyance of the message. MTS conversion is not applicable to the scenario of this document because such conversion is incompatible with CMS protection mechanisms.
内容——内容是原始用户代理希望传递给一个或多个收件人的信息。MTS在传递消息期间既不检查也不修改内容（转换除外）。MTS转换不适用于本文档的场景，因为此类转换与CMS保护机制不兼容。
One piece of information borne by the envelope identifies the type of the content. The content type is an identifier (an ASN.1 OID or Integer) that denotes the syntax and semantics of the content overall. This identifier enables the MTS to determine the message's deliverability to particular users, and enables User Agents and Message Stores to interpret and process the content.
信封上的一条信息标识内容的类型。内容类型是一个标识符（ASN.1 OID或整数），表示内容的语法和语义。此标识符使MTS能够确定消息对特定用户的可交付性，并使用户代理和消息存储能够解释和处理内容。
Another piece of information borne by the envelope identifies the types of encoded information represented in the content. An encoded information type (EIT) is an identifier (an ASN.1 Object Identifier or Integer) that denotes the medium and format (e.g., IA5 text or Group 3 facsimile) of individual portions of the content. It further enables the MTS to determine the message's deliverability to particular users, and to identify opportunities for it to make the message deliverable by converting a portion of the content from one EIT to another.
信封承载的另一条信息标识内容中表示的编码信息的类型。编码信息类型（EIT）是一个标识符（ASN.1对象标识符或整数），表示内容各个部分的媒体和格式（例如，IA5文本或第3组传真）。它还使MTS能够确定消息对特定用户的可交付性，并通过将部分内容从一个EIT转换为另一个EIT来识别使消息可交付的机会。
This document describes how S/MIME CMS is used to secure the content part of X.400 messages.
本文档描述了如何使用S/MIME CMS保护X.400消息的内容部分。
The SignedData format as described in the Cryptographic Message Syntax [CMS] MUST be used for signing of X.400 contents.
加密消息语法[CMS]中描述的SignedData格式必须用于X.400内容的签名。
The X.400 content to be protected MUST be placed in the SignedData encapContentInfo eContent field. Note that this X.400 content SHOULD maintain the encoding defined by the content type, but SHOULD NOT be MIME wrapped. The object identifier for the content type of the protected X.400 content MUST be placed in the SignedData encapContentInfo eContentType field.
要保护的X.400内容必须放在SignedData encapContentInfo eContent字段中。请注意，此X.400内容应保持由内容类型定义的编码，但不应进行MIME包装。受保护X.400内容的内容类型的对象标识符必须放在SignedData encapContentInfo eContentType字段中。
The signedData object is encapsulated by a ContentInfo SEQUENCE with a contentType of id-signedData.
signedData对象由ContentInfo序列封装，contentType id为signedData。
Note that if SMTP [SMTP] is used to transport the resulting signed-only message then the optional MIME encoding SHOULD be used. If binary transports such as X.400 are used then the optional MIME encoding SHOULD NOT be used.
请注意，如果使用SMTP[SMTP]传输生成的仅签名邮件，则应使用可选的MIME编码。如果使用X.400等二进制传输，则不应使用可选的MIME编码。
There are many reasons for this requirement. An outer MIME wrapper should not be used in X.400. Further, there are places where X.400 systems will interact with SMTP/MIME systems where the outer MIME wrapper might be necessary. Because this wrapping is outside the security wrappers, any gateway system that might bridge the gap between the two systems will be smart enough to apply or remove the outer MIME wrapper as appropriate.
这一要求有很多原因。X.400中不应使用外部MIME包装。此外，X.400系统将在某些地方与SMTP/MIME系统交互，在这些地方可能需要外部MIME包装。由于此包装在安全包装之外，因此任何可能在两个系统之间架起桥梁的网关系统都将足够智能，可以根据需要应用或删除外部MIME包装。
The signedData object MAY optionally be wrapped in MIME. This allows the system to support 7-bit transport when required. This outer MIME wrapper MAY be dynamically added or removed throughout the delivery path since it is outside the signature and encryption wrappers. In this case the application/pkcs7-mime type as defined in S/MIME Version 3.1 Message Specification [MSG] SHOULD be used with the following parameters:
signedData对象可以选择用MIME包装。这允许系统在需要时支持7位传输。此外部MIME包装可以在整个传递路径中动态添加或删除，因为它位于签名和加密包装之外。在这种情况下，S/mime版本3.1消息规范[MSG]中定义的application/pkcs7 mime类型应与以下参数一起使用：
Content-Type: application/pkcs7-mime; smime-type=signed-x400
Content-Transfer-Encoding: base64
Content-Type: application/pkcs7-mime; smime-type=signed-x400
Content-Transfer-Encoding: base64
If the application/pkcs7-mime MIME type is used to support 7-bit transport, the steps to create this format are:
如果应用程序/pkcs7 mime mime类型用于支持7位传输，则创建此格式的步骤如下：
Step 1. The X.400 content to be signed is ASN.1 encoded.
第一步。要签名的X.400内容是ASN.1编码的。
Step 2. The ASN.1 encoded X.400 content and other required data is processed into a CMS object of type SignedData. The SignedData structure is encapsulated by a ContentInfo SEQUENCE with a contentType of id-signedData.
第二步。ASN.1编码的X.400内容和其他所需数据被处理成SignedData类型的CMS对象。SignedData结构由ContentInfo序列封装，contentType id为SignedData。
Step 3. The CMS object is inserted into an application/pkcs7-mime MIME entity.
第三步。CMS对象被插入到应用程序/pkcs7 mime实体中。
The smime-type parameter for messages using application/pkcs7-mime with SignedData is "signed-x400" as defined in [TRANSPORT].
使用带有SignedData的application/pkcs7 mime的消息的smime类型参数为[TRANSPORT]中定义的“signed-x400”。
This section describes the format for enveloping an X.400 content without signing it. It is important to note that sending enveloped but not signed messages does not provide for data integrity. It is possible to replace ciphertext in such a way that the processed message will still be valid, but the meaning is altered.
本节介绍在不签名的情况下封装X.400内容的格式。需要注意的是，发送封装但未签名的消息不会提供数据完整性。以这样的方式替换密文是可能的，即处理后的消息仍然有效，但其含义会发生改变。
The EnvelopedData format as described in [CMS] is used for confidentiality of the X.400 contents.
[CMS]中所述的信封数据格式用于X.400内容的保密性。
The X.400 content to be protected MUST be placed in the EnvelopedData encryptedContentInfo encryptedContent field. Note that this X.400 content SHOULD maintain the encoding defined by the content type, but SHOULD NOT be MIME wrapped. The object identifier for content type of the protected X.400 content MUST be placed in the EnvelopedData encryptedContentInfo contentType field.
要保护的X.400内容必须放在EnvelopedData encryptedContentInfo encryptedContent字段中。请注意，此X.400内容应保持由内容类型定义的编码，但不应进行MIME包装。受保护X.400内容的内容类型的对象标识符必须放在EnvelopedData encryptedContentInfo contentType字段中。
The envelopedData object is encapsulated by a ContentInfo SEQUENCE with a contentType of id-envelopedData.
envelopedData对象由ContentInfo序列封装，contentType id为envelopedData。
Note that if SMTP is used to transport the resulting enveloped-only message then the optional MIME encoding SHOULD be used. If other transport (e.g., X.400) that is optimized for binary content is used then the optional MIME encoding SHOULD NOT be used.
请注意，如果使用SMTP传输生成的仅包含信封的邮件，则应使用可选的MIME编码。如果使用针对二进制内容进行优化的其他传输（如X.400），则不应使用可选的MIME编码。
The envelopedData object MAY optionally be wrapped in MIME. This allows the system to support 7-bit transport when required. This outer MIME wrapper MAY be dynamically added or removed throughout the delivery path since it is outside the signature and encryption wrappers. In this case, the application/pkcs7-mime type as defined in S/MIME Version 3.1 Message Specification [MSG] SHOULD be used with the following parameters:
envelopedData对象可以选择用MIME进行包装。这允许系统在需要时支持7位传输。此外部MIME包装可以在整个传递路径中动态添加或删除，因为它位于签名和加密包装之外。在这种情况下，S/mime版本3.1消息规范[MSG]中定义的application/pkcs7 mime类型应与以下参数一起使用：
Content-Type: application/pkcs7-mime; smime-type=enveloped-x400
Content-Transfer-Encoding: base64
Content-Type: application/pkcs7-mime; smime-type=enveloped-x400
Content-Transfer-Encoding: base64
If the application/pkcs7-mime MIME type is used to support 7-bit transport, the steps to create this format are:
如果应用程序/pkcs7 mime mime类型用于支持7位传输，则创建此格式的步骤如下：
Step 1. The X.400 content to be enveloped is ASN.1 encoded.
第一步。要封装的X.400内容是ASN.1编码的。
Step 2. The ASN.1 encoded X.400 content and other required data is processed into a CMS object of type EnvelopedData. In addition to encrypting a copy of the content-encryption key for each recipient, a copy of the content encryption key SHOULD be encrypted for the originator and included in the EnvelopedData (see [CMS] Section 6). The EnvelopedData structure is encapsulated by a ContentInfo SEQUENCE with a contentType of id-envelopedData.
第二步。ASN.1编码的X.400内容和其他所需数据被处理为EnvelopedData类型的CMS对象。除了为每个收件人加密一份内容加密密钥副本外，还应为发起人加密一份内容加密密钥副本，并将其包含在信封数据中（见[CMS]第6节）。EnvelopedData结构由ContentInfo序列封装，contentType id为EnvelopedData。
Step 3. The CMS object is inserted into an application/pkcs7-mime MIME entity to allow for 7-bit transport.
第三步。CMS对象被插入到application/pkcs7 mime实体中，以允许7位传输。
If the application/pkcs7-mime MIME entity is used, the smime-type parameter for enveloped-only messages is "enveloped-x400" as defined in [TRANSPORT].
如果使用应用程序/pkcs7 mime mime实体，则仅封装消息的smime类型参数为[TRANSPORT]中定义的“enveloped-x400”。
To achieve signing and enveloping, any of the signed-only and encrypted-only CMS objects may be nested.
为了实现签名和封装，可以嵌套任何仅签名和仅加密的CMS对象。
When nesting is used, backwards compatibility with S/MIME version 2 requires that each layer of the nested message are identified with the OID id-data, and when id-data is used a MIME wrapper is required. This can potentially lead to an enormous amount of overhead and should be avoided. Because S/MIME version 2 compatibility is of no concern, implementations SHOULD directly encode the encapsulated object as the eContent of the current structure.
当使用嵌套时，与S/MIME版本2的向后兼容性要求用OID id数据标识嵌套消息的每一层，当使用id数据时，需要MIME包装器。这可能会导致巨大的开销，应该避免。由于不考虑S/MIME版本2的兼容性，实现应该直接将封装的对象编码为当前结构的eContent。
MIME wrapping to support 7-bit transport is optional and need only be used around the outermost CMS structure. In this case, the application/pkcs7 content type MUST be used.
支持7位传输的MIME包装是可选的，只需在最外层的CMS结构周围使用。在这种情况下，必须使用application/pkcs7内容类型。
An S/MIME implementation MUST be able to receive and process arbitrarily nested CMS structures within reasonable resource limits of the recipient computer.
S/MIME实现必须能够在接收方计算机的合理资源限制内接收和处理任意嵌套的CMS结构。
The Enhanced Security Services for S/MIME [ESS] document provides examples of how nested, secured S/MIME messages are formatted. ESS provides an example of how a triple-wrapped S/MIME message is formatted using application/pkcs7-mime for the signatures.
增强的S/MIME安全服务[ESS]文档提供了如何格式化嵌套的安全S/MIME消息的示例。ESS提供了一个示例，说明如何使用application/pkcs7 MIME对签名格式化三重包装的S/MIME消息。
This section explains how an X.400 content may be conveyed within a Triple Wrapped Message because S/MIME version 2 compatibility is of no concern:
本节解释了X.400内容如何在三层包装的消息中传输，因为S/MIME版本2的兼容性无关紧要：
Step 1. Start with the X.400 content (called the "original content"). The X.400 content MUST be ASN.1 encoded, but SHOULD NOT be MIME wrapped.
第一步。从X.400内容（称为“原始内容”）开始。X.400内容必须是ASN.1编码的，但不应该是MIME包装的。
Step 2. Place the ASN.1 encoded X.400 content to be protected in the SignedData encapContentInfo eContent field. Add any attributes that are to be signed.
第二步。将要保护的ASN.1编码的X.400内容放在SignedData encapContentInfo eContent字段中。添加要签名的任何属性。
Step 3. Sign the result of step 2 (the original content). The SignedData encapContentInfo eContentType MUST contain the object identifier of the X.400 content.
第三步。签署第2步的结果（原始内容）。SignedData encapContentInfo EcontType必须包含X.400内容的对象标识符。
Step 4. Encrypt the result of step 3 as a single block. The EnvelopedData encryptedContentInfo contentType MUST be set to id-signedData. This is called the "encrypted body".
第四步。将步骤3的结果加密为单个块。EnvelopedData encryptedContentInfo contentType必须设置为id signedData。这称为“加密体”。
Step 5. Using the same logic as in step 2 and 3 above, sign the result of step 4 (the encrypted body) as a single block. The SignedData encapContentInfo eContentType MUST be set to id-envelopedData. The outer SignedData structure is encapsulated by a ContentInfo SEQUENCE with a contentType of id-signedData.
第五步。使用与上面步骤2和步骤3相同的逻辑，将步骤4（加密体）的结果作为单个块签名。SignedData encapContentInfo eContentType必须设置为id envelopedData。外部SignedData结构由ContentInfo序列封装，contentType id为SignedData。
Step 6. The resulting message is called the "outer signature", and is also the triple wrapped message.
第六步。生成的消息称为“外部签名”，也是三重包装的消息。
MIME wrapping to support 7-bit transport is optional and MUST only be used around the outermost CMS structure. In this case, the application/pkcs7-mime content type MUST be used. The smime-type in the case of adding a MIME wrapper MUST be consistent with that appropriate to the innermost protection layer.
支持7位传输的MIME包装是可选的，必须仅在最外层的CMS结构周围使用。在这种情况下，必须使用application/pkcs7 mime内容类型。在添加MIME包装的情况下，smime类型必须与适用于最内层保护层的类型一致。
In some instances, an smime-type will be created that only reflects one security service (such as certs-only, which applies only to signed-only messages). However, as new layers are wrapped, this smime-type SHOULD be propagated upwards. Thus if a certs-only message were to be encrypted, or wrapped in a new SignedData structure, the smime-type of certs-only should be propagated up to the next MIME wrapper. In other words, the innermost type is reflected outwards.
在某些情况下，将创建一个仅反映一个安全服务的smime类型（例如仅证书，它仅适用于仅签名的消息）。但是，当新层被包装时，这个smime类型应该向上传播。因此，如果要对仅证书消息进行加密，或将其包装在新的SignedData结构中，则只应将smime类型的证书传播到下一个MIME包装器。换句话说，最里面的类型是向外反射的。
While the objectives of this document focus on protecting X.400 content with CMS wrappers, it is a reality that users do not generally send all message using security. It therefore stands to reason that a means to carry non-secured X.400 content over the chosen transport system must be seamlessly provided. While transporting X.400 content in an X.400 system is trivial, carrying X.400 content in SMTP requires additional definition.
虽然本文档的目标集中于使用CMS包装保护X.400内容，但实际上用户通常不会使用安全性发送所有消息。因此，必须无缝提供通过所选传输系统传输非安全X.400内容的方法，这是理所当然的。虽然在X.400系统中传输X.400内容很简单，但在SMTP中传输X.400内容需要额外的定义。
Content-Type: application/x400-content; content-type = 1*DIGIT *( "."
1*DIGIT)
Content-Type: application/x400-content; content-type = 1*DIGIT *( "."
1*DIGIT)
where the content-type parameter value is either a single integer (for a built-in content-type) or an OID in dotted notation (for an extended content-type).
其中，内容类型参数值要么是单个整数（对于内置内容类型），要么是虚线表示法中的OID（对于扩展内容类型）。
S/MIME v3.1 does not specify how to get a certificate from a certificate authority, but instead mandates that every sending agent already has a certificate. The PKIX Working Group has, at the time of this writing, produced two separate standards for certificate enrollment: CMP (RFC 2510) and CMC (RFC 2792).
S/MIME v3.1没有指定如何从证书颁发机构获取证书，而是要求每个发送代理都已经有一个证书。在撰写本文时，PKIX工作组已经为证书注册制定了两个单独的标准：CMP（RFC 2510）和CMC（RFC 2792）。
A receiving agent MUST provide some certificate retrieval mechanism in order to gain access to certificates for recipients of digital envelopes. This document does not cover how S/MIME agents handle certificates, only what they do after a certificate has been validated or rejected. S/MIME certification issues are covered in [CERT31].
接收代理必须提供某种证书检索机制，以便为数字信封的收件人访问证书。本文档不介绍S/MIME代理如何处理证书，只介绍它们在证书被验证或拒绝后的操作。[CERT31]中介绍了S/MIME认证问题。
At a minimum, for initial S/MIME deployment, a user agent could automatically generate a message to an intended recipient requesting that recipient's certificate in a signed return message. Receiving and sending agents SHOULD also provide a mechanism to allow a user to "store and protect" certificates for correspondents in such a way so as to guarantee their later retrieval.
对于初始S/MIME部署，用户代理至少可以自动生成一条消息，发送给指定的收件人，在签名的返回消息中请求该收件人的证书。接收和发送代理还应提供一种机制，允许用户以这种方式“存储和保护”通信员的证书，以保证其以后的检索。
End-entity certificates used in the context of this document MAY contain an X.400 address as described in [X.400]. The address must be in the form of an "ORAddress". The X.400 address SHOULD be in the subjectAltName extension, and SHOULD NOT be in the subject distinguished name.
本文件上下文中使用的终端实体证书可能包含[X.400]中所述的X.400地址。地址必须采用“ORAddress”的形式。X.400地址应位于subjectAltName扩展名中，而不应位于subject可分辨名称中。
Sending agents SHOULD make the originator address in the X.400 content (e.g., the "originator" field in P22) match an X.400 address in the signer's certificate.
发送代理应使X.400内容中的发起人地址（例如，第22页中的“发起人”字段）与签名人证书中的X.400地址匹配。
Receiving agents MUST recognize X.400 addresses in the subjectAltName field.
接收代理必须识别subjectAltName字段中的X.400地址。
Receiving agents SHOULD check that the originator address in the X.400 content matches an X.400 address in the signer's certificate, if X.400 addresses are present in the certificate and an originator address is available in the content. A receiving agent SHOULD provide some explicit alternate processing of the message if this
接收代理应检查X.400内容中的发起人地址是否与签名人证书中的X.400地址匹配，前提是证书中存在X.400地址，且内容中有发起人地址。如果出现以下情况，则接收代理应提供一些明确的消息替代处理
comparison fails, which may be to display a message that shows the recipient the addresses in the certificate or other certificate details.
比较失败，可能是显示一条消息，向收件人显示证书中的地址或其他证书详细信息。
The subject alternative name extension is used in S/MIME as the preferred means to convey the X.400 address(es) that correspond to the entity for this certificate. Any X.400 addresses present MUST be encoded using the x400Address CHOICE of the GeneralName type. Since the SubjectAltName type is a SEQUENCE OF GeneralName, multiple X.400 addresses MAY be present.
subject alternative name extension在S/MIME中用作传递与此证书的实体对应的X.400地址的首选方式。必须使用GeneralName类型的X400地址选项对存在的任何X.400地址进行编码。由于SubjectAltName类型是GeneralName的序列，因此可能存在多个X.400地址。
This specification introduces no new security concerns to the CMS or S/MIME models. Security issues are identified in section 5 of [MSG], section 6 of [ESS] and the Security Considerations section of [CMS].
本规范没有为CMS或S/MIME模型引入新的安全问题。安全问题见[MSG]第5节、[ESS]第6节和[CMS]的安全注意事项部分。
[CERT31] Ramsdell, B., Ed., "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Certificate Handling", RFC 3850, July 2004.
[CERT31]Ramsdell，B.，Ed.，“安全/多用途Internet邮件扩展（S/MIME）版本3.1证书处理”，RFC 38502004年7月。
[CMS] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3852, July 2004.
[CMS]Housley，R.，“加密消息语法（CMS）”，RFC 38522004年7月。
[CMSAES] Schaad, J., "Use of the AES Encryption Algorithm in CMS", RFC 3565, July 2003.
[CMSAES]Schaad，J.，“AES加密算法在CMS中的使用”，RFC 3565，2003年7月。
[CMSALG] Housley, R., "Cryptographic Message Syntax (CMS) Algorithms", RFC 3370, August 2002.
[CMSALG]Housley，R.，“加密消息语法（CMS）算法”，RFC3370，2002年8月。
[ESS] Hoffman, P., Editor "Enhanced Security Services for S/MIME", RFC 2634, June 1999.
[ESS]Hoffman，P.，编辑“S/MIME增强安全服务”，RFC 2634，1999年6月。
[MSG] Ramsdell, B., Ed., "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification", RFC 3851, July 2004.
[MSG]Ramsdell，B.，编辑，“安全/多用途互联网邮件扩展（S/MIME）版本3.1消息规范”，RFC 3851，2004年7月。
[MUSTSHOULD] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[MUSTSHOULD]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[TRANSPORT] Hoffman, P. and C. Bonatti, "Transporting Secure/Multipurpose Internet Mail Extensions (S/MIME) Objects in X.400", RFC 3855, July 2004.
[传输]Hoffman，P.和C.Bonatti，“在X.400中传输安全/多用途Internet邮件扩展（S/MIME）对象”，RFC 38552004年7月。
[X.400] ITU-T X.400 Series of Recommendations, Information technology - Message Handling Systems (MHS). X.400: System and Service Overview; X.402: Overall Architecture; X.411: Message Transfer System: Abstract Service Definition and Procedures; X.420: Interpersonal Messaging System; 1996.
[X.400]ITU-T X.400系列建议，信息技术-信息处理系统（MHS）。X.400：系统和服务概述；X.402：总体架构；X.411：消息传输系统：抽象服务定义和过程；X.420：人际信息系统；1996
[BODYMAP] Alvestrand, H., Ed., "Mapping between X.400 and RFC-822/MIME Message Bodies", RFC 2157, January 1998.
[BODYMAP]Alvestrand，H.，Ed.“X.400和RFC-822/MIME消息体之间的映射”，RFC 2157，1998年1月。
[MIXER] Kille, S., Ed., "MIXER (Mime Internet X.400 Enhanced Relay): Mapping between X.400 and RFC 822/MIME", RFC 2156, January 1998.
[MIXER]Kille，S.，编辑，“MIXER（Mime互联网X.400增强中继）：X.400和RFC 822/Mime之间的映射”，RFC 2156，1998年1月。
[SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April, 2001.
[SMTP]Klensin，J.，“简单邮件传输协议”，RFC 28212001年4月。
Paul Hoffman Internet Mail Consortium 127 Segre Place Santa Cruz, CA 95060 USA
保罗·霍夫曼互联网邮件联盟127塞格雷广场圣克鲁斯，加利福尼亚州95060
EMail: phoffman@imc.org
EMail: phoffman@imc.org
Chris Bonatti IECA, Inc. 15309 Turkey Foot Road Darnestown, MD 20878-3640 USA
Chris Bonatti IECA，Inc.美国马里兰州达内斯敦土耳其脚路15309号，邮编：20878-3640
EMail: bonattic@ieca.com
EMail: bonattic@ieca.com
Anders Eggen Forsvarets Forskningsinstitutt Postboks 25 2027 Kjeller, Norway
Anders Eggen Forsvarets Forskiningsinstitutt Postboks 25 2027挪威基勒
EMail: anders.eggen@ffi.no
EMail: anders.eggen@ffi.no
Copyright (C) The Internet Society (2004). 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.
版权所有（C）互联网协会（2004年）。本文件受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 currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。