Network Working Group P. Hoffman, Editor
Request for Comments: 2634 Internet Mail Consortium
Category: Standards Track June 1999
Network Working Group P. Hoffman, Editor
Request for Comments: 2634 Internet Mail Consortium
Category: Standards Track June 1999
Enhanced Security Services for S/MIME
增强的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 (1999). All Rights Reserved.
版权所有（C）互联网协会（1999年）。版权所有。
This document describes four optional security service extensions for S/MIME. The services are:
本文档描述了S/MIME的四个可选安全服务扩展。这些服务包括：
- signed receipts - security labels - secure mailing lists - signing certificates
- 签名收据-安全标签-安全邮件列表-签名证书
The first three of these services provide functionality that is similar to the Message Security Protocol [MSP4], but are useful in many other environments, particularly business and finance. Signing certificates are useful in any environment where certificates might be transmitted with signed messages.
前三种服务提供的功能类似于消息安全协议[MSP4]，但在许多其他环境中非常有用，特别是在商业和金融环境中。签名证书在任何可能使用签名消息传输证书的环境中都很有用。
The services described here are extensions to S/MIME version 3 ([MSG] and [CERT]), and some of them can also be added to S/MIME version 2 [SMIME2]. The extensions described here will not cause an S/MIME version 3 recipient to be unable to read messages from an S/MIME version 2 sender. However, some of the extensions will cause messages created by an S/MIME version 3 sender to be unreadable by an S/MIME version 2 recipient.
这里描述的服务是对S/MIME版本3（[MSG]和[CERT]）的扩展，其中一些服务还可以添加到S/MIME版本2[SMIME2]。此处描述的扩展不会导致S/MIME版本3收件人无法读取来自S/MIME版本2发件人的邮件。但是，某些扩展将导致S/MIME版本3发件人创建的邮件无法被S/MIME版本2收件人读取。
This document describes both the procedures and the attributes needed for the four services. Note that some of the attributes described in this document are quite useful in other contexts and should be considered when extending S/MIME or other CMS applications.
本文档描述了四个服务所需的过程和属性。请注意，本文档中描述的一些属性在其他上下文中非常有用，在扩展S/MIME或其他CMS应用程序时应予以考虑。
The format of the messages are described in ASN.1:1988 [ASN1-1988].
ASN.1:1988[ASN1-1988]中描述了消息的格式。
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 [MUSTSHOULD].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[必须”中的说明进行解释。
Some of the features of each service use the concept of a "triple wrapped" message. A triple wrapped message is one that has been signed, then encrypted, then signed again. The signers of the inner and outer signatures may be different entities or the same entity. Note that the S/MIME specification does not limit the number of nested encapsulations, so there may be more than three wrappings.
每个服务的一些特性使用了“三重包装”消息的概念。三重包装的消息是经过签名、加密、再签名的消息。内部和外部签名的签名者可以是不同的实体或同一实体。请注意，S/MIME规范没有限制嵌套封装的数量，因此可能有三个以上的封装。
Not all messages need to be triple wrapped. Triple wrapping is used when a message must be signed, then encrypted, and then have signed attributes bound to the encrypted body. Outer attributes may be added or removed by the message originator or intermediate agents, and may be signed by intermediate agents or the final recipient.
并非所有消息都需要三重包装。当消息必须先签名，然后加密，然后将签名属性绑定到加密正文时，使用三重包装。外部属性可由消息发起人或中间代理添加或删除，并可由中间代理或最终收件人签名。
The inside signature is used for content integrity, non-repudiation with proof of origin, and binding attributes (such as a security label) to the original content. These attributes go from the originator to the recipient, regardless of the number of intermediate entities such as mail list agents that process the message. The signed attributes can be used for access control to the inner body. Requests for signed receipts by the originator are carried in the inside signature as well.
内部签名用于内容完整性、来源证明的不可否认性以及将属性（如安全标签）绑定到原始内容。无论处理邮件的中间实体（如邮件列表代理）的数量有多少，这些属性都会从原始发件人传递到收件人。签名属性可用于内部主体的访问控制。发起者对签名收据的请求也包含在内部签名中。
The encrypted body provides confidentiality, including confidentiality of the attributes that are carried in the inside signature.
加密体提供机密性，包括内部签名中携带的属性的机密性。
The outside signature provides authentication and integrity for information that is processed hop-by-hop, where each hop is an intermediate entity such as a mail list agent. The outer signature binds attributes (such as a security label) to the encrypted body. These attributes can be used for access control and routing decisions.
外部签名为逐跃点处理的信息提供身份验证和完整性，其中每个跃点都是中间实体，如邮件列表代理。外部签名将属性（如安全标签）绑定到加密体。这些属性可用于访问控制和路由决策。
The steps to create a triple wrapped message are:
创建三重包装邮件的步骤如下：
1. Start with a message body, called the "original content".
1. 从消息正文开始，称为“原始内容”。
2. Encapsulate the original content with the appropriate MIME Content-type headers, such as "Content-type: text/plain". An exception to this MIME encapsulation rule is that a signed receipt is not put in MIME headers.
2. 使用适当的MIME内容类型标题封装原始内容，例如“内容类型：text/plain”。此MIME封装规则的一个例外是，已签名的回执不放在MIME头中。
3. Sign the result of step 2 (the inner MIME headers and the original content). The SignedData encapContentInfo eContentType object identifier MUST be id-data. If the structure you create in step 4 is multipart/signed, then the SignedData encapContentInfo eContent MUST be absent. If the structure you create in step 4 is application/pkcs7-mime, then the SignedData encapContentInfo eContent MUST contain the result of step 2 above. The SignedData structure is encapsulated by a ContentInfo SEQUENCE with a contentType of id-signedData.
3. 签署步骤2的结果（内部MIME头和原始内容）。SignedData encapContentInfo eContentType对象标识符必须是id数据。如果在步骤4中创建的结构是多部分/已签名的，则必须缺少SignedData encapContentInfo eContent。如果在步骤4中创建的结构是application/pkcs7 mime，则SignedData encapContentInfo eContent必须包含上述步骤2的结果。SignedData结构由ContentInfo序列封装，contentType id为SignedData。
4. Add an appropriate MIME construct to the signed message from step 3 as defined in [MSG]. The resulting message is called the "inside signature".
4. 按照[MSG]中的定义，将适当的MIME构造添加到步骤3中的签名消息中。产生的消息称为“内部签名”。
- If you are signing using multipart/signed, the MIME construct added consists of a Content-type of multipart/signed with parameters, the boundary, the result of step 2 above, the boundary, a Content-type of application/pkcs7-signature, optional MIME headers (such asContent-transfer-encoding and Content-disposition), and a body part that is the result of step 3 above.
- 如果您使用multipart/signed进行签名，则添加的MIME构造由multipart/signed的内容类型（带参数）、边界、上述步骤2的结果、边界、application/pkcs7签名的内容类型、可选MIME头（如内容传输编码和内容处置）组成，以及作为上述步骤3结果的身体部位。
- If you are instead signing using application/pkcs7-mime, the MIME construct added consists of a Content-type of application/pkcs7-mime with parameters, optional MIME headers (such as Content-transfer-encoding and Content-disposition), and the result of step 3 above.
- 如果改为使用application/pkcs7 mime进行签名，则添加的mime构造由内容类型application/pkcs7 mime和参数、可选的mime头（例如内容传输编码和内容处置）以及上面步骤3的结果组成。
5. Encrypt the result of step 4 as a single block, turning it into an application/pkcs7-mime object. The EnvelopedData encryptedContentInfo contentType MUST be id-data. The EnvelopedData structure is encapsulated by a ContentInfo SEQUENCE with a contentType of id-envelopedData. This is called the "encrypted body".
5. 将步骤4的结果作为单个块加密，将其转换为application/pkcs7 mime对象。EnvelopedData encryptedContentInfo contentType必须是id数据。EnvelopedData结构由ContentInfo序列封装，contentType id为EnvelopedData。这称为“加密体”。
6. Add the appropriate MIME headers: a Content-type of application/pkcs7-mime with parameters, and optional MIME headers such as Content-transfer-encoding and Content-disposition.
6. 添加适当的MIME头：带有参数的application/pkcs7 MIME的内容类型，以及可选的MIME头，如内容传输编码和内容处置。
7. Using the same logic as in step 3 above, sign the result of step 6 (the MIME headers and the encrypted body) as a single block
7. 使用与上面步骤3相同的逻辑，将步骤6（MIME头和加密体）的结果作为单个块进行签名
8. Using the same logic as in step 4 above, add an appropriate MIME construct to the signed message from step 7. The resulting message is called the "outside signature", and is also the triple wrapped message.
8. 使用与上面步骤4相同的逻辑，将适当的MIME构造添加到步骤7中的签名消息中。生成的消息称为“外部签名”，也是三重包装的消息。
A triple wrapped message has many layers of encapsulation. The structure differs based on the choice of format for the signed portions of the message. Because of the way that MIME encapsulates data, the layers do not appear in order, and the notion of "layers" becomes vague.
三层包装的消息具有多层封装。根据消息签名部分的格式选择，结构有所不同。由于MIME封装数据的方式，层没有按顺序出现，“层”的概念变得模糊。
There is no need to use the multipart/signed format in an inner signature because it is known that the recipient is able to process S/MIME messages (because they decrypted the middle wrapper). A sending agent might choose to use the multipart/signed format in the outer layer so that a non-S/MIME agent could see that the next inner layer is encrypted; however, this is not of great value, since all it shows the recipient is that the rest of the message is unreadable. Because many sending agents always use multipart/signed structures, all receiving agents MUST be able to interpret either multipart/signed or application/pkcs7-mime signature structures.
无需在内部签名中使用多部分/签名格式，因为已知收件人能够处理S/MIME消息（因为他们解密了中间包装）。发送代理可以选择在外层使用多部分/签名格式，以便非S/MIME代理可以看到下一个内层被加密；但是，这并没有太大的价值，因为它向收件人显示的只是消息的其余部分不可读。由于许多发送代理始终使用多部分/签名结构，因此所有接收代理必须能够解释多部分/签名或应用程序/pkcs7 mime签名结构。
The format of a triple wrapped message that uses multipart/signed for both signatures is:
对两个签名使用多部分/签名的三重包装消息的格式为：
[step 8] Content-type: multipart/signed;
[step 8] protocol="application/pkcs7-signature";
[step 8] boundary=outerboundary
[step 8]
[step 8] --outerboundary
[step 6] Content-type: application/pkcs7-mime; )
[step 6] smime-type=enveloped-data )
[step 6] )
[step 4] Content-type: multipart/signed; | )
[step 4] protocol="application/pkcs7-signature"; | )
[step 4] boundary=innerboundary | )
[step 4] | )
[step 4] --innerboundary | )
[step 2] Content-type: text/plain % | )
[step 8] Content-type: multipart/signed;
[step 8] protocol="application/pkcs7-signature";
[step 8] boundary=outerboundary
[step 8]
[step 8] --outerboundary
[step 6] Content-type: application/pkcs7-mime; )
[step 6] smime-type=enveloped-data )
[step 6] )
[step 4] Content-type: multipart/signed; | )
[step 4] protocol="application/pkcs7-signature"; | )
[step 4] boundary=innerboundary | )
[step 4] | )
[step 4] --innerboundary | )
[step 2] Content-type: text/plain % | )
[step 2] % | )
[step 1] Original content % | )
[step 4] | )
[step 4] --innerboundary | )
[step 4] Content-type: application/pkcs7-signature | )
[step 4] | )
[step 3] inner SignedData block (eContent is missing) | )
[step 4] | )
[step 4] --innerboundary-- | )
[step 8]
[step 8] --outerboundary
[step 8] Content-type: application/pkcs7-signature
[step 8]
[step 7] outer SignedData block (eContent is missing)
[step 8]
[step 8] --outerboundary--
[step 2] % | )
[step 1] Original content % | )
[step 4] | )
[step 4] --innerboundary | )
[step 4] Content-type: application/pkcs7-signature | )
[step 4] | )
[step 3] inner SignedData block (eContent is missing) | )
[step 4] | )
[step 4] --innerboundary-- | )
[step 8]
[step 8] --outerboundary
[step 8] Content-type: application/pkcs7-signature
[step 8]
[step 7] outer SignedData block (eContent is missing)
[step 8]
[step 8] --outerboundary--
% = These lines are what the inner signature is computed over. | = These lines are what is encrypted in step 5. This encrypted result is opaque and is a part of an EnvelopedData block. ) = These lines are what the outer signature is computed over.
%=这些行是计算内部签名的内容。|=这些行是在步骤5中加密的。此加密结果是不透明的，并且是信封数据块的一部分。）=这些行是计算外部签名的基础。
The format of a triple wrapped message that uses application/pkcs7- mime for the both signatures is:
对两个签名使用application/pkcs7-mime的三重包装消息的格式为：
[step 8] Content-type: application/pkcs7-mime;
[step 8] smime-type=signed-data
[step 8]
[step 7] outer SignedData block (eContent is present) O
[step 6] Content-type: application/pkcs7-mime; ) O
[step 6] smime-type=enveloped-data; ) O
[step 6] ) O
[step 4] Content-type: application/pkcs7-mime; | ) O
[step 4] smime-type=signed-data | ) O
[step 4] | ) O
[step 3] inner SignedData block (eContent is present) I | ) O
[step 2] Content-type: text/plain I | ) O
[step 2] I | ) O
[step 1] Original content I | ) O
[step 8] Content-type: application/pkcs7-mime;
[step 8] smime-type=signed-data
[step 8]
[step 7] outer SignedData block (eContent is present) O
[step 6] Content-type: application/pkcs7-mime; ) O
[step 6] smime-type=enveloped-data; ) O
[step 6] ) O
[step 4] Content-type: application/pkcs7-mime; | ) O
[step 4] smime-type=signed-data | ) O
[step 4] | ) O
[step 3] inner SignedData block (eContent is present) I | ) O
[step 2] Content-type: text/plain I | ) O
[step 2] I | ) O
[step 1] Original content I | ) O
I = These lines are the inner SignedData block, which is opaque and contains the ASN.1 encoded result of step 2 as well as control information. | = These lines are what is encrypted in step 5. This encrypted result is opaque and is a part of an EnvelopedData block. ) = These lines are what the outer signature is computed over.
I=这些行是内部SignedData块，它是不透明的，包含步骤2的ASN.1编码结果以及控制信息这些行是在步骤5中加密的。此加密结果是不透明的，并且是信封数据块的一部分。）=这些行是计算外部签名的基础。
O = These lines are the outer SignedData block, which is opaque and contains the ASN.1 encoded result of step 6 as well as control information.
O=这些行是外部SignedData块，它是不透明的，包含步骤6的ASN.1编码结果以及控制信息。
The first three security services described in this document are used with triple wrapped messages in different ways. This section briefly describes the relationship of each service with triple wrapping; the other sections of the document go into greater detail.
本文档中描述的前三个安全服务以不同的方式与三层包装的消息一起使用。本节简要描述了每个服务与三层包装的关系；本文件的其他部分将更详细地介绍。
A signed receipt may be requested in any SignedData object. However, if a signed receipt is requested for a triple wrapped message, the receipt request MUST be in the inside signature, not in the outside signature. A secure mailing list agent may change the receipt policy in the outside signature of a triple wrapped message when that message is processed by the mailing list.
可以在任何SignedData对象中请求签名收据。但是，如果为三重包装邮件请求签名回执，则回执请求必须在内部签名中，而不是在外部签名中。当邮件列表处理三重包装邮件时，安全邮件列表代理可以更改该邮件外部签名中的接收策略。
Note: the signed receipts and receipt requests described in this memo differ from those described in the work done by the IETF Receipt Notification Working Group. The output of that Working Group, when finished, is not expected to work well with triple wrapped messages as described in this document.
注：本备忘录中描述的签名收据和收据请求与IETF收据通知工作组所做工作中描述的不同。该工作组的输出完成后，预计无法很好地处理本文档中描述的三重包装消息。
A security label may be included in the signed attributes of any SignedData object. A security label attribute may be included in either the inner signature, outer signature, or both.
安全标签可以包含在任何SignedData对象的签名属性中。安全标签属性可以包含在内部签名、外部签名或两者中。
The inner security label is used for access control decisions related to the plaintext original content. The inner signature provides authentication and cryptographically protects the integrity of the original signer's security label that is in the inside body. This strategy facilitates the forwarding of messages because the original signer's security label is included in the SignedData block which can be forwarded to a third party that can verify the inner signature which will cover the inner security label. The confidentiality security service can be applied to the inner security label by encrypting the entire inner SignedData block within an EnvelopedData block.
内部安全标签用于与明文原始内容相关的访问控制决策。内部签名提供身份验证，并以加密方式保护体内原始签名者安全标签的完整性。此策略有助于转发消息，因为原始签名者的安全标签包含在SignedData块中，可以转发给第三方，第三方可以验证覆盖内部安全标签的内部签名。通过加密信封数据块中的整个内部SignedData块，可以将机密性安全服务应用于内部安全标签。
A security label may also be included in the signed attributes of the outer SignedData block which will include the sensitivities of the encrypted message. The outer security label is used for access control and routing decisions related to the encrypted message. Note
安全标签也可以包括在外部SignedData块的签名属性中，该签名属性将包括加密消息的敏感性。外部安全标签用于与加密消息相关的访问控制和路由决策。笔记
that a security label attribute can only be used in a signedAttributes block. An eSSSecurityLabel attribute MUST NOT be used in an EnvelopedData or unsigned attributes.
安全标签属性只能在SignedAttribute块中使用。eSSSecurityLabel属性不得用于EnvelopedData或无符号属性。
Secure mail list message processing depends on the structure of S/MIME layers present in the message sent to the mail list agent. The mail list agent never changes the data that was hashed to form the inner signature, if such a signature is present. If an outer signature is present, then the agent will modify the data that was hashed to form that outer signature. In all cases, the agent adds or updates an mlExpansionHistory attribute to document the agent's processing, and ultimately adds or replaces the outer signature on the message to be distributed.
安全邮件列表邮件处理取决于发送到邮件列表代理的邮件中存在的S/MIME层的结构。邮件列表代理从不更改哈希后形成内部签名的数据（如果存在这样的签名）。如果存在外部签名，则代理将修改散列后形成该外部签名的数据。在所有情况下，代理都会添加或更新mlExpansionHistory属性以记录代理的处理，并最终添加或替换要分发的消息上的外部签名。
Certain attributes should be placed in the inner or outer SignedData message; some attributes can be in either. Further, some attributes must be signed, while signing is optional for others, and some attributes must not be signed. ESS defines several types of attributes. ContentHints and ContentIdentifier MAY appear in any list of attributes. contentReference, equivalentLabel, eSSSecurityLabel and mlExpansionHistory MUST be carried in a SignedAttributes or AuthAttributes type, and MUST NOT be carried in a UnsignedAttributes, UnauthAttributes or UnprotectedAttributes type. msgSigDigest, receiptRequest and signingCertificate MUST be carried in a SignedAttributes, and MUST NOT be carried in a AuthAttributes, UnsignedAttributes, UnauthAttributes or UnprotectedAttributes type.
某些属性应该放在内部或外部SignedData消息中；某些属性可以是任意一种形式。此外，某些属性必须签名，而签名对于其他属性是可选的，而某些属性不能签名。ESS定义了几种类型的属性。ContentHits和ContentIdentifier可以出现在任何属性列表中。contentReference、equivalentLabel、eSSSecurityLabel和mlExpansionHistory必须在SignedAttributes或AuthAttributes类型中携带，并且不得在UnsignedAttributes、UnauthAttributes或UnprotectedAttributes类型中携带。msgSigDigest、receiptRequest和signingCertificate必须包含在已签名的属性中，而不能包含在AuthAttributes、未签名的属性、未经授权的属性或未受保护的属性类型中。
The following table summarizes the recommendation of this profile. In the OID column, [ESS] indicates that the attribute is defined in this document.
下表总结了本概要文件的建议。在OID列中，[ESS]表示该属性是在此文档中定义的。
| |Inner or |
Attribute |OID |outer |Signed
------------------|----------------------------- |----------|--------
contentHints |id-aa-contentHint [ESS] |either |MAY
contentIdentifier |id-aa-contentIdentifier [ESS] |either |MAY
contentReference |id-aa-contentReference [ESS] |either |MUST
contentType |id-contentType [CMS] |either |MUST
counterSignature |id-countersignature [CMS] |either |MUST NOT
equivalentLabel |id-aa-equivalentLabels [ESS] |either |MUST
eSSSecurityLabel |id-aa-securityLabel [ESS] |either |MUST
messageDigest |id-messageDigest [CMS] |either |MUST
msgSigDigest |id-aa-msgSigDigest [ESS] |inner only|MUST
mlExpansionHistory|id-aa-mlExpandHistory [ESS] |outer only|MUST
receiptRequest |id-aa-receiptRequest [ESS] |inner only|MUST
signingCertificate|id-aa-signingCertificate [ESS]|either |MUST
signingTime |id-signingTime [CMS] |either |MUST
smimeCapabilities |sMIMECapabilities [MSG] |either |MUST
sMIMEEncryption-
KeyPreference |id-aa-encrypKeyPref [MSG] |either |MUST
| |Inner or |
Attribute |OID |outer |Signed
------------------|----------------------------- |----------|--------
contentHints |id-aa-contentHint [ESS] |either |MAY
contentIdentifier |id-aa-contentIdentifier [ESS] |either |MAY
contentReference |id-aa-contentReference [ESS] |either |MUST
contentType |id-contentType [CMS] |either |MUST
counterSignature |id-countersignature [CMS] |either |MUST NOT
equivalentLabel |id-aa-equivalentLabels [ESS] |either |MUST
eSSSecurityLabel |id-aa-securityLabel [ESS] |either |MUST
messageDigest |id-messageDigest [CMS] |either |MUST
msgSigDigest |id-aa-msgSigDigest [ESS] |inner only|MUST
mlExpansionHistory|id-aa-mlExpandHistory [ESS] |outer only|MUST
receiptRequest |id-aa-receiptRequest [ESS] |inner only|MUST
signingCertificate|id-aa-signingCertificate [ESS]|either |MUST
signingTime |id-signingTime [CMS] |either |MUST
smimeCapabilities |sMIMECapabilities [MSG] |either |MUST
sMIMEEncryption-
KeyPreference |id-aa-encrypKeyPref [MSG] |either |MUST
CMS defines signedAttrs as a SET OF Attribute and defines unsignedAttrs as a SET OF Attribute. ESS defines the contentHints, contentIdentifier, eSSecurityLabel, msgSigDigest, mlExpansionHistory, receiptRequest, contentReference, equivalentLabels and signingCertificate attribute types. A signerInfo MUST NOT include multiple instances of any of the attribute types defined in ESS. Later sections of ESS specify further restrictions that apply to the receiptRequest, mlExpansionHistory and eSSecurityLabel attribute types.
CMS将signedAttrs定义为一组属性，并将unsignedAttrs定义为一组属性。ESS定义ContentHits、contentIdentifier、eSSecurityLabel、msgSigDigest、mlExpansionHistory、receiptRequest、contentReference、等效标签和signingCertificate属性类型。signerInfo不能包含ESS中定义的任何属性类型的多个实例。ESS的后面部分指定了适用于receiptRequest、mlExpansionHistory和eSSecurityLabel属性类型的进一步限制。
CMS defines the syntax for the signed and unsigned attributes as "attrValues SET OF AttributeValue". For all of the attribute types defined in ESS, if the attribute type is present in a signerInfo, then it MUST only include a single instance of AttributeValue. In other words, there MUST NOT be zero, or multiple, instances of AttributeValue present in the attrValues SET OF AttributeValue.
CMS将有符号和无符号属性的语法定义为“AttrValuesSetofAttributeValue”。对于ESS中定义的所有属性类型，如果属性类型存在于signerInfo中，则它必须仅包含AttributeValue的单个实例。换句话说，AttributeValue的attrValues集合中不能存在AttributeValue的零个或多个实例。
If a counterSignature attribute is present, then it MUST be included in the unsigned attributes. It MUST NOT be included in the signed attributes. The only attributes that are allowed in a counterSignature attribute are counterSignature, messageDigest, signingTime, and signingCertificate.
如果存在会签属性，则它必须包含在未签名属性中。它不能包含在已签名属性中。会签属性中唯一允许的属性是会签、messageDigest、signingTime和signingCertificate。
Note that the inner and outer signatures are usually those of different senders. Because of this, the same attribute in the two signatures could lead to very different consequences.
请注意，内部和外部签名通常是不同发件人的签名。因此，两个签名中的相同属性可能导致截然不同的结果。
ContentIdentifier is an attribute (OCTET STRING) used to carry a unique identifier assigned to the message.
ContentIdentifier是一个属性（八位字符串），用于携带分配给消息的唯一标识符。
Some security gateways sign messages that pass through them. If the message is any type other than a signedData type, the gateway has only one way to sign the message: by wrapping it with a signedData block and MIME headers. If the message to be signed by the gateway is a signedData message already, the gateway can sign the message by inserting a signerInfo into the signedData block.
一些安全网关对通过它们的消息进行签名。如果消息不是signedData类型，则网关只有一种对消息进行签名的方法：使用signedData块和MIME头包装消息。如果要由网关签名的消息已经是signedData消息，则网关可以通过将signerInfo插入signedData块来对消息进行签名。
The main advantage of a gateway adding a signerInfo instead of wrapping the message in a new signature is that the message doesn't grow as much as if the gateway wrapped the message. The main disadvantage is that the gateway must check for the presence of certain attributes in the other signerInfos and either omit or copy those attributes.
网关添加signerInfo而不是将消息包装到新签名中的主要优点是消息不会像网关包装消息那样增长。主要缺点是网关必须检查其他signerInfos中是否存在某些属性，并忽略或复制这些属性。
If a gateway or other processor adds a signerInfo to an existing signedData block, it MUST copy the mlExpansionHistory and eSSSecurityLabel attributes from other signerInfos. This helps ensure that the recipient will process those attributes in a signerInfo that it can verify.
如果网关或其他处理器将signerInfo添加到现有signedData块，则必须从其他signerInfo复制mlExpansionHistory和eSSSecurityLabel属性。这有助于确保收件人将处理其可以验证的signerInfo中的那些属性。
Note that someone may in the future define an attribute that must be present in each signerInfo of a signedData block in order for the signature to be processed. If that happens, a gateway that inserts signerInfos and doesn't copy that attribute will cause every message with that attribute to fail when processed by the recipient. For this reason, it is safer to wrap messages with new signatures than to insert signerInfos.
请注意，将来可能会有人定义一个属性，该属性必须存在于signedData块的每个signerInfo中，以便处理签名。如果发生这种情况，则插入signerInfos但不复制该属性的网关将导致收件人在处理每个具有该属性的邮件时失败。因此，使用新签名包装邮件比插入signerInfos更安全。
The object identifiers for many of the objects described in this memo are found in [CMS], [MSG], and [CERT]. Other object identifiers used in S/MIME can be found in the registry kept at <http://www.imc.org/ietf-smime/oids.html>. When this memo moves to standards track within the IETF, it is intended that the IANA will maintain this registry.
本备忘录中描述的许多对象的对象标识符可在[CMS]、[MSG]和[CERT]中找到。S/MIME中使用的其他对象标识符可以在位于的注册表中找到<http://www.imc.org/ietf-smime/oids.html>. 当本备忘录移至IETF内的标准轨道时，IANA将维护此注册表。
Returning a signed receipt provides to the originator proof of delivery of a message, and allows the originator to demonstrate to a third party that the recipient was able to verify the signature of the original message. This receipt is bound to the original message through the signature; consequently, this service may be requested only if a message is signed. The receipt sender may optionally also encrypt a receipt to provide confidentiality between the receipt sender and the receipt recipient.
返回已签名的回执可向发端人提供消息传递的证据，并允许发端人向第三方证明收件人能够验证原始消息的签名。此回执通过签名绑定到原始邮件；因此，只有在消息被签名的情况下才能请求此服务。收据发送方还可以选择性地加密收据，以在收据发送方和收据接收方之间提供机密性。
The originator of a message may request a signed receipt from the message's recipients. The request is indicated by adding a receiptRequest attribute to the signedAttributes field of the SignerInfo object for which the receipt is requested. The receiving user agent software SHOULD automatically create a signed receipt when requested to do so, and return the receipt in accordance with mailing list expansion options, local security policies, and configuration options.
邮件的发起者可以向邮件的收件人请求签名收据。通过向请求接收的SignerInfo对象的signedAttributes字段添加receiptRequest属性来指示请求。接收用户代理软件应在收到请求时自动创建签名回执，并根据邮件列表扩展选项、本地安全策略和配置选项返回回执。
Because receipts involve the interaction of two parties, the terminology can sometimes be confusing. In this section, the "sender" is the agent that sent the original message that included a request for a receipt. The "receiver" is the party that received that message and generated the receipt.
由于收据涉及双方的互动，因此术语有时会令人混淆。在本节中，“发件人”是发送原始邮件（包括收据请求）的代理。“接收者”是接收该消息并生成收据的一方。
The steps in a typical transaction are:
典型事务中的步骤包括：
1. Sender creates a signed message including a receipt request attribute (Section 2.2).
1. 发送方创建一个包含接收请求属性的签名邮件（第2.2节）。
2. Sender transmits the resulting message to the recipient or recipients.
2. 发件人将生成的邮件发送给收件人。
3. Recipient receives message and determines if there is a valid signature and receipt request in the message (Section 2.3).
3. 收件人接收消息并确定消息中是否存在有效的签名和接收请求（第2.3节）。
4. Recipient creates a signed receipt (Section 2.4).
4. 收件人创建签名收据（第2.4节）。
5. Recipient transmits the resulting signed receipt message to the sender (Section 2.5).
5. 收件人将生成的签名接收消息发送给发件人（第2.5节）。
6. Sender receives the message and validates that it contains a signed receipt for the original message (Section 2.6). This validation relies on the sender having retained either a copy of the original message or information extracted from the original message.
6. 发件人收到邮件并验证邮件是否包含原始邮件的签名回执（第2.6节）。此验证依赖于发件人保留了原始邮件的副本或从原始邮件中提取的信息。
The ASN.1 syntax for the receipt request is given in Section 2.7; the ASN.1 syntax for the receipt is given in Section 2.8.
第2.7节给出了接收请求的ASN.1语法；收据的ASN.1语法见第2.8节。
Note that a sending agent SHOULD remember when it has sent a receipt so that it can avoid re-sending a receipt each time it processes the message.
请注意，发送代理应记住何时发送了回执，以便避免在每次处理邮件时重新发送回执。
A receipt request can indicate that receipts be sent to many places, not just to the sender (in fact, the receipt request might indicate that the receipts should not even go to the sender). In order to verify a receipt, the recipient of the receipt must be the originator or a recipient of the original message. Thus, the sender SHOULD NOT request that receipts be sent to anyone who does not have an exact copy of the message.
收据请求可以指示收据被发送到许多地方，而不仅仅是发送给发件人（事实上，收据请求可能指示收据甚至不应该发送给发件人）。为了验证回执，回执的收件人必须是原始邮件的发件人或收件人。因此，发件人不应要求将收据发送给没有邮件准确副本的任何人。
Multi-layer S/MIME messages may contain multiple SignedData layers. However, receipts may be requested only for the innermost SignedData layer in a multi-layer S/MIME message, such as a triple wrapped message. Only one receiptRequest attribute can be included in the signedAttributes of a SignerInfo.
多层S/MIME消息可能包含多个SignedData层。但是，在多层S/MIME消息（例如三层包装的消息）中，可能仅为最内层的SignedData层请求接收。SignerInfo的SignedAttribute中只能包含一个receiptRequest属性。
A ReceiptRequest attribute MUST NOT be included in the attributes of a SignerInfo in a SignedData object that encapsulates a Receipt content. In other words, the receiving agent MUST NOT request a signed receipt for a signed receipt.
封装收据内容的SignedData对象中SignerInfo的属性中不得包含ReceiptRequest属性。换言之，收货代理不得为已签字的收据申请已签字的收据。
A sender requests receipts by placing a receiptRequest attribute in the signed attributes of a signerInfo as follows:
发送方通过在signerInfo的签名属性中放置receiptRequest属性来请求收据，如下所示：
1. A receiptRequest data structure is created.
1. 将创建receiptRequest数据结构。
2. A signed content identifier for the message is created and assigned to the signedContentIdentifier field. The signedContentIdentifier is used to associate the signed receipt with the message requesting the signed receipt.
2. 消息的已签名内容标识符将被创建并分配给signedContentIdentifier字段。signedContentIdentifier用于将已签名回执与请求已签名回执的消息相关联。
3. The entities requested to return a signed receipt are noted in the receiptsFrom field.
3. 要求返回签名收据的实体在receiptsFrom字段中注明。
4. The message originator MUST populate the receiptsTo field with a GeneralNames for each entity to whom the recipient should send the signed receipt. If the message originator wants the recipient to send the signed receipt to the originator, then the originator MUST include a GeneralNames for itself in the receiptsTo field. GeneralNames is a SEQUENCE OF GeneralName. receiptsTo is a SEQUENCE OF GeneralNames in which each GeneralNames represents an entity. There may be multiple GeneralName instances in each GeneralNames. At a minimum, the message originator MUST populate each entity's GeneralNames with the address to which the signed receipt should be sent. Optionally, the message originator MAY also populate each entity's GeneralNames with other GeneralName instances (such as directoryName).
4. 消息发起人必须在receiptsTo字段中填入收件人应向其发送签名收据的每个实体的通用名称。如果消息发端人希望收件人向发端人发送已签名的回执，则发端人必须在ReceiptTo字段中包含自己的通用名称。GeneralName是GeneralName的序列。ReceiptTo是一个通用名称序列，其中每个通用名称代表一个实体。每个GeneralName中可能有多个GeneralName实例。消息发起人至少必须在每个实体的通用名称中填入签名收据应发送到的地址。或者，消息发起人还可以使用其他GeneralName实例（如directoryName）填充每个实体的GeneralName。
5. The completed receiptRequest attribute is placed in the signedAttributes field of the SignerInfo object.
5. 完成的receiptRequest属性放置在SignerinInfo对象的signedAttributes字段中。
There can be multiple SignerInfos within a SignedData object, and each SignerInfo may include signedAttributes. Therefore, a single SignedData object may include multiple SignerInfos, each SignerInfo having a receiptRequest attribute. For example, an originator can send a signed message with two SignerInfos, one containing a DSS signature, the other containing an RSA signature.
一个SignedData对象中可以有多个SignerInfos，每个SignerInfos可能包括SignedAttribute。因此，单个SignedData对象可能包括多个SignerInfos，每个SignerInfos都有一个receiptRequest属性。例如，发起者可以发送带有两个签名的签名消息，一个包含DSS签名，另一个包含RSA签名。
Each recipient SHOULD return only one signed receipt.
每个收件人只应返回一份签名收据。
Not all of the SignerInfos need to include receipt requests, but in all of the SignerInfos that do contain receipt requests, the receipt requests MUST be identical.
并非所有SignerInfos都需要包含收货请求，但在所有包含收货请求的SignerInfos中，收货请求必须相同。
The sending agent MUST retain one or both of the following items to support the validation of signed receipts returned by the recipients.
发送代理必须保留以下一项或两项，以支持验证收件人返回的签名收据。
- the original signedData object requesting the signed receipt
- 请求签名收据的原始signedData对象
- the message signature digest value used to generate the original signedData signerInfo signature value and the digest value of the Receipt content containing values included in the original signedData object. If signed receipts are requested from multiple recipients, then retaining these digest values is a performance enhancement because the sending agent can reuse the saved values when verifying each returned signed receipt.
- 消息签名摘要值，用于生成原始signedData signerInfo签名值和包含原始signedData对象中包含的值的回执内容的摘要值。如果从多个收件人请求签名收据，则保留这些摘要值是一种性能增强，因为发送代理在验证每个返回的签名收据时可以重用保存的值。
A receiptRequest is associated only with the SignerInfo object to which the receipt request attribute is directly attached. Receiving software SHOULD examine the signedAttributes field of each of the SignerInfos for which it verifies a signature in the innermost signedData object to determine if a receipt is requested. This may result in the receiving agent processing multiple receiptRequest attributes included in a single SignedData object, such as requests made from different people who signed the object in parallel.
receiptRequest仅与receiptRequest属性直接附加到的SignerInfo对象关联。接收软件应检查每个SignerInfos的signedAttributes字段，并验证最内层signedData对象中的签名，以确定是否请求接收。这可能导致接收代理处理包括在单个SignedData对象中的多个receiptRequest属性，例如来自并行签署该对象的不同人员的请求。
Before processing a receiptRequest signedAttribute, the receiving agent MUST verify the signature of the SignerInfo which covers the receiptRequest attribute. A recipient MUST NOT process a receiptRequest attribute that has not been verified. Because all receiptRequest attributes in a SignedData object must be identical, the receiving application fully processes (as described in the following paragraphs) the first receiptRequest attribute that it encounters in a SignerInfo that it verifies, and it then ensures that all other receiptRequest attributes in signerInfos that it verifies are identical to the first one encountered. If there are verified ReceiptRequest attributes which are not the same, then the processing software MUST NOT return any signed receipt. A signed receipt SHOULD be returned if any signerInfo containing a receiptRequest attribute can be validated, even if other signerInfos containing the same receiptRequest attribute cannot be validated because they are signed using an algorithm not supported by the receiving agent.
在处理receiptRequest signedAttribute之前，接收代理必须验证涵盖receiptRequest属性的SignerinInfo的签名。收件人不得处理未经验证的receiptRequest属性。由于SignedData对象中的所有receiptRequest属性必须相同，因此接收应用程序将完全处理（如以下段落所述）在其验证的SignerinInfo中遇到的第一个receiptRequest属性，然后，它确保signerInfos中所有其他它验证的receiptRequest属性与遇到的第一个相同。如果存在不相同的已验证ReceiptRequest属性，则处理软件不得返回任何已签名的收据。如果可以验证包含receiptRequest属性的任何signerInfos，则应返回已签名的收据，即使无法验证包含相同receiptRequest属性的其他signerInfos，因为它们是使用接收代理不支持的算法签名的。
If a receiptRequest attribute is absent from the signed attributes, then a signed receipt has not been requested from any of the message recipients and MUST NOT be created. If a receiptRequest attribute is present in the signed attributes, then a signed receipt has been requested from some or all of the message recipients. Note that in some cases, a receiving agent might receive two almost-identical messages, one with a receipt request and the other without one. In this case, the receiving agent SHOULD send a signed receipt for the message that requests a signed receipt.
如果已签名属性中缺少receiptRequest属性，则未从任何邮件收件人请求已签名回执，因此不得创建该回执。如果签名属性中存在receiptRequest属性，则已从部分或所有邮件收件人请求签名回执。请注意，在某些情况下，接收代理可能会收到两条几乎相同的消息，一条带有接收请求，另一条没有。在这种情况下，接收代理应该为请求签名回执的消息发送签名回执。
If a receiptRequest attribute is present in the signed attributes, the following process SHOULD be used to determine if a message recipient has been requested to return a signed receipt.
如果已签名属性中存在receiptRequest属性，则应使用以下过程确定是否已请求邮件收件人返回已签名的回执。
1. If an mlExpansionHistory attribute is present in the outermost signedData block, do one of the following two steps, based on the absence or presence of mlReceiptPolicy:
1. 如果最外层的signedData块中存在mlExpansionHistory属性，请根据是否存在mlReceiptPolicy执行以下两个步骤之一：
1.1. If an mlReceiptPolicy value is absent from the last MLData element, a Mail List receipt policy has not been specified and the processing software SHOULD examine the receiptRequest attribute value to determine if a receipt should be created and returned.
1.1. 如果最后一个MLData元素中缺少mlReceiptPolicy值，则未指定邮件列表接收策略，处理软件应检查receiptRequest属性值，以确定是否应创建和返回接收。
1.2. If an mlReceiptPolicy value is present in the last MLData element, do one of the following two steps, based on the value of mlReceiptPolicy:
1.2. 如果最后一个MLData元素中存在mlReceiptPolicy值，请根据mlReceiptPolicy的值执行以下两个步骤之一：
1.2.1. If the mlReceiptPolicy value is none, then the receipt policy of the Mail List supersedes the originator's request for a signed receipt and a signed receipt MUST NOT be created.
1.2.1. 如果mlReceiptPolicy值为none，则邮件列表的接收策略将取代发起者的签名收据请求，并且不得创建签名收据。
1.2.2. If the mlReceiptPolicy value is insteadOf or inAdditionTo, the processing software SHOULD examine the receiptsFrom value from the receiptRequest attribute to determine if a receipt should be created and returned. If a receipt is created, the insteadOf and inAdditionTo fields identify entities that SHOULD be sent the receipt instead of or in addition to the originator.
1.2.2. 如果mlReceiptPolicy值不是或不是附加值，则处理软件应检查receiptRequest属性中的receiptsFrom值，以确定是否应创建和返回收据。如果创建了收据，则insteadOf和INADADDENTTO字段将标识应发送收据而不是或除了发端人之外的实体。
2. If the receiptsFrom value of the receiptRequest attribute allOrFirstTier, do one of the following two steps based on the value of allOrFirstTier.
2. 如果receiptRequest属性AllorFirstier的receiptsFrom值为AllorFirstier，请基于AllorFirstier的值执行以下两个步骤之一。
2.1. If the value of allOrFirstTier is allReceipts, then a signed receipt SHOULD be created.
2.1. 如果AllorFirstier的值为allReceipts，则应创建签名收据。
2.2. If the value of allOrFirstTier is firstTierRecipients, do one of the following two steps based on the presence of an mlExpansionHistory attribute in an outer signedData block:
2.2. 如果AllorFirstier的值为firstTierRecipients，则根据外部signedData块中是否存在mlExpansionHistory属性，执行以下两个步骤之一：
2.2.1. If an mlExpansionHistory attribute is present, then this recipient is not a first tier recipient and a signed receipt MUST NOT be created.
2.2.1. 如果存在mlExpansionHistory属性，则此收件人不是第一层收件人，并且不得创建已签名的回执。
2.2.2. If an mlExpansionHistory attribute is not present, then a signed receipt SHOULD be created.
2.2.2. 如果mlExpansionHistory属性不存在，则应创建签名收据。
3. If the receiptsFrom value of the receiptRequest attribute is a receiptList:
3. 如果receiptRequest属性的receiptsFrom值是receiptList：
3.1. If receiptList contains one of the GeneralNames of the recipient, then a signed receipt SHOULD be created.
3.1. 如果receiptList包含收件人的通用名称之一，则应创建签名收据。
3.2. If receiptList does not contain one of the GeneralNames of the recipient, then a signed receipt MUST NOT be created.
3.2. 如果receiptList不包含收件人的通用名称之一，则不得创建签名收据。
A flow chart for the above steps to be executed for each signerInfo for which the receiving agent verifies the signature would be:
对于接收代理验证签名的每个签名信息，要执行的上述步骤的流程图如下：
0. Receipt Request attribute present? YES -> 1. NO -> STOP 1. Has mlExpansionHistory in outer signedData? YES -> 1.1. NO -> 2. 1.1. mlReceiptPolicy absent? YES -> 2. NO -> 1.2. 1.2. Pick based on value of mlReceiptPolicy. none -> 1.2.1. insteadOf or inAdditionTo -> 1.2.2. 1.2.1. STOP. 1.2.2. Examine receiptsFrom to determine if a receipt should be created, create it if required, send it to recipients designated by mlReceiptPolicy, then -> STOP. 2. Is value of receiptsFrom allOrFirstTier? YES -> Pick based on value of allOrFirstTier. allReceipts -> 2.1. firstTierRecipients -> 2.2. NO -> 3. 2.1. Create a receipt, then -> STOP. 2.2. Has mlExpansionHistory in the outer signedData block? YES -> 2.2.1. NO -> 2.2.2. 2.2.1. STOP. 2.2.2. Create a receipt, then -> STOP. 3. Is receiptsFrom value of receiptRequest a receiptList? YES -> 3.1. NO -> STOP. 3.1. Does receiptList contain the recipient? YES -> Create a receipt, then -> STOP. NO -> 3.2. 3.2. STOP.
0. 收货请求属性是否存在？是->1。否->停止1。外部签名数据中是否有mlExpansionHistory？是->1.1。否->2。1.1. 你不在吗？是->2。否->1.2。1.2. 根据mlReceiptPolicy的值进行拾取。无->1.2.1。取代或补充->1.2.2。1.2.1. 停止1.2.2. 检查receiptsFrom以确定是否应创建收据，必要时创建收据，将其发送给mlReceiptPolicy指定的收件人，然后->停止。2.来自AllorFirstier的收据的价值是多少？是->根据AllorFirstier的值拾取。所有收据->2.1。第一层客户->2.2。否->3。2.1. 创建收据，然后->停止。2.2. 外部signedData块中是否有mlExpansionHistory？是->2.2.1。否->2.2.2。2.2.1. 停止2.2.2. 创建收据，然后->停止。3.receiptRequest的receiptsFrom值是否为receiptList？是->3.1。否->停止。3.1. receiptList是否包含收件人？是->创建收据，然后->停止。否->3.2。3.2. 停止
A signed receipt is a signedData object encapsulating a Receipt content (also called a "signedData/Receipt"). Signed receipts are created as follows:
签名收据是封装收据内容的signedData对象（也称为“signedData/receipt”）。签名收据的创建如下所示：
1. The signature of the original signedData signerInfo that includes the receiptRequest signed attribute MUST be successfully verified before creating the signedData/Receipt.
1. 在创建signedData/Receipt之前，必须成功验证包含receiptRequest signed属性的原始signedData SignerinInfo的签名。
1.1. The content of the original signedData object is digested as described in [CMS]. The resulting digest value is then compared with the value of the messageDigest attribute included in the signedAttributes of the original signedData signerInfo. If these digest values are different, then the signature verification process fails and the signedData/Receipt MUST NOT be created.
1.1. 原始signedData对象的内容按照[CMS]中的描述进行摘要。然后将生成的摘要值与原始signedData signerInfo的SignedAttribute中包含的messageDigest属性的值进行比较。如果这些摘要值不同，则签名验证过程失败，并且不能创建签名数据/收据。
1.2. The ASN.1 DER encoded signedAttributes (including messageDigest, receiptRequest and, possibly, other signed attributes) in the original signedData signerInfo are digested as described in [CMS]. The resulting digest value, called msgSigDigest, is then used to verify the signature of the original signedData signerInfo. If the signature verification fails, then the signedData/Receipt MUST NOT be created.
1.2. 原始signedData signerInfo中ASN.1 DER编码的SignedAttribute（包括messageDigest、receiptRequest，可能还有其他签名属性）按照[CMS]中的描述进行摘要。生成的摘要值称为msgSigDigest，然后用于验证原始signedData signerInfo的签名。如果签名验证失败，则不能创建签名数据/收据。
2. A Receipt structure is created.
2. 将创建一个收据结构。
2.1. The value of the Receipt version field is set to 1.
2.1. 收据版本字段的值设置为1。
2.2. The object identifier from the contentType attribute included in the original signedData signerInfo that includes the receiptRequest attribute is copied into the Receipt contentType.
2.2. 包含receiptRequest属性的原始signedData signerInfo中包含的contentType属性中的对象标识符被复制到ReceiptContentType中。
2.3. The original signedData signerInfo receiptRequest signedContentIdentifier is copied into the Receipt signedContentIdentifier.
2.3. 原始signedData signerInfo receiptRequest signedContentIdentifier复制到收据signedContentIdentifier中。
2.4. The signature value from the original signedData signerInfo that includes the receiptRequest attribute is copied into the Receipt originatorSignatureValue.
2.4. 原始signedData signerInfo中包含receiptRequest属性的签名值被复制到ReceiptOriginatorSignatureValue中。
3. The Receipt structure is ASN.1 DER encoded to produce a data stream, D1.
3. 接收结构被ASN.1 DER编码以产生数据流D1。
4. D1 is digested. The resulting digest value is included as the messageDigest attribute in the signedAttributes of the signerInfo which will eventually contain the signedData/Receipt signature value.
4. D1被消化。生成的摘要值作为messageDigest属性包含在signerInfo的SignedAttribute中，该属性最终将包含signedData/Receipt签名值。
5. The digest value (msgSigDigest) calculated in Step 1 to verify the signature of the original signedData signerInfo is included as the msgSigDigest attribute in the signedAttributes of the signerInfo which will eventually contain the signedData/Receipt signature value.
5. 在步骤1中为验证原始signedData signerInfo的签名而计算的摘要值（msgSigDigest）将作为msgSigDigest属性包含在signerInfo的SignedAttribute中，该属性最终将包含signedData/Receipt签名值。
6. A contentType attribute including the id-ct-receipt object identifier MUST be created and added to the signed attributes of the signerInfo which will eventually contain the signedData/Receipt signature value.
6. 必须创建包含id ct收据对象标识符的contentType属性，并将其添加到signerInfo的已签名属性中，该属性最终将包含signedData/收据签名值。
7. A signingTime attribute indicating the time that the signedData/Receipt is signed SHOULD be created and added to the signed attributes of the signerInfo which will eventually contain the signedData/Receipt signature value. Other attributes (except receiptRequest) may be added to the signedAttributes of the signerInfo.
7. 应创建一个signingTime属性，指示签名数据/收据的签名时间，并将其添加到SignerinInfo的签名属性中，该属性最终将包含签名数据/收据签名值。其他属性（receiptRequest除外）可以添加到SignerinInfo的SignedAttribute。
8. The signedAttributes (messageDigest, msgSigDigest, contentType and, possibly, others) of the signerInfo are ASN.1 DER encoded and digested as described in [CMS]. The resulting digest value is used to calculate the signature value which is then included in the signedData/Receipt signerInfo.
8. signerInfo的SignedAttribute（messageDigest、msgSigDigest、contentType，可能还有其他）按照[CMS]中的描述进行ASN.1 DER编码和摘要。生成的摘要值用于计算签名值，然后将其包含在signedData/Receipt SignerinInfo中。
9. The ASN.1 DER encoded Receipt content MUST be directly encoded within the signedData encapContentInfo eContent OCTET STRING defined in [CMS]. The id-ct-receipt object identifier MUST be included in the signedData encapContentInfo eContentType. This results in a single ASN.1 encoded object composed of a signedData including the Receipt content. The Data content type MUST NOT be used. The Receipt content MUST NOT be encapsulated in a MIME header or any other header prior to being encoded as part of the signedData object.
9. ASN.1 DER编码的收据内容必须直接编码在[CMS]中定义的signedData encapContentInfo eContent八位字节字符串中。id ct收据对象标识符必须包含在signedData encapContentInfo eContentType中。这将产生一个ASN.1编码的对象，该对象由包含收据内容的signedData组成。不得使用数据内容类型。在将收据内容编码为signedData对象的一部分之前，不得将其封装在MIME头或任何其他头中。
10. The signedData/Receipt is then put in an application/pkcs7-mime MIME wrapper with the smime-type parameter set to "signed-receipt". This will allow for identification of signed receipts without having to crack the ASN.1 body. The smime-type parameter would still be set as normal in any layer wrapped around this message.
10. 然后将signedData/Receipt放入应用程序/pkcs7 mime mime包装中，smime类型参数设置为“signed Receipt”。这将允许识别已签名收据，而无需破解ASN.1正文。smime类型参数仍将在围绕此消息的任何层中设置为正常。
11. If the signedData/Receipt is to be encrypted within an envelopedData object, then an outer signedData object MUST be created that encapsulates the envelopedData object, and a contentHints attribute with contentType set to the id-ct-receipt object identifier MUST be included in the outer signedData SignerInfo signedAttributes. When a receiving agent processes the outer signedData object, the presence of the id-ct-receipt OID in the contentHints contentType indicates that a signedData/Receipt is encrypted within the envelopedData object encapsulated by the outer signedData.
11. 如果要在envelopedData对象中加密signedData/收据，则必须创建封装envelopedData对象的外部signedData对象，并且必须在外部signedData SignerInfo SignedAttribute中包含contentType设置为id ct收据对象标识符的ContentHits属性。当接收代理处理外部signedData对象时，ContentHipts contentType中的id ct receipt OID表示signedData/收据在外部signedData封装的envelopedData对象内加密。
All sending agents that support the generation of ESS signed receipts MUST provide the ability to send encrypted signed receipts (that is, a signedData/Receipt encapsulated within an envelopedData). The sending agent MAY send an encrypted signed receipt in response to an envelopedData-encapsulated signedData requesting a signed receipt. It is a matter of local policy regarding whether or not the signed receipt should be encrypted. The ESS signed receipt includes the message digest value calculated for the original signedData object that requested the signed receipt. If the original signedData object was sent encrypted within an envelopedData object and the ESS signed receipt is sent unencrypted, then the message digest value calculated for the original encrypted signedData object is sent unencrypted. The responder should consider this when deciding whether or not to encrypt the ESS signed receipt.
所有支持生成ESS签名收据的发送代理必须能够发送加密的签名收据（即封装在信封数据中的签名数据/收据）。发送代理可以发送加密的签名收据，以响应信封数据封装的签名数据请求签名收据。是否对签名收据进行加密是当地政策的问题。ESS签名回执包括为请求签名回执的原始signedData对象计算的消息摘要值。如果原始signedData对象是在envelopedData对象中加密发送的，而ESS签名回执是未加密发送的，则为原始加密signedData对象计算的消息摘要值将被未加密发送。应答者在决定是否加密ESS签名收据时应考虑这一点。
An MLExpansionHistory attribute MUST NOT be included in the attributes of a SignerInfo in a SignedData object that encapsulates a Receipt content. This is true because when a SignedData/Receipt is sent to an MLA for distribution, then the MLA must always encapsulate the received SignedData/Receipt in an outer SignedData in which the MLA will include the MLExpansionHistory attribute. The MLA cannot change the signedAttributes of the received SignedData/Receipt object, so it can't add the MLExpansionHistory to the SignedData/Receipt.
封装收据内容的SignedData对象中SignerInfo的属性中不得包含MLExpansionHistory属性。这是正确的，因为当向MLA发送SignedData/Receipt进行分发时，MLA必须始终将收到的SignedData/Receipt封装在外部SignedData中，MLA将在其中包含MLExpansionHistory属性。MLA无法更改收到的SignedData/Receipt对象的SignedAttribute，因此无法将MLExpansionHistory添加到SignedData/Receipt。
If a signed receipt was created by the process described in the sections above, then the software MUST use the following process to determine to whom the signed receipt should be sent.
如果签名收据是通过上述章节中描述的过程创建的，则软件必须使用以下过程来确定签名收据应发送给谁。
1. The receiptsTo field must be present in the receiptRequest attribute. The software initiates the sequence of recipients with the value(s) of receiptsTo.
1. receiptsTo字段必须出现在receiptRequest属性中。软件使用receiptsTo的值启动收件人序列。
2. If the MlExpansionHistory attribute is present in the outer SignedData block, and the last MLData contains an MLReceiptPolicy value of insteadOf, then the software replaces the sequence of recipients with the value(s) of insteadOf.
2. 如果外部SignedData块中存在MlExpansionHistory属性，并且最后一个MLData包含MLReceiptPolicy值insteadOf，则软件将用insteadOf值替换收件人序列。
3. If the MlExpansionHistory attribute is present in the outer SignedData block and the last MLData contains an MLReceiptPolicy value of inAdditionTo, then the software adds the value(s) of inAdditionTo to the sequence of recipients.
3. 如果外部SignedData块中存在MlExpansionHistory属性，并且最后一个MLData包含MLReceiptPolicy值inAdditionTo，则软件会将inAdditionTo值添加到收件人序列中。
A signed receipt is communicated as a single ASN.1 encoded object composed of a signedData object directly including a Receipt content. It is identified by the presence of the id-ct-receipt object identifier in the encapContentInfo eContentType value of the signedData object including the Receipt content.
签名收据作为单个ASN.1编码对象进行通信，该对象由直接包含收据内容的signedData对象组成。它由包含收据内容的signedData对象的encapContentInfo eContentType值中的id ct收据对象标识符标识。
Although recipients are not supposed to send more than one signed receipt, receiving agents SHOULD be able to accept multiple signed receipts from a recipient.
虽然收件人不应发送多个签名收据，但接收代理应能够从收件人处接收多个签名收据。
A signedData/Receipt is validated as follows:
签名数据/收据的验证如下：
1. ASN.1 decode the signedData object including the Receipt content.
1. ASN.1解码包含收据内容的signedData对象。
2. Extract the contentType, signedContentIdentifier, and originatorSignatureValue from the decoded Receipt structure to identify the original signedData signerInfo that requested the signedData/Receipt.
2. 从解码的回执结构中提取contentType、signedContentIdentifier和originatorSignatureValue，以标识请求signedData/回执的原始signedData signerInfo。
3. Acquire the message signature digest value calculated by the sender to generate the signature value included in the original signedData signerInfo that requested the signedData/Receipt.
3. 获取发件人计算的消息签名摘要值，以生成请求签名数据/收据的原始签名数据signerInfo中包含的签名值。
3.1. If the sender-calculated message signature digest value has been saved locally by the sender, it must be located and retrieved.
3.1. 如果发件人已在本地保存发件人计算的邮件签名摘要值，则必须找到并检索该值。
3.2. If it has not been saved, then it must be re-calculated based on the original signedData content and signedAttributes as described in [CMS].
3.2. 如果未保存，则必须根据[CMS]中所述的原始signedData内容和SignedAttribute重新计算。
4. The message signature digest value calculated by the sender is then compared with the value of the msgSigDigest signedAttribute included in the signedData/Receipt signerInfo. If these digest values are identical, then that proves that the message signature digest value calculated by the recipient based on the received
4. 然后将发件人计算的消息签名摘要值与signedData/ReceiveSignerinInfo中包含的msgSigDigest signedAttribute的值进行比较。如果这些摘要值相同，则证明收件人根据收到的摘要值计算的消息签名摘要值
original signedData object is the same as that calculated by the sender. This proves that the recipient received exactly the same original signedData content and signedAttributes as sent by the sender because that is the only way that the recipient could have calculated the same message signature digest value as calculated by the sender. If the digest values are different, then the signedData/Receipt signature verification process fails.
原始signedData对象与发送方计算的对象相同。这证明收件人收到的原始signedData内容和SignedAttribute与发件人发送的完全相同，因为这是收件人计算与发件人计算的相同邮件签名摘要值的唯一方法。如果摘要值不同，则签名数据/收据签名验证过程失败。
5. Acquire the digest value calculated by the sender for the Receipt content constructed by the sender (including the contentType, signedContentIdentifier, and signature value that were included in the original signedData signerInfo that requested the signedData/Receipt).
5. 获取发送方为发送方构造的回执内容计算的摘要值（包括请求签名数据/回执的原始签名数据signerInfo中包含的contentType、signedContentIdentifier和签名值）。
5.1. If the sender-calculated Receipt content digest value has been saved locally by the sender, it must be located and retrieved.
5.1. 如果发件人已在本地保存发件人计算的回执内容摘要值，则必须找到并检索该值。
5.2. If it has not been saved, then it must be re-calculated. As described in section above, step 2, create a Receipt structure including the contentType, signedContentIdentifier and signature value that were included in the original signedData signerInfo that requested the signed receipt. The Receipt structure is then ASN.1 DER encoded to produce a data stream which is then digested to produce the Receipt content digest value.
5.2. 如果尚未保存，则必须重新计算。如上文第节第2步所述，创建一个收据结构，包括请求签名收据的原始signedData signerInfo中包含的contentType、signedContentIdentifier和签名值。然后对接收结构进行ASN.1 DER编码以生成数据流，然后对数据流进行摘要处理以生成接收内容摘要值。
6. The Receipt content digest value calculated by the sender is then compared with the value of the messageDigest signedAttribute included in the signedData/Receipt signerInfo. If these digest values are identical, then that proves that the values included in the Receipt content by the recipient are identical to those that were included in the original signedData signerInfo that requested the signedData/Receipt. This proves that the recipient received the original signedData signed by the sender, because that is the only way that the recipient could have obtained the original signedData signerInfo signature value for inclusion in the Receipt content. If the digest values are different, then the signedData/Receipt signature verification process fails.
6. 然后将发件人计算的收据内容摘要值与signedData/Receipt SignerinInfo中包含的messageDigest signedAttribute的值进行比较。如果这些摘要值相同，则证明收件人在收据内容中包含的值与请求签名数据/收据的原始签名数据签名信息中包含的值相同。这证明收件人收到了由发件人签名的原始signedData，因为这是收件人获得原始signedData signerInfo签名值以包含在收据内容中的唯一方法。如果摘要值不同，则签名数据/收据签名验证过程失败。
7. The ASN.1 DER encoded signedAttributes of the signedData/Receipt signerInfo are digested as described in [CMS].
7. 已签名数据/收据签名信息的ASN.1 DER编码的已签名属性按照[CMS]中所述进行摘要。
8. The resulting digest value is then used to verify the signature value included in the signedData/Receipt signerInfo. If the signature verification is successful, then that proves the integrity of the signedData/receipt signerInfo signedAttributes and authenticates the identity of the signer of the signedData/Receipt
8. 然后，生成的摘要值用于验证signedData/Receipt SignerinInfo中包含的签名值。如果签名验证成功，则证明signedData/receipt signerInfo SignedAttribute的完整性，并验证signedData/receipt签名者的身份
signerInfo. Note that the signedAttributes include the recipient-calculated Receipt content digest value (messageDigest attribute) and recipient-calculated message signature digest value (msgSigDigest attribute). Therefore, the aforementioned comparison of the sender-generated and recipient-generated digest values combined with the successful signedData/Receipt signature verification proves that the recipient received the exact original signedData content and signedAttributes (proven by msgSigDigest attribute) that were signed by the sender of the original signedData object (proven by messageDigest attribute). If the signature verification fails, then the signedData/Receipt signature verification process fails.
先生。请注意，SignedAttribute包括收件人计算的回执内容摘要值（messageDigest属性）和收件人计算的邮件签名摘要值（msgSigDigest属性）。因此，上述发送方生成的摘要值与接收方生成的摘要值的比较以及成功的signedData/Receipt签名验证证明接收方收到了准确的原始signedData内容和SignedAttribute（由msgSigDigest属性验证）由原始signedData对象的发件人签名（由messageDigest属性验证）。如果签名验证失败，则签名数据/收据签名验证过程失败。
The signature verification process for each signature algorithm that is used in conjunction with the CMS protocol is specific to the algorithm. These processes are described in documents specific to the algorithms.
与CMS协议一起使用的每个签名算法的签名验证过程特定于该算法。这些过程在特定于算法的文档中进行了描述。
A receiptRequest attribute value has ASN.1 type ReceiptRequest. Use the receiptRequest attribute only within the signed attributes associated with a signed message.
receiptRequest属性值具有ASN.1类型receiptRequest。仅在与签名消息关联的签名属性中使用receiptRequest属性。
ReceiptRequest ::= SEQUENCE {
signedContentIdentifier ContentIdentifier,
receiptsFrom ReceiptsFrom,
receiptsTo SEQUENCE SIZE (1..ub-receiptsTo)) OF GeneralNames }
ReceiptRequest ::= SEQUENCE {
signedContentIdentifier ContentIdentifier,
receiptsFrom ReceiptsFrom,
receiptsTo SEQUENCE SIZE (1..ub-receiptsTo)) OF GeneralNames }
ub-receiptsTo INTEGER ::= 16
ub-receiptsTo INTEGER ::= 16
id-aa-receiptRequest OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 1}
id-aa-receiptRequest OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 1}
ContentIdentifier ::= OCTET STRING
ContentIdentifier ::= OCTET STRING
id-aa-contentIdentifier OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 7}
id-aa-contentIdentifier OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 7}
A signedContentIdentifier MUST be created by the message originator when creating a receipt request. To ensure global uniqueness, the minimal signedContentIdentifier SHOULD contain a concatenation of user-specific identification information (such as a user name or public keying material identification information), a GeneralizedTime string, and a random number.
在创建回执请求时，消息发起人必须创建signedContentIdentifier。为确保全局唯一性，最小signedContentIdentifier应包含特定于用户的标识信息（如用户名或公钥材料标识信息）、泛化时间字符串和随机数的串联。
The receiptsFrom field is used by the originator to specify the recipients requested to return a signed receipt. A CHOICE is provided to allow specification of:
发端人使用receiptsFrom字段指定请求返回签名收据的收件人。提供了一个选项，以允许指定：
- receipts from all recipients are requested - receipts from first tier (recipients that did not receive the message as members of a mailing list) recipients are requested - receipts from a specific list of recipients are requested
- 请求来自所有收件人的收据-请求来自第一层（未作为邮件列表成员接收邮件的收件人）收件人的收据-请求来自特定收件人列表的收据
ReceiptsFrom ::= CHOICE {
allOrFirstTier [0] AllOrFirstTier,
-- formerly "allOrNone [0]AllOrNone"
receiptList [1] SEQUENCE OF GeneralNames }
ReceiptsFrom ::= CHOICE {
allOrFirstTier [0] AllOrFirstTier,
-- formerly "allOrNone [0]AllOrNone"
receiptList [1] SEQUENCE OF GeneralNames }
AllOrFirstTier ::= INTEGER { -- Formerly AllOrNone
allReceipts (0),
firstTierRecipients (1) }
AllOrFirstTier ::= INTEGER { -- Formerly AllOrNone
allReceipts (0),
firstTierRecipients (1) }
The receiptsTo field is used by the originator to identify the user(s) to whom the identified recipient should send signed receipts. The message originator MUST populate the receiptsTo field with a GeneralNames for each entity to whom the recipient should send the signed receipt. If the message originator wants the recipient to send the signed receipt to the originator, then the originator MUST include a GeneralNames for itself in the receiptsTo field.
发端人使用receiptsTo字段识别已识别收件人应向其发送已签名收据的用户。消息发起人必须在receiptsTo字段中填入收件人应向其发送签名收据的每个实体的通用名称。如果消息发端人希望收件人向发端人发送已签名的回执，则发端人必须在ReceiptTo字段中包含自己的通用名称。
Receipts are represented using a new content type, Receipt. The Receipt content type shall have ASN.1 type Receipt. Receipts must be encapsulated within a SignedData message.
收据使用新的内容类型Receipt表示。收据内容类型应具有ASN.1类型的收据。收据必须封装在SignedData消息中。
Receipt ::= SEQUENCE {
version ESSVersion,
contentType ContentType,
signedContentIdentifier ContentIdentifier,
originatorSignatureValue OCTET STRING }
Receipt ::= SEQUENCE {
version ESSVersion,
contentType ContentType,
signedContentIdentifier ContentIdentifier,
originatorSignatureValue OCTET STRING }
id-ct-receipt OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-ct(1) 1}
id-ct-receipt OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-ct(1) 1}
ESSVersion ::= INTEGER { v1(1) }
ESSVersion ::= INTEGER { v1(1) }
The version field defines the syntax version number, which is 1 for this version of the standard.
版本字段定义语法版本号，对于本版本的标准，该版本号为1。
Many applications find it useful to have information that describes the innermost signed content of a multi-layer message available on the outermost signature layer. The contentHints attribute provides such information.
许多应用程序发现，在最外层签名层上提供描述多层消息最内层签名内容的信息非常有用。ContentHitts属性提供此类信息。
Content-hints attribute values have ASN.1 type contentHints.
内容提示属性值具有ASN.1类型的内容提示。
ContentHints ::= SEQUENCE {
contentDescription UTF8String (SIZE (1..MAX)) OPTIONAL,
contentType ContentType }
ContentHints ::= SEQUENCE {
contentDescription UTF8String (SIZE (1..MAX)) OPTIONAL,
contentType ContentType }
id-aa-contentHint OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 4}
id-aa-contentHint OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 4}
The contentDescription field may be used to provide information that the recipient may use to select protected messages for processing, such as a message subject. If this field is set, then the attribute is expected to appear on the signedData object enclosing an envelopedData object and not on the inner signedData object. The (SIZE (1..MAX)) construct constrains the sequence to have at least one entry. MAX indicates the upper bound is unspecified. Implementations are free to choose an upper bound that suits their environment.
contentDescription字段可用于提供收件人可用于选择受保护的消息进行处理的信息，例如消息主题。如果设置了此字段，则该属性应出现在包含envelopedData对象的signedData对象上，而不是出现在内部signedData对象上。（SIZE（1..MAX））构造将序列约束为至少有一个条目。MAX表示未指定上限。实现可以自由选择适合其环境的上限。
Messages which contain a signedData object wrapped around an envelopedData object, thus masking the inner content type of the message, SHOULD include a contentHints attribute, except for the case of the data content type. Specific message content types may either force or preclude the inclusion of the contentHints attribute. For example, when a signedData/Receipt is encrypted within an envelopedData object, an outer signedData object MUST be created that encapsulates the envelopedData object and a contentHints attribute with contentType set to the id-ct-receipt object identifier MUST be included in the outer signedData SignerInfo signedAttributes.
包含包裹在envelopedData对象周围的signedData对象（从而屏蔽消息的内部内容类型）的消息应包含ContentHitts属性，数据内容类型除外。特定的消息内容类型可能会强制或阻止包含ContentHights属性。例如，当在envelopedData对象中加密signedData/收据时，必须创建封装envelopedData对象的外部signedData对象，并且必须在外部signedData SignerInfo SignedAttribute中包含contentType设置为id ct收据对象标识符的ContentHits属性。
The msgSigDigest attribute can only be used in the signed attributes of a signed receipt. It contains the digest of the ASN.1 DER encoded signedAttributes included in the original signedData that requested the signed receipt. Only one msgSigDigest attribute can appear in a signed attributes set. It is defined as follows:
msgSigDigest属性只能用于已签名收据的已签名属性。它包含请求签名收据的原始签名数据中包含的ASN.1 DER编码签名属性的摘要。签名属性集中只能显示一个msgSigDigest属性。其定义如下：
msgSigDigest ::= OCTET STRING
msgSigDigest ::= OCTET STRING
id-aa-msgSigDigest OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 5}
id-aa-msgSigDigest OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 5}
The contentReference attribute is a link from one SignedData to another. It may be used to link a reply to the original message to which it refers, or to incorporate by reference one SignedData into another. The first SignedData MUST include a contentIdentifier signed attribute, which SHOULD be constructed as specified in section 2.7. The second SignedData links to the first by including a ContentReference signed attribute containing the content type, content identifier, and signature value from the first SignedData.
contentReference属性是从一个SignedData到另一个SignedData的链接。它可以用于将回复链接到它所引用的原始消息，或者通过引用将一个签名数据合并到另一个签名数据中。第一个SignedData必须包含contentIdentifier签名属性，该属性应按照第2.7节的规定构造。第二个SignedData通过包含ContentReference签名属性链接到第一个，该属性包含第一个SignedData的内容类型、内容标识符和签名值。
ContentReference ::= SEQUENCE {
contentType ContentType,
signedContentIdentifier ContentIdentifier,
originatorSignatureValue OCTET STRING }
ContentReference ::= SEQUENCE {
contentType ContentType,
signedContentIdentifier ContentIdentifier,
originatorSignatureValue OCTET STRING }
id-aa-contentReference OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 10 }
id-aa-contentReference OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 10 }
This section describes the syntax to be used for security labels that can optionally be associated with S/MIME encapsulated data. A security label is a set of security information regarding the sensitivity of the content that is protected by S/MIME encapsulation.
本节描述用于安全标签的语法，这些安全标签可以选择性地与S/MIME封装数据关联。安全标签是关于受S/MIME封装保护的内容的敏感度的一组安全信息。
"Authorization" is the act of granting rights and/or privileges to users permitting them access to an object. "Access control" is a means of enforcing these authorizations. The sensitivity information in a security label can be compared with a user's authorizations to determine if the user is allowed to access the content that is protected by S/MIME encapsulation.
“授权”是向允许用户访问对象的用户授予权利和/或特权的行为。“访问控制”是执行这些授权的一种手段。可以将安全标签中的敏感度信息与用户的授权进行比较，以确定是否允许用户访问受s/MIME封装保护的内容。
Security labels may be used for other purposes such as a source of routing information. The labels often describe ranked levels ("secret", "confidential", "restricted", and so on) or are role-based, describing which kind of people can see the information ("patient's health-care team", "medical billing agents", "unrestricted", and so on).
安全标签可用于其他目的，例如路由信息源。标签通常描述等级（“机密”、“机密”、“受限”等），或者基于角色，描述哪类人可以看到信息（“患者的医疗团队”、“医疗账单代理”、“不受限”等）。
A sending agent may include a security label attribute in the signed attributes of a signedData object. A receiving agent examines the security label on a received message and determines whether or not the recipient is allowed to see the contents of the message.
发送代理可以在signedData对象的签名属性中包括安全标签属性。接收代理检查接收到的邮件上的安全标签，并确定是否允许收件人查看邮件内容。
A sending agent that is using security labels MUST put the security label attribute in the signedAttributes field of a SignerInfo block. The security label attribute MUST NOT be included in the unsigned attributes. Integrity and authentication security services MUST be applied to the security label, therefore it MUST be included as a signed attribute, if used. This causes the security label attribute to be part of the data that is hashed to form the SignerInfo signature value. A SignerInfo block MUST NOT have more than one security label signed attribute.
使用安全标签的发送代理必须将安全标签属性放入SignerInfo块的signedAttributes字段中。未签名属性中不得包含安全标签属性。完整性和身份验证安全服务必须应用于安全标签，因此，如果使用，必须将其作为签名属性包含。这将导致安全标签属性成为散列以形成SignerInfo签名值的数据的一部分。SignerInfo块不能有多个安全标签签名属性。
When there are multiple SignedData blocks applied to a message, a security label attribute may be included in either the inner signature, outer signature, or both. A security label signed attribute may be included in a signedAttributes field within the inner SignedData block. The inner security label will include the sensitivities of the original content and will be used for access control decisions related to the plaintext encapsulated content. The inner signature provides authentication of the inner security label and cryptographically protects the original signer's inner security label of the original content.
当有多个SignedData块应用于消息时，安全标签属性可以包含在内部签名、外部签名或两者中。安全标签签名属性可以包含在内部SignedData块内的SignedAttribute字段中。内部安全标签将包括原始内容的敏感性，并将用于与明文封装内容相关的访问控制决策。内部签名提供内部安全标签的身份验证，并以加密方式保护原始内容的原始签名者的内部安全标签。
When the originator signs the plaintext content and signed attributes, the inner security label is bound to the plaintext content. An intermediate entity cannot change the inner security label without invalidating the inner signature. The confidentiality security service can be applied to the inner security label by encrypting the entire inner signedData object within an EnvelopedData block.
当发起人对明文内容和已签名属性进行签名时，内部安全标签将绑定到明文内容。中间实体在不使内部签名无效的情况下无法更改内部安全标签。机密性安全服务可以通过加密信封数据块中的整个内部signedData对象应用于内部安全标签。
A security label signed attribute may also be included in a signedAttributes field within the outer SignedData block. The outer security label will include the sensitivities of the encrypted
安全标签签名属性也可以包含在外部SignedData块内的SignedAttribute字段中。外部安全标签将包括加密文件的敏感性
message and will be used for access control decisions related to the encrypted message and for routing decisions. The outer signature provides authentication of the outer security label (as well as for the encapsulated content which may include nested S/MIME messages).
消息和将用于与加密消息相关的访问控制决策和路由决策。外部签名为外部安全标签（以及可能包含嵌套S/MIME消息的封装内容）提供身份验证。
There can be multiple SignerInfos within a SignedData object, and each SignerInfo may include signedAttributes. Therefore, a single SignedData object may include multiple eSSSecurityLabels, each SignerInfo having an eSSSecurityLabel attribute. For example, an originator can send a signed message with two SignerInfos, one containing a DSS signature, the other containing an RSA signature. If any of the SignerInfos included in a SignedData object include an eSSSecurityLabel attribute, then all of the SignerInfos in that SignedData object MUST include an eSSSecurityLabel attribute and the value of each MUST be identical.
一个SignedData对象中可以有多个SignerInfos，每个SignerInfos可能包括SignedAttribute。因此，单个SignedData对象可能包括多个eSSSecurityLabel，每个SignerInfo都有一个eSSSecurityLabel属性。例如，发起者可以发送带有两个签名的签名消息，一个包含DSS签名，另一个包含RSA签名。如果SignedData对象中包含的任何SignerInfos包含eSSSecurityLabel属性，则该SignedData对象中的所有SignerInfos都必须包含eSSSecurityLabel属性，并且每个属性的值必须相同。
Before processing an eSSSecurityLabel signedAttribute, the receiving agent MUST verify the signature of the SignerInfo which covers the eSSSecurityLabel attribute. A recipient MUST NOT process an eSSSecurityLabel attribute that has not been verified.
在处理eSSSecurityLabel signedAttribute之前，接收代理必须验证涵盖eSSSecurityLabel属性的SignerInfo的签名。收件人不得处理未经验证的eSSSecurityLabel属性。
A receiving agent MUST process the eSSSecurityLabel attribute, if present, in each SignerInfo in the SignedData object for which it verifies the signature. This may result in the receiving agent processing multiple eSSSecurityLabels included in a single SignedData object. Because all eSSSecurityLabels in a SignedData object must be identical, the receiving agent processes (such as performing access control) on the first eSSSecurityLabel that it encounters in a SignerInfo that it verifies, and then ensures that all other eSSSecurityLabels in signerInfos that it verifies are identical to the first one encountered. If the eSSSecurityLabels in the signerInfos that it verifies are not all identical, then the receiving agent MUST warn the user of this condition.
接收代理必须在其验证签名的SignedData对象中的每个SignerInfo中处理eSSSecurityLabel属性（如果存在）。这可能导致接收代理处理单个SignedData对象中包含的多个ESSSecurityLabel。由于SignedData对象中的所有eSSSecurityLabel必须相同，因此接收代理对其在验证的signerInfos中遇到的第一个eSSSecurityLabel进行处理（例如执行访问控制），然后确保其验证的signerInfos中的所有其他eSSSecurityLabel与遇到的第一个eSSSecurityLabel相同。如果其验证的signerInfos中的ESSSecurityLabel不完全相同，则接收代理必须警告用户此情况。
Receiving agents SHOULD have a local policy regarding whether or not to show the inner content of a signedData object that includes an eSSSecurityLabel security-policy-identifier that the processing software does not recognize. If the receiving agent does not recognize the eSSSecurityLabel security-policy-identifier value, then it SHOULD stop processing the message and indicate an error.
接收代理应具有本地策略，以确定是否显示signedData对象的内部内容，该对象包含处理软件无法识别的eSSSecurityLabel安全策略标识符。如果接收代理无法识别eSSSecurityLabel安全策略标识符值，则应停止处理消息并指示错误。
The eSSSecurityLabel syntax is derived directly from [MTSABS] ASN.1
module. (The MTSAbstractService module begins with "DEFINITIONS
IMPLICIT TAGS ::=".) Further, the eSSSecurityLabel syntax is
compatible with that used in [MSP4].
The eSSSecurityLabel syntax is derived directly from [MTSABS] ASN.1
module. (The MTSAbstractService module begins with "DEFINITIONS
IMPLICIT TAGS ::=".) Further, the eSSSecurityLabel syntax is
compatible with that used in [MSP4].
ESSSecurityLabel ::= SET {
security-policy-identifier SecurityPolicyIdentifier,
security-classification SecurityClassification OPTIONAL,
privacy-mark ESSPrivacyMark OPTIONAL,
security-categories SecurityCategories OPTIONAL }
ESSSecurityLabel ::= SET {
security-policy-identifier SecurityPolicyIdentifier,
security-classification SecurityClassification OPTIONAL,
privacy-mark ESSPrivacyMark OPTIONAL,
security-categories SecurityCategories OPTIONAL }
id-aa-securityLabel OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 2}
id-aa-securityLabel OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 2}
SecurityPolicyIdentifier ::= OBJECT IDENTIFIER
SecurityPolicyIdentifier ::= OBJECT IDENTIFIER
SecurityClassification ::= INTEGER {
unmarked (0),
unclassified (1),
restricted (2),
confidential (3),
secret (4),
top-secret (5) } (0..ub-integer-options)
SecurityClassification ::= INTEGER {
unmarked (0),
unclassified (1),
restricted (2),
confidential (3),
secret (4),
top-secret (5) } (0..ub-integer-options)
ub-integer-options INTEGER ::= 256
ub-integer-options INTEGER ::= 256
ESSPrivacyMark ::= CHOICE {
pString PrintableString (SIZE (1..ub-privacy-mark-length)),
utf8String UTF8String (SIZE (1..MAX))
}
ESSPrivacyMark ::= CHOICE {
pString PrintableString (SIZE (1..ub-privacy-mark-length)),
utf8String UTF8String (SIZE (1..MAX))
}
ub-privacy-mark-length INTEGER ::= 128
ub-privacy-mark-length INTEGER ::= 128
SecurityCategories ::= SET SIZE (1..ub-security-categories) OF
SecurityCategory
SecurityCategories ::= SET SIZE (1..ub-security-categories) OF
SecurityCategory
ub-security-categories INTEGER ::= 64
ub-security-categories INTEGER ::= 64
SecurityCategory ::= SEQUENCE {
type [0] OBJECT IDENTIFIER,
value [1] ANY DEFINED BY type -- defined by type
}
SecurityCategory ::= SEQUENCE {
type [0] OBJECT IDENTIFIER,
value [1] ANY DEFINED BY type -- defined by type
}
--Note: The aforementioned SecurityCategory syntax produces identical --hex encodings as the following SecurityCategory syntax that is --documented in the X.411 specification:
--注意：前面提到的SecurityCategory语法生成与X.411规范中记录的以下SecurityCategory语法相同的十六进制编码：
--
--SecurityCategory ::= SEQUENCE {
-- type [0] SECURITY-CATEGORY,
-- value [1] ANY DEFINED BY type }
--
--SECURITY-CATEGORY MACRO ::=
--BEGIN
--TYPE NOTATION ::= type | empty
--VALUE NOTATION ::= value (VALUE OBJECT IDENTIFIER)
--END
--
--SecurityCategory ::= SEQUENCE {
-- type [0] SECURITY-CATEGORY,
-- value [1] ANY DEFINED BY type }
--
--SECURITY-CATEGORY MACRO ::=
--BEGIN
--TYPE NOTATION ::= type | empty
--VALUE NOTATION ::= value (VALUE OBJECT IDENTIFIER)
--END
This section gives more detail on the the various components of the eSSSecurityLabel syntax.
本节详细介绍了eSSSecurityLabel语法的各个组件。
A security policy is a set of criteria for the provision of security services. The eSSSecurityLabel security-policy-identifier is used to identify the security policy in force to which the security label relates. It indicates the semantics of the other security label components.
安全策略是提供安全服务的一组标准。eSSSecurityLabel安全策略标识符用于标识与安全标签相关的有效安全策略。它指示其他安全标签组件的语义。
This specification defines the use of the Security Classification field exactly as is specified in the X.411 Recommendation, which states in part:
本规范完全按照X.411建议中的规定定义了安全分类字段的使用，其中部分规定：
If present, a security-classification may have one of a hierarchical list of values. The basic security-classification hierarchy is defined in this Recommendation, but the use of these values is defined by the security-policy in force. Additional values of security-classification, and their position in the hierarchy, may also be defined by a security-policy as a local matter or by bilateral agreement. The basic security-classification hierarchy is, in ascending order: unmarked, unclassified, restricted, confidential, secret, top-secret.
如果存在，安全分类可以具有值的分层列表之一。本建议中定义了基本安全分类层次结构，但这些值的使用由现行安全策略定义。安全分类的附加值及其在层次结构中的位置也可以由安全策略作为本地事项或双边协议来定义。基本安全分类层次结构按升序排列：未标记、未分类、受限、机密、机密、绝密。
This means that the security policy in force (identified by the eSSSecurityLabel security-policy-identifier) defines the SecurityClassification integer values and their meanings.
这意味着有效的安全策略（由eSSSecurityLabel安全策略标识符标识）定义了SecurityClassification整数值及其含义。
An organization can develop its own security policy that defines the SecurityClassification INTEGER values and their meanings. However, the general interpretation of the X.411 specification is that the values of 0 through 5 are reserved for the "basic hierarchy" values
组织可以制定自己的安全策略，定义SecurityClassification整数值及其含义。然而，X.411规范的一般解释是0到5的值保留为“基本层次”值
of unmarked, unclassified, restricted, confidential, secret, and top-secret. Note that X.411 does not provide the rules for how these values are used to label data and how access control is performed using these values.
无标记、非机密、受限、机密、机密和绝密。请注意，X.411未提供如何使用这些值标记数据以及如何使用这些值执行访问控制的规则。
There is no universal definition of the rules for using these "basic hierarchy" values. Each organization (or group of organizations) will define a security policy which documents how the "basic hierarchy" values are used (if at all) and how access control is enforced (if at all) within their domain.
对于使用这些“基本层次”值的规则没有通用的定义。每个组织（或组织组）将定义一个安全策略，该策略记录如何使用“基本层次结构”值（如果有）以及如何在其域内实施访问控制（如果有）。
Therefore, the security-classification value MUST be accompanied by a security-policy-identifier value to define the rules for its use. For example, a company's "secret" classification may convey a different meaning than the US Government "secret" classification. In summary, a security policy SHOULD NOT use integers 0 through 5 for other than their X.411 meanings, and SHOULD instead use other values in a hierarchical fashion.
因此，安全分类值必须伴随安全策略标识符值，以定义其使用规则。例如，公司的“机密”分类可能传达与美国政府的“机密”分类不同的含义。总之，安全策略不应使用整数0到5表示X.411以外的含义，而应以分层方式使用其他值。
Note that the set of valid security-classification values MUST be hierarchical, but these values do not necessarily need to be in ascending numerical order. Further, the values do not need to be contiguous.
请注意，有效的安全分类值集必须是分层的，但这些值不一定需要按升序排列。此外，这些值不需要是连续的。
For example, in the Defense Message System 1.0 security policy, the security-classification value of 11 indicates Sensitive-But-Unclassified and 5 indicates top-secret. The hierarchy of sensitivity ranks top-secret as more sensitive than Sensitive-But-Unclassified even though the numerical value of top-secret is less than Sensitive-But-Unclassified.
例如，在Defense Message System 1.0安全策略中，安全分类值11表示敏感但未分类，5表示绝密。尽管绝密的数值小于敏感但未分类，但敏感度等级将绝密列为比敏感但未分类更敏感的等级。
(Of course, if security-classification values are both hierarchical and in ascending order, a casual reader of the security policy is more likely to understand it.)
（当然，如果安全分类值是分层的，并且是按升序排列的，那么安全策略的普通读者更容易理解它。）
An example of a security policy that does not use any of the X.411 values might be:
不使用任何X.411值的安全策略的示例可能是：
10 -- anyone 15 -- Morgan Corporation and its contractors 20 -- Morgan Corporation employees 25 -- Morgan Corporation board of directors
10--任何人15--摩根公司及其承包商20--摩根公司员工25--摩根公司董事会
An example of a security policy that uses part of the X.411 hierarchy might be:
使用部分X.411层次结构的安全策略的示例可能是：
0 -- unmarked 1 -- unclassified, can be read by everyone
0--未标记1--未分类，每个人都可以阅读
2 -- restricted to Timberwolf Productions staff 6 -- can only be read to Timberwolf Productions executives
2--仅限Timberwolf Productions员工6--只能阅读给Timberwolf Productions高管
If present, the eSSSecurityLabel privacy-mark is not used for access control. The content of the eSSSecurityLabel privacy-mark may be defined by the security policy in force (identified by the eSSSecurityLabel security-policy-identifier) which may define a list of values to be used. Alternately, the value may be determined by the originator of the security-label.
如果存在，eSSSecurityLabel隐私标记不用于访问控制。eSSSecurityLabel隐私标记的内容可由有效的安全策略（由eSSSecurityLabel安全策略标识符标识）定义，该安全策略可定义要使用的值列表。或者，该值可由安全标签的发起人确定。
If present, the eSSSecurityLabel security-categories provide further granularity for the sensitivity of the message. The security policy in force (identified by the eSSSecurityLabel security-policy-identifier) is used to indicate the syntaxes that are allowed to be present in the eSSSecurityLabel security-categories. Alternately, the security-categories and their values may be defined by bilateral agreement.
如果存在，eSSSecurityLabel安全类别为消息的敏感性提供了进一步的粒度。有效的安全策略（由eSSSecurityLabel安全策略标识符标识）用于指示允许存在于eSSSecurityLabel安全类别中的语法。或者，可通过双边协议确定安全类别及其价值。
Because organizations are allowed to define their own security policies, many different security policies will exist. Some organizations may wish to create equivalencies between their security policies with the security policies of other organizations. For example, the Acme Company and the Widget Corporation may reach a bilateral agreement that the "Acme private" security-classification value is equivalent to the "Widget sensitive" security-classification value.
由于允许组织定义自己的安全策略，因此将存在许多不同的安全策略。一些组织可能希望在其安全策略与其他组织的安全策略之间建立等效性。例如，Acme公司和Widget公司可能达成双边协议，即“Acme私有”安全分类值等同于“Widget敏感”安全分类值。
Receiving agents MUST NOT process an equivalentLabels attribute in a message if the agent does not trust the signer of that attribute to translate the original eSSSecurityLabel values to the security policy included in the equivalentLabels attribute. Receiving agents have the option to process equivalentLabels attributes but do not have to. It is acceptable for a receiving agent to only process eSSSecurityLabels. All receiving agents SHOULD recognize equivalentLabels attributes even if they do not process them.
如果接收代理不信任消息中的EquivalentLabel属性的签名者将原始eSSSecurityLabel值转换为EquivalentLabel属性中包含的安全策略，则接收代理不得处理该属性。接收代理可以选择处理等效标签属性，但不必这样做。接收代理只处理eSSSecurityLabels是可以接受的。所有接收代理都应该识别等价标签属性，即使它们不处理这些属性。
The EquivalentLabels signed attribute is defined as:
EquivalentLabels signed属性定义为：
EquivalentLabels ::= SEQUENCE OF ESSSecurityLabel
EquivalentLabels ::= SEQUENCE OF ESSSecurityLabel
id-aa-equivalentLabels OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 9}
id-aa-equivalentLabels OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 9}
As stated earlier, the ESSSecurityLabel contains the sensitivity values selected by the original signer of the signedData. If an ESSSecurityLabel is present in a signerInfo, all signerInfos in the signedData MUST contain an ESSSecurityLabel and they MUST all be identical. In addition to an ESSSecurityLabel, a signerInfo MAY also include an equivalentLabels signed attribute. If present, the equivalentLabels attribute MUST include one or more security labels that are believed by the signer to be semantically equivalent to the ESSSecurityLabel attribute included in the same signerInfo.
如前所述，ESSSecurityLabel包含由签名数据的原始签名者选择的灵敏度值。如果signerInfo中存在ESSSecurityLabel，则signedData中的所有signerInfos都必须包含ESSSecurityLabel，并且它们必须完全相同。除了ESSSecurityLabel外，signerInfo还可以包括equivalentLabels signed属性。如果存在，EquivalentLabel属性必须包含一个或多个安全标签，签名者认为这些安全标签在语义上等同于同一signerInfo中包含的ESSSecurityLabel属性。
All security-policy object identifiers MUST be unique in the set of ESSSecurityLabel and EquivalentLabels security labels. Before using an EquivalentLabels attribute, a receiving agent MUST ensure that all security-policy OIDs are unique in the security label or labels included in the EquivalentLabels. Once the receiving agent selects the security label (within the EquivalentLabels) to be used for processing, then the security-policy OID of the selected EquivalentLabels security label MUST be compared with the ESSSecurityLabel security-policy OID to ensure that they are unique.
所有安全策略对象标识符在ESSSecurityLabel和EquivalentLabel安全标签集中必须是唯一的。在使用EquivalentLabels属性之前，接收代理必须确保所有安全策略OID在EquivalentLabel中包含的一个或多个安全标签中是唯一的。一旦接收代理选择要用于处理的安全标签（在等效标签内），则必须将所选等效标签安全标签的安全策略OID与ESSSecurityLabel安全策略OID进行比较，以确保它们是唯一的。
In the case that an ESSSecurityLabel attribute is not included in a signerInfo, then an EquivalentLabels attribute may still be included. For example, in the Acme security policy, the absence of an ESSSecurityLabel could be defined to equate to a security label composed of the Acme security-policy OID and the "unmarked" security-classification.
如果signerInfo中未包含ESSSecurityLabel属性，则仍可能包含EquivalentLabel属性。例如，在Acme安全策略中，ESSSecurityLabel的缺失可以定义为等同于由Acme安全策略OID和“未标记”安全分类组成的安全标签。
Note that equivalentLabels MUST NOT be used to convey security labels that are semantically different from the ESSSecurityLabel included in the signerInfos in the signedData. If an entity needs to apply a security label that is semantically different from the ESSSecurityLabel, then it MUST include the sematically different security label in an outer signedData object that encapsulates the signedData object that includes the ESSSecurityLabel.
请注意，不得使用等效标签传达与signedData中signerInfos中包含的ESSSecurityLabel语义不同的安全标签。如果实体需要应用语义不同于ESSSecurityLabel的安全标签，则必须在封装包含ESSSecurityLabel的signedData对象的外部signedData对象中包含语义不同的安全标签。
If present, the equivalentLabels attribute MUST be a signed attribute; it MUST NOT be an unsigned attribute. [CMS] defines signedAttributes as a SET OF Attribute. A signerInfo MUST NOT include multiple instances of the equivalentLabels attribute. CMS defines the ASN.1 syntax for the signed attributes to include attrValues SET OF
如果存在，equivalentLabels属性必须是有符号属性；它不能是未签名的属性。[CMS]将SignedAttribute定义为一组属性。signerInfo不能包含equivalentLabels属性的多个实例。CMS为已签名属性定义ASN.1语法，以包括属性集的属性值
AttributeValue. A equivalentLabels attribute MUST only include a single instance of AttributeValue. There MUST NOT be zero or multiple instances of AttributeValue present in the attrValues SET OF AttributeValue.
属性值。equivalentLabels属性只能包含AttributeValue的单个实例。AttributeValue的attrValues集合中不能存在AttributeValue的零个或多个实例。
A receiving agent SHOULD process the ESSSecurityLabel before processing any EquivalentLabels. If the policy in the ESSSecurityLabel is understood by the receiving agent, it MUST process that label and MUST ignore all EquivalentLabels.
接收代理应在处理任何等效标签之前处理ESSSecurityLabel。如果接收代理了解ESSSecurityLabel中的策略，则它必须处理该标签，并且必须忽略所有等效标签。
When processing an EquivalentLabels attribute, the receiving agent MUST validate the signature on the EquivalentLabels attribute. A receiving agent MUST NOT act on an equivalentLabels attribute for which the signature could not be validated, and MUST NOT act on an equivalentLabels attribute unless that attribute is signed by an entity trusted to translate the original eSSSecurityLabel values to the security policy included in the equivalentLabels attribute. Determining who is allowed to specify equivalence mappings is a local policy. If a message has more than one EquivalentLabels attribute, the receiving agent SHOULD process the first one that it reads and validates that contains the security policy of interest to the receiving agent.
处理EquivalentLabels属性时，接收代理必须验证EquivalentLabels属性上的签名。接收代理不得对签名无法验证的equivalentLabels属性执行操作，也不得对equivalentLabels属性执行操作，除非该属性由受信任的实体签署，以将原始eSSSecurityLabel值转换为equivalentLabels属性中包含的安全策略。确定允许谁指定等价映射是本地策略。如果消息具有多个EquivalentLabels属性，则接收代理应处理它读取并验证的第一个属性，该属性包含接收代理感兴趣的安全策略。
Sending agents must create recipient-specific data structures for each recipient of an encrypted message. This process can impair performance for messages sent to a large number of recipients. Thus, Mail List Agents (MLAs) that can take a single message and perform the recipient-specific encryption for every recipient are often desired.
发送代理必须为加密邮件的每个收件人创建特定于收件人的数据结构。此过程可能会影响发送给大量收件人的邮件的性能。因此，通常需要能够接收单个邮件并对每个收件人执行特定于收件人的加密的邮件列表代理（MLA）。
An MLA appears to the message originator as a normal message recipient, but the MLA acts as a message expansion point for a Mail List (ML). The sender of a message directs the message to the MLA, which then redistributes the message to the members of the ML. This process offloads the per-recipient processing from individual user agents and allows for more efficient management of large MLs. MLs are true message recipients served by MLAs that provide cryptographic and expansion services for the mailing list.
MLA在邮件发起者看来是一个普通的邮件收件人，但MLA充当邮件列表（ML）的邮件扩展点。消息的发送者将消息定向到MLA，然后MLA将消息重新分发给ML的成员。此过程从单个用户代理卸载每个收件人的处理，并允许更有效地管理大型MLs。MLs是由MLA服务的真正的邮件收件人，为邮件列表提供加密和扩展服务。
In addition to cryptographic handling of messages, secure mailing lists also have to prevent mail loops. A mail loop is where one mailing list is a member of a second mailing list, and the second
除了对邮件进行加密处理外，安全邮件列表还必须防止邮件循环。邮件循环是指一个邮件列表是第二个邮件列表的成员，而第二个
mailing list is a member of the first. A message will go from one list to the other in a rapidly-cascading succession of mail that will be distributed to all other members of both lists.
邮件列表是第一组的成员。消息将以快速级联的方式从一个列表传递到另一个列表，并将其分发给两个列表的所有其他成员。
To prevent mail loops, MLAs use the mlExpansionHistory attribute of the outer signature of a triple wrapped message. The mlExpansionHistory attribute is essentially a list of every MLA that has processed the message. If an MLA sees its own unique entity identifier in the list, it knows that a loop has been formed, and does not send the message to the list again.
为了防止邮件循环，MLA使用三重包装消息的外部签名的mlExpansionHistory属性。mlExpansionHistory属性本质上是处理消息的每个MLA的列表。如果MLA在列表中看到自己的唯一实体标识符，则它知道已形成循环，并且不会再次向列表发送消息。
Mail list expansion processing is noted in the value of the mlExpansionHistory attribute, located in the signed attributes of the MLA's SignerInfo block. The MLA creates or updates the signed mlExpansionHistory attribute value each time the MLA expands and signs a message for members of a mail list.
邮件列表扩展处理在MLA的SignerinInfo块的signed属性中的mlExpansionHistory属性值中进行了说明。每次MLA为邮件列表的成员展开和签名邮件时，MLA都会创建或更新已签名的mlExpansionHistory属性值。
The MLA MUST add an MLData record containing the MLA's identification information, date and time of expansion, and optional receipt policy to the end of the mail list expansion history sequence. If the mlExpansionHistory attribute is absent, then the MLA MUST add the attribute and the current expansion becomes the first element of the sequence. If the mlExpansionHistory attribute is present, then the MLA MUST add the current expansion information to the end of the existing MLExpansionHistory sequence. Only one mlExpansionHistory attribute can be included in the signedAttributes of a SignerInfo.
MLA必须将包含MLA标识信息、扩展日期和时间以及可选接收策略的MLData记录添加到邮件列表扩展历史序列的末尾。如果缺少mlExpansionHistory属性，则MLA必须添加该属性，并且当前扩展将成为序列的第一个元素。如果存在mlExpansionHistory属性，则MLA必须将当前扩展信息添加到现有mlExpansionHistory序列的末尾。SignerInfo的SignedAttribute中只能包含一个mlExpansionHistory属性。
Note that if the mlExpansionHistory attribute is absent, then the recipient is a first tier message recipient.
请注意，如果缺少mlExpansionHistory属性，则收件人是第一层邮件收件人。
There can be multiple SignerInfos within a SignedData object, and each SignerInfo may include signedAttributes. Therefore, a single SignedData object may include multiple SignerInfos, each SignerInfo having a mlExpansionHistory attribute. For example, an MLA can send a signed message with two SignerInfos, one containing a DSS signature, the other containing an RSA signature.
一个SignedData对象中可以有多个SignerInfos，每个SignerInfos可能包括SignedAttribute。因此，单个SignedData对象可能包括多个SignerInfos，每个SignerInfos都有一个mlExpansionHistory属性。例如，MLA可以发送带有两个SignerInfos的签名消息，一个包含DSS签名，另一个包含RSA签名。
If an MLA creates a SignerInfo that includes an mlExpansionHistory attribute, then all of the SignerInfos created by the MLA for that SignedData object MUST include an mlExpansionHistory attribute, and the value of each MUST be identical. Note that other agents might later add SignerInfo attributes to the SignedData block, and those additional SignerInfos might not include mlExpansionHistory attributes.
如果MLA创建的SignerInfos包含mlExpansionHistory属性，则MLA为该SignedData对象创建的所有SignerInfos都必须包含mlExpansionHistory属性，并且每个属性的值必须相同。请注意，其他代理稍后可能会将SignerInfo属性添加到SignedData块，这些附加的SignerInfos可能不包括mlExpansionHistory属性。
A recipient MUST verify the signature of the SignerInfo which covers the mlExpansionHistory attribute before processing the mlExpansionHistory, and MUST NOT process the mlExpansionHistory attribute unless the signature over it has been verified. If a SignedData object has more than one SignerInfo that has an mlExpansionHistory attribute, the recipient MUST compare the mlExpansionHistory attributes in all the SignerInfos that it has verified, and MUST NOT process the mlExpansionHistory attribute unless every verified mlExpansionHistory attribute in the SignedData block is identical. If the mlExpansionHistory attributes in the verified signerInfos are not all identical, then the receiving agent MUST stop processing the message and SHOULD notify the user or MLA administrator of this error condition. In the mlExpansionHistory processing, SignerInfos that do not have an mlExpansionHistory attribute are ignored.
在处理mlExpansionHistory之前，收件人必须验证SignerInfo的签名，该签名包含mlExpansionHistory属性，并且不得处理mlExpansionHistory属性，除非已验证其上的签名。如果SignedData对象具有多个具有mlExpansionHistory属性的SignerInfo，则收件人必须比较其已验证的所有SignerInfos中的mlExpansionHistory属性，并且不得处理mlExpansionHistory属性，除非SignedData块中每个已验证的mlExpansionHistory属性相同。如果verified signerInfos中的mlExpansionHistory属性不完全相同，则接收代理必须停止处理消息，并应将此错误情况通知用户或MLA管理员。在mlExpansionHistory处理中，忽略没有mlExpansionHistory属性的SignerInfos。
Prior to expanding a message, the MLA examines the value of any existing mail list expansion history attribute to detect an expansion loop. An expansion loop exists when a message expanded by a specific MLA for a specific mail list is redelivered to the same MLA for the same mail list.
在扩展消息之前，MLA检查任何现有邮件列表扩展历史属性的值，以检测扩展循环。当由特定邮件列表的特定MLA扩展的邮件重新传递到相同邮件列表的相同MLA时，存在扩展循环。
Expansion loops are detected by examining the mailListIdentifier field of each MLData entry found in the mail list expansion history. If an MLA finds its own identification information, then the MLA must discontinue expansion processing and should provide warning of an expansion loop to a human mail list administrator. The mail list administrator is responsible for correcting the loop condition.
通过检查邮件列表扩展历史记录中找到的每个MLData条目的mailListIdentifier字段来检测扩展循环。如果MLA找到自己的标识信息，则MLA必须停止扩展处理，并应向人工邮件列表管理员提供扩展循环警告。邮件列表管理员负责更正循环条件。
The first few paragraphs of this section provide a high-level description of MLA processing. The rest of the section provides a detailed description of MLA processing.
本节的前几段提供了MLA处理的高级描述。本节其余部分提供了MLA处理的详细说明。
MLA message processing depends on the structure of the S/MIME layers in the message sent to the MLA for expansion. In addition to sending triple wrapped messages to an MLA, an entity can send other types of messages to an MLA, such as:
MLA消息处理取决于发送给MLA进行扩展的消息中S/MIME层的结构。除了向MLA发送三重包装的消息外，实体还可以向MLA发送其他类型的消息，例如：
- a single wrapped signedData or envelopedData message - a double wrapped message (such as signed and enveloped, enveloped and signed, or signed and signed, and so on) - a quadruple-wrapped message (such as if a well-formed triple wrapped message was sent through a gateway that added an outer SignedData layer)
- 单包装signedData或envelopedData消息-双包装消息（如签名和信封、信封和签名或签名和签名等）-四包装消息（如格式良好的三包装消息通过添加外部signedData层的网关发送）
In all cases, the MLA MUST parse all layers of the received message to determine if there are any signedData layers that include an eSSSecurityLabel signedAttribute. This may include decrypting an EnvelopedData layer to determine if an encapsulated SignedData layer includes an eSSSecurityLabel attribute. The MLA MUST fully process each eSSSecurityLabel attribute found in the various signedData layers, including performing access control checks, before distributing the message to the ML members. The details of the access control checks are beyond the scope of this document. The MLA MUST verify the signature of the signerInfo including the eSSSecurityLabel attribute before using it.
在所有情况下，MLA都必须解析接收到的消息的所有层，以确定是否存在任何包含eSSSecurityLabel signedAttribute的signedData层。这可能包括解密EnvelopedData层，以确定封装的SignedData层是否包含eSSSecurityLabel属性。在将消息分发给ML成员之前，MLA必须完全处理在各个signedData层中找到的每个eSSSecurityLabel属性，包括执行访问控制检查。访问控制检查的详细信息超出了本文档的范围。MLA必须在使用signerInfo之前验证signerInfo的签名，包括eSSSecurityLabel属性。
In all cases, the MLA MUST sign the message to be sent to the ML members in a new "outer" signedData layer. The MLA MUST add or update an mlExpansionHistory attribute in the "outer" signedData that it creates to document MLA processing. If there was an "outer" signedData layer included in the original message received by the MLA, then the MLA-created "outer" signedData layer MUST include each signed attribute present in the original "outer" signedData layer, unless the MLA explicitly replaces an attribute (such as signingTime or mlExpansionHistory) with a new value.
在所有情况下，MLA必须在新的“外部”signedData层中对要发送给ML成员的消息进行签名。MLA必须在其创建的“外部”签名数据中添加或更新mlExpansionHistory属性，以记录MLA处理。如果MLA接收的原始消息中包含“外部”signedData层，则MLA创建的“外部”signedData层必须包含原始“外部”signedData层中存在的每个签名属性，除非MLA使用新值显式替换属性（如signingTime或mlExpansionHistory）。
When an S/MIME message is received by the MLA, the MLA MUST first determine which received signedData layer, if any, is the "outer" signedData layer. To identify the received "outer" signedData layer, the MLA MUST verify the signature and fully process the signedAttributes in each of the outer signedData layers (working from the outside in) to determine if any of them either include an mlExpansionHistory attribute or encapsulate an envelopedData object.
当MLA接收到S/MIME消息时，MLA必须首先确定哪个接收到的signedData层（如果有）是“外部”signedData层。要识别接收到的“外部”signedData层，MLA必须验证签名并完全处理每个外部signedData层中的SignedAttribute（从外向内工作），以确定其中是否有任何一个包含mlExpansionHistory属性或封装envelopedData对象。
The MLA's search for the "outer" signedData layer is completed when it finds one of the following:
MLA对“外部”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).
- “外部”signedData层，包括mlExpansionHistory属性或封装envelopedData对象（envelopedData层）原始内容（即既不是envelopedData也不是signedData的层）。
If the MLA finds an "outer" signedData layer, then the MLA MUST perform the following steps:
如果MLA发现“外部”signedData层，则MLA必须执行以下步骤：
1. Strip off all of the signedData layers that encapsulated the "outer" signedData layer
1. 剥离封装“外部”signedData层的所有signedData层
2. Strip off the "outer" signedData layer itself (after remembering the included signedAttributes)
2. 去掉“外部”signedData层本身（记住包含的SignedAttribute后）
3. Expand the envelopedData (if present)
3. 展开信封数据（如果存在）
4. Sign the message to be sent to the ML members in a new "outer" signedData layer that includes the signedAttributes (unless explicitly replaced) from the original, received "outer" signedData layer.
4. 在新的“外部”signedData层中对要发送给ML成员的消息进行签名，该层包括来自原始接收的“外部”signedData层的SignedAttribute（除非明确替换）。
If the MLA finds an "outer" signedData layer that includes an mlExpansionHistory attribute AND the MLA subsequently finds an envelopedData layer buried deeper with the layers of the received message, then the MLA MUST strip off all of the signedData layers down to the envelopedData layer (including stripping off the original "outer" signedData layer) and MUST sign the expanded envelopedData in a new "outer" signedData layer that includes the signedAttributes (unless explicitly replaced) from the original, received "outer" signedData layer.
如果MLA发现一个包含mlExpansionHistory属性的“外部”signedData层，并且MLA随后发现一个与接收到的消息层埋得更深的信封数据层，则MLA必须将所有signedData层剥离到信封数据层（包括剥离原始的“外部”数据）signedData层），并且必须在新的“外部”signedData层中对扩展的信封数据进行签名，该层包括来自原始接收的“外部”signedData层的SignedAttribute（除非明确替换）。
If the MLA does not find an "outer" signedData layer AND does not find an envelopedData layer, then the MLA MUST sign the original, received message in a new "outer" signedData layer. If the MLA does not find an "outer" signedData AND does find an envelopedData layer then it MUST expand the envelopedData layer, if present, and sign it in a new "outer" signedData layer.
如果MLA未找到“外部”签名数据层，也未找到信封数据层，则MLA必须在新的“外部”签名数据层中对原始接收到的消息进行签名。如果MLA没有找到“外部”签名数据，但找到了信封数据层，则必须展开信封数据层（如果存在），并在新的“外部”签名数据层中对其签名。
The following examples help explain the rules above:
以下示例有助于解释上述规则：
1) A message (S1(Original Content)) (where S = SignedData) is sent to the MLA in which the signedData layer does not include an MLExpansionHistory attribute. The MLA verifies and fully processes the signedAttributes in S1. The MLA decides that there is not an original, received "outer" signedData layer since it finds the original content, but never finds an envelopedData and never finds an mlExpansionHistory attribute. The MLA calculates a new signedData layer, S2, resulting in the following message sent to the ML recipients: (S2(S1(Original Content))). The MLA includes an mlExpansionHistory attribute in S2.
1) 将消息（S1（原始内容））（其中S=SignedData）发送到其中SignedData层不包括MLExpansionHistory属性的MLA。MLA验证并完全处理S1中的已签名属性。MLA确定不存在原始接收的“外部”signedData层，因为它找到了原始内容，但从未找到信封数据，也从未找到mlExpansionHistory属性。MLA计算一个新的signedData层S2，从而将以下消息发送给ML收件人：（S2（S1（原始内容）））。MLA在S2中包含mlExpansionHistory属性。
2) A message (S3(S2(S1(Original Content)))) is sent to the MLA in which none of the signedData layers includes an MLExpansionHistory attribute. The MLA verifies and fully processes the signedAttributes in S3, S2 and S1. The MLA decides that there is not an original, received "outer" signedData layer since it finds the original content, but never finds an envelopedData and never finds an mlExpansionHistory attribute. The MLA calculates a new signedData layer, S4, resulting in the following
2) 将消息（S3（S2（S1（原始内容）））发送到MLA，其中没有任何signedData层包含MLExpansionHistory属性。MLA验证并完全处理S3、S2和S1中的已签名属性。MLA确定不存在原始接收的“外部”signedData层，因为它找到了原始内容，但从未找到信封数据，也从未找到mlExpansionHistory属性。MLA计算新的signedData层S4，结果如下
message sent to the ML recipients: (S4(S3(S2(S1(Original Content))))). The MLA includes an mlExpansionHistory attribute in S4.
发送给ML收件人的消息：（S4（S3（S2（S1（原始内容'））））。MLA在S4中包含mlExpansionHistory属性。
3) A message (E1(S1(Original Content))) (where E = envelopedData) is sent to the MLA in which S1 does not include an MLExpansionHistory attribute. The MLA decides that there is not an original, received "outer" signedData layer since it finds the E1 as the outer layer. The MLA expands the recipientInformation in E1. The MLA calculates a new signedData layer, S2, resulting in the following message sent to the ML recipients: (S2(E1(S1(Original Content)))). The MLA includes an mlExpansionHistory attribute in S2.
3) 向MLA发送消息（E1（S1（原始内容））（其中E=信封数据），其中S1不包括MLExpansionHistory属性。MLA确定不存在原始接收的“外部”签名数据层，因为它发现E1是外层。MLA扩展E1中的接收方信息。MLA计算一个新的signedData层S2，从而将以下消息发送给ML收件人：（S2（E1（S1（原始内容）））。MLA在S2中包含mlExpansionHistory属性。
4) A message (S2(E1(S1(Original Content)))) is sent to the MLA in which S2 includes an MLExpansionHistory attribute. The MLA verifies the signature and fully processes the signedAttributes in S2. The MLA finds the mlExpansionHistory attribute in S2, so it decides that S2 is the "outer" signedData. The MLA remembers the signedAttributes included in S2 for later inclusion in the new outer signedData that it applies to the message. The MLA strips off S2. The MLA then expands the recipientInformation in E1 (this invalidates the signature in S2 which is why it was stripped). The nMLA calculates a new signedData layer, S3, resulting in the following message sent to the ML recipients: (S3(E1(S1(Original Content)))). The MLA includes in S3 the attributes from S2 (unless it specifically replaces an attribute value) including an updated mlExpansionHistory attribute.
4) A message (S2(E1(S1(Original Content)))) is sent to the MLA in which S2 includes an MLExpansionHistory attribute. The MLA verifies the signature and fully processes the signedAttributes in S2. The MLA finds the mlExpansionHistory attribute in S2, so it decides that S2 is the "outer" signedData. The MLA remembers the signedAttributes included in S2 for later inclusion in the new outer signedData that it applies to the message. The MLA strips off S2. The MLA then expands the recipientInformation in E1 (this invalidates the signature in S2 which is why it was stripped). The nMLA calculates a new signedData layer, S3, resulting in the following message sent to the ML recipients: (S3(E1(S1(Original Content)))). The MLA includes in S3 the attributes from S2 (unless it specifically replaces an attribute value) including an updated mlExpansionHistory attribute.translate error, please retry
5) A message (S3(S2(E1(S1(Original Content))))) is sent to the MLA in which none of the signedData layers include an MLExpansionHistory attribute. The MLA verifies the signature and fully processes the signedAttributes in S3 and S2. When the MLA encounters E1, then it decides that S2 is the "outer" signedData since S2 encapsulates E1. The MLA remembers the signedAttributes included in S2 for later inclusion in the new outer signedData that it applies to the message. The MLA strips off S3 and S2. The MLA then expands the recipientInformation in E1 (this invalidates the signatures in S3 and S2 which is why they were stripped). The MLA calculates a new signedData layer, S4, resulting in the following message sent to the ML recipients: (S4(E1(S1(Original Content)))). The MLA includes in S4 the attributes from S2 (unless it specifically replaces an attribute value) and includes a new mlExpansionHistory attribute.
5) 将消息（S3（S2（E1（S1（原始内容‘‘）’））））发送到没有任何签名数据层包含MLExpansionHistory属性的MLA。MLA验证签名并在S3和S2中完全处理签名属性。当MLA遇到E1时，它决定S2是“外部”签名数据，因为S2封装E1。MLA会记住S2中包含的SignedAttribute，以便稍后包含在应用于消息的新外部signedData中。MLA剥离S3和S2。然后，MLA扩展E1中的recipientInformation（这会使S3和S2中的签名无效，这就是它们被剥离的原因）。MLA计算新的signedData层S4，从而将以下消息发送给ML接收者：（S4（E1（S1（原始内容）））。MLA在S4中包含S2中的属性（除非它专门替换属性值），并包含新的mlExpansionHistory属性。
6) A message (S3(S2(E1(S1(Original Content))))) is sent to the MLA in which S3 includes an MLExpansionHistory attribute. In this case, the MLA verifies the signature and fully processes the
6) 将消息（S3（S2（E1（S1（原始内容‘‘‘）’）））发送到MLA，其中S3包括MLExpansionHistory属性。在这种情况下，MLA验证签名并完全处理签名
signedAttributes in S3. The MLA finds the mlExpansionHistory in S3, so it decides that S3 is the "outer" signedData. The MLA remembers the signedAttributes included in S3 for later inclusion in the new outer signedData that it applies to the message. The MLA keeps on parsing encapsulated layers because it must determine if there are any eSSSecurityLabel attributes contained within. The MLA verifies the signature and fully processes the signedAttributes in S2. When the MLA encounters E1, then it strips off S3 and S2. The MLA then expands the recipientInformation in E1 (this invalidates the signatures in S3 and S2 which is why they were stripped). The MLA calculates a new signedData layer, S4, resulting in the following message sent to the ML recipients: (S4(E1(S1(Original Content)))). The MLA includes in S4 the attributes from S3 (unless it specifically replaces an attribute value) including an updated mlExpansionHistory attribute.
S3中的签名属性。MLA在S3中查找mlExpansionHistory，因此它决定S3是“外部”签名数据。MLA会记住S3中包含的SignedAttribute，以便稍后包含在应用于消息的新外部signedData中。MLA继续解析封装层，因为它必须确定其中是否包含任何eSSSecurityLabel属性。MLA验证签名并在S2中完全处理签名属性。当MLA遇到E1时，它会剥离S3和S2。然后，MLA扩展E1中的recipientInformation（这会使S3和S2中的签名无效，这就是它们被剥离的原因）。MLA计算新的signedData层S4，从而将以下消息发送给ML接收者：（S4（E1（S1（原始内容）））。MLA在S4中包含来自S3的属性（除非它专门替换属性值），包括更新的mlExpansionHistory属性。
The processing used depends on the type of the outermost layer of the message. There are three cases for the type of the outermost data:
所使用的处理取决于消息最外层的类型。最外层数据的类型有三种情况：
- EnvelopedData - SignedData - data
- 信封数据-签名数据-数据
1. The MLA locates its own RecipientInfo and uses the information it contains to obtain the message key.
1. MLA定位其自己的RecipientInfo并使用其包含的信息获取消息密钥。
2. The MLA removes the existing recipientInfos field and replaces it with a new recipientInfos value built from RecipientInfo structures created for each member of the mailing list. The MLA also removes the existing originatorInfo field and replaces it with a new originatorInfo value built from information describing the MLA.
2. MLA删除现有的recipientInfos字段，并将其替换为一个新的recipientInfos值，该值是根据为邮件列表的每个成员创建的RecipientInfo结构生成的。MLA还删除现有的originatorInfo字段，并将其替换为根据描述MLA的信息构建的新originatorInfo值。
3. The MLA encapsulates the expanded encrypted message in a SignedData block, adding an mlExpansionHistory attribute as described in the "Mail List Expansion" section to document the expansion.
3. MLA将扩展的加密消息封装在SignedData块中，如“邮件列表扩展”部分所述，添加mlExpansionHistory属性以记录扩展。
4. The MLA signs the new message and delivers the updated message to mail list members to complete MLA processing.
4. MLA对新邮件进行签名，并将更新后的邮件发送给邮件列表成员以完成MLA处理。
MLA processing of multi-layer messages depends on the type of data in each of the layers. Step 3 below specifies that different processing will take place depending on the type of CMS message that has been signed. That is, it needs to know the type of data at the next inner layer, which may or may not be the innermost layer.
多层消息的MLA处理取决于每个层中的数据类型。下面的步骤3指定根据已签名的CMS消息的类型进行不同的处理。也就是说，它需要知道下一个内层的数据类型，可能是最内层，也可能不是最内层。
1. The MLA verifies the signature value found in the outermost SignedData layer associated with the signed data. MLA processing of the message terminates if the message signature is invalid.
1. MLA验证在与签名数据关联的最外层SignedData层中找到的签名值。如果消息签名无效，则消息的MLA处理终止。
2. If the outermost SignedData layer includes a signed mlExpansionHistory attribute, the MLA checks for an expansion loop as described in the "Detecting Mail List Expansion Loops" section, then go to step 3. If the outermost SignedData layer does not include a signed mlExpansionHistory attribute, the MLA signs the whole message (including this outermost SignedData layer that doesn't have an mlExpansionHistory attribute), and delivers the updated message to mail list members to complete MLA processing.
2. 如果最外层的SignedData层包含signed mlExpansionHistory属性，MLA将按照“检测邮件列表扩展循环”部分中的说明检查扩展循环，然后转至步骤3。如果最外层的SignedData层不包含signed mlExpansionHistory属性，MLA将对整个邮件（包括不具有mlExpansionHistory属性的最外层SignedData层）进行签名，并将更新后的邮件传递给邮件列表成员以完成MLA处理。
3. Determine the type of the data that has been signed. That is, look at the type of data on the layer just below the SignedData, which may or may not be the "innermost" layer. Based on the type of data, perform either step 3.1 (EnvelopedData), step 3.2 (SignedData), or step 3.3 (all other types).
3. 确定已签名数据的类型。也就是说，查看SignedData下面的层上的数据类型，它可能是也可能不是“最内层”层。根据数据类型，执行步骤3.1（信封数据）、步骤3.2（签名数据）或步骤3.3（所有其他类型）。
3.1. If the signed data is EnvelopedData, the MLA performs expansion processing of the encrypted message as described previously. Note that this process invalidates the signature value in the outermost SignedData layer associated with the original encrypted message. Proceed to section 3.2 with the result of the expansion.
3.1. 如果签名数据是信封数据，则MLA如前所述执行加密消息的扩展处理。请注意，此过程将使与原始加密消息关联的最外层SignedData层中的签名值无效。继续第3.2节，了解扩展结果。
3.2. If the signed data is SignedData, or is the result of expanding an EnvelopedData block in step 3.1:
3.2. 如果签名数据是SignedData，或是步骤3.1中展开EnvelopedData块的结果：
3.2.1. The MLA strips the existing outermost SignedData layer after remembering the value of the mlExpansionHistory and all other signed attributes in that layer, if present.
3.2.1. MLA在记住mlExpansionHistory的值和该层中所有其他已签名属性（如果存在）后，将剥离现有最外层的SignedData层。
3.2.2. If the signed data is EnvelopedData (from step 3.1), the MLA encapsulates the expanded encrypted message in a new outermost SignedData layer. On the other
3.2.2. 如果签名数据是信封数据（步骤3.1），MLA将扩展的加密消息封装在新的最外层签名数据层中。另一方面
hand, if the signed data is SignedData (from step 3.2), the MLA encapsulates the signed data in a new outermost SignedData layer.
另一方面，如果签名数据是SignedData（从步骤3.2开始），MLA会将签名数据封装在新的最外层SignedData层中。
3.2.3. The outermost signedData layer created by the MLA replaces the original outermost signedData layer. The MLA MUST create an signed attribute list for the new outermost signedData layer which MUST include each signed attribute present in the original outermost signedData layer, unless the MLA explicitly replaces one or more particular attributes with new value. A special case is the mlExpansionHistory attribute. The MLA MUST add an mlExpansionHistory signed attribute to the outer signedData layer as follows:
3.2.3. MLA创建的最外层signedData层将替换原始的最外层signedData层。MLA必须为新的最外层signedData层创建一个签名属性列表，该列表必须包括原始最外层signedData层中存在的每个签名属性，除非MLA显式地用新值替换一个或多个特定属性。一种特殊情况是mlExpansionHistory属性。MLA必须将mlExpansionHistory签名属性添加到外部signedData层，如下所示：
3.2.3.1. If the original outermost SignedData layer included an mlExpansionHistory attribute, the attribute's value is copied and updated with the current ML expansion information as described in the "Mail List Expansion" section.
3.2.3.1. 如果原始最外层的SignedData层包含mlExpansionHistory属性，则该属性的值将被复制，并使用“邮件列表扩展”部分中描述的当前ML扩展信息进行更新。
3.2.3.2. If the original outermost SignedData layer did not include an mlExpansionHistory attribute, a new attribute value is created with the current ML expansion information as described in the "Mail List Expansion" section.
3.2.3.2. 如果原始最外层的SignedData层不包含mlExpansionHistory属性，则将使用“邮件列表扩展”部分中所述的当前ML扩展信息创建一个新属性值。
3.3. If the signed data is not EnvelopedData or SignedData:
3.3. 如果签名数据不是信封数据或签名数据：
3.3.1. The MLA encapsulates the received signedData object in an outer SignedData object, and adds an mlExpansionHistory attribute to the outer SignedData object containing the current ML expansion information as described in the "Mail List Expansion" section.
3.3.1. MLA将接收到的signedData对象封装在外部signedData对象中，并向包含当前ML扩展信息的外部signedData对象添加mlExpansionHistory属性，如“邮件列表扩展”部分所述。
4. The MLA signs the new message and delivers the updated message to mail list members to complete MLA processing.
4. MLA对新邮件进行签名，并将更新后的邮件发送给邮件列表成员以完成MLA处理。
A flow chart for the above steps would be:
上述步骤的流程图如下：
1. Has a valid signature? YES -> 2. NO -> STOP. 2. Does outermost SignedData layer contain mlExpansionHistory? YES -> Check it, then -> 3. NO -> Sign message (including outermost SignedData that doesn't have mlExpansionHistory), deliver it, STOP. 3. Check type of data just below outermost SignedData.
1. 你有有效的签名吗？是->2。否->停止。2.最外层的SignedData层是否包含mlExpansionHistory？是->检查，然后->3。否->对消息（包括没有mlExpansionHistory的最外层已签名数据）进行签名、传递、停止。3.检查最外层签名数据下方的数据类型。
EnvelopedData -> 3.1. SignedData -> 3.2. all others -> 3.3. 3.1. Expand the encrypted message, then -> 3.2. 3.2. -> 3.2.1. 3.2.1. Strip outermost SignedData layer, note value of mlExpansionHistory and other signed attributes, then -> 3.2.2. 3.2.2. Encapsulate in new signature, then -> 3.2.3. 3.2.3. Create new signedData layer. Was there an old mlExpansionHistory? YES -> copy the old mlExpansionHistory values, then -> 4. NO -> create new mlExpansionHistory value, then -> 4. 3.3. Encapsulate in a SignedData layer and add an mlExpansionHistory attribute, then -> 4. 4. Sign message, deliver it, STOP.
信封数据->3.1。签名数据->3.2。所有其他->3.3。3.1. 展开加密消息，然后->3.2。3.2. -> 3.2.1. 3.2.1. 剥离最外层的SignedData层，注意mlExpansionHistory和其他已签名属性的值，然后->3.2.2。3.2.2. 封装在新签名中，然后->3.2.3。3.2.3. 创建新的signedData层。是否有一个古老的MLExpansion历史？是->复制旧的mlExpansionHistory值，然后->4。否->创建新的mlExpansionHistory值，然后->4。3.3. 封装在SignedData层中并添加mlExpansionHistory属性，然后->4。4.签名、传递、停止。
1. The MLA encapsulates the message in a SignedData layer, and adds an mlExpansionHistory attribute containing the current ML expansion information as described in the "Mail List Expansion" section.
1. MLA将消息封装在SignedData层中，并添加包含当前ML扩展信息的mlExpansionHistory属性，如“邮件列表扩展”部分所述。
2. The MLA signs the new message and delivers the updated message to mail list members to complete MLA processing.
2. MLA对新邮件进行签名，并将更新后的邮件发送给邮件列表成员以完成MLA处理。
4.3 Mail List Agent Signed Receipt Policy Processing
4.3 邮件列表代理已签名的回执策略处理
If a mailing list (B) is a member of another mailing list (A), list B often needs to propagate forward the mailing list receipt policy of A. As a general rule, a mailing list should be conservative in propagating forward the mailing list receipt policy because the ultimate recipient need only process the last item in the ML expansion history. The MLA builds the expansion history to meet this requirement.
如果邮件列表（B）是另一个邮件列表（a）的成员，则列表B通常需要转发a的邮件列表接收策略。一般来说，邮件列表在转发邮件列表接收策略时应保守，因为最终收件人只需处理ML扩展历史中的最后一项。MLA构建扩展历史以满足此要求。
The following table describes the outcome of the union of mailing list A's policy (the rows in the table) and mailing list B's policy (the columns in the table).
下表描述了邮件列表A的策略（表中的行）和邮件列表B的策略（表中的列）合并的结果。
| B's policy
A's policy | none insteadOf inAdditionTo missing
-----------------------------------------------------------------------
none | none none none none
insteadOf | none insteadOf(B) *1 insteadOf(A)
inAdditionTo | none insteadOf(B) *2 inAdditionTo(A)
missing | none insteadOf(B) inAdditionTo(B) missing
| B's policy
A's policy | none insteadOf inAdditionTo missing
-----------------------------------------------------------------------
none | none none none none
insteadOf | none insteadOf(B) *1 insteadOf(A)
inAdditionTo | none insteadOf(B) *2 inAdditionTo(A)
missing | none insteadOf(B) inAdditionTo(B) missing
*1 = insteadOf(insteadOf(A) + inAdditionTo(B))
*2 = inAdditionTo(inAdditionTo(A) + inAdditionTo(B))
*1 = insteadOf(insteadOf(A) + inAdditionTo(B))
*2 = inAdditionTo(inAdditionTo(A) + inAdditionTo(B))
An mlExpansionHistory attribute value has ASN.1 type MLExpansionHistory. If there are more than ub-ml-expansion-history mailing lists in the sequence, the receiving agent should provide notification of the error to a human mail list administrator. The mail list administrator is responsible for correcting the overflow condition.
mlExpansionHistory属性值具有ASN.1类型的mlExpansionHistory。如果序列中有多个ub ml扩展历史邮件列表，则接收代理应向人工邮件列表管理员提供错误通知。邮件列表管理员负责纠正溢出情况。
MLExpansionHistory ::= SEQUENCE
SIZE (1..ub-ml-expansion-history) OF MLData
MLExpansionHistory ::= SEQUENCE
SIZE (1..ub-ml-expansion-history) OF MLData
id-aa-mlExpandHistory OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 3}
id-aa-mlExpandHistory OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 3}
ub-ml-expansion-history INTEGER ::= 64
ub-ml-expansion-history INTEGER ::= 64
MLData contains the expansion history describing each MLA that has processed a message. As an MLA distributes a message to members of an ML, the MLA records its unique identifier, date and time of expansion, and receipt policy in an MLData structure.
MLData包含描述已处理消息的每个MLA的扩展历史记录。当MLA向ML成员分发消息时，MLA会在MLData结构中记录其唯一标识符、扩展日期和时间以及接收策略。
MLData ::= SEQUENCE {
mailListIdentifier EntityIdentifier,
expansionTime GeneralizedTime,
mlReceiptPolicy MLReceiptPolicy OPTIONAL }
MLData ::= SEQUENCE {
mailListIdentifier EntityIdentifier,
expansionTime GeneralizedTime,
mlReceiptPolicy MLReceiptPolicy OPTIONAL }
EntityIdentifier ::= CHOICE {
issuerAndSerialNumber IssuerAndSerialNumber,
subjectKeyIdentifier SubjectKeyIdentifier }
EntityIdentifier ::= CHOICE {
issuerAndSerialNumber IssuerAndSerialNumber,
subjectKeyIdentifier SubjectKeyIdentifier }
The receipt policy of the ML can withdraw the originator's request for the return of a signed receipt. However, if the originator of the message has not requested a signed receipt, the MLA cannot request a signed receipt. In the event that a ML's signed receipt policy supersedes the originator's request for signed receipts, such that the originator will not receive any signed receipts, then the MLA MAY inform the originator of that fact.
ML的收据政策可以撤回发端人返回已签名收据的请求。但是，如果消息的发起者没有请求签名回执，MLA将无法请求签名回执。如果ML的签名收据政策取代了发端人的签名收据请求，因此发端人将不会收到任何签名收据，则MLA可通知发端人该事实。
When present, the mlReceiptPolicy specifies a receipt policy that supersedes the originator's request for signed receipts. The policy can be one of three possibilities: receipts MUST NOT be returned (none); receipts should be returned to an alternate list of recipients, instead of to the originator (insteadOf); or receipts should be returned to a list of recipients in addition to the originator (inAdditionTo).
当存在时，mlReceiptPolicy指定一个接收策略，该策略取代发端人的签名接收请求。该政策可以是三种可能性之一：不得退回收据（无）；收据应返回给收件人的替代列表，而不是发端人（而不是）；或收据应返回给除发起人之外的收件人列表（除此之外）。
MLReceiptPolicy ::= CHOICE {
none [0] NULL,
insteadOf [1] SEQUENCE SIZE (1..MAX) OF GeneralNames,
inAdditionTo [2] SEQUENCE SIZE (1..MAX) OF GeneralNames }
MLReceiptPolicy ::= CHOICE {
none [0] NULL,
insteadOf [1] SEQUENCE SIZE (1..MAX) OF GeneralNames,
inAdditionTo [2] SEQUENCE SIZE (1..MAX) OF GeneralNames }
Concerns have been raised over the fact that the certificate which the signer of a CMS SignedData object desired to be bound into the verification process of the SignedData object is not cryptographically bound into the signature itself. This section addresses this issue by creating a new attribute to be placed in the signed attributes section of a SignerInfo object.
CMS SignedData对象的签名者希望绑定到SignedData对象的验证过程中的证书未以加密方式绑定到签名本身，这一事实引起了人们的关注。本节通过创建一个新属性来解决此问题，该属性将放置在SignerInfo对象的signed attributes部分中。
This section also presents a description of a set of possible attacks dealing with the substitution of one certificate to verify the signature for the desired certificate. A set of ways for preventing or addressing these attacks is presented to deal with the simplest of the attacks.
本节还介绍了一组可能的攻击，这些攻击涉及替换一个证书以验证所需证书的签名。本文介绍了一套防止或解决这些攻击的方法，以应对最简单的攻击。
Authorization information can be used as part of a signature verification process. This information can be carried in either attribute certificates and other public key certificates. The signer needs to have the ability to restrict the set of certificates used in the signature verification process, and information needs to be encoded so that is covered by the signature on the SignedData object. The methods in this section allow for the set of authorization certificates to be listed as part of the signing certificate attribute.
授权信息可以用作签名验证过程的一部分。此信息可以在属性证书和其他公钥证书中携带。签名者需要能够限制签名验证过程中使用的证书集，并且需要对信息进行编码，以便签名数据对象上的签名能够覆盖这些信息。本节中的方法允许将授权证书集作为签名证书属性的一部分列出。
Explicit certificate policies can also be used as part of a signature verification process. If a signer desires to state an explicit certificate policy that should be used when validating the signature, that policy needs to be cryptographically bound into the signing process. The methods described in this section allows for a set of certificate policy statements to be listed as part of the signing certificate attribute.
显式证书策略也可以用作签名验证过程的一部分。如果签名者希望声明在验证签名时应使用的显式证书策略，则需要将该策略以加密方式绑定到签名过程中。本节中描述的方法允许将一组证书策略语句作为签名证书属性的一部分列出。
At least three different attacks can be launched against a possible signature verification process by replacing the certificate or certficates used in the signature verification process.
通过替换签名验证过程中使用的一个或多个证书，可以对可能的签名验证过程发起至少三种不同的攻击。
The first attack deals with simple substitution of one certificate for another certificate. In this attack, the issuer and serial number in the SignerInfo is modified to refer to a new certificate. This new certificate is used during the signature verification process.
第一种攻击是简单地将一个证书替换为另一个证书。在此攻击中，SignerInfo中的颁发者和序列号被修改为引用新证书。此新证书在签名验证过程中使用。
The first version of this attack is a simple denial of service attack where an invalid certificate is substituted for the valid certificate. This renders the message unverifiable, as the public key in the certificate no longer matches the private key used to sign the message.
此攻击的第一个版本是一种简单的拒绝服务攻击，其中用无效证书替换有效证书。这会使消息无法验证，因为证书中的公钥与用于签名消息的私钥不再匹配。
The second version is a substitution of one valid certificate for the original valid certificate where the public keys in the certificates match. This allows the signature to be validated under potentially different certificate constraints than the originator of the message intended.
第二个版本是用一个有效证书替换证书中公钥匹配的原始有效证书。这允许在可能不同于消息的原始发件人的证书约束下验证签名。
The second attack deals with a certificate authority (CA) re-issuing the signing certificate (or potentially one of its certificates). This attack may start becoming more frequent as Certificate Authorities reissue their own root certificates, or as certificate authorities change policies in the certificate while reissuing their root certificates. This problem also occurs when cross certificates (with potentially different restrictions) are used in the process of verifying a signature.
第二种攻击涉及证书颁发机构（CA）重新颁发签名证书（或可能是其中一个证书）。随着证书颁发机构重新颁发其自己的根证书，或者证书颁发机构在重新颁发其根证书时更改证书中的策略，此攻击可能会变得更加频繁。在验证签名的过程中使用交叉证书（具有可能不同的限制）时，也会出现此问题。
The third attack deals with a rogue entity setting up a certificate authority that attempts to duplicate the structure of an existing CA. Specifically, the rogue entity issues a new certificate with the same public keys as the signer used, but signed by the rogue entity's private key.
第三种攻击涉及恶意实体设置证书颁发机构，试图复制现有CA的结构。具体而言，恶意实体使用与签名者相同的公钥颁发新证书，但由恶意实体的私钥签名。
This document does not attempt to solve all of the above attacks; however, a brief description of responses to each of the attacks is given in this section.
本文件并不试图解决上述所有攻击；但是，本节简要介绍了对每种攻击的响应。
The denial of service attack cannot be prevented. After the certificate identifier has been modified in transit, no verification of the signature is possible. There is also no way to automatically identify the attack because it is indistinguishable from a message corruption.
无法阻止拒绝服务攻击。在传输过程中修改证书标识符后，无法验证签名。也无法自动识别攻击，因为它与消息损坏无法区分。
The substitution of a valid certificate can be responded to in two different manners. The first is to make a blanket statement that the use of the same public key in two different certificates is bad practice and has to be avoided. In practice, there is no practical way to prevent users from getting new certificates with the same public keys, and it should be assumed that they will do this. Section 5.4 provides a new attribute that can be included in the SignerInfo signed attributes. This binds the correct certificate identifier into the signature. This will convert the attack from a potentially successful one to simply a denial of service attack.
有效证书的替换可以用两种不同的方式响应。第一种是笼统地说，在两个不同的证书中使用相同的公钥是不好的做法，必须避免。实际上，没有切实可行的方法来阻止用户获得具有相同公钥的新证书，应该假设他们会这样做。第5.4节提供了可包含在SignerInfo signed attributes中的新属性。这会将正确的证书标识符绑定到签名中。这会将可能成功的攻击转化为简单的拒绝服务攻击。
A CA should never reissue a certificate with different attributes. Certificate Authorities that do so are following poor practices and cannot be relied on. Using the hash of the certificate as the reference to the certificate prevents this attack for end-entity certificates.
CA不应重新颁发具有不同属性的证书。这样做的证书颁发机构遵循的是糟糕的做法，不能依赖。使用证书的哈希作为证书的引用可防止对最终实体证书的这种攻击。
Preventing the attack based on reissuing of CA certificates would require a substantial change to the usage of the signingCertificate attribute presented in section 5.4. It would require that ESSCertIDs would need to be included in the attribute to represent the issuer certificates in the signer's certification path. This presents problems when the relying party is using a cross-certificate as part of its authentication process, and this certificate does not appear
要防止基于重新颁发CA证书的攻击，需要对第5.4节中介绍的signingCertificate属性的用法进行重大更改。它需要在属性中包含EssCertId，以表示签名者证书路径中的颁发者证书。当依赖方使用交叉证书作为其身份验证过程的一部分，并且该证书未出现时，这会出现问题
on the list of certificates. The problems outside of a closed PKI make the addition of this information prone to error, possibly causing the rejection of valid chains.
在证书列表上。封闭PKI之外的问题使得添加此信息容易出错，可能导致拒绝有效链。
The best method of preventing this attack is to avoid trusting the rogue CA. The use of the hash to identify certificates prevents the use of end-entity certificates from the rogue authority. However the only true way to prevent this attack is to never trust the rogue CA.
防止此攻击的最佳方法是避免信任流氓CA。使用哈希来标识证书可防止使用来自流氓认证机构的最终实体证书。然而，防止这种攻击的唯一真正方法是永远不要信任流氓CA。
Some applications require that additional information be used as part of the signature validation process. In particular, authorization information from attribute certificates and other public key certificates or policy identifiers provide additional information about the abilities and intent of the signer. The signing certificate attribute described in Section 5.4 provides the ability to bind this context information as part of the signature.
有些应用程序要求在签名验证过程中使用附加信息。特别地，来自属性证书和其他公钥证书或策略标识符的授权信息提供了关于签名者的能力和意图的附加信息。第5.4节中描述的签名证书属性提供了将此上下文信息绑定为签名的一部分的能力。
Some applications require that authorization information found in attribute certificates and/or other public key certificates be validated. This validation requires that the application be able to find the correct certificates to perform the verification process; however there is no list of the certificates to used in a SignerInfo object. The sender has the ability to include a set of attribute certificates and public key certificates in a SignedData object. The receiver has the ability to retrieve attribute certificates and public key certificates from a directory service. There are some circumstances where the signer may wish to limit the set of certificates that may be used in verifying a signature. It is useful to be able to list the set of certificates the signer wants the recipient to use in validating the signature.
某些应用程序要求验证属性证书和/或其他公钥证书中的授权信息。此验证要求应用程序能够找到正确的证书来执行验证过程；但是，并没有要在SignerInfo对象中使用的证书列表。发送方能够在SignedData对象中包含一组属性证书和公钥证书。接收方能够从目录服务检索属性证书和公钥证书。在某些情况下，签名人可能希望限制可用于验证签名的证书集。能够列出签名者希望接收者在验证签名时使用的证书集非常有用。
A related aspect of the certificate binding is the issue of multiple certification paths. In some instances, the semantics of a certificate in its use with a message may depend on the Certificate Authorities and policies that apply. To address this issue, the signer may also wish to bind that context under the signature. While this could be done by either signing the complete certification path or a policy ID, only a binding for the policy ID is described here.
证书绑定的一个相关方面是多个证书路径的问题。在某些情况下，证书与消息一起使用时的语义可能取决于应用的证书颁发机构和策略。为了解决这一问题，签名人还可能希望将该上下文绑定到签名下。虽然这可以通过对完整的证书路径或策略ID进行签名来完成，但这里只描述了策略ID的绑定。
The signing certificate attribute is designed to prevent the simple substitution and re-issue attacks, and to allow for a restricted set of authorization certificates to be used in verifying a signature.
签名证书属性旨在防止简单的替换和重新颁发攻击，并允许在验证签名时使用一组受限的授权证书。
The definition of SigningCertificate is
签名证书的定义是
SigningCertificate ::= SEQUENCE {
certs SEQUENCE OF ESSCertID,
policies SEQUENCE OF PolicyInformation OPTIONAL
}
SigningCertificate ::= SEQUENCE {
certs SEQUENCE OF ESSCertID,
policies SEQUENCE OF PolicyInformation OPTIONAL
}
id-aa-signingCertificate OBJECT IDENTIFIER ::= { iso(1)
member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
smime(16) id-aa(2) 12 }
id-aa-signingCertificate OBJECT IDENTIFIER ::= { iso(1)
member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
smime(16) id-aa(2) 12 }
The first certificate identified in the sequence of certificate identifiers MUST be the certificate used to verify the signature. The encoding of the ESSCertID for this certificate SHOULD include the issuerSerial field. If other constraints ensure that issuerAndSerialNumber will be present in the SignerInfo, the issuerSerial field MAY be omitted. The certificate identified is used during the signature verification process. If the hash of the certificate does not match the certificate used to verify the signature, the signature MUST be considered invalid.
证书标识符序列中标识的第一个证书必须是用于验证签名的证书。此证书的ESSCertID编码应包括issuerSerial字段。如果其他约束确保SignerinInfo中存在issuerAndSerialNumber，则可以省略issuerSerial字段。标识的证书在签名验证过程中使用。如果证书的哈希与用于验证签名的证书不匹配，则签名必须视为无效。
If more than one certificate is present in the sequence of ESSCertIDs, the certificates after the first one limit the set of authorization certificates that are used during signature validation. Authorization certificates can be either attribute certificates or normal certificates. The issuerSerial field (in the ESSCertID structure) SHOULD be present for these certificates, unless the client who is validating the signature is expected to have easy access to all the certificates requred for validation. If only the signing certificate is present in the sequence, there are no restrictions on the set of authorization certificates used in validating the signature.
如果ESSCertID序列中存在多个证书，则第一个证书之后的证书将限制签名验证期间使用的授权证书集。授权证书可以是属性证书或普通证书。除非验证签名的客户可以轻松访问验证所需的所有证书，否则这些证书应显示issuerSerial字段（在ESSCertID结构中）。如果序列中仅存在签名证书，则对验证签名时使用的授权证书集没有限制。
The sequence of policy information terms identifies those certificate policies that the signer asserts apply to the certificate, and under which the certificate should be relied upon. This value suggests a policy value to be used in the relying party's certification path validation.
策略信息术语的顺序标识了签名者声称应用于证书的那些证书策略，以及证书应该依赖的那些证书策略。此值表示要在依赖方的认证路径验证中使用的策略值。
If present, the SigningCertificate attribute MUST be a signed attribute; it MUST NOT be an unsigned attribute. CMS defines SignedAttributes as a SET OF Attribute. A SignerInfo MUST NOT include
如果存在，SigningCertificate属性必须是已签名属性；它不能是未签名的属性。CMS将SignedAttribute定义为一组属性。签名信息不得包括
multiple instances of the SigningCertificate attribute. CMS defines the ASN.1 syntax for the signed attributes to include attrValues SET OF AttributeValue. A SigningCertificate attribute MUST include only a single instance of AttributeValue. There MUST NOT be zero or multiple instances of AttributeValue present in the attrValues SET OF AttributeValue.
SigningCertificate属性的多个实例。CMS为签名属性定义ASN.1语法，以包括AttributeValue的attrValues集。SigningCertificate属性只能包含AttributeValue的一个实例。AttributeValue的attrValues集合中不能存在AttributeValue的零个或多个实例。
The best way to identify certificates is an often-discussed issue. [CERT] has imposed a restriction for SignedData objects that the issuer DN must be present in all signing certificates. The issuer/serial number pair is therefore sufficient to identify the correct signing certificate. This information is already present, as part of the SignerInfo object, and duplication of this information would be unfortunate. A hash of the entire certificate serves the same function (allowing the receiver to verify that the same certificate is being used as when the message was signed), is smaller, and permits a detection of the simple substitution attacks.
识别证书的最佳方法是一个经常讨论的问题。[CERT]对SignedData对象施加了限制，即颁发者DN必须存在于所有签名证书中。因此，颁发者/序列号对足以识别正确的签名证书。此信息作为SignerInfo对象的一部分已经存在，复制此信息将是不幸的。整个证书的散列服务于相同的功能（允许接收方验证与消息签名时使用相同的证书），更小，并且允许检测简单的替换攻击。
Attribute certificates and additional public key certificates containing authorization information do not have an issuer/serial number pair represented anywhere in a SignerInfo object. When an attribute certificate or an additional public key certificate is not included in the SignedData object, it becomes much more difficult to get the correct set of certificates based only on a hash of the certificate. For this reason, these certificates SHOULD be identified by the IssuerSerial object.
属性证书和包含授权信息的其他公钥证书在SignerInfo对象中的任何位置都没有表示颁发者/序列号对。当属性证书或附加公钥证书未包含在SignedData对象中时，仅根据证书的哈希值获取正确的证书集变得更加困难。因此，这些证书应该由IssuerSerial对象标识。
This document defines a certificate identifier as:
本文档将证书标识符定义为：
ESSCertID ::= SEQUENCE {
certHash Hash,
issuerSerial IssuerSerial OPTIONAL
}
ESSCertID ::= SEQUENCE {
certHash Hash,
issuerSerial IssuerSerial OPTIONAL
}
Hash ::= OCTET STRING -- SHA1 hash of entire certificate
Hash ::= OCTET STRING -- SHA1 hash of entire certificate
IssuerSerial ::= SEQUENCE {
issuer GeneralNames,
serialNumber CertificateSerialNumber
}
IssuerSerial ::= SEQUENCE {
issuer GeneralNames,
serialNumber CertificateSerialNumber
}
When creating an ESSCertID, the certHash is computed over the entire DER encoded certificate including the signature. The issuerSerial would normally be present unless the value can be inferred from other information.
创建ESSCertID时，certHash将计算整个DER编码证书（包括签名）。除非可以从其他信息推断出该值，否则发行人序列通常是存在的。
When encoding IssuerSerial, serialNumber is the serial number that uniquely identifies the certificate. For non-attribute certificates, the issuer MUST contain only the issuer name from the certificate encoded in the directoryName choice of GeneralNames. For attribute certificates, the issuer MUST contain the issuer name field from the attribute certificate.
对IssuerSerial进行编码时，serialNumber是唯一标识证书的序列号。对于非属性证书，颁发者必须仅包含在GeneralName的directoryName选项中编码的证书中的颁发者名称。对于属性证书，颁发者必须包含属性证书中的颁发者名称字段。
All security considerations from [CMS] and [SMIME3] apply to applications that use procedures described in this document.
[CMS]和[SMIME3]中的所有安全注意事项适用于使用本文档中描述的过程的应用程序。
As stated in Section 2.3, a recipient of a receipt request must not send back a reply if it cannot validate the signature. Similarly, if there conflicting receipt requests in a message, the recipient must not send back receipts, since an attacker may have inserted the conflicting request. Sending a signed receipt to an unvalidated sender can expose information about the recipient that it may not want to expose to unknown senders.
如第2.3节所述，如果接收请求的接收人无法验证签名，则不得发回回复。类似地，如果邮件中存在冲突的回执请求，则收件人不得发回回执，因为攻击者可能插入了冲突的请求。向未经验证的发件人发送已签名的回执可能会暴露收件人的信息，而收件人可能不想向未知发件人公开这些信息。
Senders of receipts should consider encrypting the receipts to prevent a passive attacker from gleaning information in the receipts.
收据的发送者应该考虑加密收据以防止被动攻击者从收据中收集信息。
Senders must not rely on recipients' processing software to correctly process security labels. That is, the sender cannot assume that adding a security label to a message will prevent recipients from viewing messages the sender doesn't want them to view. It is expected that there will be many S/MIME clients that will not understand security labels but will still display a labelled message to a recipient.
发件人不得依赖收件人的处理软件来正确处理安全标签。也就是说，发件人不能假设向邮件添加安全标签会阻止收件人查看发件人不希望他们查看的邮件。预计会有许多S/MIME客户端不理解安全标签，但仍会向收件人显示带标签的消息。
A receiving agent that processes security labels must handle the content of the messages carefully. If the agent decides not to show the message to the intended recipient after processing the security label, the agent must take care that the recipient does not accidentally see the content at a later time. For example, if an error response sent to the originator contains the content that was hidden from the recipient, and that error response bounces back to the sender due to addressing errors, the original recipient can possibly see the content since it is unlikely that the bounce message will have the proper security labels.
处理安全标签的接收代理必须仔细处理消息的内容。如果代理在处理安全标签后决定不向预期收件人显示邮件，则代理必须注意收件人以后不会意外看到内容。例如，如果发送给发起人的错误响应包含对收件人隐藏的内容，并且该错误响应由于寻址错误而反弹回给发件人，则原始收件人可能会看到该内容，因为反弹消息不太可能具有正确的安全标签。
A man-in-the-middle attack can cause a recipient to send receipts to an attacker if that attacker has a signature that can be validated by the recipient. The attack consists of intercepting the original message and adding a mLData attribute that says that a receipt should be sent to the attacker in addition to whoever else was going to get the receipt.
中间人攻击可导致收件人向攻击者发送收据，前提是该攻击者具有可由收件人验证的签名。攻击包括截获原始消息并添加一个mLData属性，该属性表示除了其他将获得回执的人之外，还应向攻击者发送回执。
Mailing lists that encrypt their content may be targets for denial-of-service attacks if they do not use the mailing list management described in Section 4. Using simple RFC822 header spoofing, it is quite easy to subscribe one encrypted mailing list to another, thereby setting up an infinite loop.
如果邮件列表未使用第4节中描述的邮件列表管理，则对其内容进行加密的邮件列表可能成为拒绝服务攻击的目标。使用简单的RFC822头欺骗，很容易将一个加密邮件列表订阅给另一个，从而建立一个无限循环。
Mailing List Agents need to be aware that they can be used as oracles for the the adaptive chosen ciphertext attack described in [CMS]. MLAs should notify an administrator if a large number of undecryptable messages are received.
邮件列表代理需要意识到，它们可以用作[CMS]中描述的自适应选择密文攻击的预言器。如果收到大量不可加密的消息，MLA应通知管理员。
When verifying a signature using certificates that come with a [CMS] message, the recipient should only verify using certificates previously known to be valid, or certificates that have come from a signed SigningCertificate attribute. Otherwise, the attacks described in Section 5 can cause the receiver to possibly think a signature is valid when it is not.
使用[CMS]消息附带的证书验证签名时，收件人应仅使用先前已知有效的证书或来自签名签名证书属性的证书进行验证。否则，第5节中描述的攻击可能会导致接收方认为签名无效。
A. ASN.1 Module
A.ASN.1模块
ExtendedSecurityServices
{ iso(1) member-body(2) us(840) rsadsi(113549)
pkcs(1) pkcs-9(9) smime(16) modules(0) ess(2) }
ExtendedSecurityServices
{ iso(1) member-body(2) us(840) rsadsi(113549)
pkcs(1) pkcs-9(9) smime(16) modules(0) ess(2) }
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
IMPORTS
进口
-- Cryptographic Message Syntax (CMS)
ContentType, IssuerAndSerialNumber, SubjectKeyIdentifier
FROM CryptographicMessageSyntax { iso(1) member-body(2) us(840)
rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) modules(0) cms(1)}
-- Cryptographic Message Syntax (CMS)
ContentType, IssuerAndSerialNumber, SubjectKeyIdentifier
FROM CryptographicMessageSyntax { iso(1) member-body(2) us(840)
rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) modules(0) cms(1)}
-- PKIX Certificate and CRL Profile, Sec A.2 Implicitly Tagged Module,
-- 1988 Syntax
PolicyInformation FROM PKIX1Implicit88 {iso(1)
identified-organization(3) dod(6) internet(1) security(5)
mechanisms(5) pkix(7)id-mod(0) id-pkix1-implicit-88(2)}
-- PKIX Certificate and CRL Profile, Sec A.2 Implicitly Tagged Module,
-- 1988 Syntax
PolicyInformation FROM PKIX1Implicit88 {iso(1)
identified-organization(3) dod(6) internet(1) security(5)
mechanisms(5) pkix(7)id-mod(0) id-pkix1-implicit-88(2)}
-- X.509
GeneralNames, CertificateSerialNumber FROM CertificateExtensions
{joint-iso-ccitt ds(5) module(1) certificateExtensions(26) 0};
-- X.509
GeneralNames, CertificateSerialNumber FROM CertificateExtensions
{joint-iso-ccitt ds(5) module(1) certificateExtensions(26) 0};
-- Extended Security Services
--扩展安全服务
-- The construct "SEQUENCE SIZE (1..MAX) OF" appears in several ASN.1
-- constructs in this module. A valid ASN.1 SEQUENCE can have zero or
-- more entries. The SIZE (1..MAX) construct constrains the SEQUENCE to
-- have at least one entry. MAX indicates the upper bound is unspecified.
-- Implementations are free to choose an upper bound that suits their
-- environment.
-- The construct "SEQUENCE SIZE (1..MAX) OF" appears in several ASN.1
-- constructs in this module. A valid ASN.1 SEQUENCE can have zero or
-- more entries. The SIZE (1..MAX) construct constrains the SEQUENCE to
-- have at least one entry. MAX indicates the upper bound is unspecified.
-- Implementations are free to choose an upper bound that suits their
-- environment.
UTF8String ::= [UNIVERSAL 12] IMPLICIT OCTET STRING
-- The contents are formatted as described in [UTF8]
UTF8String ::= [UNIVERSAL 12] IMPLICIT OCTET STRING
-- The contents are formatted as described in [UTF8]
-- Section 2.7
--第2.7节
ReceiptRequest ::= SEQUENCE {
signedContentIdentifier ContentIdentifier,
receiptsFrom ReceiptsFrom,
receiptsTo SEQUENCE SIZE (1..ub-receiptsTo) OF GeneralNames }
ReceiptRequest ::= SEQUENCE {
signedContentIdentifier ContentIdentifier,
receiptsFrom ReceiptsFrom,
receiptsTo SEQUENCE SIZE (1..ub-receiptsTo) OF GeneralNames }
ub-receiptsTo INTEGER ::= 16
ub-receiptsTo INTEGER ::= 16
id-aa-receiptRequest OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 1}
id-aa-receiptRequest OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 1}
ContentIdentifier ::= OCTET STRING
ContentIdentifier ::= OCTET STRING
id-aa-contentIdentifier OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 7}
id-aa-contentIdentifier OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 7}
ReceiptsFrom ::= CHOICE {
allOrFirstTier [0] AllOrFirstTier,
-- formerly "allOrNone [0]AllOrNone"
receiptList [1] SEQUENCE OF GeneralNames }
ReceiptsFrom ::= CHOICE {
allOrFirstTier [0] AllOrFirstTier,
-- formerly "allOrNone [0]AllOrNone"
receiptList [1] SEQUENCE OF GeneralNames }
AllOrFirstTier ::= INTEGER { -- Formerly AllOrNone
allReceipts (0),
firstTierRecipients (1) }
AllOrFirstTier ::= INTEGER { -- Formerly AllOrNone
allReceipts (0),
firstTierRecipients (1) }
-- Section 2.8
--第2.8节
Receipt ::= SEQUENCE {
version ESSVersion,
contentType ContentType,
signedContentIdentifier ContentIdentifier,
originatorSignatureValue OCTET STRING }
Receipt ::= SEQUENCE {
version ESSVersion,
contentType ContentType,
signedContentIdentifier ContentIdentifier,
originatorSignatureValue OCTET STRING }
id-ct-receipt OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-ct(1) 1}
id-ct-receipt OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-ct(1) 1}
ESSVersion ::= INTEGER { v1(1) }
ESSVersion ::= INTEGER { v1(1) }
-- Section 2.9
--第2.9节
ContentHints ::= SEQUENCE {
contentDescription UTF8String (SIZE (1..MAX)) OPTIONAL,
contentType ContentType }
ContentHints ::= SEQUENCE {
contentDescription UTF8String (SIZE (1..MAX)) OPTIONAL,
contentType ContentType }
id-aa-contentHint OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 4}
id-aa-contentHint OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 4}
-- Section 2.10
--第2.10节
MsgSigDigest ::= OCTET STRING
MsgSigDigest ::= OCTET STRING
id-aa-msgSigDigest OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 5}
id-aa-msgSigDigest OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 5}
-- Section 2.11
--第2.11节
ContentReference ::= SEQUENCE {
contentType ContentType,
signedContentIdentifier ContentIdentifier,
originatorSignatureValue OCTET STRING }
ContentReference ::= SEQUENCE {
contentType ContentType,
signedContentIdentifier ContentIdentifier,
originatorSignatureValue OCTET STRING }
id-aa-contentReference OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 10 }
id-aa-contentReference OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 10 }
-- Section 3.2
--第3.2节
ESSSecurityLabel ::= SET {
security-policy-identifier SecurityPolicyIdentifier,
security-classification SecurityClassification OPTIONAL,
privacy-mark ESSPrivacyMark OPTIONAL,
security-categories SecurityCategories OPTIONAL }
ESSSecurityLabel ::= SET {
security-policy-identifier SecurityPolicyIdentifier,
security-classification SecurityClassification OPTIONAL,
privacy-mark ESSPrivacyMark OPTIONAL,
security-categories SecurityCategories OPTIONAL }
id-aa-securityLabel OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 2}
id-aa-securityLabel OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 2}
SecurityPolicyIdentifier ::= OBJECT IDENTIFIER
SecurityPolicyIdentifier ::= OBJECT IDENTIFIER
SecurityClassification ::= INTEGER {
unmarked (0),
unclassified (1),
restricted (2),
confidential (3),
secret (4),
top-secret (5) } (0..ub-integer-options)
SecurityClassification ::= INTEGER {
unmarked (0),
unclassified (1),
restricted (2),
confidential (3),
secret (4),
top-secret (5) } (0..ub-integer-options)
ub-integer-options INTEGER ::= 256
ub-integer-options INTEGER ::= 256
ESSPrivacyMark ::= CHOICE {
pString PrintableString (SIZE (1..ub-privacy-mark-length)),
utf8String UTF8String (SIZE (1..MAX))
}
ESSPrivacyMark ::= CHOICE {
pString PrintableString (SIZE (1..ub-privacy-mark-length)),
utf8String UTF8String (SIZE (1..MAX))
}
ub-privacy-mark-length INTEGER ::= 128
ub-privacy-mark-length INTEGER ::= 128
SecurityCategories ::= SET SIZE (1..ub-security-categories) OF
SecurityCategory
SecurityCategories ::= SET SIZE (1..ub-security-categories) OF
SecurityCategory
ub-security-categories INTEGER ::= 64
ub-security-categories INTEGER ::= 64
SecurityCategory ::= SEQUENCE {
type [0] OBJECT IDENTIFIER,
value [1] ANY DEFINED BY type -- defined by type
}
SecurityCategory ::= SEQUENCE {
type [0] OBJECT IDENTIFIER,
value [1] ANY DEFINED BY type -- defined by type
}
--Note: The aforementioned SecurityCategory syntax produces identical
--hex encodings as the following SecurityCategory syntax that is
--documented in the X.411 specification:
--
--SecurityCategory ::= SEQUENCE {
-- type [0] SECURITY-CATEGORY,
-- value [1] ANY DEFINED BY type }
--
--SECURITY-CATEGORY MACRO ::=
--BEGIN
--TYPE NOTATION ::= type | empty
--VALUE NOTATION ::= value (VALUE OBJECT IDENTIFIER)
--END
--Note: The aforementioned SecurityCategory syntax produces identical
--hex encodings as the following SecurityCategory syntax that is
--documented in the X.411 specification:
--
--SecurityCategory ::= SEQUENCE {
-- type [0] SECURITY-CATEGORY,
-- value [1] ANY DEFINED BY type }
--
--SECURITY-CATEGORY MACRO ::=
--BEGIN
--TYPE NOTATION ::= type | empty
--VALUE NOTATION ::= value (VALUE OBJECT IDENTIFIER)
--END
-- Section 3.4
--第3.4节
EquivalentLabels ::= SEQUENCE OF ESSSecurityLabel
EquivalentLabels ::= SEQUENCE OF ESSSecurityLabel
id-aa-equivalentLabels OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 9}
id-aa-equivalentLabels OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 9}
-- Section 4.4
--第4.4节
MLExpansionHistory ::= SEQUENCE
SIZE (1..ub-ml-expansion-history) OF MLData
MLExpansionHistory ::= SEQUENCE
SIZE (1..ub-ml-expansion-history) OF MLData
id-aa-mlExpandHistory OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 3}
id-aa-mlExpandHistory OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 3}
ub-ml-expansion-history INTEGER ::= 64
ub-ml-expansion-history INTEGER ::= 64
MLData ::= SEQUENCE {
mailListIdentifier EntityIdentifier,
expansionTime GeneralizedTime,
mlReceiptPolicy MLReceiptPolicy OPTIONAL }
MLData ::= SEQUENCE {
mailListIdentifier EntityIdentifier,
expansionTime GeneralizedTime,
mlReceiptPolicy MLReceiptPolicy OPTIONAL }
EntityIdentifier ::= CHOICE {
issuerAndSerialNumber IssuerAndSerialNumber,
subjectKeyIdentifier SubjectKeyIdentifier }
EntityIdentifier ::= CHOICE {
issuerAndSerialNumber IssuerAndSerialNumber,
subjectKeyIdentifier SubjectKeyIdentifier }
MLReceiptPolicy ::= CHOICE {
none [0] NULL,
insteadOf [1] SEQUENCE SIZE (1..MAX) OF GeneralNames,
inAdditionTo [2] SEQUENCE SIZE (1..MAX) OF GeneralNames }
MLReceiptPolicy ::= CHOICE {
none [0] NULL,
insteadOf [1] SEQUENCE SIZE (1..MAX) OF GeneralNames,
inAdditionTo [2] SEQUENCE SIZE (1..MAX) OF GeneralNames }
-- Section 5.4
--第5.4节
SigningCertificate ::= SEQUENCE {
certs SEQUENCE OF ESSCertID,
policies SEQUENCE OF PolicyInformation OPTIONAL
}
SigningCertificate ::= SEQUENCE {
certs SEQUENCE OF ESSCertID,
policies SEQUENCE OF PolicyInformation OPTIONAL
}
id-aa-signingCertificate OBJECT IDENTIFIER ::= { iso(1)
member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
smime(16) id-aa(2) 12 }
id-aa-signingCertificate OBJECT IDENTIFIER ::= { iso(1)
member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
smime(16) id-aa(2) 12 }
ESSCertID ::= SEQUENCE {
certHash Hash,
issuerSerial IssuerSerial OPTIONAL
}
ESSCertID ::= SEQUENCE {
certHash Hash,
issuerSerial IssuerSerial OPTIONAL
}
Hash ::= OCTET STRING -- SHA1 hash of entire certificate
Hash ::= OCTET STRING -- SHA1 hash of entire certificate
IssuerSerial ::= SEQUENCE {
issuer GeneralNames,
serialNumber CertificateSerialNumber
}
IssuerSerial ::= SEQUENCE {
issuer GeneralNames,
serialNumber CertificateSerialNumber
}
END -- of ExtendedSecurityServices
结束--ExtendedSecurityServices的终止
B. References
B.参考资料
[ASN1-1988] "Recommendation X.208: Specification of Abstract Syntax Notation One (ASN.1)".
[ASN1-1988]“建议X.208：抽象语法符号1的规范（ASN.1）”。
[ASN1-1994] "Recommendation X.680: Specification of Abstract Syntax Notation One (ASN.1)".
[ASN1-1994]“建议X.680：抽象语法符号1（ASN.1）的规范”。
[CERT] Ramsdell, B., Editor, "S/MIME Version 3 Certificate Handling", RFC 2632, June 1999.
[CERT]Ramsdell，B.，编辑，“S/MIME版本3证书处理”，RFC 2632，1999年6月。
[CMS] Housley, R., "Cryptographic Message Syntax", RFC 2630, June 1999.
[CMS]Housley，R.，“加密消息语法”，RFC 2630，1999年6月。
[MSG] Ramsdell, B., Editor, "S/MIME Version 3 Message Specification", RFC 2633, June 1999.
[MSG]Ramsdell，B.，编辑，“S/MIME版本3消息规范”，RFC 2633，1999年6月。
[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月。
[MSP4] "Secure Data Network System (SDNS) Message Security Protocol (MSP) 4.0", Specification SDN.701, Revision A, 1997-02-06.
[MSP4]“安全数据网络系统（SDNS）消息安全协议（MSP）4.0”，规范SDN.701，版本A，1997-02-06。
[MTSABS] "1988 International Telecommunication Union (ITU) Data
Communication Networks Message Handling Systems: Message
Transfer System: Abstract Service Definition and
Procedures, Volume VIII, Fascicle VIII.7, Recommendation
X.411"; MTSAbstractService {joint-iso-ccitt mhs-motis(6)
mts(3) modules(0) mts-abstract-service(1)}
[MTSABS] "1988 International Telecommunication Union (ITU) Data
Communication Networks Message Handling Systems: Message
Transfer System: Abstract Service Definition and
Procedures, Volume VIII, Fascicle VIII.7, Recommendation
X.411"; MTSAbstractService {joint-iso-ccitt mhs-motis(6)
mts(3) modules(0) mts-abstract-service(1)}
[PKCS7-1.5] Kaliski, B., "PKCS #7: Cryptographic Message Syntax", RFC 2315, March 1998.
[PKCS7-1.5]Kaliski，B.，“PKCS#7：加密消息语法”，RFC 2315，1998年3月。
[SMIME2] Dusse, S., Hoffman, P., Ramsdell, B., Lundblade, L. and L. Repka"S/MIME Version 2 Message Specification", RFC 2311, March 1998, and Dusse, S., Hoffman, P. and B. Ramsdell,"S/MIME Version 2 Certificate Handling", RFC 2312, March 1998.
[SMIME2]Dusse，S.，Hoffman，P.，Ramsdell，B.，Lundblade，L.和L.Repka“S/MIME版本2消息规范”，RFC 2311，1998年3月；Dusse，S.，Hoffman，P.和B.Ramsdell，“S/MIME版本2证书处理”，RFC 2312，1998年3月。
[UTF8] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 2279, January 1998.
[UTF8]Yergeau，F.，“UTF-8，ISO 10646的转换格式”，RFC 2279，1998年1月。
C. Acknowledgments
C.致谢
The first draft of this work was prepared by David Solo. John Pawling did a huge amount of very detailed revision work during the many phases of the document.
这项工作的初稿是由大卫·索洛编写的。约翰·帕林在文件的许多阶段做了大量非常详细的修订工作。
Many other people have contributed hard work to this memo, including:
许多其他人为这份备忘录付出了辛勤的努力，包括：
Andrew Farrell Bancroft Scott Bengt Ackzell Bill Flanigan Blake Ramsdell Carlisle Adams Darren Harter David Kemp Denis Pinkas Francois Rousseau Jim Schaad Russ Housley Scott Hollenbeck Steve Dusse
Andrew Farrell Bancroft Scott Bengt Ackzell Bill Flanigan Blake Ramsdell Carlisle Adams Darren Harter David Kemp Denis Pinkas Francois Rousseau Jim Schaad Russ Housley Scott Hollenbeck Steve Dusse
Editor's Address
编辑地址
Paul Hoffman Internet Mail Consortium 127 Segre Place Santa Cruz, CA 95060
保罗霍夫曼互联网邮件联盟127塞格雷广场圣克鲁斯，加利福尼亚州95060
EMail: phoffman@imc.org
EMail: phoffman@imc.org
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (1999). All Rights Reserved.
版权所有（C）互联网协会（1999年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。