Independent Submission A. Melnikov
Request for Comments: 7281 Isode Ltd
Category: Informational June 2014
ISSN: 2070-1721
Independent Submission A. Melnikov
Request for Comments: 7281 Isode Ltd
Category: Informational June 2014
ISSN: 2070-1721
Authentication-Results Registration for S/MIME Signature Verification
S/MIME签名验证的身份验证结果注册
Abstract
摘要
RFC 7001 specifies the Authentication-Results header field for conveying results of message authentication checks. This document defines a new authentication method to be used in the Authentication-Results header field for S/MIME-related signature checks.
RFC 7001指定用于传输消息身份验证检查结果的身份验证结果标头字段。本文档定义了一种新的身份验证方法，用于S/MIME相关签名检查的身份验证结果标题字段。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
这是对RFC系列的贡献，独立于任何其他RFC流。RFC编辑器已选择自行发布此文档，并且未声明其对实现或部署的价值。RFC编辑批准发布的文件不适用于任何级别的互联网标准；见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7281.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7281.
Copyright Notice
版权公告
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2014 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
Table of Contents
目录
1. Introduction ....................................................2
2. Conventions Used in This Document ...............................2
3. "smime" Authentication Method ...................................2
3.1. S/MIME Results .............................................3
3.2. Email Authentication Parameters for S/MIME .................4
3.2.1. body.smime-part .....................................4
3.2.2. body.smime-identifier ...............................4
3.2.3. body.smime-serial and body.smime-issuer .............5
3.3. Examples ...................................................5
4. IANA Considerations .............................................7
5. Security Considerations .........................................9
6. References .....................................................10
6.1. Normative References ......................................10
6.2. Informative References ....................................10
Appendix A. Acknowledgements ......................................11
1. Introduction ....................................................2
2. Conventions Used in This Document ...............................2
3. "smime" Authentication Method ...................................2
3.1. S/MIME Results .............................................3
3.2. Email Authentication Parameters for S/MIME .................4
3.2.1. body.smime-part .....................................4
3.2.2. body.smime-identifier ...............................4
3.2.3. body.smime-serial and body.smime-issuer .............5
3.3. Examples ...................................................5
4. IANA Considerations .............................................7
5. Security Considerations .........................................9
6. References .....................................................10
6.1. Normative References ......................................10
6.2. Informative References ....................................10
Appendix A. Acknowledgements ......................................11
[RFC7001] specifies the Authentication-Results header field for conveying results of message authentication checks. As S/MIME signature verification (and alteration) is sometimes implemented in border message transfer agents, guards, and gateways (for example, see [RFC3183]), there is a need to convey signature verification status to Mail User Agents (MUAs) and downstream filters. This document defines a new authentication method to be used in the Authentication-Results header field for S/MIME-related signature checks.
[RFC7001]指定用于传输消息身份验证检查结果的身份验证结果标头字段。由于S/MIME签名验证（和更改）有时在边界消息传输代理、守卫和网关中实现（例如，请参见[RFC3183]），因此需要将签名验证状态传递给邮件用户代理（MUA）和下游过滤器。本文档定义了一种新的身份验证方法，用于S/MIME相关签名检查的身份验证结果标题字段。
The formal syntax uses the Augmented Backus-Naur Form (ABNF) [RFC5234] notation, including the core rules defined in Appendix B of [RFC5234].
形式语法使用扩展的巴科斯-诺尔形式（ABNF）[RFC5234]表示法，包括[RFC5234]附录B中定义的核心规则。
S/MIME signature and countersignature verification is represented by the "smime" method and is defined in [RFC5751].
S/MIME签名和会签验证由“smime”方法表示，并在[RFC5751]中定义。
The result values used by S/MIME [RFC5751] are as follows:
S/MIME[RFC5751]使用的结果值如下：
+-----------+-------------------------------------------------------+
| Result | Meaning |
| code | |
+-----------+-------------------------------------------------------+
| none | The message was not signed. |
| | |
| pass | The message was signed, the signature or signatures |
| | were acceptable to the verifier, and the signature(s) |
| | passed verification tests. |
| | |
| fail | The message was signed and the signature or |
| | signatures were acceptable to the verifier, but they |
| | failed the verification test(s). |
| | |
| policy | The message was signed and signature(s) passed |
| | verification tests, but the signature or signatures |
| | were not acceptable to the verifier. |
| | |
| neutral | The message was signed but the signature or |
| | signatures contained syntax errors or were not |
| | otherwise able to be processed. This result is also |
| | used for other failures not covered elsewhere in this |
| | list. |
| | |
| temperror | The message could not be verified due to some error |
| | that is likely transient in nature, such as a |
| | temporary inability to retrieve a certificate or |
| | Certificate Revocation List (CRL). A later attempt |
| | may produce a final result. |
| | |
| permerror | The message could not be verified due to some error |
| | that is unrecoverable, such as a required header |
| | field being absent or the signer's certificate not |
| | being available. A later attempt is unlikely to |
| | produce a final result. |
+-----------+-------------------------------------------------------+
+-----------+-------------------------------------------------------+
| Result | Meaning |
| code | |
+-----------+-------------------------------------------------------+
| none | The message was not signed. |
| | |
| pass | The message was signed, the signature or signatures |
| | were acceptable to the verifier, and the signature(s) |
| | passed verification tests. |
| | |
| fail | The message was signed and the signature or |
| | signatures were acceptable to the verifier, but they |
| | failed the verification test(s). |
| | |
| policy | The message was signed and signature(s) passed |
| | verification tests, but the signature or signatures |
| | were not acceptable to the verifier. |
| | |
| neutral | The message was signed but the signature or |
| | signatures contained syntax errors or were not |
| | otherwise able to be processed. This result is also |
| | used for other failures not covered elsewhere in this |
| | list. |
| | |
| temperror | The message could not be verified due to some error |
| | that is likely transient in nature, such as a |
| | temporary inability to retrieve a certificate or |
| | Certificate Revocation List (CRL). A later attempt |
| | may produce a final result. |
| | |
| permerror | The message could not be verified due to some error |
| | that is unrecoverable, such as a required header |
| | field being absent or the signer's certificate not |
| | being available. A later attempt is unlikely to |
| | produce a final result. |
+-----------+-------------------------------------------------------+
A signature is "acceptable to the verifier" if it passes local policy checks (or there are no specific local policy checks). For example, a verifier might require that the domain in the rfc822Name subjectAltName in the signing certificate matches the domain in the address of the sender of the message (value of the Sender header field, if present; value of the From header field otherwise), thus making third-party signatures unacceptable. [RFC5751] advises that
如果签名通过了本地策略检查（或没有特定的本地策略检查），则签名是“验证者可以接受的”。例如，验证器可能要求签名证书中rfc822Name subjectAltName中的域与消息发送者地址中的域匹配（发送者标头字段的值，如果存在；发件人标头字段的值，否则），从而使第三方签名不可接受。[RFC5751]建议：
if a message fails verification, it should be treated as an unsigned message. A report of "fail" here permits the receiver of the report to decide how to handle the failure. A report of "neutral" or "none" preempts that choice, ensuring that the message will be treated as if it had not been signed.
如果消息验证失败，则应将其视为未签名消息。此处的“失败”报告允许报告接收者决定如何处理失败。“中立”或“无”的报告优先考虑了这一选择，确保消息将被视为未经签名。
This document defines several new authentication parameters for conveying S/MIME-related information, such as the location of an S/MIME signature and the identity associated with the entity that signed the message or one of its body parts.
本文档定义了几个新的身份验证参数，用于传递与S/MIME相关的信息，例如S/MIME签名的位置以及与签名消息的实体或其主体部分之一相关联的标识。
body.smime-part contains the MIME body part reference that contains the S/MIME signature. The syntax of this property is described by the smime-part ABNF production below. application/pkcs7-signature or application/pkcs7-mime (containing SignedData) media type body parts are referenced using the <section> syntax (see Section 6.4.5 of [RFC3501]). If the signature being verified is encapsulated by another Cryptographic Message Syntax (CMS) content type (e.g., application/pkcs7-mime containing EnvelopedData, which contains SignedData), such an inner signature body part can be referenced using "section[/section..." syntax.
body.smime-part包含包含S/MIME签名的MIME正文部分引用。此属性的语法由下面的smime部件ABNF产品描述。使用<section>语法引用应用程序/pkcs7签名或应用程序/pkcs7 mime（包含签名数据）媒体类型主体部分（参见[RFC3501]第6.4.5节）。如果正在验证的签名由另一个加密消息语法（CMS）内容类型（例如，包含EnvelopedData的application/pkcs7 mime，其中包含SignedData）封装，则可以使用“section[/section…”语法引用此类内部签名主体部分。
smime-part = section ["/" smime-subpart]
smime-subpart = smime-part
section = <Defined in Section 6.4.5 of [RFC3501]>
smime-part = section ["/" smime-subpart]
smime-subpart = smime-part
section = <Defined in Section 6.4.5 of [RFC3501]>
body.smime-identifier contains the email address [RFC5322] associated with the S/MIME signature referenced in the corresponding body.smime-part. The email address can be specified explicitly in the signer's X.509 certificate or derived from the identity of the signer. Note that this email address can correspond to a countersignature.
body.smime-identifier包含与相应body.smime-part中引用的S/MIME签名关联的电子邮件地址[RFC5322]。电子邮件地址可以在签名者的X.509证书中明确指定，也可以从签名者的身份派生。请注意，此电子邮件地址可以对应于会签。
body.smime-serial contains the serialNumber of the X.509 certificate associated with the S/MIME signature (see Section 4.1.2.2 of [RFC5280]) referenced in the corresponding body.smime-part.
body.smime-serial包含与相应body.smime-part中引用的S/MIME签名相关联的X.509证书的序列号（参见[RFC5280]第4.1.2.2节）。
body.smime-issuer contains the issuer name DN (distinguished name) (e.g., "CN=CA1,ST=BC,c=CA") of the X.509 certificate associated with the S/MIME signature (see Section 4.1.2.4 of [RFC5280]) referenced in the corresponding body.smime-part.
body.smime-issuer包含与相应body.smime-part中引用的S/MIME签名相关联的X.509证书的发行人名称DN（可分辨名称）（例如，“CN=CA1，ST=BC，c=CA”）（参见[RFC5280]的第4.1.2.4节）。
Either both or neither of body.smime-serial and body.smime-issuer should be present in an Authentication-Results header field.
身份验证结果标头字段中应同时存在body.smime-serial和body.smime-issuer或两者都不存在。
body.smime-serial and body.smime-issuer are used for cases when body.smime-identifier (email address) can't be derived by the entity adding the corresponding Authentication-Results header field. For example, this can be used when gatewaying from X.400.
body.smime-serial和body.smime-issuer用于添加相应身份验证结果标头字段的实体无法派生body.smime-identifier（电子邮件地址）的情况。例如，从X.400进行网关连接时可以使用此选项。
Return-Path: <aliceDss@example.com>
Authentication-Results: example.net;
smime=fail (certificate is revoked by CRL)
body.smime-identifier=aliceDss@example.com
body.smime-part=2
Received: from ietfa.example.com (localhost [IPv6:::1])
by ietfa.example.com (Postfix) with ESMTP id 2875111E81A0;
Fri, 06 Sep 2002 00:35:14 -0700 (PDT)
MIME-Version: 1.0
To: User2@example.com
From: aliceDss@example.com
Subject: Example 4.8
Message-Id: <020906002550300.249@example.com>
Date: Fri, 06 Sep 2002 00:25:21 -0700
Content-Type: multipart/signed;
micalg=SHA1;
boundary="----=_NextBoundary____Fri,_06_Sep_2002_00:25:21";
protocol="application/pkcs7-signature"
Return-Path: <aliceDss@example.com>
Authentication-Results: example.net;
smime=fail (certificate is revoked by CRL)
body.smime-identifier=aliceDss@example.com
body.smime-part=2
Received: from ietfa.example.com (localhost [IPv6:::1])
by ietfa.example.com (Postfix) with ESMTP id 2875111E81A0;
Fri, 06 Sep 2002 00:35:14 -0700 (PDT)
MIME-Version: 1.0
To: User2@example.com
From: aliceDss@example.com
Subject: Example 4.8
Message-Id: <020906002550300.249@example.com>
Date: Fri, 06 Sep 2002 00:25:21 -0700
Content-Type: multipart/signed;
micalg=SHA1;
boundary="----=_NextBoundary____Fri,_06_Sep_2002_00:25:21";
protocol="application/pkcs7-signature"
This is a multi-part message in MIME format.
这是MIME格式的多部分消息。
------=_NextBoundary____Fri,_06_Sep_2002_00:25:21
------=_NextBoundary____Fri,_06_Sep_2002_00:25:21
This is some sample content.
------=_NextBoundary____Fri,_06_Sep_2002_00:25:21
Content-Type: application/pkcs7-signature; name=smime.p7s
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=smime.p7s
This is some sample content.
------=_NextBoundary____Fri,_06_Sep_2002_00:25:21
Content-Type: application/pkcs7-signature; name=smime.p7s
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=smime.p7s
MIIDdwYJKoZIhvcNAQcCoIIDaDCCA2QCAQExCTAHBgUrDgMCGjALBgkqhkiG9w0BBwGgggL
gMIIC3DCCApugAwIBAgICAMgwCQYHKoZIzjgEAzASMRAwDgYDVQQDEwdDYXJsRFNTMB4XDT
k5MDgxNzAxMTA0OVoXDTM5MTIzMTIzNTk1OVowEzERMA8GA1UEAxMIQWxpY2VEU1MwggG2M
IIBKwYHKoZIzjgEATCCAR4CgYEAgY3N7YPqCp45PsJIKKPkR5PdDteoDuxTxauECE//lOFz
SH4M1vNESNH+n6+koYkv4dkwyDbeP5u/t0zcX2mK5HXQNwyRCJWb3qde+fz0ny/dQ6iLVPE
/sAcIR01diMPDtbPjVQh11Tl2EMR4vf+dsISXN/LkURu15AmWXPN+W9sCFQDiR6YaRWa4E8
baj7g3IStii/eTzQKBgCY40BSJMqo5+z5t2UtZakx2IzkEAjVc8ssaMMMeUF3dm1nizaoFP
VjAe6I2uG4Hr32KQiWn9HXPSgheSz6Q+G3qnMkhijt2FOnOLl2jB80jhbgvMAF8bUmJEYk2
RL34yJVKU1a14vlz7BphNh8Rf8K97dFQ/5h0wtGBSmA5ujY5A4GEAAKBgFzjuVp1FJYLqXr
d4z+p7Kxe3L23ExE0phaJKBEj2TSGZ3V1ExI9Q1tv5VG/+onyohs+JH09B41bY8i7RaWgSu
OF1s4GgD/oI34a8iSrUxq4Jw0e7wi/ZhSAXGKsZfoVi/G7NNTSljf2YUeyxDKE8H5BQP1Gp
2NOM/Kl4vTyg+W4o4GBMH8wDAYDVR0TAQH/BAIwADAOBgNVHQ8BAf8EBAMCBsAwHwYDVR0j
BBgwFoAUcEQ+gi5vh95K03XjPSC8QyuT8R8wHQYDVR0OBBYEFL5sobPjwfftQ3CkzhMB4v3
jl/7NMB8GA1UdEQQYMBaBFEFsaWNlRFNTQGV4YW1wbGUuY29tMAkGByqGSM44BAMDMAAwLQ
IUVQykGR9CK4lxIjONg2q1PWdrv0UCFQCfYVNSVAtcst3a53Yd4hBSW0NevTFjMGECAQEwG
DASMRAwDgYDVQQDEwdDYXJsRFNTAgIAyDAHBgUrDgMCGjAJBgcqhkjOOAQDBC4wLAIUM/mG
f6gkgp9Z0XtRdGimJeB/BxUCFGFFJqwYRt1WYcIOQoGiaowqGzVI
MIIDdwYJKoZIhvcNAQcCoIIDaDCCA2QCAQExCTAHBgUrDgMCGjALBgkqhkiG9w0BBwGgggL
gMIIC3DCCApugAwIBAgICAMgwCQYHKoZIzjgEAzASMRAwDgYDVQQDEwdDYXJsRFNTMB4XDT
k5MDgxNzAxMTA0OVoXDTM5MTIzMTIzNTk1OVowEzERMA8GA1UEAxMIQWxpY2VEU1MwggG2M
IIBKwYHKoZIzjgEATCCAR4CgYEAgY3N7YPqCp45PsJIKKPkR5PdDteoDuxTxauECE//lOFz
SH4M1vNESNH+n6+koYkv4dkwyDbeP5u/t0zcX2mK5HXQNwyRCJWb3qde+fz0ny/dQ6iLVPE
/sAcIR01diMPDtbPjVQh11Tl2EMR4vf+dsISXN/LkURu15AmWXPN+W9sCFQDiR6YaRWa4E8
baj7g3IStii/eTzQKBgCY40BSJMqo5+z5t2UtZakx2IzkEAjVc8ssaMMMeUF3dm1nizaoFP
VjAe6I2uG4Hr32KQiWn9HXPSgheSz6Q+G3qnMkhijt2FOnOLl2jB80jhbgvMAF8bUmJEYk2
RL34yJVKU1a14vlz7BphNh8Rf8K97dFQ/5h0wtGBSmA5ujY5A4GEAAKBgFzjuVp1FJYLqXr
d4z+p7Kxe3L23ExE0phaJKBEj2TSGZ3V1ExI9Q1tv5VG/+onyohs+JH09B41bY8i7RaWgSu
OF1s4GgD/oI34a8iSrUxq4Jw0e7wi/ZhSAXGKsZfoVi/G7NNTSljf2YUeyxDKE8H5BQP1Gp
2NOM/Kl4vTyg+W4o4GBMH8wDAYDVR0TAQH/BAIwADAOBgNVHQ8BAf8EBAMCBsAwHwYDVR0j
BBgwFoAUcEQ+gi5vh95K03XjPSC8QyuT8R8wHQYDVR0OBBYEFL5sobPjwfftQ3CkzhMB4v3
jl/7NMB8GA1UdEQQYMBaBFEFsaWNlRFNTQGV4YW1wbGUuY29tMAkGByqGSM44BAMDMAAwLQ
IUVQykGR9CK4lxIjONg2q1PWdrv0UCFQCfYVNSVAtcst3a53Yd4hBSW0NevTFjMGECAQEwG
DASMRAwDgYDVQQDEwdDYXJsRFNTAgIAyDAHBgUrDgMCGjAJBgcqhkjOOAQDBC4wLAIUM/mG
f6gkgp9Z0XtRdGimJeB/BxUCFGFFJqwYRt1WYcIOQoGiaowqGzVI
------=_NextBoundary____Fri,_06_Sep_2002_00:25:21--
------=_NextBoundary____Fri,_06_Sep_2002_00:25:21--
IANA has added the following entries to the "Email Authentication Methods" sub-registry of the "Email Authentication Parameters" registry:
IANA已将以下条目添加到“电子邮件身份验证参数”注册表的“电子邮件身份验证方法”子注册表中：
+------+----------+-------+------------+----------------+-------+------+
|Method| Defined | ptype | Property | Value |Status | Ver- |
| | in | | | | | sion |
+------+----------+-------+------------+----------------+-------+------+
| smime| [RFC5751]| body | smime-part | A reference to |active | 1 |
| | | | | the MIME body | | |
| | | | | part that | | |
| | | | | contains the | | |
| | | | | signature, as | | |
| | | | | defined in | | |
| | | | | Section 3.2.1 | | |
| | | | | of [RFC7281]. | | |
| | | | | | | |
| smime| [RFC5751]| body | smime- | The email |active | 1 |
| | | | identifier | address | | |
| | | | | [RFC5322] | | |
| | | | | associated | | |
| | | | | with the | | |
| | | | | S/MIME | | |
| | | | | signature. | | |
| | | | | The email | | |
| | | | | address can be | | |
| | | | | specified | | |
| | | | | explicitly or | | |
| | | | | derived from | | |
| | | | | the identity | | |
| | | | | of the signer. | | |
| | | | | Note that this | | |
| | | | | email address | | |
| | | | | can correspond | | |
| | | | | to a counter- | | |
| | | | | signature. | | |
| | | | | | | |
+------+----------+-------+------------+----------------+-------+------+
|Method| Defined | ptype | Property | Value |Status | Ver- |
| | in | | | | | sion |
+------+----------+-------+------------+----------------+-------+------+
| smime| [RFC5751]| body | smime-part | A reference to |active | 1 |
| | | | | the MIME body | | |
| | | | | part that | | |
| | | | | contains the | | |
| | | | | signature, as | | |
| | | | | defined in | | |
| | | | | Section 3.2.1 | | |
| | | | | of [RFC7281]. | | |
| | | | | | | |
| smime| [RFC5751]| body | smime- | The email |active | 1 |
| | | | identifier | address | | |
| | | | | [RFC5322] | | |
| | | | | associated | | |
| | | | | with the | | |
| | | | | S/MIME | | |
| | | | | signature. | | |
| | | | | The email | | |
| | | | | address can be | | |
| | | | | specified | | |
| | | | | explicitly or | | |
| | | | | derived from | | |
| | | | | the identity | | |
| | | | | of the signer. | | |
| | | | | Note that this | | |
| | | | | email address | | |
| | | | | can correspond | | |
| | | | | to a counter- | | |
| | | | | signature. | | |
| | | | | | | |
| smime| [RFC5751]| body | smime- | serialNumber |active | 1 |
| | | | serial | of the | | |
| | | | | certificate | | |
| | | | | associated | | |
| | | | | with the | | |
| | | | | S/MIME | | |
| | | | | signature (see | | |
| | | | | Section | | |
| | | | | 4.1.2.2 of | | |
| | | | | [RFC5280]. | | |
| | | | | | | |
| smime| [RFC5751]| body | smime- | Issuer name DN |active | 1 |
| | | | issuer | (e.g., "CN=CA1,| | |
| | | | | ST=BC,c=CA") | | |
| | | | | of the | | |
| | | | | certificate | | |
| | | | | associated | | |
| | | | | with the | | |
| | | | | S/MIME | | |
| | | | | signature (see | | |
| | | | | Section | | |
| | | | | 4.1.2.4 of | | |
| | | | | [RFC5280]. | | |
+------+----------+-------+------------+----------------+-------+------+
| smime| [RFC5751]| body | smime- | serialNumber |active | 1 |
| | | | serial | of the | | |
| | | | | certificate | | |
| | | | | associated | | |
| | | | | with the | | |
| | | | | S/MIME | | |
| | | | | signature (see | | |
| | | | | Section | | |
| | | | | 4.1.2.2 of | | |
| | | | | [RFC5280]. | | |
| | | | | | | |
| smime| [RFC5751]| body | smime- | Issuer name DN |active | 1 |
| | | | issuer | (e.g., "CN=CA1,| | |
| | | | | ST=BC,c=CA") | | |
| | | | | of the | | |
| | | | | certificate | | |
| | | | | associated | | |
| | | | | with the | | |
| | | | | S/MIME | | |
| | | | | signature (see | | |
| | | | | Section | | |
| | | | | 4.1.2.4 of | | |
| | | | | [RFC5280]. | | |
+------+----------+-------+------------+----------------+-------+------+
IANA has added the following entries to the "Email Authentication Result Names" sub-registry of the "Email Authentication Parameters" registry:
IANA已将以下条目添加到“电子邮件身份验证参数”注册表的“电子邮件身份验证结果名称”子注册表中：
+-----------+-----------+----------+-----------------------+--------+
| Code | Defined | Auth | Meaning | Status |
| | | Method | | |
+-----------+-----------+----------+-----------------------+--------+
| none | [RFC7281] | smime | [RFC7281] Section 3.1 | active |
| | | | | |
| pass | [RFC7281] | smime | [RFC7281] Section 3.1 | active |
| | | | | |
| fail | [RFC7281] | smime | [RFC7281] Section 3.1 | active |
| | | | | |
| policy | [RFC7281] | smime | [RFC7281] Section 3.1 | active |
| | | | | |
| neutral | [RFC7281] | smime | [RFC7281] Section 3.1 | active |
| | | | | |
| temperror | [RFC7281] | smime | [RFC7281] Section 3.1 | active |
| | | | | |
| permerror | [RFC7281] | smime | [RFC7281] Section 3.1 | active |
+-----------+-----------+----------+-----------------------+--------+
+-----------+-----------+----------+-----------------------+--------+
| Code | Defined | Auth | Meaning | Status |
| | | Method | | |
+-----------+-----------+----------+-----------------------+--------+
| none | [RFC7281] | smime | [RFC7281] Section 3.1 | active |
| | | | | |
| pass | [RFC7281] | smime | [RFC7281] Section 3.1 | active |
| | | | | |
| fail | [RFC7281] | smime | [RFC7281] Section 3.1 | active |
| | | | | |
| policy | [RFC7281] | smime | [RFC7281] Section 3.1 | active |
| | | | | |
| neutral | [RFC7281] | smime | [RFC7281] Section 3.1 | active |
| | | | | |
| temperror | [RFC7281] | smime | [RFC7281] Section 3.1 | active |
| | | | | |
| permerror | [RFC7281] | smime | [RFC7281] Section 3.1 | active |
+-----------+-----------+----------+-----------------------+--------+
This document doesn't add new security considerations not already covered by [RFC7001] and [RFC5751]. In particular, security considerations related to the use of weak cryptography over plaintext, weakening and breaking of cryptographic algorithms over time, and changing the behavior of message processing based on presence of a signature specified in [RFC5751] are relevant to this document. Similarly, the following security considerations specified in [RFC7001] are particularly relevant to this document: Forged Header Fields, Misleading Results, Internal Mail Transfer Agent (MTA) Lists, and Compromised Internal Hosts.
本文档不添加[RFC7001]和[RFC5751]中尚未涉及的新安全注意事项。特别是，与在明文上使用弱加密、随着时间的推移削弱和破坏加密算法以及基于[RFC5751]中规定的签名的存在改变消息处理行为相关的安全考虑与本文件相关。类似地，[RFC7001]中规定的以下安全注意事项与本文档特别相关：伪造的标题字段、误导性结果、内部邮件传输代理（MTA）列表和受损的内部主机。
To repeat something already mentioned in RFC 7001, Section 7.1:
重复RFC 7001第7.1节中已经提到的内容：
An MUA or filter that accesses a mailbox whose messages are handled by a non-conformant MTA, and understands Authentication-Results header fields, could potentially make false conclusions based on forged header fields. A malicious user or agent could forge a header field using the DNS domain of a receiving ADMD as the authserv-id token in the value of the header field and, with the rest of the value, claim that the message was properly authenticated. The non-conformant MTA would fail to strip the forged header field, and the MUA could inappropriately trust it.
如果MUA或筛选器访问其邮件由不符合MTA处理的邮箱，并了解身份验证结果标头字段，则可能基于伪造的标头字段得出错误结论。恶意用户或代理可以使用接收ADMD的DNS域作为头字段值中的authserv id令牌伪造头字段，并使用剩余值声明消息已正确验证。不一致的MTA将无法剥离伪造的标头字段，MUA可能会不适当地信任它。
For this reason, it is best not to have processing of the Authentication-Results header field enabled by default; instead, it should be ignored, at least for the purposes of enacting filtering decisions, unless specifically enabled by the user or administrator after verifying that the border MTA is compliant. It is acceptable to have an MUA aware of this specification but have an explicit list of hostnames whose Authentication-Results header fields are trustworthy; however, this list should initially be empty.
出于这个原因，最好不要在默认情况下启用身份验证结果头字段的处理；相反，应该忽略它，至少是为了制定过滤决策，除非用户或管理员在验证border MTA是否符合要求后特别启用。可以让MUA知道该规范，但有一个明确的主机名列表，其验证结果头字段是可信的；但是，此列表最初应为空。
So, to emphasize this point: whenever possible, MUAs should implement their own S/MIME signature verification instead of implementing this specification.
因此，为了强调这一点：只要有可能，MUA应该实现自己的S/MIME签名验证，而不是实现这个规范。
Note that agents adding Authentication-Results header fields containing S/MIME authentication method might be unable to verify S/MIME signatures inside encrypted CMS content types such as EnvelopedData [RFC5652]. So, agents processing Authentication-Results header fields can't treat the lack of an Authentication-Results header field with S/MIME authentication method as an indication that the corresponding S/MIME signature is missing, invalid, or valid.
请注意，添加包含S/MIME身份验证方法的身份验证结果标头字段的代理可能无法验证加密CMS内容类型（如EnvelopedData[RFC5652]）中的S/MIME签名。因此，处理身份验证结果头字段的代理不能将缺少S/MIME身份验证方法的身份验证结果头字段视为相应的S/MIME签名丢失、无效或有效的指示。
[RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, March 2003.
[RFC3501]Crispin，M.，“互联网消息访问协议-版本4rev1”，RFC 35012003年3月。
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234]Crocker，D.和P.Overell，“语法规范的扩充BNF:ABNF”，STD 68，RFC 5234，2008年1月。
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008.
[RFC5280]Cooper，D.，Santesson，S.，Farrell，S.，Boeyen，S.，Housley，R.，和W.Polk，“Internet X.509公钥基础设施证书和证书撤销列表（CRL）配置文件”，RFC 52802008年5月。
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, October 2008.
[RFC5322]Resnick，P.，Ed.“互联网信息格式”，RFC5222008年10月。
[RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification", RFC 5751, January 2010.
[RFC5751]Ramsdell，B.和S.Turner，“安全/多用途Internet邮件扩展（S/MIME）版本3.2消息规范”，RFC 57512010年1月。
[RFC7001] Kucherawy, M., "Message Header Field for Indicating Message Authentication Status", RFC 7001, September 2013.
[RFC7001]Kucherawy，M.，“用于指示消息身份验证状态的消息头字段”，RFC 70012013年9月。
[RFC3183] Dean, T. and W. Ottaway, "Domain Security Services using S/MIME", RFC 3183, October 2001.
[RFC3183]Dean，T.和W.Ottaway，“使用S/MIME的域安全服务”，RFC3183，2001年10月。
[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, RFC 5652, September 2009.
[RFC5652]Housley，R.，“加密消息语法（CMS）”，STD 70，RFC 56522009年9月。
Thank you to Murray S. Kucherawy, David Wilson, Jim Schaad, SM, and Steve Kille for comments and corrections on this document.
感谢Murray S.Kucherawy、David Wilson、Jim Schaad、SM和Steve Kille对本文档的评论和更正。
Author's Address
作者地址
Alexey Melnikov Isode Ltd 14 Castle Mews Hampton, Middlesex TW12 2NP United Kingdom
Alexey Melnikov Isode Ltd 14 Castle Mews Hampton，英国米德尔塞克斯TW12 2NP
EMail: Alexey.Melnikov@isode.com
EMail: Alexey.Melnikov@isode.com