Network Working Group P. Hoffman
Request for Comments: 3855 IMC
Category: Standards Track C. Bonatti
IECA
July 2004
Network Working Group P. Hoffman
Request for Comments: 3855 IMC
Category: Standards Track C. Bonatti
IECA
July 2004
Transporting Secure/Multipurpose Internet Mail Extensions (S/MIME) Objects in X.400
在X.400中传输安全/多用途Internet邮件扩展（S/MIME）对象
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 protocol options for conveying objects that have been protected using the Cryptographic Message Syntax (CMS) and Secure/Multipurpose Internet Mail Extensions (S/MIME) version 3.1 over an X.400 message transfer system.
本文档描述了通过X.400消息传输系统传输已使用加密消息语法（CMS）和安全/多用途Internet邮件扩展（S/MIME）版本3.1保护的对象的协议选项。
The techniques described in the Cryptographic Message Syntax [CMS] specification and message specifications can reasonably be transported via a variety of electronic mail systems. This specification defines the options and values necessary to enable interoperable transport of S/MIME messages over an X.400 system.
加密消息语法[CMS]规范和消息规范中描述的技术可以通过各种电子邮件系统进行合理传输。本规范定义了在X.400系统上实现S/MIME消息互操作传输所需的选项和值。
This document describes a mechanism for using CMS objects as the message content of X.400 messages in a native X.400 environment. This means that gateways or other functions that expect to deal with IPMS, such as those specified in [MIXER] and [BODYMAP], cannot do anything with these messages. Note that cooperating S/MIME agents must support common forms of message content in order to achieve interoperability.
本文档描述了在原生X.400环境中使用CMS对象作为X.400消息内容的机制。这意味着期望处理IPM的网关或其他功能（如[MIXER]和[BODYMAP]中指定的功能）无法处理这些消息。请注意，为了实现互操作性，协作的S/MIME代理必须支持常见形式的消息内容。
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。
Object Identifier (OID): A globally unique identifier value consisting of a sequence of integer values assigned through distributed registration as specified by ISO/IEC 8824.
对象标识符（OID）：一个全局唯一标识符值，由ISO/IEC 8824规定的通过分布式注册分配的整数值序列组成。
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位数据的通道发送。
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实现的向后兼容性。
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能够确定消息对特定用户的可交付性，并使用户代理和消息存储能够解释和处理内容。
Some X.400 content types further refine the structure of content as a set of heading elements and body parts. An example of this is the Interpersonal Messaging System (IPMS). The IPMS content structure is able to convey zero or more arbitrary body parts each identified by the body part type. The body part type is an ASN.1 OID or Integer that denotes the syntax and semantics of the body part in question.
一些X.400内容类型将内容结构进一步细化为一组标题元素和正文部分。人际信息系统（IPMS）就是一个例子。IPMS内容结构能够传输零个或多个任意身体部位，每个部位由身体部位类型标识。body part类型是一个ASN.1 OID或整数，表示所讨论的body part的语法和语义。
When transporting a CMS-protected message in X.400, the preferred approach (except as discussed in section 2.3 below) is to convey the object as X.400 message content. This section describes how S/MIME CMS objects are conveyed as the content part of X.400 messages. This mechanism is suitable for transport of CMS-protected messages regardless of the mail content that has been encapsulated.
在X.400中传输CMS保护的消息时，首选方法（下文第2.3节讨论的除外）是将对象作为X.400消息内容传输。本节描述S/MIME CMS对象如何作为X.400消息的内容部分进行传输。此机制适用于传输受CMS保护的邮件，而不考虑已封装的邮件内容。
Implementations MUST include the CMS object in the content field of the X.400 message.
实现必须在X.400消息的内容字段中包含CMS对象。
If the CMS object is covered by an outer MIME wrapper, the content-type field of the P1 envelope MUST be set to the following CMS-defined value:
如果CMS对象由外部MIME包装覆盖，则P1信封的内容类型字段必须设置为以下CMS定义的值：
id-data OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
rsadsi(113549) pkcs(1) pkcs7(7) 1 }
id-data OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
rsadsi(113549) pkcs(1) pkcs7(7) 1 }
If the CMS object is not covered by an outer MIME wrapper, the content-type field of the P1 envelope MUST be set to the following CMS-defined value:
如果CMS对象未被外部MIME包装覆盖，则P1信封的内容类型字段必须设置为以下CMS定义的值：
id-ct-contentInfo OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)
content-types(1) 6}
id-ct-contentInfo OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)
content-types(1) 6}
When transporting a plaintext MIME object in X.400, the preferred approach is to convey the object as X.400 message content. The
在X.400中传输明文MIME对象时，首选方法是将该对象作为X.400消息内容进行传输。这个
content-type field of the P1 envelope MUST be set to the following CMS-defined value:
P1信封的内容类型字段必须设置为以下CMS定义的值：
id-data OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
rsadsi(113549) pkcs(1) pkcs7(7) 1 }
id-data OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
rsadsi(113549) pkcs(1) pkcs7(7) 1 }
Under some circumstances S/MIME CMS-protected messages can be conveyed within select body parts of the content. Implementations generally SHOULD NOT embed CMS objects within X.400 body parts, but should instead convey them as content as described in section 2.2. Nevertheless, one notable exception is necessary for the case of forwarding.
在某些情况下，受S/MIME CMS保护的消息可以在内容的选定正文部分中传递。实现通常不应将CMS对象嵌入X.400身体部位，而应将其作为第2.2节所述的内容进行传达。然而，对于转发的情况，有一个值得注意的例外是必要的。
In instances when CMS objects are forwarded as part of a message forwarding function, use of a body part is necessary. When forwarding a CMS object in an IPMS or IPMS-compatible body part, implementations MUST use the content-body-part as formally defined by [X.400], as shown below for reference.
当CMS对象作为消息转发功能的一部分被转发时，有必要使用正文部分。在IPMS或与IPMS兼容的正文部分中转发CMS对象时，实现必须使用[X.400]正式定义的内容正文部分，如下所示以供参考。
content-body-part {ExtendedContentType:content-type}
EXTENDED-BODY-PART-TYPE ::= {
PARAMETERS {ForwardedContentParameters IDENTIFIED BY
{id-ep-content -- concatenated with content-type -- }},
DATA {Content IDENTIFIED BY
{id-et-content -- concatenated with content-type -- }} }
content-body-part {ExtendedContentType:content-type}
EXTENDED-BODY-PART-TYPE ::= {
PARAMETERS {ForwardedContentParameters IDENTIFIED BY
{id-ep-content -- concatenated with content-type -- }},
DATA {Content IDENTIFIED BY
{id-et-content -- concatenated with content-type -- }} }
ForwardedContentParameters ::= SET {
delivery-time [0] MessageDeliveryTime OPTIONAL,
delivery-envelope [1] OtherMessageDeliveryFields OPTIONAL,
mts-identifier [2] MessageDeliveryIdentifier OPTIONAL }
ForwardedContentParameters ::= SET {
delivery-time [0] MessageDeliveryTime OPTIONAL,
delivery-envelope [1] OtherMessageDeliveryFields OPTIONAL,
mts-identifier [2] MessageDeliveryIdentifier OPTIONAL }
id-ep-content ::= {joint-iso-itu-t(2) mhs(6) ipms(1) ep(11) 17}
id-ep-content ::= {joint-iso-itu-t(2) mhs(6) ipms(1) ep(11) 17}
id-et-content ::= {joint-iso-itu-t(2) mhs(6) ipms(1) et(4) 17}
id-et-content ::= {joint-iso-itu-t(2) mhs(6) ipms(1) et(4) 17}
The implementation MUST copy the CMS object to be forwarded into the Content field of the content-body-part. The direct-reference field of the body part MUST include the OID formed by the concatenation of the id-et-content value and the following CMS-defined value.
实现必须将要转发的CMS对象复制到内容主体部分的内容字段中。身体部位的直接参考字段必须包括由id et内容值和以下CMS定义值串联而成的OID。
id-ct-contentInfo OBJECT IDENTIFIER ::=
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
pkcs-9(9) smime(16) content-types(1) 6}
id-ct-contentInfo OBJECT IDENTIFIER ::=
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
pkcs-9(9) smime(16) content-types(1) 6}
For example, to forward any CMS object the DATA component of the body part would be identified by { 2 6 1 4 17 1 2 840 113549 1 9 16 1 6 }.
例如，要转发任何CMS对象，身体部位的数据组件将由{2 6 1 4 17 1 2 840 113549 1 9 16 1 6}标识。
The ForwardedContentParameters are optional and MAY be supported at the discretion of the implementor. The OID value id-et-content MAY also be included in the original-encoded-information-types field of the X.400 message envelope at the discretion of the sending S/MIME agent.
ForwardedContentParameters是可选的，可由实现者自行决定是否支持。OID值id et内容也可以由发送S/MIME代理决定包含在X.400消息信封的原始编码信息类型字段中。
In this instance, the content-type field of the P1 envelope MUST be set to the value associate with the forwarding content (e.g., integer 22 for IPMS).
在这种情况下，P1信封的内容类型字段必须设置为与转发内容相关联的值（例如，IPMS的整数22）。
According to various S/MIME specifications for message wrapping, CMS objects MAY optionally be wrapped in MIME to dynamically support 7- bit transport. This outer wrapping is not required for X.400 transport, and generally SHOULD NOT be applied in a homogeneous X.400 environment. Heterogeneous mail systems or other factors MAY require the presence of this outer MIME wrapper
根据消息包装的各种S/MIME规范，CMS对象可以选择用MIME包装，以动态支持7位传输。X.400运输不需要这种外包装，通常不应在均匀的X.400环境中使用。异构邮件系统或其他因素可能需要此外部MIME包装器
In [MSG], the application/pkcs7-mime content type and optional "smime-type" parameter are used to convey details about the security applied (signed or enveloped) along with information about the contained content. This may aid receiving S/MIME implementations in correctly processing the secured content. Additional values of smime-type are defined in [ESS]. In an X.400 transport environment, MIME typing is not available. Therefore the equivalent semantic is conveyed using the Encoded Information Types (EITs). The EITs are conveyed in the original-encoded-information-types field of the X.400 message envelope. This memo defines the following smime-types.
在[MSG]中，application/pkcs7 mime content type和可选的“smime type”参数用于传递有关应用（签名或封装）的安全性的详细信息以及有关包含内容的信息。这可能有助于接收S/MIME实现以正确处理安全内容。smime类型的其他值在[ESS]中定义。在X.400传输环境中，MIME类型不可用。因此，使用编码信息类型（EIT）传达等效语义。EIT在X.400消息信封的原始编码信息类型字段中传输。此备忘录定义了以下smime类型。
+-----------------------------------------------------+
| |
| smime-type EIT Value (OID) |
| CMS protection type Inner Content |
| |
+-----------------------------------------------------+
| |
| enveloped-data id-eit-envelopedData |
| EnvelopedData Data |
| |
| signed-data id-eit-signedData |
| SignedData Data |
| |
| certs-only id-eit-certsOnly |
| SignedData empty (zero-length content) |
| |
| signed-receipt id-eit-signedReceipt |
| SignedData Receipt |
| |
| enveloped-x400 id-eit-envelopedx400 |
| EnvelopedData X.400 content |
| |
| signed-x400 id-eit-signedx400 |
| SignedData X.400 content |
| |
| compressed-data id-eit-compressedData |
| CompressedData RFC 3274 compression wrapper |
| |
+-----------------------------------------------------+
+-----------------------------------------------------+
| |
| smime-type EIT Value (OID) |
| CMS protection type Inner Content |
| |
+-----------------------------------------------------+
| |
| enveloped-data id-eit-envelopedData |
| EnvelopedData Data |
| |
| signed-data id-eit-signedData |
| SignedData Data |
| |
| certs-only id-eit-certsOnly |
| SignedData empty (zero-length content) |
| |
| signed-receipt id-eit-signedReceipt |
| SignedData Receipt |
| |
| enveloped-x400 id-eit-envelopedx400 |
| EnvelopedData X.400 content |
| |
| signed-x400 id-eit-signedx400 |
| SignedData X.400 content |
| |
| compressed-data id-eit-compressedData |
| CompressedData RFC 3274 compression wrapper |
| |
+-----------------------------------------------------+
Sending agents SHOULD include the appropriate S/MIME EIT OID value. Receiving agents SHOULD recognize S/MIME OID values in the EITs field, and process the message appropriately according to local procedures.
发送代理应包括适当的S/MIME EIT OID值。接收代理应识别EITs字段中的S/MIME OID值，并根据本地过程适当处理消息。
In order that consistency can be obtained in future S/MIME EIT assignments, the following guidelines should be followed when assigning new EIT values. Values assigned for S/MIME EITs should correspond to assigned smime-type values on a one-to-one basis. The restrictions of section 3.2.2 of [MSG] therefore apply. S/MIME EIT values may coexist with other EIT values intended to further qualify the makeup of the protected content.
为了在未来的S/MIME EIT分配中获得一致性，在分配新EIT值时应遵循以下准则。为S/MIME EIT指定的值应与指定的smime类型值一一对应。因此，[MSG]第3.2.2节的限制适用。S/MIME EIT值可能与其他EIT值共存，以进一步限定受保护内容的构成。
The enveloped data EIT indicates that the X.400 content field contains a MIME type that has been protected by the CMS enveloped-data content type in accordance with [MSG]. The resulting enveloped data CMS content is conveyed in accordance with section 2.2. This EIT should be indicated by the following OID value:
封装数据EIT表示X.400内容字段包含一个MIME类型，该类型已根据[MSG]受到CMS封装数据内容类型的保护。根据第2.2节传送产生的封装数据内容。该EIT应由以下OID值表示：
id-eit-envelopedData OBJECT IDENTIFIER ::=
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
pkcs-9(9) smime(16) id-eit(10) id-eit-envelopedData(1) }
id-eit-envelopedData OBJECT IDENTIFIER ::=
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
pkcs-9(9) smime(16) id-eit(10) id-eit-envelopedData(1) }
The signed data EIT indicates that the X.400 content field contains a MIME type that has been protected by the CMS signed-data content type in accordance with [MSG]. The resulting signed data CMS content is conveyed in accordance with section 2.2. This EIT should be indicated by the following OID value:
签名数据EIT表示X.400内容字段包含一个MIME类型，该类型已根据[MSG]受到CMS签名数据内容类型的保护。根据第2.2节传送产生的签名数据内容。该EIT应由以下OID值表示：
id-eit-signedData OBJECT IDENTIFIER ::=
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
pkcs-9(9) smime(16) id-eit(10) id-eit-signedData(2) }
id-eit-signedData OBJECT IDENTIFIER ::=
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
pkcs-9(9) smime(16) id-eit(10) id-eit-signedData(2) }
The certs-only message is used to transport certificates and/or CRLs, such as in response to a registration request. This is described in [CERT31]. The certs-only message consists of a single instance of CMS content of type signed-data. The encapContentInfo eContent field MUST be absent and signerInfos field MUST be empty. The resulting certs-only CMS content is conveyed in accordance with section 2.2. This EIT should be indicated by the following OID value:
“仅证书”消息用于传输证书和/或CRL，例如响应注册请求。这在[CERT31]中有描述。certs only消息由签名数据类型的CMS内容的单个实例组成。encapContentInfo eContent字段必须不存在，signerInfos字段必须为空。根据第2.2节的规定，仅传送证书CMS内容。该EIT应由以下OID值表示：
id-eit-certsOnly OBJECT IDENTIFIER ::=
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
pkcs-9(9) smime(16) id-eit(10) id-eit-certsOnly(3) }
id-eit-certsOnly OBJECT IDENTIFIER ::=
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
pkcs-9(9) smime(16) id-eit(10) id-eit-certsOnly(3) }
The signed receipt EIT indicates that the X.400 content field contains a Receipt content that has been protected by the CMS signed-data content type in accordance with [ESS]. The resulting CMS signed-data content is conveyed in accordance with section 2.2. This EIT should be indicated by the following OID value:
签名收据EIT表示X.400内容字段包含已根据[ESS]受CMS签名数据内容类型保护的收据内容。产生的CMS签名数据内容按照第2.2节进行传输。该EIT应由以下OID值表示：
id-eit-signedReceipt OBJECT IDENTIFIER ::=
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
pkcs-9(9) smime(16) id-eit(10) id-eit-signedReceipt(4) }
id-eit-signedReceipt OBJECT IDENTIFIER ::=
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
pkcs-9(9) smime(16) id-eit(10) id-eit-signedReceipt(4) }
The enveloped X.400 EIT indicates that the X.400 content field contains X.400 content that has been protected by the CMS enveloped-data content type in accordance with [X400WRAP]. The resulting enveloped X.400 CMS content is conveyed in accordance with section 2.2. This EIT should be indicated by the following OID value:
封装的X.400 EIT表示X.400内容字段包含X.400内容，该内容已根据[X400WRAP]受到CMS封装数据内容类型的保护。根据第2.2节的规定传送最终封装的X.400 CMS内容。该EIT应由以下OID值表示：
id-eit-envelopedX400 OBJECT IDENTIFIER ::=
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
pkcs-9(9) smime(16) id-eit(10) id-eit-envelopedX400(5) }
id-eit-envelopedX400 OBJECT IDENTIFIER ::=
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
pkcs-9(9) smime(16) id-eit(10) id-eit-envelopedX400(5) }
The signed X.400 EIT indicates that the X.400 content field contains X.400 content that has been protected by the CMS signed-data content type in accordance with [X400WRAP]. The resulting signed X.400 CMS content is conveyed in accordance with section 2.2. This EIT should be indicated by the following OID value:
签名的X.400 EIT表示X.400内容字段包含X.400内容，该内容已根据[X400WRAP]受到CMS签名数据内容类型的保护。根据第2.2节的规定传达最终签名的X.400 CMS内容。该EIT应由以下OID值表示：
id-eit-signedX400 OBJECT IDENTIFIER ::=
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
pkcs-9(9) smime(16) id-eit(10) id-eit-signedX400(6) }
id-eit-signedX400 OBJECT IDENTIFIER ::=
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
pkcs-9(9) smime(16) id-eit(10) id-eit-signedX400(6) }
The compressed data EIT indicates that the X.400 content field contains a another type that has been compressed by the compressed-data content type in accordance with [COMPRESS]. The resulting CMS content is conveyed in accordance with section 2.2. This EIT should be indicated by the following OID value:
压缩数据EIT表示X.400内容字段包含另一种类型，该类型已根据[压缩]由压缩数据内容类型压缩。根据第2.2节传送产生的CMS内容。该EIT应由以下OID值表示：
id-eit-compressedData OBJECT IDENTIFIER ::=
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
pkcs-9(9) smime(16) id-eit(10) id-eit-compressedData(7) }
id-eit-compressedData OBJECT IDENTIFIER ::=
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
pkcs-9(9) smime(16) id-eit(10) id-eit-compressedData(7) }
Care should be taken in the selection of X.400 services to be used in conjunction with CMS objects. Services affecting conversion of the content, expansion of Distribution Lists (DLs), and message redirection can interact badly with services provided by the "EnvelopedData" and "SignedData" CMS content types.
在选择与CMS对象一起使用的X.400服务时应小心。影响内容转换、通讯组列表（DLs）扩展和消息重定向的服务可能会与“EnvelopedData”和“SignedData”CMS内容类型提供的服务发生严重交互。
MTS conversion is not applicable to the scenario of this document because such conversion is incompatible with CMS protection mechanisms. X.400 systems that implement conversion services should generally be unable to attempt conversion of CMS content types because those types do not conform to X.420 structure rules. Nevertheless, when transporting CMS objects within an X.400 environment, the Conversion Prohibition service SHOULD be selected.
MTS转换不适用于本文档的场景，因为此类转换与CMS保护机制不兼容。实现转换服务的X.400系统通常无法尝试转换CMS内容类型，因为这些类型不符合X.420结构规则。然而，在X.400环境中传输CMS对象时，应选择转换禁止服务。
X.400 message redirection services can have an indirect impact on the application of the CMS "EnvelopedData" content type. Several different forms of redirection are possible in X.400, including:
X.400消息重定向服务可能会对CMS“EnvelopedData”内容类型的应用产生间接影响。X.400中有几种不同形式的重定向，包括：
- Originator Requested Alternate Recipient (ORAR) - Alternate Recipient Assignment - Redirection of Incoming Messages
- 发起人请求的备用收件人（ORAR）-备用收件人分配-传入邮件的重定向
In addition, any auto-forwarding services that are not security-aware may share the same problem. An auto-forwarding implementation that removes the EnvelopedData and reapplies it for the forwarded recipient is not affected by this problem. The normal case is that the private key is not available when the human user is not present, thus decryption is not possible. However, if the private key is present, forwarding can be used instead.
此外，任何不具备安全意识的自动转发服务都可能存在相同的问题。删除信封数据并为转发的收件人重新应用该数据的自动转发实现不受此问题的影响。正常情况下，当人类用户不存在时，私钥不可用，因此无法解密。但是，如果存在私钥，则可以使用转发。
When the "EnvelopedData" content type is used to protect message contents, an instance of RecipientInfo is needed for each recipient and alternate recipient in order to ensure the desired access to the message. A RecipientInfo for the originator is a good practice just in case the MTS returns the whole message.
当“EnvelopedData”内容类型用于保护邮件内容时，每个收件人和备用收件人都需要RecipientInfo实例，以确保对邮件的所需访问。为发起者提供RecipientInfo是一种很好的做法，以防MTS返回整个消息。
In the event that ORAR is used, the originator is aware of the identity of the alternate recipient and SHOULD include a corresponding RecipientInfo element. For other forms of redirection (including non-security-aware auto-forwarding) the alternate recipient must either have access to the intended recipient's keys (not recommended) or must relay the message to the intended recipient by other means.
在使用ORAR的情况下，发起者知道替代接收者的身份，并应包括相应的RecipientInfo元素。对于其他形式的重定向（包括无安全意识的自动转发），备用收件人必须能够访问预期收件人的密钥（不推荐），或者必须通过其他方式将邮件转发给预期收件人。
X.400 DLs can have an indirect impact on the application of the CMS "EnvelopedData" content type. When the "EnvelopedData" content type is used to protect message contents, an instance of RecipientInfo is needed for each recipient in order to ensure the desired access to
X.400 DLs可能对CMS“信封数据”内容类型的应用产生间接影响。当使用“EnvelopedData”内容类型来保护邮件内容时，每个收件人都需要RecipientInfo实例，以确保所需的访问权限
the message. Messages to a DL would typically include only a single RecipientInfo associated with the DL. Unlike Mail Lists (MLs) described in [ESS], however, X.400 DLs are not generally security-aware and do not regenerate RecipientInfo elements for the DL members. It is recommended that a security-aware ML conforming to [ESS] be used in preference to X.400 DLs. When transporting CMS objects within an X.400 environment, the DL Expansion Prohibited service SHOULD be selected.
信息。发送到DL的消息通常只包含一个与DL关联的RecipientInfo。然而，与[ESS]中描述的邮件列表（MLs）不同，X.400 DLs通常不具备安全意识，并且不会为DL成员重新生成RecipientInfo元素。建议优先使用符合[ESS]的安全意识ML，而不是X.400 DLs。在X.400环境中传输CMS对象时，应选择DL扩展禁止服务。
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]的安全注意事项部分。
[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月。
[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月。
[COMPRESS] Gutmann, P., "Compressed Data Content Type for Cryptographic Message Syntax (CMS)", RFC 3274, June 2002.
[COMPRESS]Gutmann，P.，“加密消息语法（CMS）的压缩数据内容类型”，RFC 3274，2002年6月。
[ESS] Hoffman, P., Ed., "Enhanced Security Services for S/MIME", RFC 2634, June 1999.
[ESS]Hoffman，P.，Ed.“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月。
[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., "Mapping between X.400 and RFC-822/MIME Message Bodies", RFC 2157, January 1998.
[BODYMAP]Alvestrand，H.，“X.400和RFC-822/MIME消息体之间的映射”，RFC 2157，1998年1月。
[MIXER] Kille, S., "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月。
[X400WRAP] Hoffman, P., Bonatti, C., and A. Eggen, "Securing X.400 Content with Secure/Multipurpose Internet Mail Extensions (S/MIME), RFC 3854, July 2004.
[X400WRAP]Hoffman，P.，Bonatti，C.，和A.Eggen，“使用安全/多用途Internet邮件扩展（S/MIME）保护X.400内容”，RFC 3854，2004年7月。
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
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编辑功能的资金目前由互联网协会提供。