Network Working Group T. Dean
Request for Comments: 3183 W. Ottaway
Category: Experimental QinetiQ
October 2001
Network Working Group T. Dean
Request for Comments: 3183 W. Ottaway
Category: Experimental QinetiQ
October 2001
Domain Security Services using S/MIME
使用S/MIME的域安全服务
Status of this Memo
本备忘录的状况
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
这份备忘录为互联网社区定义了一个实验性协议。它没有规定任何类型的互联网标准。要求进行讨论并提出改进建议。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2001). All Rights Reserved.
版权所有（C）互联网协会（2001年）。版权所有。
Abstract
摘要
This document describes how the S/MIME (Secure/Multipurpose Internet Mail Extensions) protocol can be processed and generated by a number of components of a communication system, such as message transfer agents, guards and gateways to deliver security services. These services are collectively referred to as 'Domain Security Services'.
本文档描述了通信系统的许多组件如何处理和生成S/MIME（安全/多用途Internet邮件扩展）协议，如消息传输代理、警卫和网关，以提供安全服务。这些服务统称为“域安全服务”。
Acknowledgements
致谢
Significant comments were made by Luis Barriga, Greg Colla, Trevor Freeman, Russ Housley, Dave Kemp, Jim Schaad and Michael Zolotarev.
路易斯·巴里加、格雷格·科拉、特雷弗·弗里曼、罗斯·霍斯利、戴夫·坎普、吉姆·沙德和迈克尔·佐洛塔雷夫发表了重要评论。
The S/MIME [1] series of standards define a data encapsulation format for the provision of a number of security services including data integrity, confidentiality, and authentication. S/MIME is designed for use by messaging clients to deliver security services to distributed messaging applications.
S/MIME[1]系列标准定义了一种数据封装格式，用于提供许多安全服务，包括数据完整性、机密性和身份验证。S/MIME是为消息传递客户端设计的，用于向分布式消息传递应用程序提供安全服务。
The mechanisms described in this document are designed to solve a number of interoperability problems and technical limitations that arise when different security domains wish to communicate securely, for example when two domains use incompatible messaging technologies such as the X.400 series and SMTP/MIME, or when a single domain wishes to communicate securely with one of its members residing on an untrusted domain. The scenarios covered by this document are domain-to-domain, individual-to-domain and domain-to-individual
本文档中描述的机制旨在解决不同安全域希望安全通信时出现的许多互操作性问题和技术限制，例如，当两个域使用不兼容的消息传递技术（如X.400系列和SMTP/MIME）时，或者，当单个域希望与其驻留在不受信任域上的成员之一进行安全通信时。本文档涵盖的场景包括域到域、个人到域和域到个人
communications. This document is also applicable to organizations and enterprises that have internal PKIs which are not accessible by the outside world, but wish to interoperate securely using the S/MIME protocol.
通讯。本文档也适用于拥有外部世界无法访问的内部PKI，但希望使用S/MIME协议安全地进行互操作的组织和企业。
There are many circumstances when it is not desirable or practical to provide end-to-end (desktop-to-desktop) security services, particularly between different security domains. An organization that is considering providing end-to-end security services will typically have to deal with some if not all of the following issues:
在许多情况下，提供端到端（桌面到桌面）安全服务是不可取或不实际的，特别是在不同的安全域之间。考虑提供端到端安全服务的组织通常必须处理以下一些问题（如果不是全部的话）：
1) Heterogeneous message access methods: Users are accessing mail using mechanisms which re-format messages, such as using Web browsers. Message reformatting in the Message Store makes end-to-end encryption and signature validation impossible.
1) 异构消息访问方法：用户使用重新格式化消息的机制（如使用Web浏览器）访问邮件。消息存储中的消息重新格式化使端到端加密和签名验证无法进行。
2) Message screening and audit: Server-based mechanisms such as searching for prohibited words or other content, virus scanning, and audit, are incompatible with end-to-end encryption.
2) 邮件筛选和审核：基于服务器的机制（如搜索禁止的单词或其他内容、病毒扫描和审核）与端到端加密不兼容。
3) PKI deployment issues: There may not be any certificate paths between two organizations. Or an organization may be sensitive about aspects of its PKI and unwilling to expose them to outside access. Also, full PKI deployment for all employees, may be expensive, not necessary or impractical for large organizations. For any of these reasons, direct end-to-end signature validation and encryption are impossible.
3) PKI部署问题：两个组织之间可能没有任何证书路径。或者，一个组织可能对其PKI的某些方面很敏感，不愿意让外部访问。此外，为所有员工部署完整的PKI可能成本高昂，对于大型组织来说不必要或不切实际。出于上述任何原因，直接端到端签名验证和加密都是不可能的。
4) Heterogeneous message formats: One organization using X.400 series protocols wishes to communicate with another using SMTP. Message reformatting at gateways makes end-to-end encryption and signature validation impossible.
4) 异构消息格式：使用X.400系列协议的一个组织希望使用SMTP与另一个组织通信。网关上的消息重新格式化使端到端加密和签名验证变得不可能。
This document describes an approach to solving these problems by providing message security services at the level of a domain or an organization. This document specifies how these 'domain security services' can be provided using the S/MIME protocol. Domain security services may replace or complement mechanisms at the desktop. For example, a domain may decide to provide desktop-to-desktop signatures but domain-to-domain encryption services. Or it may allow desktop-to-desktop services for intra-domain use, but enforce domain-based services for communication with other domains.
本文档描述了通过在域或组织级别提供消息安全服务来解决这些问题的方法。本文档指定如何使用S/MIME协议提供这些“域安全服务”。域安全服务可以替代或补充桌面上的机制。例如，域可能决定提供桌面到桌面签名，但不提供域到域加密服务。或者，它可能允许在域内使用桌面到桌面服务，但强制使用基于域的服务与其他域通信。
Domain services can also be used by individual members of a corporation who are geographically remote and who wish to exchange encrypted and/or signed messages with their base.
域服务也可由地理位置较远的公司的单个成员使用，这些成员希望与其基地交换加密和/或签名消息。
Whether or not a domain based service is inherently better or worse than desktop based solutions is an open question. Some experts believe that only end-to-end solutions can be truly made secure, while others believe that the benefits offered by such things as content checking at domain boundaries offers considerable increase in practical security for many real systems. The additional service of allowing signature checking at several points on a communications path is also an extra benefit in many situations. This debate is outside the scope of this document. What is offered here is a set of tools that integrators can tailor in different ways to meet different needs in different circumstances.
与基于桌面的解决方案相比，基于域的服务本质上是更好还是更差，这是一个悬而未决的问题。一些专家认为，只有端到端的解决方案才能真正做到安全，而另一些专家则认为，域边界的内容检查等功能带来的好处大大提高了许多实际系统的实际安全性。在许多情况下，允许在通信路径上的多个点进行签名检查的附加服务也是一个额外的好处。这一辩论超出了本文件的范围。这里提供的是一套工具，集成商可以以不同的方式定制，以满足不同环境下的不同需求。
Message transfer agents (MTAs), guards, firewalls and protocol translation gateways all provide domain security services. As with desktop based solutions, these components must be resilient against a wide variety of attacks intended to subvert the security services. Therefore, careful consideration should be given to security of these components, to make sure that their siting and configuration minimises the possibility of attack.
消息传输代理（MTA）、防护、防火墙和协议转换网关都提供域安全服务。与基于桌面的解决方案一样，这些组件必须能够抵御各种旨在破坏安全服务的攻击。因此，应仔细考虑这些组件的安全性，以确保其位置和配置将攻击的可能性降至最低。
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 [2].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[2]中所述进行解释。
This section gives an informal overview of the security services that are provided by S/MIME between different security domains. These services are provided by a combination of mechanisms in the sender's and recipient's domains.
本节非正式概述了S/MIME在不同安全域之间提供的安全服务。这些服务由发送方和接收方域中的机制组合提供。
Later sections describe definitively how these services map onto elements of the S/MIME protocol.
后面的部分将明确描述这些服务如何映射到S/MIME协议的元素上。
The following security mechanisms are specified in this document:
本文件规定了以下安全机制：
1. Domain signature 2. Review signature 3. Additional attributes signature 4. Domain encryption and decryption
1. 域签名2。审查签名3。附加属性签名4。域加密和解密
The signature types defined in this document are referred to as DOMSEC defined signatures.
本文档中定义的签名类型称为DOMSEC定义的签名。
The term 'security domain' as used in this document is defined as a collection of hardware and personnel operating under a single security authority and performing a common business function. Members of a security domain will of necessity share a high degree of mutual trust, due to their shared aims and objectives.
本文件中使用的术语“安全域”定义为在单一安全机构下运行并执行公共业务功能的硬件和人员的集合。安全领域的成员由于其共同的目的和目标，必然会有高度的互信。
A security domain is typically protected from direct outside attack by physical measures and from indirect (electronic) attack by a combination of firewalls and guards at network boundaries. The interface between two security domains is termed a 'security boundary'. One example of a security domain is an organizational network ('Intranet').
安全域通常通过物理措施防止直接的外部攻击，并通过防火墙和网络边界的防护措施防止间接（电子）攻击。两个安全域之间的接口称为“安全边界”。安全域的一个示例是组织网络（“Intranet”）。
A domain signature is an S/MIME signature generated on behalf of a set of users in a domain. A domain signature can be used to authenticate information sent between domains or between a certain domain and one of its individuals, for example, when two 'Intranets' are connected using the Internet, or when an Intranet is connected to a remote user over the Internet. It can be used when two domains employ incompatible signature schemes internally or when there are no certification links between their PKIs. In both cases messages from the originator's domain are signed over the original message and signature (if present) using an algorithm, key, and certificate which can be processed by the recipient(s) or the recipient(s) domain. A domain signature is sometimes referred to as an "organizational signature".
域签名是代表域中的一组用户生成的S/MIME签名。域签名可用于验证域之间或特定域与其个人之间发送的信息，例如，当两个“内部网”使用Internet连接时，或当内部网通过Internet连接到远程用户时。当两个域在内部使用不兼容的签名方案时，或者当它们的PKI之间没有认证链接时，可以使用它。在这两种情况下，来自发端人域的邮件都使用可由收件人或收件人域处理的算法、密钥和证书在原始邮件和签名（如果存在）上签名。域签名有时称为“组织签名”。
A third party may review messages before they are forwarded to the final recipient(s) who may be in the same or a different security domain. Organizational policy and good security practice often require that messages be reviewed before they are released to external recipients. Having reviewed a message, an S/MIME signature is added to it - a review signature. An agent could check the review signature at the domain boundary, to ensure that only reviewed messages are released.
第三方可以在将邮件转发给可能位于相同或不同安全域中的最终收件人之前查看邮件。组织策略和良好的安全实践通常要求在将邮件发布给外部收件人之前对其进行审查。审阅完邮件后，会向其添加一个S/MIME签名—审阅签名。代理可以检查域边界处的审阅签名，以确保仅发布已审阅的消息。
A third party can add additional attributes to a signed message. An S/MIME signature is used for this purpose - an additional attributes signature. An example of an additional attribute is the 'Equivalent Label' attribute defined in ESS [3].
第三方可以向签名邮件添加其他属性。S/MIME签名用于此目的—附加属性签名。附加属性的一个示例是ESS[3]中定义的“等效标签”属性。
Domain encryption is S/MIME encryption performed on behalf of a collection of users in a domain. Domain encryption can be used to protect information between domains, for example, when two 'Intranets' are connected using the Internet. It can also be used when end users do not have PKI/encryption capabilities at the desktop, or when two domains employ incompatible encryption schemes internally. In the latter case messages from the originator's domain are encrypted (or re-encrypted) using an algorithm, key, and certificate which can be decrypted by the recipient(s) or an entity in their domain. This scheme also applies to protecting information between a single domain and one of its members when both are connected using an untrusted network, e.g., the Internet.
域加密是代表域中的用户集合执行的S/MIME加密。域加密可用于保护域之间的信息，例如，当两个“内部网”使用Internet连接时。当终端用户在桌面上没有PKI/加密功能时，或者当两个域在内部使用不兼容的加密方案时，也可以使用该方法。在后一种情况下，来自发端人域的消息使用算法、密钥和证书进行加密（或重新加密），收件人或其域中的实体可以对这些算法、密钥和证书进行解密。该方案还适用于保护单个域与其成员之一之间的信息，前提是两者都使用不受信任的网络（如Internet）进行连接。
This section describes the S/MIME protocol elements that are used to provide the security services described above. ESS [3] introduces the concept of triple-wrapped messages that are first signed, then encrypted, then signed again. This document also uses this concept of triple-wrapping. In addition, this document also uses the concept of 'signature encapsulation'. 'Signature encapsulation' denotes a signed or unsigned message that is wrapped in a signature, this signature covering both the content and the first (inner) signature, if present.
本节介绍用于提供上述安全服务的S/MIME协议元素。ESS[3]引入了三重包装消息的概念，这些消息首先经过签名，然后经过加密，然后再次签名。本文件还使用了三重包装的概念。此外，本文档还使用了“签名封装”的概念“签名封装”表示封装在签名中的已签名或未签名消息，此签名涵盖内容和第一个（内部）签名（如果存在）。
Signature encapsulation MAY be performed on the inner and/or the outer signature of a triple-wrapped message.
签名封装可在三重包装消息的内部和/或外部签名上执行。
For example, the originator signs a message which is then encapsulated with an 'additional attributes' signature. This is then encrypted. A reviewer then signs this encrypted data, which is then encapsulated by a domain signature.
例如，发起者对消息进行签名，然后用“附加属性”签名对消息进行封装。然后对其进行加密。然后，审阅者对加密数据进行签名，然后通过域签名对加密数据进行封装。
There is a possibility that some policies will require signatures to be added in a specific order. By only allowing signatures to be added by encapsulation it is possible to determine the order in which the signatures have been added.
有些策略可能要求按特定顺序添加签名。通过仅允许通过封装添加签名，可以确定添加签名的顺序。
A DOMSEC defined signature MAY encapsulate a message in one of the following ways:
DOMSEC定义的签名可以以下列方式之一封装消息：
1) An unsigned message has an empty signature layer added to it (i.e., the message is wrapped in a signedData that has a signerInfos which contains no elements). This is to enable backward compatibility with S/MIME software that does not have a DOMSEC capability. Since the signerInfos will contain no signers
1) 未签名的消息中添加了一个空签名层（即，该消息包装在一个signedData中，该signedData包含一个不包含任何元素的signerInfos）。这是为了实现与不具有DOMSEC功能的S/MIME软件的向后兼容性。因为signerInfos将不包含任何签名者
the eContentType, within the EncapsulatedContentInfo, MUST be id-data as described in CMS [5]. However, the eContent field will contain the unsigned message instead of being left empty as suggested in section 5.2 in CMS [5]. This is so that when the DOMSEC defined signature is added, as defined in method 2) below, the signature will cover the unsigned message.
封装的ContentInfo中的eContentType必须是CMS[5]中描述的id数据。但是，eContent字段将包含未签名的消息，而不是CMS[5]第5.2节中建议的空消息。这样，当添加DOMSEC定义的签名（如下面方法2）中所定义）时，签名将覆盖未签名的消息。
2) Signature Encapsulation is used to wrap the original signed message with a DOMSEC defined signature. This is so that the DOMSEC defined signature covers the message and all the previously added signatures. Also, it is possible to determine that the DOMSEC defined signature was added after the signatures that are already there.
2) 签名封装用于使用DOMSEC定义的签名包装原始签名消息。这使得DOMSEC定义的签名覆盖了消息和所有先前添加的签名。此外，还可以确定DOMSEC定义的签名是在已经存在的签名之后添加的。
An entity receiving an S/MIME signed message would normally expect the signature to be that of the originator of the message. However, the message security services defined in this document require the recipient to be able to accept messages signed by other entities and/or the originator. When other entities sign the message the name in the certificate will not match the message sender's name. An S/MIME compliant implementation would normally flag a warning if there were a mismatch between the name in the certificate and the message sender's name. (This check prevents a number of types of masquerade attack.)
接收S/MIME签名消息的实体通常希望签名是消息的发起人的签名。但是，本文档中定义的邮件安全服务要求收件人能够接受由其他实体和/或发起者签名的邮件。当其他实体对邮件进行签名时，证书中的名称将与邮件发件人的名称不匹配。如果证书中的名称与消息发送者的名称不匹配，则符合S/MIME的实现通常会标记警告。（此检查可防止多种类型的伪装攻击。）
In the case of domain security services, this warning condition SHOULD be suppressed under certain circumstances. These circumstances are defined by a naming convention that specifies the form that the signers name SHOULD adhere to. Adherence to this naming convention avoids the problems of uncontrolled naming and the possible masquerade attacks that this would produce.
对于域安全服务，在某些情况下应抑制此警告条件。这些情况由指定签名人姓名应遵循的形式的命名约定定义。遵守此命名约定可以避免不受控制的命名问题以及由此可能产生的伪装攻击。
As an assistance to implementation, a signed attribute is defined to be included in the S/MIME signature - the 'signature type' attribute. On receiving a message containing this attribute, the naming convention checks are invoked.
作为对实现的帮助，已签名属性定义为包含在S/MIME签名中——“签名类型”属性。在接收到包含此属性的消息时，将调用命名约定检查。
Implementations conforming to this standard MUST support the naming convention for signature generation and verification. Implementations conforming to this standard MUST recognize the signature type attribute for signature verification. Implementations conforming to this standard MUST support the signature type attribute for signature generation.
符合本标准的实现必须支持签名生成和验证的命名约定。符合本标准的实现必须识别签名验证的签名类型属性。符合此标准的实现必须支持签名生成的签名类型属性。
The following naming conventions are specified for agents generating signatures specified in this document:
为生成本文档中指定的签名的代理指定以下命名约定：
* For a domain signature, an agent generating this signature MUST be named 'domain-signing-authority'
* 对于域签名，生成此签名的代理必须命名为“域签名机构”
* For a review signature, an agent generating this signature MUST be named 'review-authority'.
* 对于审核签名，生成此签名的代理必须命名为“审核机构”。
* For an additional attributes signature, an agent generating this signature MUST be named 'attribute-authority'.
* 对于附加属性签名，生成此签名的代理必须命名为“属性权限”。
This name shall appear as the 'common name (CN)' component of the subject field in the X.509 certificate. There MUST be only one CN component present. Additionally, if the certificate contains an RFC 822 address, this name shall appear in the end entity component of the address - on the left-hand side of the '@' symbol.
该名称应作为X.509证书中主题字段的“通用名称（CN）”组成部分出现。必须只存在一个CN组件。此外，如果证书包含RFC 822地址，则该名称应出现在地址的终端实体组件中，“@”符号的左侧。
In the case of a domain signature, an additional naming rule is defined: the 'name mapping rule'. The name mapping rule states that for a domain signing authority, the domain part of its name MUST be the same as, or an ascendant of, the domain name of the message originator(s) that it is representing. The domain part is defined as follows:
对于域签名，定义了一个额外的命名规则：“名称映射规则”。名称映射规则规定，对于域签名机构，其名称的域部分必须与其所代表的消息发起人的域名相同，或是其域名的升序。域部分的定义如下：
* In the case of an X.500 distinguished subject name of an X.509 certificate, the domain part is the country, organization, organizational unit, state, and locality components of the distinguished name.
* 对于X.509证书的X.500可分辨主题名，域部分是可分辨名称的国家、组织、组织单位、州和地区组成部分。
* In the case of an RFC 2247 distinguished name, the domain part is the domain components of the distinguished name.
* 对于RFC 2247可分辨名称，域部分是可分辨名称的域组件。
* If the certificate contains an RFC 822 address, the domain part is defined to be the RFC 822 address component on the right-hand side of the '@' symbol.
* 如果证书包含RFC 822地址，则域部分被定义为“@”符号右侧的RFC 822地址组件。
For example, a domain signing authority acting on behalf of John Doe
of the Acme corporation, whose distinguished name is 'cn=John Doe,
ou=marketing,o=acme,c=us' and whose e-mail address is
John.Doe@marketing.acme.com, could have a certificate containing a
distinguished name of
'cn=domain-signing-authority,o=acme,c=us' and an RFC 822 address of
'domain-signing-authority@acme.com'. If John Doe has an RFC 2247
For example, a domain signing authority acting on behalf of John Doe
of the Acme corporation, whose distinguished name is 'cn=John Doe,
ou=marketing,o=acme,c=us' and whose e-mail address is
John.Doe@marketing.acme.com, could have a certificate containing a
distinguished name of
'cn=domain-signing-authority,o=acme,c=us' and an RFC 822 address of
'domain-signing-authority@acme.com'. If John Doe has an RFC 2247
defined address of 'cn=John Doe,dc=marketing,dc=acme,dc=us' then an address of 'cn=domain-signing-authority,dc=acme,dc=us' could be used to represent the domain signing authority.
定义了“cn=John Doe，dc=marketing，dc=acme，dc=us”的地址，然后可以使用“cn=domain signing authority，dc=acme，dc=us”的地址来表示域签名权限。
When the X.500 distinguished subject name has consecutive organizational units and/or localities it is important to understand the ordering of these values in order to determine if the domain part of the domain signature is an ascendant. In this case, when parsing the distinguished subject name from the most significant component (i.e., country, locality or organization) the parsed organizational unit or locality is deemed to be the ascendant of consecutive (unparsed) organizational units or localities.
当X.500可分辨主题名称具有连续的组织单位和/或位置时，了解这些值的顺序非常重要，以便确定域签名的域部分是否为优势。在这种情况下，当从最重要的组成部分（即国家、地区或组织）解析可分辨主题名称时，解析的组织单位或地区被认为是连续（未解析）组织单位或地区的优势。
When parsing an RFC 2247 subject name from the most significant component (i.e., the 'dc' entry that represents the country, locality or organization) the parsed 'dc' entry is deemed to be the ascendant of consecutive (unparsed) 'dc' entries.
当从最重要的组成部分（即代表国家、地区或组织的“dc”条目）解析RFC 2247受试者名称时，解析的“dc”条目被认为是连续（未解析的）“dc”条目的优势。
For example, a domain signing authority acting on behalf of John Doe of the Acme corporation, whose distinguished name is 'cn=John Doe, ou=marketing,ou=defence,o=acme,c=us' and whose e-mail address is John.Doe@marketing.defence.acme.com, could have a certificate containing a distinguished name of 'cn=domain-signing-authority,ou=defence,o=acme,c=us' and an RFC 822 address of 'domain-signing-authority@defence.acme.com'. If John Doe has an RFC 2247 defined address of 'cn=John Doe,dc=marketing,dc=defense,dc=acme,dc=us' then the domain signing authority could have a distinguished name of 'cn=domain-signing-authority,dc=defence,dc=acme,dc=us'.
例如，代表Acme公司John Doe的域签名机构，其可分辨名称为'cn=John Doe，ou=marketing，ou=Defense，o=Acme，c=us'，其电子邮件地址为John。Doe@marketing.defence.acme.com，可以有一个包含可分辨名称'cn=域签名机构，ou=防御，o=acme，c=us'和RFC 822地址的“域签名”-authority@defence.acme.com'. 如果John Doe的RFC 2247定义地址为“cn=John Doe，dc=marketing，dc=defense，dc=acme，dc=us”，则域签名机构的可分辨名称为“cn=domain signing authority，dc=defense，dc=acme，dc=us”。
Any message received where the domain part of the domain signing agent's name does not match, or is not an ascendant of, the originator's domain name MUST be flagged.
如果域签名代理名称的域部分与发端人的域名不匹配或不是发端人的域名的优势，则必须标记收到的任何消息。
This naming rule prevents agents from one organization masquerading as domain signing authorities on behalf of another. For the other types of signature defined in this document, no such named mapping rule is defined.
此命名规则防止一个组织的代理冒充为另一个组织的域签名机构。对于本文档中定义的其他类型的签名，未定义此类命名映射规则。
Implementations conforming to this standard MUST support this name mapping convention as a minimum. Implementations MAY choose to supplement this convention with other locally defined conventions. However, these MUST be agreed between sender and recipient domains prior to secure exchange of messages.
符合此标准的实现必须至少支持此名称映射约定。实现可以选择使用其他本地定义的约定来补充此约定。但是，在安全交换邮件之前，必须在发件人和收件人域之间达成一致。
On verifying the signature, a receiving agent MUST ensure that the naming convention has been adhered to. Any message that violates the convention MUST be flagged.
在验证签名时，接收代理必须确保遵守命名约定。必须标记任何违反约定的消息。
An S/MIME signed attribute is used to indicate the type of signature. This should be used in conjunction with the naming conventions specified in the previous section. When an S/MIME signed message containing the signature type attribute is received it triggers the software to verify that the correct naming convention has been used.
S/MIME签名属性用于指示签名的类型。这应与上一节中指定的命名约定结合使用。当接收到包含签名类型属性的S/MIME签名消息时，它会触发软件以验证是否使用了正确的命名约定。
The ASN.1 [4] notation of this attribute is: -
该属性的ASN.1[4]符号为：-
SignatureType ::= SEQUENCE OF OBJECT IDENTIFIER
SignatureType ::= SEQUENCE OF OBJECT IDENTIFIER
id-sti OBJECT IDENTIFIER ::= {iso(1) member-body(2) us(840)
rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) 9 }
id-sti OBJECT IDENTIFIER ::= {iso(1) member-body(2) us(840)
rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) 9 }
-- signature type identifier
--签名类型标识符
If present, the SignatureType attribute MUST be a signed attribute, as defined in [5]. If the SignatureType attribute is absent and there are no further encapsulated signatures the recipient SHOULD assume that the signature is that of the message originator.
如果存在，SignatureType属性必须是[5]中定义的已签名属性。如果SignatureType属性不存在，并且没有进一步封装的签名，则收件人应假定该签名是消息发起人的签名。
All of the signatures defined here are generated and processed as described in [5]. They are distinguished by the presence of the following values in the SignatureType signed attribute:
此处定义的所有签名均按[5]中所述生成和处理。它们的区别在于SignatureType signed属性中存在以下值：
id-sti-domainSig OBJECT IDENTIFIER ::= { id-sti 2 }
-- domain signature.
id-sti-domainSig OBJECT IDENTIFIER ::= { id-sti 2 }
-- domain signature.
id-sti-addAttribSig OBJECT IDENTIFIER ::= { id-sti 3 }
-- additional attributes signature.
id-sti-addAttribSig OBJECT IDENTIFIER ::= { id-sti 3 }
-- additional attributes signature.
id-sti-reviewSig OBJECT IDENTIFIER ::= { id-sti 4 }
-- review signature.
id-sti-reviewSig OBJECT IDENTIFIER ::= { id-sti 4 }
-- review signature.
For completeness, an attribute type is also specified for an originator signature. However, this signature type is optional. It is defined as follows:
为了完整性，还为发起人签名指定了属性类型。但是，此签名类型是可选的。其定义如下：
id-sti-originatorSig OBJECT IDENTIFIER ::= { id-sti 1 }
-- originator's signature.
id-sti-originatorSig OBJECT IDENTIFIER ::= { id-sti 1 }
-- originator's signature.
All signature types, except the originator type, MUST encapsulate other signatures. Note a DOMSEC defined signature could be encapsulating an empty signature as defined in section 3.
除发起人类型外，所有签名类型都必须封装其他签名。注：DOMSEC定义的签名可以封装第3节中定义的空签名。
A SignerInfo MUST NOT include multiple instances of SignatureType. A signed attribute representing a SignatureType MAY include multiple instances of different SignatureType values as an AttributeValue of attrValues [5], as long as the SignatureType 'additional attributes' is not present.
SignerInfo不能包含SignatureType的多个实例。只要SignatureType“附加属性”不存在，表示SignatureType的签名属性可以包括不同SignatureType值的多个实例作为attrValues[5]的AttributeValue。
If there is more than one SignerInfo in a signerInfos (i.e., when different algorithms are used) then the SignatureType attribute in all the SignerInfos MUST contain the same content.
如果signerInfos中有多个SignerInfo（即，当使用不同的算法时），则所有signerInfos中的SignatureType属性必须包含相同的内容。
The following sections describe the conditions under which each of these types of signature may be generated, and how they are processed.
以下各节描述了生成每种类型签名的条件，以及如何处理这些签名。
A 'domain signature' is a proxy signature generated on a user's behalf in the user's domain. The signature MUST adhere to the naming conventions in 3.1.1, including the name mapping convention. A 'domain signature' on a message authenticates the fact that the message has been released from that domain. Before signing, a process generating a 'domain signature' MUST first satisfy itself of the authenticity of the message originator. This is achieved by one of two methods. Either the 'originator's signature' is checked, if S/MIME signatures are used inside a domain. Or if not, some mechanism external to S/MIME is used, such as the physical address of the originating client or an authenticated IP link.
“域签名”是代表用户在其域中生成的代理签名。签名必须遵守3.1.1中的命名约定，包括名称映射约定。消息上的“域签名”验证消息已从该域释放的事实。在签名之前，生成“域签名”的流程必须首先确认消息发起人的真实性。这是通过两种方法之一实现的。如果在域内使用s/MIME签名，则检查“发起人签名”。或者，如果不是，则使用S/MIME外部的某种机制，例如原始客户端的物理地址或经过身份验证的IP链路。
If the originator's authenticity is successfully verified by one of the above methods and all other signatures present are valid, including those that have been encrypted, a 'domain signature' can be added to a message.
如果通过上述方法之一成功验证了发端人的真实性，并且存在的所有其他签名（包括已加密的签名）均有效，则可以将“域签名”添加到邮件中。
If a 'domain signature' is added and the message is received by a Mail List Agent (MLA) there is a possibility that the 'domain signature' will be removed. To stop the 'domain signature' from being removed the steps in section 5 MUST be followed.
如果添加了“域签名”，并且邮件列表代理（MLA）接收到该邮件，则可能会删除“域签名”。要阻止删除“域签名”，必须遵循第5节中的步骤。
An entity generating a domain signature MUST do so using a certificate containing a subject name that follows the naming convention specified in 3.1.1.
生成域签名的实体必须使用包含符合3.1.1中指定的命名约定的主题名称的证书来生成域签名。
If the originator's authenticity is not successfully verified or all the signatures present are not valid, a 'domain signature' MUST NOT be generated.
如果未成功验证发端人的真实性或存在的所有签名无效，则不得生成“域签名”。
On reception, the 'domain signature' SHOULD be used to verify the authenticity of a message. A check MUST be made to ensure that both the naming convention and the name mapping convention have been used as specified in this standard.
接收时，应使用“域签名”来验证消息的真实性。必须进行检查，以确保按照本标准的规定使用了命名约定和名称映射约定。
A recipient can assume that successful verification of the domain signature also authenticates the message originator.
收件人可以假定域签名的成功验证也验证了消息发起人的身份。
If there is an originator signature present, the name in that certificate SHOULD be used to identify the originator. This information can then be displayed to the recipient.
如果存在发起人签名，则应使用该证书中的名称来识别发起人。然后可以向收件人显示此信息。
If there is no originator signature present, the only assumption that can be made is the domain the message originated from.
如果不存在发端人签名，则可以做出的唯一假设是消息的发端域。
A domain signer can be assumed to have verified any signatures that it encapsulates. Therefore, it is not necessary to verify these signatures before treating the message as authentic. However, this standard does not preclude a recipient from attempting to verify any other signatures that are present.
可以假定域签名者已验证其封装的任何签名。因此，在将消息视为真实消息之前，无需验证这些签名。但是，本标准不排除收件人尝试验证存在的任何其他签名。
The 'domain signature' is indicated by the presence of the value id-sti-domainSig in a 'signature type' signed attribute.
“域签名”由“签名类型”签名属性中的值id sti domainSig表示。
There MAY be one or more 'domain signature' signatures in an S/MIME encoding.
S/MIME编码中可能有一个或多个“域签名”签名。
The 'additional attributes' signature type indicates that the SignerInfo contains additional attributes that are associated with the message.
“additional attributes”（附加属性）签名类型表示SignerInfo包含与消息关联的附加属性。
All attributes in the applicable SignerInfo MUST be treated as additional attributes. Successful verification of an 'additional attributes' signature means only that the attributes are authentically bound to the message. A recipient MUST NOT assume that its successful verification also authenticates the message originator.
必须将适用SignerInfo中的所有属性视为附加属性。“附加属性”签名的成功验证仅意味着属性被真正绑定到消息。收件人不得假定其成功验证也验证了邮件发起人的身份。
An entity generating an 'additional attributes' signature MUST do so using a certificate containing a subject name that follows the naming convention specified in 3.1.1. On reception, a check MUST be made to ensure that the naming convention has been used.
生成“附加属性”签名的实体必须使用包含符合3.1.1中指定的命名约定的主题名称的证书进行签名。接收时，必须进行检查以确保使用了命名约定。
A signer MAY include any of the attributes listed in [3] or in this document when generating an 'additional attributes' signature. The following attributes have a special meaning, when present in an 'additional attributes' signature:
在生成“附加属性”签名时，签名人可以包括[3]或本文档中列出的任何属性。以下属性在“附加属性”签名中具有特殊含义：
1) Equivalent Label: label values in this attribute are to be treated as equivalent to the security label contained in an encapsulated SignerInfo, if present.
1) 等效标签：此属性中的标签值将被视为与封装的SignerInfo（如果存在）中包含的安全标签等效。
2) Security Label: the label value indicates the aggregate sensitivity of the inner message content plus any encapsulated signedData and envelopedData containers. The label on the original data is indicated by the value in the originator's signature, if present.
2) 安全标签：标签值表示内部消息内容加上任何封装的signedData和envelopedData容器的聚合敏感度。原始数据上的标签由发起人签名中的值表示（如果存在）。
An 'additional attributes' signature is indicated by the presence of the value id-sti-addAttribSig in a 'signature type' signed attribute. Other Object Identifiers MUST NOT be included in the sequence of OIDs if this value is present.
“附加属性”签名由“签名类型”签名属性中的值id sti addAttribSig表示。如果存在此值，则OID序列中不得包含其他对象标识符。
There MAY be multiple 'additional attributes' signatures in an S/MIME encoding.
S/MIME编码中可能有多个“附加属性”签名。
The review signature indicates that the signer has reviewed the message. Successful verification of a review signature means only that the signer has approved the message for onward transmission to the recipient(s). When the recipient is in another domain, a device on a domain boundary such as a Mail Guard or firewall may be configured to check review signatures. A recipient MUST NOT assume that its successful verification also authenticates the message originator.
审阅签名表示签名者已审阅邮件。审核签名的成功验证仅意味着签名人已批准将邮件转发给收件人。当收件人在另一个域中时，可以将域边界上的设备（如邮件防护或防火墙）配置为检查审阅签名。收件人不得假定其成功验证也验证了邮件发起人的身份。
An entity generating a signed review signature MUST do so using a certificate containing a subject name that follows the naming convention specified in 3.1.1. On reception, a check MUST be made to ensure that the naming convention has been used.
生成签名审查签名的实体必须使用包含符合3.1.1中规定的命名约定的主题名称的证书。接收时，必须进行检查以确保使用了命名约定。
A review signature is indicated by the presence of the value id-sti-reviewSig in a 'signature type' signed attribute.
“签名类型”签名属性中的值id sti reviewSig表示审阅签名。
There MAY be multiple review signatures in an S/MIME encoding.
S/MIME编码中可能有多个审阅签名。
The 'originator signature' is used to indicate that the signer is the originator of the message and its contents. It is included in this document for completeness only. An originator signature is indicated either by the absence of the signature type attribute, or by the presence of the value id-sti-originatorSig in a 'signature type' signed attribute.
“发起人签名”用于表示签名人是消息及其内容的发起人。本文件中包含的内容仅用于完整性。发起人签名由签名类型属性的缺失或“签名类型”签名属性中的值id sti originatorSig表示。
Message encryption may be performed by a third party on behalf of a set of originators in a domain. This is referred to as domain encryption. Message decryption may be performed by a third party on behalf of a set of recipients in a domain. This is referred to as domain decryption. The third party that performs these processes is referred to in this section as a "Domain Confidentiality Authority" (DCA). Both of these processes are described in this section.
消息加密可由第三方代表域中的一组发起者执行。这称为域加密。消息解密可由第三方代表域中的一组收件人执行。这称为域解密。执行这些过程的第三方在本节中称为“域保密机构”（DCA）。本节介绍了这两种过程。
Messages may be encrypted for decryption by the final recipient and/or by a DCA in the recipient's domain. The message may also be encrypted for decryption by a DCA in the originator's domain (e.g., for content analysis, audit, key word scanning, etc.). The choice of which of these is actually performed is a system specific issue that depends on system security policy. It is therefore outside the scope of this document. These processes of encryption and decryption processes are shown in the following table.
消息可由最终收件人和/或收件人域中的DCA加密解密。该消息还可以由发起人域中的DCA进行加密以解密（例如，用于内容分析、审计、关键字扫描等）。选择实际执行哪一项是系统特定的问题，取决于系统安全策略。因此，它不在本文件的范围内。下表显示了加密和解密过程的这些过程。
--------------------------------------------------------------------
| | Recipient Decryption | Domain Decryption |
|------------------------|----------------------|--------------------|
| Originator Encryption | Case(a) | Case(b) |
| Domain Encryption | Case(c) | Case(d) |
--------------------------------------------------------------------
--------------------------------------------------------------------
| | Recipient Decryption | Domain Decryption |
|------------------------|----------------------|--------------------|
| Originator Encryption | Case(a) | Case(b) |
| Domain Encryption | Case(c) | Case(d) |
--------------------------------------------------------------------
Case (a), encryption of messages by the originator for decryption by the final recipient(s), is described in CMS [5]. In cases (c) and (d), encryption is performed not by the originator but by the DCA in the originator's domain. In cases (b) and (d), decryption is performed not by the recipient(s) but by the DCA in the recipient's domain.
CMS[5]中描述了（a）种情况，即发起人对消息进行加密，以供最终收件人解密。在（c）和（d）种情况下，加密不是由发起人执行的，而是由发起人域中的DCA执行的。在情况（b）和（d）中，解密不是由接收方执行的，而是由接收方域中的DCA执行的。
A client implementation that conforms to this standard MUST support case (b) for transmission, case (c) for reception and case (a) for transmission and reception.
符合本标准的客户机实现必须支持案例（b）用于传输，案例（c）用于接收，案例（A）用于传输和接收。
A DCA implementation that conforms to this standard MUST support cases (c) and (d), for transmission, and cases (b) and (d) for reception. In cases (c) and (d) the 'domain signature' SHOULD be applied before the encryption. In cases (b) and (d) the message SHOULD be decrypted before the originators 'domain signature' is obtained and verified.
符合本标准的DCA实现必须支持用于传输的情况（c）和（d），以及用于接收的情况（b）和（d）。在（c）和（d）种情况下，应在加密之前应用“域签名”。在（b）和（d）种情况下，应在获得和验证发端人的“域签名”之前解密消息。
The process of encryption and decryption is documented in CMS [5]. The only additional requirement introduced by domain encryption and decryption is for greater flexibility in the management of keys, as described in the following subsections. As with signatures, a naming convention and name mapping convention are used to locate the correct public key.
CMS[5]中记录了加密和解密过程。域加密和解密引入的唯一附加要求是密钥管理的更大灵活性，如下小节所述。与签名一样，命名约定和名称映射约定用于定位正确的公钥。
The mechanisms described below are applicable both to key agreement and key transport systems, as documented in CMS [5]. The phrase 'encryption key' is used as a collective term to cover the key management keys used by both techniques.
如下所述的机制适用于关键协议和关键传输系统，如CMS[5]中所述。短语“加密密钥”用作一个集合术语，以涵盖两种技术使用的密钥管理密钥。
The mechanisms below are also applicable to individual roving users who wish to encrypt messages that are sent back to base.
下面的机制也适用于希望加密发送回base的消息的个人巡回用户。
A DCA MUST be named 'domain-confidentiality-authority'. This name MUST appear in the 'common name(CN)' component of the subject field in the X.509 certificate. Additionally, if the certificate contains an RFC 822 address, this name MUST appear in the end entity part of the address, i.e., on the left-hand side of the '@' symbol.
DCA必须命名为“域保密机构”。此名称必须出现在X.509证书中“主题”字段的“通用名称（CN）”组件中。此外，如果证书包含RFC 822地址，则该名称必须出现在地址的结束实体部分，即“@”符号的左侧。
Along with this naming convention, an additional naming rule is defined: the 'name mapping rule'. The name mapping rule states that for a DCA, the domain part of its name MUST be the same as, or an ascendant of (as defined in section 3.1.1), the domain name of the set of entities that it represents. The domain part is defined as follows:
除了此命名约定之外，还定义了一个额外的命名规则：“名称映射规则”。名称映射规则规定，对于DCA，其名称的域部分必须与它所代表的一组实体的域名相同，或是其上升部分（如第3.1.1节所定义）。域部分的定义如下：
* In the case of an X.500 distinguished name of an X.509 certificate, the domain part is the country, organization, organizational unit, state, and locality components of the distinguished name.
* 对于X.509证书的X.500可分辨名称，域部分是可分辨名称的国家、组织、组织单位、州和地区组件。
* In the case of an RFC 2247 distinguished name, the domain part is the domain components of the distinguished name.
* 对于RFC 2247可分辨名称，域部分是可分辨名称的域组件。
* If the certificate contains an RFC 822 address, the domain part is defined to be the RFC 822 address part on the right-hand side of the '@' symbol.
* 如果证书包含RFC 822地址，则域部分被定义为“@”符号右侧的RFC 822地址部分。
For example, a DCA acting on behalf of John Doe of the Acme corporation, whose distinguished name is 'cn=John Doe,ou=marketing, o=acme,c=us' and whose e-mail address is John.Doe@marketing.acme.com, could have a certificate containing a distinguished name of 'cn=domain-confidentiality-authority,o=acme,c=us' and an e-mail address of 'domain-confidentiality-authority@acme.com'. If John Doe has an RFC 2247 defined address of 'cn=John Doe,dc=marketing, dc=defense,dc=acme,dc=us' then the domain signing authority could have a distinguished name of 'cn=domain-signing-authority,dc=defence,dc=acme,dc=us'. The key associated with this certificate would be used for encrypting messages for John Doe.
例如，代表Acme公司John Doe的DCA，其识别名称为'cn=John Doe，ou=marketing，o=Acme，c=us'，其电子邮件地址为John。Doe@marketing.acme.com，可以有一个包含可分辨名称'cn=域保密机构，o=acme，c=us'和“域机密性”的电子邮件地址-authority@acme.com'. 如果John Doe的RFC 2247定义地址为“cn=John Doe，dc=marketing，dc=defense，dc=acme，dc=us”，则域签名机构的可分辨名称为“cn=domain signing authority，dc=defense，dc=acme，dc=us”。与此证书关联的密钥将用于加密John Doe的消息。
Any message received where the domain part of the domain encrypting agents name does not match, or is not an ascendant of, the domain name of the entities it represents MUST be flagged.
如果域加密代理名称的域部分与它所代表的实体的域名不匹配或不是其优势，则必须标记收到的任何消息。
This naming rule prevents messages being encrypted for the wrong domain decryption agent.
此命名规则防止为错误的域解密代理加密消息。
Implementations conforming to this standard MUST support this name mapping convention as a minimum. Implementations may choose to supplement this convention with other locally defined conventions. However, these MUST be agreed between sender and recipient domains prior to sending any messages.
符合此标准的实现必须至少支持此名称映射约定。实现可以选择使用其他本地定义的约定来补充此约定。但是，在发送任何邮件之前，必须在发件人和收件人域之间达成一致。
At the sender's domain, DCA encryption is achieved using the recipient DCA's certificate or the end recipient's certificate. For this, the encrypting process must be able to correctly locate the certificate for the corresponding DCA in the recipient's domain or the one corresponding to the end recipient. Having located the correct certificate, the encryption process is then performed and additional information required for decryption is conveyed to the recipient in the recipientInfo field as specified in CMS [5]. A DCA encryption agent MUST be named according to the naming convention specified in section 4.1. This is so that the corresponding certificate can be found.
在发送方的域中，使用接收方的DCA证书或最终接收方的证书实现DCA加密。为此，加密过程必须能够正确定位收件人域中相应DCA的证书或与最终收件人对应的证书。找到正确的证书后，将执行加密过程，并按照CMS[5]中的规定，在recipientInfo字段中将解密所需的附加信息传送给收件人。DCA加密代理必须根据第4.1节规定的命名约定进行命名。这样可以找到相应的证书。
No specific method for locating the certificate to the corresponding DCA in the recipient's domain or the one corresponding to the end recipient is mandated in this document. An implementation may choose to access a local certificate store to locate the correct certificate. Alternatively, a X.500 or LDAP directory may be used in one of the following ways:
本文档中没有强制规定将证书定位到收件人域中相应的DCA或最终收件人对应的DCA的特定方法。实现可以选择访问本地证书存储来定位正确的证书。或者，X.500或LDAP目录可通过以下方式之一使用：
1. The directory may store the DCA certificate in the recipient's directory entry. When the user certificate attribute is requested, this certificate is returned.
1. 目录可以将DCA证书存储在收件人的目录条目中。当请求用户证书属性时，将返回此证书。
2. The encrypting agent maps the recipient's name to the DCA name in the manner specified in 4.1. The user certificate attribute associated with this directory entry is then obtained.
2. 加密代理以4.1中指定的方式将收件人的名称映射到DCA名称。然后获取与此目录项关联的用户证书属性。
This document does not mandate either of these processes. Whichever one is used, the name mapping conventions must be adhered to, in order to maintain confidentiality.
本文件不强制执行这两个过程中的任何一个。无论使用哪一种，都必须遵守名称映射约定，以保持机密性。
Having located the correct certificate, the encryption process is then performed. A recipientInfo for the DCA or end recipient is then generated, as described in CMS [5].
找到正确的证书后，将执行加密过程。然后生成DCA或最终收件人的recipientInfo，如CMS[5]所述。
DCA encryption may be performed for decryption by the end recipient and/or by a DCA. End recipient decryption is described in CMS [5]. DCA decryption is described in section 4.3.
可由最终接收者和/或由DCA执行DCA加密以进行解密。CMS[5]中描述了最终收件人解密。第4.3节描述了DCA解密。
DCA decryption uses a private-key belonging to the DCA and the necessary information conveyed in the DCA's recipientInfo field.
DCA解密使用属于DCA的私钥和DCA的recipientInfo字段中传递的必要信息。
It should be noted that domain decryption can be performed on messages encrypted by the originator and/or by a DCA in the originator's domain. In the first case, the encryption process is described in CMS [5]; in the second case, the encryption process is described in 4.2.
应该注意的是，域解密可以对由发端人和/或由发端人域中的DCA加密的消息执行。在第一种情况下，在CMS[5]中描述了加密过程；在第二种情况下，4.2中描述了加密过程。
5. Applying a Domain Signature when Mail List Agents are Present.
5. 存在邮件列表代理时应用域签名。
It is possible that a message leaving a DOMSEC domain may encounter a Mail List Agent (MLA) before it reaches the final recipient. There is a possibility that this would result in the 'domain signature' being stripped off the message. We do not want a MLA to remove the 'domain signature'. Therefore, the 'domain signature' must be applied to the message in such a way that will prevent a MLA from removing it.
离开DOMSEC域的邮件可能在到达最终收件人之前遇到邮件列表代理（MLA）。这可能会导致“域签名”从消息中剥离。我们不希望MLA删除“域签名”。因此，“域签名”必须以防止MLA删除的方式应用于消息。
A MLA will search a message for the "outer" signedData layer, as defined in ESS [3] section 4.2, and strip off all signedData layers that encapsulate this "outer" signedData layer. Where this "outer" signedData layer is found will depend on whether the message contains a mlExpansionHistory attribute or an envelopedData layer.
MLA将在邮件中搜索ESS[3]第4.2节中定义的“外部”signedData层，并去除封装该“外部”signedData层的所有signedData层。找到此“外部”signedData层的位置将取决于消息是否包含mlExpansionHistory属性或envelopedData层。
There is a possibility that a message leaving a DOMSEC domain has already been processed by a MLA, in which case a 'mlExpansionHistory' attribute will be present within the message.
离开DOMSEC域的消息可能已经由MLA处理，在这种情况下，“mlExpansionHistory”属性将出现在消息中。
There is a possibility that the message will contain an envelopedData layer. This will be the case when the message has been encrypted within the domain for the domain's "Domain Confidentiality Authority", see section 4.0, and, possibly, the final recipient.
消息可能包含信封数据层。当邮件已在域内为域的“域保密机构”（见第4.0节）加密，并且可能为最终收件人加密时，就会出现这种情况。
How the 'domain signature' is applied will depend on what is already present within the message. Before the 'domain signature' can be applied the message MUST be searched for the "outer" signedData layer, this search is complete when one of the following is found: -
如何应用“域签名”将取决于消息中已经存在的内容。在应用“域签名”之前，必须在邮件中搜索“外部”signedData层，当找到以下任一项时，此搜索即完成：-
- The "outer" signedData layer that includes an mlExpansionHistory attribute or encapsulates an envelopedData object. - An envelopedData layer. - The original content (that is, a layer that is neither envelopedData nor signedData).
- 包含mlExpansionHistory属性或封装envelopedData对象的“外部”signedData层。-包络数据层原始内容（即，既不是信封数据也不是签名数据的层）。
If a signedData layer containing a mlExpansionHistory attribute has been found then: -
如果找到包含mlExpansionHistory属性的signedData层，则：-
1) Strip off the signedData layer (after remembering the included signedAttributes).
1) 去掉signedData层（记住包含的SignedAttribute之后）。
2) Search the rest of the message until an envelopedData layer or the original content is found.
2) 搜索邮件的其余部分，直到找到信封数据层或原始内容。
3) a) If an envelopedData layer has been found then: -
3) a） 如果已找到信封数据层，则：-
- Strip off all the signedData layers down to the envelopedData layer. - Locate the RecipientInfo for the local DCA and use the information it contains to obtain the message key. - Decrypt the encryptedContent using the message key. - Encapsulate the decrypted message with a 'domain signature' - If local policy requires the message to be encrypted using S/MIME encryption before leaving the domain then encapsulate the 'domain signature' with an envelopedData layer containing RecipientInfo structures for each of the recipients and an originatorInfo value built from information describing this DCA.
- 剥离所有signedData层，直至包络数据层。-找到本地DCA的RecipientInfo并使用其包含的信息获取消息密钥。-使用消息密钥解密加密内容。-使用“域签名”封装解密的邮件-如果本地策略要求在离开域之前使用S/MIME加密对邮件进行加密，则使用包含每个收件人的RecipientInfo结构的envelopedData层和根据信息生成的originatorInfo值封装“域签名”描述此DCA。
If local policy does not require the message to be encrypted using S/MIME encryption but there is an envelopedData at a lower level within the message then the 'domain signature' MUST be encapsulated by an envelopedData as described above.
如果本地策略不要求使用S/MIME加密对消息进行加密，但消息中存在较低级别的envelopedData，则“域签名”必须如上所述由envelopedData封装。
An example when it may not be local policy to require S/MIME encryption is when there is a link crypto present.
例如，当存在链接加密时，要求S/MIME加密可能不是本地策略。
b) If an envelopedData layer has not been found then: -
b) 如果未找到信封数据层，则：-
- Encapsulate the new message with a 'domain signature'.
- 用“域签名”封装新消息。
4) Encapsulate the new message in a signedData layer, adding the signedAttributes from the signedData layer that contained the mlExpansionHistory attribute.
4) 将新消息封装在signedData层中，从包含mlExpansionHistory属性的signedData层添加SignedAttribute。
If no signedData layer containing a mlExpansionHistory attribute has been found but an envelopedData has been found then: -
如果未找到包含mlExpansionHistory属性的signedData层，但找到了envelopedData，则：-
1) Strip off all the signedData layers down to the envelopedData layer. 2) Locate the RecipientInfo for the local DCA and use the information it contains to obtain the message key. 3) Decrypt the encryptedContent using the message key. 4) Encapsulate the decrypted message with a 'domain signature' 5) If local policy requires the message to be encrypted before leaving the domain then encapsulate the 'domain signature' with an envelopedData layer containing RecipientInfo structures for each of the recipients and an originatorInfo value built from information describing this DCA.
1) 将所有signedData层剥离到envelopedData层。2） 找到本地DCA的RecipientInfo，并使用其中包含的信息获取消息密钥。3） 使用消息密钥解密加密内容。4） 使用“域签名”封装解密的邮件5）如果本地策略要求在离开域之前对邮件进行加密，则使用包含每个收件人的RecipientInfo结构的envelopedData层以及根据描述此DCA的信息构建的originatorInfo值封装“域签名”。
If local policy does not require the message to be encrypted using S/MIME encryption but there is an envelopedData at a lower level within the message then the 'domain signature' MUST be encapsulated by an envelopedData as described above.
如果本地策略不要求使用S/MIME加密对消息进行加密，但消息中存在较低级别的envelopedData，则“域签名”必须如上所述由envelopedData封装。
If no signedData layer containing a mlExpansionHistory attribute has been found and no envelopedData has been found then: -
如果未找到包含mlExpansionHistory属性的signedData层，且未找到envelopedData，则：-
1) Encapsulate the message in a 'domain signature'.
1) 将消息封装在“域签名”中。
The following examples help explain the above rules. All of the signedData objects are valid and none of them are a domain signature. If a signedData object was a domain signature then it would not be necessary to validate any further signedData objects.
以下示例有助于解释上述规则。所有signedData对象都是有效的，并且没有一个是域签名。如果signedData对象是域签名，则无需验证任何其他signedData对象。
1) A message (S1 (Original Content)) (where S = signedData) in which the signedData does not include an mlExpansionHistory attribute is to have a 'domain signature' applied. The signedData, S1, is verified. No "outer" signedData is found, after searching for one as defined above, since the original content is found, nor is an envelopedData or a mlExpansionHistory attribute found. A new signedData layer, S2, is created that contains a 'domain signature', resulting in the following message sent out of the domain (S2 (S1 (Original Content))).
1) 如果消息（S1（原始内容））（其中S=signedData）中的signedData不包含mlExpansionHistory属性，则将应用“域签名”。已验证签名数据S1。由于找到了原始内容，因此在搜索如上定义的外部签名数据后，找不到“外部”签名数据，也找不到envelopedData或mlExpansionHistory属性。创建一个新的signedData层S2，该层包含“域签名”，从而将以下消息发送出域（S2（S1（原始内容）））。
2) A message (S3 (S2 (S1 (Original Content))) in which none of the signedData layers includes an mlExpansionHistory attribute is to have a 'domain signature' applied. The signedData objects S1, S2 and S3 are verified. There is not an original, "outer" signedData layer since the original content is found, nor is an envelopedData or a mlExpansionHistory attribute found. A new signedData layer, S4, is created that contains a 'domain signature', resulting in the following message sent out of the domain (S4 (S3 (S2 (S1 (Original Content))).
2) 一种消息（S3（S2（S1（原始内容）），其中没有一个signedData层包含mlExpansionHistory属性。已验证signedData对象S1、S2和S3。没有原始的“外部”signedData层，因为找到了原始内容，也没有找到envelopedData或mlExpansionHistory属性。将创建一个新的signedData层S4，该层包含“域签名”，从而将以下消息发送出域（S4（S3（S2（S1（原始内容）））。
3) A message (E1 (S1 (Original Content))) (where E = envelopedData) in which S1 does not include a mlExpansionHistory attribute is to have a 'domain signature' applied. There is not an original, received "outer" signedData layer since the envelopedData, E1, is found at the outer layer. The encryptedContent is decrypted. The signedData, S1, is verified. The decrypted content is wrapped in a new signedData layer, S2, which contains a 'domain signature'. If local policy requires the message to be encrypted, using S/MIME encryption, before it leaves the domain then this new message is wrapped in an envelopedData layer, E2, resulting in the following message sent out of the domain (E2 (S2 (S1 (Original Content)))), else the message is not wrapped in an envelopedData layer resulting in the following message (S2 (S1 (Original Content))) being sent.
3) S1不包含mlExpansionHistory属性的消息（E1（S1（原始内容））（其中E=信封数据）将应用“域签名”。由于信封数据E1位于外层，因此没有收到的原始“外部”签名数据层。加密的内容被解密。已验证签名数据S1。解密的内容被包装在一个新的signedData层S2中，该层包含一个“域签名”。如果本地策略要求在消息离开域之前使用S/MIME加密对其进行加密，则此新消息将包装在信封数据层E2中，从而导致以下消息从域发送出去（E2（S2（S1（原始内容）），否则，该消息未包装在信封数据层中，导致发送以下消息（S2（S1（原始内容））。
4) A message (S2 (E1 (S1 (Original Content)))) in which S2 includes a mlExpansionHistory attribute is to have a 'domain signature' applied. The signedData object S2 is verified. The mlExpansionHistory attribute is found in S2, so S2 is the "outer" signedData. The signed attributes in S2 are remembered for later inclusion in the new outer signedData that is applied to the message. S2 is stripped off and the message is decrypted. The signedData object S1 is verified. The decrypted message is wrapped in a signedData layer, S3, which contains a 'domain signature'. If local policy requires the message to be encrypted, using S/MIME encryption, before it leaves the domain then this new message is wrapped in an envelopedData layer, E2. A new signedData layer, S4, is then wrapped around the envelopedData,
4) S2包含mlExpansionHistory属性的消息（S2（E1（S1（原始内容）））将应用“域签名”。已验证signedData对象S2。mlExpansionHistory属性位于S2中，因此S2是“外部”签名数据。S2中的已签名属性将被记住，以便稍后包含在应用于消息的新外部已签名数据中。S2被剥离，消息被解密。验证signedData对象S1。解密后的消息包装在signedData层S3中，该层包含“域签名”。如果本地策略要求在消息离开域之前使用S/MIME加密对其进行加密，则此新消息将包装在信封数据层E2中。然后将新的signedData层S4包裹在信封数据周围，
E2, resulting in the following message sent out of the domain (S4 (E2 (S3 (S1 (Original Content))))). If local policy does not require the message to be encrypted, using S/MIME encryption, before it leaves the domain then the message is not wrapped in an envelopedData layer but is wrapped in a new signedData layer, S4, resulting in the following message sent out of the domain (S4 (S3 (S1 (Original Content). The signedData S4, in both cases, contains the signed attributes from S2.
E2，导致以下消息从域中发送出去（S4（E2（S3（S1（原始内容'）））））。如果本地策略不要求在消息离开域之前使用S/MIME加密对其进行加密，则消息不会包装在信封数据层中，而是包装在新的签名数据层S4中，从而导致以下消息从域中发送出去（S4（S3（S1）（原始内容）。在这两种情况下，signedData S4都包含S2中的已签名属性。
5) A message (S3 (S2 (E1 (S1 (Original Content))))) in which none of the signedData layers include a mlExpansionHistory attribute is to have a 'domain signature' applied. The signedData objects S3 and S2 are verified. When the envelopedData E1 is found the signedData objects S3 and S2 are stripped off. The encryptedContent is decrypted. The signedData object S1 is verified. The decrypted content is wrapped in a new signedData layer, S4, which contains a 'domain signature'. If local policy requires the message to be encrypted, using S/MIME encryption, before it leaves the domain then this new message is wrapped in an envelopedData layer, E2, resulting in the following message sent out of the domain (E2 (S4 (S1 (Original Content)))), else the message is not wrapped in an envelopedData layer resulting in the following message (S4 (S1 (Original Content))) being sent.
5) 一种消息（S3（S2（E1（S1（原始内容'）））），其中没有任何signedData层包含mlExpansionHistory属性）将应用“域签名”。验证signedData对象S3和S2。当找到信封数据E1时，将剥离签名数据对象S3和S2。加密的内容被解密。验证signedData对象S1。解密的内容被包装在一个新的signedData层S4中，该层包含一个“域签名”。如果本地策略要求在消息离开域之前使用S/MIME加密对其进行加密，则此新消息将被包装在信封数据层E2中，从而导致以下消息从域发送出去（E2（S4（S1（原始内容）），否则，该消息未包装在信封数据层中，导致发送以下消息（S4（S1（原始内容））。
6) A message (S3 (S2 (E1 (S1 (Original Content))))) in which S3 includes a mlExpansionHistory attribute is to have a 'domain signature' applied. The signedData objects S3 and S2 are verified. The mlExpansionHistory attribute is found in S3, so S3 is the "outer" signedData. The signed attributes in S3 are remembered for later inclusion in the new outer signedData that is applied to the message. The signedData object S3 is stripped off. When the envelopedData layer, E1, is found the signedData object S2 is stripped off. The encryptedContent is decrypted. The signedData object S1 is verified. The decrypted content is wrapped in a new signedData layer, S4, which contains a 'domain signature'. If local policy requires the message to be encrypted, using S/MIME encryption, before it leaves the domain then this new message is wrapped in an envelopedData layer, E2. A new signedData layer, S5, is then wrapped around the envelopedData, E2, resulting in the following message sent out of the domain (S5 (E2 (S4 (S1 (Original Content))))). If local policy does not require the message to be encrypted, using S/MIME encryption, before it leaves the domain then the message is not wrapped in an envelopedData layer but is wrapped in a new signedData layer, S5, resulting in the following message sent out of the domain (S5 (S4 (S1 (Original Content). The signedData S5, in both cases, contains the signed attributes from S3.
6) 其中S3包含mlExpansionHistory属性的消息（S3（S2）（E1（S1（原始内容'））））将应用“域签名”。验证signedData对象S3和S2。mlExpansionHistory属性位于S3中，因此S3是“外部”签名数据。S3中的已签名属性将被记住，以便稍后包含在应用于消息的新外部已签名数据中。signedData对象S3被剥离。当找到包络数据层E1时，signedData对象S2被剥离。加密的内容被解密。验证signedData对象S1。解密的内容被包装在一个新的signedData层S4中，该层包含一个“域签名”。如果本地策略要求在消息离开域之前使用S/MIME加密对其进行加密，则此新消息将包装在信封数据层E2中。然后，新的signedData层S5包裹在信封数据E2的周围，从而产生从域发送的以下消息（S5（E2（S4（S1（原始内容'））））。如果本地策略不要求在消息离开域之前使用S/MIME加密对其进行加密，则消息不包装在信封数据层中，而是包装在新的签名数据层S5中，从而导致以下消息从域发送出去（S5（S4（S1（原始内容））.在这两种情况下，signedData S5都包含来自S3的签名属性。
7) A message (S3 (E2 (S2 (E1 (S1 (Original Content)))))) in which S3 does not include a mlExpansionHistory attribute is to have a 'domain signature' applied. The signedData object S3 is verified. When the envelopedData E2 is found the signedData object S3 is stripped off. The encryptedContent is decrypted. The signedData object S2 is verified, the envelopedData E1 is decrypted and the signedData object S1 is verified. The signedData object S2 is wrapped in a new signedData layer S4, which contains a 'domain signature'. Since there is an envelopedData E1 lower down in the message, the new message is wrapped in an envelopedData layer, E3, resulting in the following message sent out of the domain (E3 (S4 (S2 (E1 (S1 (Original Content)))))).
7) 消息（S3（E2（S2（E1（S1（原始内容‘‘‘‘‘‘‘‘）’）））中S3不包括mlExpansionHistory属性）将应用“域签名”。已验证signedData对象S3。当找到envelopedData E2时，signedData对象S3被剥离。加密的内容被解密。验证signedData对象S2，解密信封数据E1，验证signedData对象S1。signedData对象S2包装在新的signedData层S4中，该层包含“域签名”。由于在消息的下面有一个信封数据E1，新消息被包装在信封数据层E3中，从而导致以下消息被发送出域（E3（S4（S2）（E1（S1（原始内容'））））））。
This specification relies on the existence of several well known names, such as domain-confidentiality-authority. Organizations must take care with these names, even if they do not support DOMSEC, so that certificates issued in these names are only issued to legitimate entities. If this is not true then an individual could get a certificate associated with domain-confidentiality-authority@acme.com and as a result might be able to read messages the a DOMSEC client intended for others.
此规范依赖于几个众所周知的名称的存在，例如域保密机构。组织必须注意这些名称，即使它们不支持DOMSEC，这样以这些名称颁发的证书只能颁发给合法实体。如果这不是真的，那么个人可以获得与域机密性相关的证书-authority@acme.com因此，您可能能够读取DOMSEC客户端为其他人准备的消息。
Implementations MUST protect all private keys. Compromise of the signer's private key permits masquerade.
实现必须保护所有私钥。签名者私钥的泄露允许伪装。
Similarly, compromise of the content-encryption key may result in disclosure of the encrypted content.
类似地，内容加密密钥的泄露可能导致加密内容的泄露。
Compromise of key material is regarded as an even more serious issue for domain security services than for an S/MIME client. This is because compromise of the private key may in turn compromise the security of a whole domain. Therefore, great care should be used when considering its protection.
对于域安全服务来说，关键材料的泄露被认为是比S/MIME客户端更严重的问题。这是因为私钥的泄露可能反过来危害整个域的安全性。因此，在考虑对其进行保护时，应格外小心。
Domain encryption alone is not secure and should be used in conjunction with a domain signature to avoid a masquerade attack, where an attacker that has obtained a DCA certificate can fake a message to that domain pretending to be another domain.
仅域加密是不安全的，应与域签名结合使用以避免伪装攻击，即获得DCA证书的攻击者可以假装是另一个域而向该域伪造消息。
When an encrypted DOMSEC message is sent to an end user in such a way that the message is decrypted by the end users DCA the message will be in plain text and therefore confidentiality could be compromised.
当加密的DOMSEC消息以最终用户DCA解密的方式发送给最终用户时，该消息将以纯文本形式发送，因此保密性可能受到损害。
If the recipient's DCA is compromised then the recipient can not guarantee the integrity of the message. Furthermore, even if the recipient's DCA correctly verifies a message's signatures, then a message could be undetectably modified, when there are no signatures on a message that the recipient can verify.
如果收件人的DCA受损，则收件人无法保证邮件的完整性。此外，即使收件人的DCA正确地验证了邮件的签名，当收件人无法验证邮件上的签名时，也可能无法检测到邮件被修改。
DOMSECSyntax
{ iso(1) member-body(2) us(840) rsadsi(113549)
pkcs(1) pkcs-9(9) smime(16) modules(0) domsec(10) }
DOMSECSyntax
{ iso(1) member-body(2) us(840) rsadsi(113549)
pkcs(1) pkcs-9(9) smime(16) modules(0) domsec(10) }
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
-- EXPORTS All
-- The types and values defined in this module are exported for
-- use in the other ASN.1 modules. Other applications may use
-- them for their own purposes.
-- EXPORTS All
-- The types and values defined in this module are exported for
-- use in the other ASN.1 modules. Other applications may use
-- them for their own purposes.
SignatureType ::= SEQUENCE OF OBJECT IDENTIFIER
SignatureType ::= SEQUENCE OF OBJECT IDENTIFIER
id-smime OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 16 }
id-smime OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 16 }
id-sti OBJECT IDENTIFIER ::= { id-smime 9 } -- signature type
identifier
id-sti OBJECT IDENTIFIER ::= { id-smime 9 } -- signature type
identifier
-- Signature Type Identifiers
--签名类型标识符
id-sti-originatorSig OBJECT IDENTIFIER ::= { id-sti 1 }
id-sti-domainSig OBJECT IDENTIFIER ::= { id-sti 2 }
id-sti-addAttribSig OBJECT IDENTIFIER ::= { id-sti 3 }
id-sti-reviewSig OBJECT IDENTIFIER ::= { id-sti 4 }
id-sti-originatorSig OBJECT IDENTIFIER ::= { id-sti 1 }
id-sti-domainSig OBJECT IDENTIFIER ::= { id-sti 2 }
id-sti-addAttribSig OBJECT IDENTIFIER ::= { id-sti 3 }
id-sti-reviewSig OBJECT IDENTIFIER ::= { id-sti 4 }
END -- of DOMSECSyntax
END——DOMSECSyntax的
[1] Ramsdell, B., "S/MIME Version 3 Message Specification", RFC 2633, June 1999.
[1] Ramsdell，B.，“S/MIME版本3消息规范”，RFC 2633，1999年6月。
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[2] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[3] Hoffman, P., "Enhanced Security Services for S/MIME", RFC 2634, June 1999.
[3] Hoffman，P.，“S/MIME的增强安全服务”，RFC 2634，1999年6月。
[4] International Telecommunications Union, Recommendation X.208, "Open systems interconnection: specification of Abstract Syntax Notation (ASN.1)", CCITT Blue Book, 1989.
[4] 国际电信联盟，建议X.208，“开放系统互连：抽象语法符号规范（ASN.1）”，CCITT蓝皮书，1989年。
[5] Housley, R., "Cryptographic Message Syntax", RFC 2630, June 1999.
[5] Housley，R.，“加密消息语法”，RFC 2630，1999年6月。
Tim Dean QinetiQ St. Andrews Road Malvern Worcs WR14 3PS
蒂姆·迪安·基内蒂克圣安德鲁斯路马尔文沃茨WR14 3PS
Phone: +44 (0) 1684 894239
Fax: +44 (0) 1684 896660
EMail: tbdean@QinetiQ.com
Phone: +44 (0) 1684 894239
Fax: +44 (0) 1684 896660
EMail: tbdean@QinetiQ.com
William Ottaway QinetiQ St. Andrews Road Malvern Worcs WR14 3PS
威廉·奥塔维·奇内蒂克圣安德鲁斯路马尔文沃茨WR14 3PS
Phone: +44 (0) 1684 894079
Fax: +44 (0) 1684 896660
EMail: wjottaway@QinetiQ.com
Phone: +44 (0) 1684 894079
Fax: +44 (0) 1684 896660
EMail: wjottaway@QinetiQ.com
Copyright (C) The Internet Society (2001). All Rights Reserved.
版权所有（C）互联网协会（2001年）。版权所有。
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编辑功能的资金目前由互联网协会提供。