Internet Engineering Task Force (IETF) M. Kucherawy
Request for Comments: 6008 Cloudmark, Inc.
Category: Standards Track September 2010
ISSN: 2070-1721
Internet Engineering Task Force (IETF) M. Kucherawy
Request for Comments: 6008 Cloudmark, Inc.
Category: Standards Track September 2010
ISSN: 2070-1721
Authentication-Results Registration for Differentiating among Cryptographic Results
用于区分加密结果的身份验证结果注册
Abstract
摘要
This memo updates the registry of properties in Authentication-Results: message header fields to allow a multiple-result report to distinguish among one or more cryptographic signatures on a message, thus associating specific results with the signatures they represent.
此备忘录更新“身份验证结果：消息头”字段中属性的注册表，以允许多结果报告区分消息上的一个或多个加密签名，从而将特定结果与其表示的签名相关联。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见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/rfc6008.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6008.
Copyright Notice
版权公告
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2010 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. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Keywords . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 2
4. Definition . . . . . . . . . . . . . . . . . . . . . . . . . . 3
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 4
6.1. Improvement . . . . . . . . . . . . . . . . . . . . . . . . 4
6.2. Result Forgeries . . . . . . . . . . . . . . . . . . . . . 4
6.3. New Schemes with Small Signatures . . . . . . . . . . . . . 4
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5
7.1. Normative References . . . . . . . . . . . . . . . . . . . 5
7.2. Informative References . . . . . . . . . . . . . . . . . . 5
Appendix A. Authentication-Results Example . . . . . . . . . . . . 6
A.1. Multiple DKIM Signatures with One Failure . . . . . . . . . 6
Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . . 7
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Keywords . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 2
4. Definition . . . . . . . . . . . . . . . . . . . . . . . . . . 3
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 4
6.1. Improvement . . . . . . . . . . . . . . . . . . . . . . . . 4
6.2. Result Forgeries . . . . . . . . . . . . . . . . . . . . . 4
6.3. New Schemes with Small Signatures . . . . . . . . . . . . . 4
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5
7.1. Normative References . . . . . . . . . . . . . . . . . . . 5
7.2. Informative References . . . . . . . . . . . . . . . . . . 5
Appendix A. Authentication-Results Example . . . . . . . . . . . . 6
A.1. Multiple DKIM Signatures with One Failure . . . . . . . . . 6
Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . . 7
[AUTHRES] defined a new header field for electronic mail messages that presents the results of a message authentication effort in a machine-readable format. Absent from that specification was the means by which the results of two cryptographic signatures, such as those provided by [DKIM], can both have results reported in an unambiguous manner.
[AUTHRES]为电子邮件定义了一个新的标题字段，该字段以机器可读的格式显示邮件身份验证工作的结果。该规范中缺少两个加密签名（如[DKIM]提供的签名）的结果可以以明确的方式报告的方法。
Fortunately, [AUTHRES] created IANA registries of reporting properties, enabling an easy remedy for this problem. This memo thus registers an additional reporting property allowing a result to be associated with a specific digital signature.
幸运的是，[AUTHRES]创建了报告属性的IANA注册中心，为解决这个问题提供了一个简单的方法。因此，此备忘录注册了一个附加的报告属性，允许结果与特定的数字签名相关联。
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 [KEYWORDS].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[关键词]中所述进行解释。
A message can contain multiple signatures of a common sender authentication mechanism, such as [DKIM]. For example, a DomainKeys Identified Mail (DKIM) signer could apply signatures using two or more different message canonicalization algorithms to determine the resistance of each to being broken in transit.
消息可以包含公共发送方身份验证机制（如[DKIM]）的多个签名。例如，域密钥识别邮件（DKIM）签名者可以使用两个或多个不同的消息规范化算法应用签名，以确定每个签名在传输过程中被破坏的阻力。
By applying supported "ptype.property" combinations (cf. the ABNF in [AUTHRES]), a result can be associated with a given signature provided the signatures are all unique within one of the registered values (e.g., all of them had unique "header.d" or "header.i" values). This is not guaranteed, however; a single signing agent might have practical reasons for affixing multiple signatures with the same "d=" values while varying other signature parameters. This means one could get a "dkim=pass" and "dkim=fail" result simultaneously on verification, which is clearly ambiguous.
通过应用支持的“ptype.property”组合（参见[AUTHRES]中的ABNF），可以将结果与给定的签名相关联，前提是签名在一个注册值内都是唯一的（例如，所有签名都具有唯一的“header.d”或“header.i”值）。然而，这并不能保证；单个签名代理可能有实际的理由使用相同的“d=”值附加多个签名，同时改变其他签名参数。这意味着在验证时可以同时得到“dkim=pass”和“dkim=fail”结果，这显然是不明确的。
It is thus necessary either to create or to identify a signature attribute guaranteed to be unique, such that it is possible to unambiguously associate a result with the signature to which it refers.
因此，有必要创建或标识保证唯一的签名属性，以便能够明确地将结果与其引用的签名相关联。
Collisions during general use of SHA1 and SHA256 are uncommon (see [HASH-ATTACKS]), and RSA key signing mechanisms are resilient to producing common substrings. Thus, the actual digital signature for a cryptographic signing of the message is an ideal property for such a unique identification. It is not, however, necessary to include the entire digital signature in an [AUTHRES] header field just to identify which result goes with which signature; since the signatures will almost always be substantially different, it is anticipated that only the first several bytes of a signature will be needed for disambiguating results.
在SHA1和SHA256的一般使用过程中发生冲突是不常见的（请参见[HASH-ATTACKS]），RSA密钥签名机制能够灵活地生成公共子字符串。因此，消息的加密签名的实际数字签名是这种唯一标识的理想属性。然而，不需要将整个数字签名包括在[AUTHRES]头字段中，仅仅为了识别哪个结果与哪个签名相匹配；由于签名几乎总是本质上不同的，因此预期仅需要签名的前几个字节来消除歧义结果。
This memo adds the "header.b" reporting item to the IANA "Email Authentication Methods" registry created upon publication of [AUTHRES]. The value associated with this item in the header field MUST be at least the first eight characters of the digital signature (the "b=" tag from a DKIM-Signature) for which a result is being relayed, and MUST be long enough to be unique among the results being reported. Where the total length of the digital signature is fewer than eight characters, the entire signature MUST be included. Matching of the value of this item against the signature itself MUST be case-sensitive.
此备忘录将“header.b”报告项添加到发布[AUTHRES]时创建的IANA“电子邮件验证方法”注册表中。标题字段中与此项关联的值必须至少是转发结果的数字签名（“b=”来自DKIM签名的标记）的前八个字符，并且必须足够长，以便在报告的结果中是唯一的。如果数字签名的总长度小于8个字符，则必须包含整个签名。此项的值与签名本身的匹配必须区分大小写。
If an evaluating agent observes that, despite the use of this disambiguating tag, unequal authentication results are offered about the same signature from the same trusted authserv-id, that agent SHOULD ignore all such results.
如果评估代理观察到，尽管使用了此消歧标记，但来自同一可信authserv id的同一签名提供了不等的身份验证结果，则该代理应忽略所有此类结果。
Per [IANA-CONSID], the following item is added to the "Email Authentication Methods" registry:
根据[IANA-CONSID]，将以下项目添加到“电子邮件身份验证方法”注册表中：
+------------+----------+--------+----------------+-----------------+
| Method | Defined | ptype | property | value |
+------------+----------+--------+----------------+-----------------+
| dkim | RFC4871 | header | b | full or partial |
| | | | | value of |
| | | | | signature "b" |
| | | | | tag |
+------------+----------+--------+----------------+-----------------+
+------------+----------+--------+----------------+-----------------+
| Method | Defined | ptype | property | value |
+------------+----------+--------+----------------+-----------------+
| dkim | RFC4871 | header | b | full or partial |
| | | | | value of |
| | | | | signature "b" |
| | | | | tag |
+------------+----------+--------+----------------+-----------------+
[AUTHRES] discussed general security considerations regarding the use of this header field. The following new security considerations apply when adding or processing this new ptype/property combination:
[AUTHRES]讨论了有关使用此标头字段的一般安全注意事项。添加或处理此新的ptype/属性组合时，以下新的安全注意事项适用：
Rather than introducing a new security issue, this can be seen to fix a security weakness of the original specification: Useful information can now be obtained from results that could previously have been ambiguous and thus obscured or, worse, misinterpreted.
这并没有引入新的安全问题，而是修复了原始规范的一个安全弱点：现在可以从以前可能模棱两可的结果中获得有用的信息，从而使结果变得模糊，甚至更糟糕，被误解。
An attacker could copy a valid signature and add it to a message in transit, modifying some portion of it. This could cause two results to be provided for the same "header.b" value even if the entire "b=" string is used in an attempt to differentiate the results. This attack could cause an ambiguous result to be relayed and possibly neutralize any benefit given to a "pass" result that would have otherwise occurred, possibly impacting the delivery of valid messages.
攻击者可以复制有效签名并将其添加到传输中的消息中，从而修改其中的某些部分。这可能会导致为同一“header.b”值提供两个结果，即使在尝试区分结果时使用了整个“b=”字符串。此攻击可能导致转送不明确的结果，并可能抵消“通过”结果的任何好处，否则可能会发生，可能会影响有效消息的传递。
It is worth noting, however, that a false negative ("fail") can be generated in this way, but it is extremely difficult to create a false positive ("pass") through such an attack. Thus, a cautious implementation could discard the false negative in that instance.
然而，值得注意的是，可以通过这种方式生成假阴性（“失败”），但通过这种攻击创建假阳性（“通过”）是极其困难的。因此，在这种情况下，谨慎的实现可以消除假阴性。
Should a new signing scheme be introduced with a signature whose length is less than eight characters, Section 4 specifies that the entire signature must be used. The obvious concern in such a case
如果引入的新签名方案的签名长度小于8个字符，则第4节规定必须使用整个签名。在这种情况下，显而易见的担忧
would be that the signature scheme is itself prone to collisions, making the value reported by this field not useful. In such cases, the risk is created by the likelihood of collisions and not by this mechanism; furthermore, Section 4 recommends the results be ignored if that were to occur, preventing the application of an ambiguous result.
可能是签名方案本身容易发生冲突，使得此字段报告的值无效。在这种情况下，风险是由碰撞的可能性造成的，而不是由这种机制造成的；此外，第4节建议，如果出现这种情况，应忽略结果，以防止应用不明确的结果。
[AUTHRES] Kucherawy, M., "Message Header Field for Indicating Message Authentication Status", RFC 5451, April 2009.
[AUTHRES]Kucherawy，M.，“用于指示消息身份验证状态的消息头字段”，RFC 54512009年4月。
[DKIM] Allman, E., Callas, J., Delany, M., Libbey, M., Fenton, J., and M. Thomas, "DomainKeys Identified Mail (DKIM) Signatures", RFC 4871, May 2007.
[DKIM]Allman，E.，Callas，J.，Delany，M.，Libbey，M.，Fenton，J.，和M.Thomas，“域密钥识别邮件（DKIM）签名”，RFC 48712007年5月。
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[关键词]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[HASH-ATTACKS] Hoffman, P. and B. Schneier, "Attacks on Cryptographic Hashes in Internet Protocols", RFC 4270, November 2005.
[散列攻击]Hoffman，P.和B.Schneier，“对互联网协议中加密散列的攻击”，RFC 42702005年11月。
[IANA-CONSID] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[IANA-CONSID]Narten，T.和H.Alvestrand，“在RFC中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，2008年5月。
This section presents an example of the use of this new item header field to indicate unambiguous authentication results.
本节给出了使用此新项目标题字段来指示明确身份验证结果的示例。
A message that had two DKIM signatures applied by the same domain, one of which failed:
具有由同一域应用的两个DKIM签名的消息，其中一个签名失败：
Authentication-Results: mail-router.example.net;
dkim=pass (good signature) header.d=newyork.example.com
header.b=oINEO8hg;
dkim=fail (bad signature) header.d=newyork.example.com
header.b=EToRSuvU
Received: from newyork.example.com
(newyork.example.com [192.0.2.250])
by mail-router.example.net (8.11.6/8.11.6)
for <recipient@example.net>
with ESMTP id i7PK0sH7021929;
Fri, Feb 15 2002 17:19:22 -0800
DKIM-Signature: v=1; a=rsa-sha256; s=rashani;
d=newyork.example.com;
t=1188964191; c=relaxed/simple;
h=From:Date:To:Message-Id:Subject;
bh=sEu28nfs9fuZGD/pSr7ANysbY3jtdaQ3Xv9xPQtS0m7=;
b=oINEO8hgn/gnunsg ... 9n9ODSNFSDij3=
DKIM-Signature: v=1; a=rsa-sha256; s=rashani;
d=newyork.example.com;
t=1188964191; c=simple/simple;
h=From:Date:To:Message-Id:Subject;
bh=sEu28nfs9fuZGD/pSr7ANysbY3jtdaQ3Xv9xPQtS0m7=;
b=EToRSuvUfQVP3Bkz ... rTB0t0gYnBVCM=
From: sender@newyork.example.com
Date: Fri, Feb 15 2002 16:54:30 -0800
To: meetings@example.net
Message-Id: <12345.abc@newyork.example.com>
Subject: here's a sample
Authentication-Results: mail-router.example.net;
dkim=pass (good signature) header.d=newyork.example.com
header.b=oINEO8hg;
dkim=fail (bad signature) header.d=newyork.example.com
header.b=EToRSuvU
Received: from newyork.example.com
(newyork.example.com [192.0.2.250])
by mail-router.example.net (8.11.6/8.11.6)
for <recipient@example.net>
with ESMTP id i7PK0sH7021929;
Fri, Feb 15 2002 17:19:22 -0800
DKIM-Signature: v=1; a=rsa-sha256; s=rashani;
d=newyork.example.com;
t=1188964191; c=relaxed/simple;
h=From:Date:To:Message-Id:Subject;
bh=sEu28nfs9fuZGD/pSr7ANysbY3jtdaQ3Xv9xPQtS0m7=;
b=oINEO8hgn/gnunsg ... 9n9ODSNFSDij3=
DKIM-Signature: v=1; a=rsa-sha256; s=rashani;
d=newyork.example.com;
t=1188964191; c=simple/simple;
h=From:Date:To:Message-Id:Subject;
bh=sEu28nfs9fuZGD/pSr7ANysbY3jtdaQ3Xv9xPQtS0m7=;
b=EToRSuvUfQVP3Bkz ... rTB0t0gYnBVCM=
From: sender@newyork.example.com
Date: Fri, Feb 15 2002 16:54:30 -0800
To: meetings@example.net
Message-Id: <12345.abc@newyork.example.com>
Subject: here's a sample
Example 1: Header field reporting results from multiple signatures added at initial signing
示例1：头字段报告初始签名时添加的多个签名的结果
Here we see an example of a message that was signed twice by the author's ADministrative Management Domain (ADMD). One signature used "relaxed" header canonicalization, and the other used "simple" header canonicalization; both used "simple" body canonicalization.
这里我们看到一个由作者的管理域（ADMD）签署两次的消息示例。一个签名使用“宽松”标题规范化，另一个使用“简单”标题规范化；两者都使用“简单”的身体规范化。
Presumably due to a change in one of the five header fields covered by the two signatures, the former signature passed, while the latter signature failed to verify. In particular, the "relaxed" header canonicalization of [DKIM] is resilient to changes in whitespace in the header, while "simple" is not, and the latter is the one that failed in this example.
可能是由于两个签名所覆盖的五个标题字段中的一个发生了变化，前一个签名通过了，而后一个签名无法验证。特别是，[DKIM]的“宽松”头规范化能够适应头中空格的变化，而“简单”则不然，后者在本例中失败了。
The item registered by this memo allows an evaluation module to determine which DKIM result goes with which signature. Without the "header.b" portion of the result, it is unclear which one passed and which one failed.
此备忘录注册的项目允许评估模块确定哪个DKIM结果与哪个签名相符。如果没有结果的“header.b”部分，就不清楚哪个通过了，哪个失败了。
The author wishes to acknowledge the following for their review and constructive criticism of this proposal: Dave Crocker, Tony Hansen, Eliot Lear, S. Moonesamy, and Alessandro Vesely.
作者希望感谢以下各方对该提案的评论和建设性批评：戴夫·克罗克、托尼·汉森、艾略特·李尔、S.穆内萨米和亚历山德罗·维斯利。
Author's Address
作者地址
Murray S. Kucherawy Cloudmark, Inc. 128 King St., 2nd Floor San Francisco, CA 94107 US
MurayS.KuCaWaWy CuldMax公司，128国王圣，第二楼旧金山，CA 94107美国
Phone: +1 415 946 3800
EMail: msk@cloudmark.com
Phone: +1 415 946 3800
EMail: msk@cloudmark.com