Internet Engineering Task Force (IETF) P. Hoffman
Request for Comments: 8162 ICANN
Category: Experimental J. Schlyter
ISSN: 2070-1721 Kirei AB
May 2017
Internet Engineering Task Force (IETF) P. Hoffman
Request for Comments: 8162 ICANN
Category: Experimental J. Schlyter
ISSN: 2070-1721 Kirei AB
May 2017
Using Secure DNS to Associate Certificates with Domain Names for S/MIME
使用安全DNS将证书与S/MIME的域名关联
Abstract
摘要
This document describes how to use secure DNS to associate an S/MIME user's certificate with the intended domain name, similar to the way that DNS-Based Authentication of Named Entities (DANE), RFC 6698, does for TLS.
本文档描述了如何使用安全DNS将S/MIME用户的证书与预期域名相关联，类似于基于DNS的命名实体身份验证（DANE）RFC 6698对TLS的方式。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
本文件不是互联网标准跟踪规范；它是为检查、实验实施和评估而发布的。
This document defines an Experimental Protocol for the Internet community. 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). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 7841.
本文档为互联网社区定义了一个实验协议。本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 7841第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/rfc8162.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc8162.
Copyright Notice
版权公告
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2017 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
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Experiment Goal . . . . . . . . . . . . . . . . . . . . . 3
2. The SMIMEA Resource Record . . . . . . . . . . . . . . . . . 4
3. Location of the SMIMEA Record . . . . . . . . . . . . . . . . 4
4. Email Address Variants and Internationalization
Considerations . . . . . . . . . . . . . . . . . . . . . . . 5
5. Mandatory-to-Implement Features . . . . . . . . . . . . . . . 6
6. Application Use of S/MIME Certificate Associations . . . . . 6
7. Certificate Size and DNS . . . . . . . . . . . . . . . . . . 7
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
9. Security Considerations . . . . . . . . . . . . . . . . . . . 7
9.1. Response Size . . . . . . . . . . . . . . . . . . . . . . 8
9.2. Email Address Information Leak . . . . . . . . . . . . . 8
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
10.1. Normative References . . . . . . . . . . . . . . . . . . 9
10.2. Informative References . . . . . . . . . . . . . . . . . 10
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Experiment Goal . . . . . . . . . . . . . . . . . . . . . 3
2. The SMIMEA Resource Record . . . . . . . . . . . . . . . . . 4
3. Location of the SMIMEA Record . . . . . . . . . . . . . . . . 4
4. Email Address Variants and Internationalization
Considerations . . . . . . . . . . . . . . . . . . . . . . . 5
5. Mandatory-to-Implement Features . . . . . . . . . . . . . . . 6
6. Application Use of S/MIME Certificate Associations . . . . . 6
7. Certificate Size and DNS . . . . . . . . . . . . . . . . . . 7
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
9. Security Considerations . . . . . . . . . . . . . . . . . . . 7
9.1. Response Size . . . . . . . . . . . . . . . . . . . . . . 8
9.2. Email Address Information Leak . . . . . . . . . . . . . 8
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
10.1. Normative References . . . . . . . . . . . . . . . . . . 9
10.2. Informative References . . . . . . . . . . . . . . . . . 10
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
S/MIME [RFC5751] messages often contain a certificate (some messages contain more than one certificate). These certificates assist in authenticating the sender of the message and can be used for encrypting messages that will be sent in reply. In order for the S/MIME receiver to authenticate that a message is from the sender identified in the message, the receiver's Mail User Agent (MUA) must validate that this certificate is associated with the purported sender. Currently, the MUA must trust a trust anchor upon which the sender's certificate is rooted and must successfully validate the certificate. There are other requirements on the MUA, such as associating the identity in the certificate with that of the message, that are out of scope for this document.
S/MIME[RFC5751]消息通常包含一个证书（有些消息包含多个证书）。这些证书有助于验证邮件的发件人，并可用于加密将作为回复发送的邮件。为了让S/MIME接收方验证消息是否来自消息中标识的发送方，接收方的邮件用户代理（MUA）必须验证此证书是否与声称的发送方关联。目前，MUA必须信任发送方证书所基于的信任锚，并且必须成功验证证书。MUA上还有其他要求，例如将证书中的标识与消息中的标识相关联，这些要求超出了本文档的范围。
Some people want to authenticate the association of the sender's certificate with the sender without trusting a configured trust anchor. Others to want mitigate the difficulty of finding certificates from outside the enterprise. Given that the DNS administrator for a domain name is authorized to give identifying information about the zone, it makes sense to allow that administrator to also make an authoritative binding between email messages purporting to come from the domain name and a certificate that might be used by someone authorized to send mail from those servers. The easiest way to do this is to use the DNS.
有些人希望在不信任已配置的信任锚的情况下验证发送方证书与发送方的关联。其他人希望减轻从企业外部查找证书的困难。鉴于域名的DNS管理员有权提供有关该区域的标识信息，允许该管理员在声称来自该域名的电子邮件和授权从这些服务器发送邮件的人可能使用的证书之间进行权威绑定是有意义的。最简单的方法是使用DNS。
This document describes a mechanism for associating a user's certificate with the domain that is similar to that described in DANE itself [RFC6698], as updated by [RFC7218] and [RFC7671]; it is also similar to the mechanism given in [RFC7929] for OpenPGP. Most of the operational and security considerations for using the mechanism in this document are described in RFC 6698 and are not described here at all. Only the major differences between this mechanism and those used in RFC 6698 are described here. Thus, the reader must be familiar with RFC 6698 before reading this document.
本文档描述了一种将用户证书与域关联的机制，该机制类似于由[RFC7218]和[RFC7671]更新的DANE自身[RFC6698]中描述的机制；它也类似于[RFC7929]中针对OpenPGP给出的机制。RFC 6698中描述了本文档中使用该机制的大多数操作和安全注意事项，此处完全不作描述。这里只描述了该机制与RFC 6698中使用的机制之间的主要区别。因此，读者在阅读本文件之前必须熟悉RFC 6698。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”在所有大写字母出现时（如图所示）应按照BCP 14[RFC2119][RFC8174]所述进行解释。
This document also makes use of standard PKIX, DNSSEC, and S/MIME terminology. See PKIX [RFC5280], DNSSEC [RFC4033] [RFC4034] [RFC4035], and S/MIME [RFC5751] for these terms.
本文档还使用了标准PKIX、DNSSEC和S/MIME术语。有关这些条款，请参见PKIX[RFC5280]、DNSSEC[RFC4033][RFC4034][RFC4035]和S/MIME[RFC5751]。
This specification is one experiment in improving access to public keys for end-to-end email security. There are a range of ways in which this can reasonably be done for OpenPGP or S/MIME, for example, using the DNS, SMTP, or HTTP. Proposals for each of these have been made with various levels of support in terms of implementation and deployment. For each such experiment, specifications such as this will enable experiments to be carried out that may succeed or that may uncover technical or other impediments to large- or small-scale deployments. The IETF encourages those implementing and deploying such experiments to publicly document their experiences so that future specifications in this space can benefit.
本规范是一项旨在提高端到端电子邮件安全性的公钥访问能力的实验。对于OpenPGP或S/MIME，有一系列合理的方法可以做到这一点，例如，使用DNS、SMTP或HTTP。在执行和部署方面，每一项建议都得到了各级支持。对于每一个这样的实验，像这样的规范将使实验能够成功进行，或者可能发现技术或其他阻碍大规模或小型部署的障碍。IETF鼓励那些实施和部署此类实验的人公开记录他们的经验，以便该领域的未来规范能够受益。
This document defines an RRtype whose use is Experimental. The goal of the experiment is to see whether encrypted email usage will increase if an automated discovery method is available to Mail Transfer Agents (MTAs) and if MUAs help the end user with email encryption key management.
本文档定义了一个RRtype，其用途是实验性的。实验的目标是，如果邮件传输代理（MTA）可以使用自动发现方法，并且MUA可以帮助最终用户管理电子邮件加密密钥，那么加密电子邮件的使用是否会增加。
It is unclear if this RRtype will scale to some of the larger email service deployments. Concerns have been raised about the size of the SMIMEA record and the size of the resulting DNS zone files. This experiment hopefully will give the IETF some insight into whether or not this is a problem.
目前尚不清楚这种RRtype是否会扩展到一些较大的电子邮件服务部署中。有人对SMIMEA记录的大小和生成的DNS区域文件的大小表示担忧。这个实验有望让IETF了解这是否是一个问题。
If the experiment is successful, it is expected that the findings of the experiment will result in an updated document for Standards Track approval.
如果试验成功，预计试验结果将产生一份更新的文件，供标准跟踪批准。
The SMIMEA DNS resource record (RR) is used to associate an end entity certificate or public key with the associated email address, thus forming a "SMIMEA certificate association". The semantics of how the SMIMEA resource record is interpreted are given later in this document. Note that the information returned in the SMIMEA record might be for the end entity certificate, or it might be for the trust anchor or an intermediate certificate. This mechanism is similar to the one given in [RFC7929] for OpenPGP.
SMIMEA DNS资源记录（RR）用于将终端实体证书或公钥与关联的电子邮件地址关联，从而形成“SMIMEA证书关联”。本文后面将给出如何解释SMIMEA资源记录的语义。请注意，SMIMEA记录中返回的信息可能是针对最终实体证书的，也可能是针对信任锚或中间证书的。该机制类似于[RFC7929]中针对OpenPGP给出的机制。
The type value for the SMIMEA RRtype is defined in Section 8. The SMIMEA resource record is class independent.
第8节定义了SMIMEA RRtype的类型值。SMIMEA资源记录与类无关。
The SMIMEA wire format and presentation format are the same as for the TLSA record as described in Section 2.1 of [RFC6698]. The certificate usage field, the selector field, and the matching type field have the same format; the semantics are also the same except where RFC 6698 talks about TLS as the target protocol for the certificate information.
SMIMEA导线格式和表示格式与[RFC6698]第2.1节中描述的TLSA记录相同。证书使用字段、选择器字段和匹配类型字段的格式相同；语义也相同，除了RFC6698将TLS作为证书信息的目标协议。
The DNS does not allow the use of all characters that are supported in the "local-part" of email addresses as defined in [RFC5322] and [RFC6530]. Therefore, email addresses are mapped into DNS using the following method:
DNS不允许使用[RFC5322]和[RFC6530]中定义的电子邮件地址“本地部分”中支持的所有字符。因此，使用以下方法将电子邮件地址映射到DNS：
1. The "left-hand side" of the email address, called the "local-part" in both the mail message format definition [RFC5322] and in the specification for internationalized email [RFC6530]) is encoded in UTF-8 (or its subset ASCII). If the local-part is written in another charset, it MUST be converted to UTF-8.
1. 电子邮件地址的“左侧”，在邮件消息格式定义[RFC5322]和国际化电子邮件规范[RFC6530]中都称为“本地部分”，用UTF-8（或其子集ASCII）编码。如果本地部分写入另一个字符集，则必须将其转换为UTF-8。
2. The local-part is first canonicalized using the following rules. If the local-part is unquoted, any comments and/or folding whitespace (CFWS) around dots (".") is removed. Any enclosing double quotes are removed. Any literal quoting is removed.
2. 首先使用以下规则规范化本地部分。如果本地部分没有引号，则删除点（“.”）周围的任何注释和/或折叠空格（CFW）。所有包含的双引号都将被删除。删除任何文字引用。
3. If the local-part contains any non-ASCII characters, it SHOULD be normalized using the Unicode Normalization Form C from [UNICODE]. Recommended normalization rules can be found in Section 10.1 of [RFC6530].
3. 如果本地部分包含任何非ASCII字符，则应使用[Unicode]中的Unicode规范化表单C对其进行规范化。建议的规范化规则见[RFC6530]第10.1节。
4. The local-part is hashed using the SHA2-256 [RFC5754] algorithm, with the hash truncated to 28 octets and represented in its hexadecimal representation, to become the left-most label in the prepared domain name.
4. 使用SHA2-256[RFC5754]算法对本地部分进行散列，散列被截断为28个八位字节，并以十六进制表示，成为准备好的域名中最左边的标签。
5. The string "_smimecert" becomes the second left-most label in the prepared domain name.
5. 字符串“\u smimecert”成为准备好的域名中第二个最左边的标签。
6. The domain name (the "right-hand side" of the email address, called the "domain" in [RFC5322]) is appended to the result of step 5 to complete the prepared domain name.
6. 将域名（电子邮件地址的“右侧”，在[RFC5322]中称为“域”）附加到步骤5的结果中，以完成准备好的域名。
For example, to request an SMIMEA resource record for a user whose email address is "hugh@example.com", an SMIMEA query would be placed for the following QNAME: "c93f1e400f26708f98cb19d936620da35eec8f72e57 f9eec01c1afd6._smimecert.example.com".
例如，为电子邮件地址为“”的用户请求SMIMEA资源记录hugh@example.com，将为以下QNAME放置SMIMEA查询：“c93f1e400f26708f98cb19d936620da35eec8f72e57 f9eec01c1afd6._smimecert.example.com”。
Mail systems usually handle variant forms of local-parts. The most common variants are upper and lower case, often automatically corrected when a name is recognized as such. Other variants include systems that ignore "noise" characters such as dots, so that local-parts 'johnsmith' and 'John.Smith' would be equivalent. Many systems allow "extensions" such as 'john-ext' or 'mary+ext' where 'john' or 'mary' is treated as the effective local-part, and the 'ext' is passed to the recipient for further handling. This can complicate finding the SMIMEA record associated with the dynamically created email address.
邮件系统通常处理本地部件的各种形式。最常见的变体是大写和小写，通常在识别名称时自动更正。其他变体包括忽略“噪声”字符（如点）的系统，因此本地部分“johnsmith”和“John.Smith”是等效的。许多系统允许“扩展”，如“john ext”或“mary+ext”，其中“john”或“mary”被视为有效的本地部分，“ext”被传递给接收者进行进一步处理。这会使查找与动态创建的电子邮件地址关联的SMIMEA记录变得复杂。
[RFC5321] and its predecessors have always made it clear that only the recipient MTA is allowed to interpret the local-part of an address. Therefore, sending MUAs and MTAs supporting this specification MUST NOT perform any kind of mapping rules based on the email address. In order to improve the chances of finding SMIMEA resource records for a particular local-part, domains that allow variant forms (such as treating local-parts as case-insensitive) might publish SMIMEA resource records for all variants of local-parts, might publish variants on first use (for example, a webmail provider that also controls DNS for a domain can publish variants as used by owner of a particular local-part), or might just publish SMIMEA resource records for the most common variants.
[RFC5321]及其前身一直明确指出，只有收件人MTA才可以解释地址的本地部分。因此，发送支持此规范的MUA和MTA时，不得基于电子邮件地址执行任何类型的映射规则。为了提高查找特定本地零件的SMIMEA资源记录的机会，允许变体形式的域（例如，将本地零件视为不区分大小写）可能会发布本地零件所有变体的SMIMEA资源记录，可能会在首次使用时发布变体（例如，还控制域DNS的Web邮件提供商可以发布特定本地部件所有者使用的变体），或者可能只发布最常见变体的SMIMEA资源记录。
Section 3 above defines how the local-part is used to determine the location in which one looks for an SMIMEA resource record. Given the variety of local-parts seen in email, designing a good experiment for this is difficult as a) some current implementations are known to lowercase at least US-ASCII local-parts, b) we know from (many) other
上面的第3节定义了如何使用本地部分来确定查找SMIMEA资源记录的位置。考虑到电子邮件中看到的本地部分的多样性，为此设计一个好的实验是很困难的，因为a）一些当前的实现至少是小写的US-ASCII本地部分，b）我们从（许多）其他地方知道
situations that any strategy based on guessing and making multiple DNS queries is not going to achieve consensus for good reasons, and c) the underlying issues are just hard -- see Section 10.1 of [RFC6530] for discussion of just some of the issues that would need to be tackled to fully address this problem.
任何基于猜测和进行多个DNS查询的策略都无法达成一致意见的情况有很好的理由，并且c）根本问题很难解决——请参阅[RFC6530]第10.1节，了解为完全解决此问题而需要解决的一些问题的讨论。
However, while this specification is not the place to try to address these issues with local-parts, doing so is also not required to determine the outcome of this experiment. If this experiment succeeds, then further work on email addresses with non-ASCII local-parts will be needed, and that would be better based on the findings from this experiment, rather than doing nothing or starting this experiment based on a speculative approach to what is a very complex topic.
然而，虽然本规范不是试图解决本地部件的这些问题的地方，但也不需要这样做来确定本实验的结果。如果这项实验成功，那么就需要对带有非ASCII本地部分的电子邮件地址进行进一步的研究，而这将更好地基于这项实验的发现，而不是什么都不做，或者基于对一个非常复杂的主题的推测性方法开始这项实验。
S/MIME MUAs conforming to this specification MUST be able to correctly interpret SMIMEA records with certificate usages 0, 1, 2, and 3. S/MIME MUAs conforming to this specification MUST be able to compare a certificate association with a certificate offered by another S/MIME MUA using selector types 0 and 1, and matching type 0 (no hash used) and matching type 1 (SHA-256), and SHOULD be able to make such comparisons with matching type 2 (SHA-512).
符合本规范的S/MIME MUA必须能够正确解释具有证书用法0、1、2和3的SMIMEA记录。符合本规范的S/MIME MUA必须能够使用选择器类型0和1、匹配类型0（未使用哈希）和匹配类型1（SHA-256）将证书关联与另一个S/MIME MUA提供的证书进行比较，并且应该能够与匹配类型2（SHA-512）进行此类比较。
S/MIME MUAs conforming to this specification MUST be able to interpret any S/MIME capabilities (defined in [RFC4262]) in any certificates that it receives through SMIMEA records.
符合本规范的S/MIME MUA必须能够解释其通过SMIMEA记录接收的任何证书中的任何S/MIME功能（在[RFC4262]中定义）。
The SMIMEA record allows an application or service to obtain an S/MIME certificate or public key and use it for verifying a digital signature or encrypting a message to the public key. The DNS answer MUST pass DNSSEC validation; if DNSSEC validation reaches any state other than "Secure" (as specified in [RFC4035]), the DNSSEC validation MUST be treated as a failure.
SMIMEA记录允许应用程序或服务获取S/MIME证书或公钥，并将其用于验证数字签名或将消息加密到公钥。DNS应答必须通过DNSSEC验证；如果DNSSEC验证达到除“安全”（如[RFC4035]中规定）以外的任何状态，则必须将DNSSEC验证视为失败。
If no S/MIME certificates are known for an email address, an SMIMEA DNS lookup MAY be performed to seek the certificate or public key that corresponds to that email address. This can then be used to verify a received signed message or can be used to send out an encrypted email message. An application whose attempt fails to retrieve a DNSSEC-verified SMIMEA resource record from the DNS should remember that failed attempt and not retry it for some time. This will avoid sending out a DNS request for each email message the application is sending out; such DNS requests constitute a privacy leak.
如果电子邮件地址没有已知的S/MIME证书，则可以执行SMIMEA DNS查找以查找对应于该电子邮件地址的证书或公钥。然后，这可以用于验证收到的签名邮件，也可以用于发送加密的电子邮件。尝试从DNS检索DNSSEC验证的SMIMEA资源记录失败的应用程序应记住该失败的尝试，并且在一段时间内不要重试。这将避免为应用程序发送的每个电子邮件发送DNS请求；此类DNS请求构成隐私泄露。
Due to the expected size of the SMIMEA record, applications SHOULD use TCP -- not UDP -- to perform queries for the SMIMEA resource record.
由于SMIMEA记录的预期大小，应用程序应该使用TCP（而不是UDP）来执行对SMIMEA资源记录的查询。
Although the reliability of the transport of large DNS resource records has improved in the last years, it is still recommended to keep the DNS records as small as possible without sacrificing the security properties of the public key. The algorithm type and key size of certificates should not be modified to accommodate this section.
尽管大型DNS资源记录传输的可靠性在过去几年中有所提高，但仍建议在不牺牲公钥安全属性的情况下尽可能保持DNS记录的小。不应修改证书的算法类型和密钥大小以适应此部分。
This document uses a new DNS RRtype, SMIMEA, whose value (53) was allocated by IANA from the "Resource Record (RR) TYPEs" subregistry of the "Domain Name System (DNS) Parameters" registry.
本文档使用新的DNS RRtype SMIMEA，其值（53）由IANA从“域名系统（DNS）参数”注册表的“资源记录（RR）类型”子区分配。
Client treatment of any information included in the trust anchor is a matter of local policy. This specification does not mandate that such information be inspected or validated by the domain name administrator.
客户对信托锚中包含的任何信息的处理是当地政策的问题。本规范不要求域名管理员检查或验证此类信息。
DNSSEC does not protect the queries from pervasive monitoring as defined in [RFC7258]. Since DNS queries are currently mostly unencrypted, a query to look up a target SMIMEA record could reveal that a user using the (monitored) recursive DNS server is attempting to send encrypted email to a target.
DNSSEC不保护查询免受[RFC7258]中定义的普遍监控。由于DNS查询目前大多未加密，因此查询目标SMIMEA记录可能会发现使用（受监控的）递归DNS服务器的用户正试图向目标发送加密电子邮件。
Various components could be responsible for encrypting an email message to a target recipient. It could be done by the sender's MUA, an MUA plugin, or the sender's MTA. Each of these have their own characteristics. An MUA can ask the user to make a decision before continuing. The MUA can either accept or refuse a message. The MTA might deliver the message as is or encrypt the message before delivering. Each of these components should attempt to encrypt an unencrypted outgoing message whenever possible.
各种组件可能负责加密发送给目标收件人的电子邮件。它可以由发送方的MUA、MUA插件或发送方的MTA完成。每一种都有自己的特点。MUA可以要求用户在继续之前做出决定。MUA可以接受或拒绝消息。MTA可以按原样传递邮件，也可以在传递前对邮件进行加密。只要可能，这些组件中的每一个都应该尝试加密未加密的传出消息。
In theory, two different local-parts could hash to the same value. This document assumes that such a hash collision has a negligible chance of happening.
理论上，两个不同的局部部分可以散列为相同的值。本文档假设这种哈希冲突发生的可能性很小。
If an obtained S/MIME certificate is revoked or expired, that certificate MUST NOT be used, even if that would result in sending a message in plaintext.
如果获得的S/MIME证书被吊销或过期，则不得使用该证书，即使这会导致以明文形式发送消息。
Anyone who can obtain a DNSSEC private key of a domain name via coercion, theft, or brute-force calculations can replace any SMIMEA record in that zone and all of the delegated child zones. Any future messages encrypted with the malicious SMIMEA key could then be read. Therefore, a certificate or key obtained from a DNSSEC-validated SMIMEA record can only be trusted as much as the DNS domain can be trusted.
任何可以通过强制、盗窃或暴力计算获得域名DNSSEC私钥的人都可以替换该区域和所有委托子区域中的任何SMIMEA记录。随后，任何使用恶意SMIMEA密钥加密的未来消息都可能被读取。因此，从DNSSEC验证的SMIMEA记录中获得的证书或密钥只能像DNS域一样受信任。
Organizations that are required to be able to read everyone's encrypted email should publish the escrow key as the SMIMEA record. Mail servers of such organizations MAY optionally re-encrypt the message to the individual's S/MIME key. This case can be considered a special case of the key-replacement attack described above.
要求能够阅读每个人的加密电子邮件的组织应将托管密钥发布为SMIMEA记录。此类组织的邮件服务器可以选择性地将邮件重新加密到个人的s/MIME密钥。这种情况可视为上述密钥替换攻击的特殊情况。
To prevent amplification attacks, an Authoritative DNS server MAY wish to prevent returning SMIMEA records over UDP unless the source IP address has been confirmed with DNS Cookies [RFC7873]. If a query is received via UDP without source IP address verification, the server MUST NOT return REFUSED but answer the query with an empty answer section and the truncation flag set ("TC=1").
为了防止放大攻击，权威DNS服务器可能希望防止通过UDP返回SMIMEA记录，除非已使用DNS cookie确认源IP地址[RFC7873]。如果通过UDP接收查询而未进行源IP地址验证，则服务器不得返回拒绝，而是使用空的应答部分和设置的截断标志（“TC=1”）来应答查询。
The hashing of the local-part in this document is not a security feature. Publishing SMIMEA records will create a list of hashes of valid email addresses, which could simplify obtaining a list of valid email addresses for a particular domain. It is desirable to not ease the harvesting of email addresses where possible.
本文档中本地部分的哈希不是安全特性。发布SMIMEA记录将创建有效电子邮件地址的哈希列表，这可以简化获取特定域的有效电子邮件地址列表的过程。在可能的情况下，最好不要轻易获取电子邮件地址。
The domain name part of the email address is not used as part of the hash so that hashes can be used in multiple zones deployed using DNAME [RFC6672]. This makes it slightly easier and cheaper to brute-force the SHA2-256 hashes into common and short local-parts, as single rainbow tables [Rainbow] can be reused across domains. This can be somewhat countered by using NSEC3 [RFC5155].
电子邮件地址的域名部分不用作哈希的一部分，因此可以在使用DNAME[RFC6672]部署的多个区域中使用哈希。这使得将SHA2-256哈希强制转换为公共和简短的本地部分变得更加容易和便宜，因为单个彩虹表[rainbow]可以跨域重用。这可以通过使用NSEC3[RFC5155]在某种程度上克服。
DNS zones that are signed with DNSSEC using NSEC [RFC4033] for denial of existence are susceptible to zone walking, a mechanism that allows someone to enumerate all the SMIMEA hashes in a zone. This can be used in combination with previously hashed common or short local-parts (in rainbow tables) to deduce valid email addresses. DNSSEC-signed zones using NSEC3 for denial of existence instead of NSEC are significantly harder to brute-force after performing a zone walk.
使用NSEC[RFC4033]为拒绝存在而与DNSSEC签署的DNS区域易受区域漫游的影响，该机制允许某人枚举区域中的所有SMIMEA哈希。这可以与之前散列的公共或短本地部分（在rainbow表中）结合使用，以推断有效的电子邮件地址。在执行区域漫游后，使用NSEC3而不是NSEC进行拒绝存在的DNSSEC签名区域更难进行暴力攻击。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, DOI 10.17487/RFC4033, March 2005, <http://www.rfc-editor.org/info/rfc4033>.
[RFC4033]Arends，R.，Austein，R.，Larson，M.，Massey，D.，和S.Rose，“DNS安全介绍和要求”，RFC 4033，DOI 10.17487/RFC4033，2005年3月<http://www.rfc-editor.org/info/rfc4033>.
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, DOI 10.17487/RFC4034, March 2005, <http://www.rfc-editor.org/info/rfc4034>.
[RFC4034]Arends，R.，Austein，R.，Larson，M.，Massey，D.，和S.Rose，“DNS安全扩展的资源记录”，RFC 4034，DOI 10.17487/RFC4034，2005年3月<http://www.rfc-editor.org/info/rfc4034>.
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, <http://www.rfc-editor.org/info/rfc4035>.
[RFC4035]Arends，R.，Austein，R.，Larson，M.，Massey，D.，和S.Rose，“DNS安全扩展的协议修改”，RFC 4035，DOI 10.17487/RFC4035，2005年3月<http://www.rfc-editor.org/info/rfc4035>.
[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, DOI 10.17487/RFC5280, May 2008, <http://www.rfc-editor.org/info/rfc5280>.
[RFC5280]Cooper，D.，Santesson，S.，Farrell，S.，Boeyen，S.，Housley，R.，和W.Polk，“Internet X.509公钥基础设施证书和证书撤销列表（CRL）配置文件”，RFC 5280，DOI 10.17487/RFC5280，2008年5月<http://www.rfc-editor.org/info/rfc5280>.
[RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification", RFC 5751, DOI 10.17487/RFC5751, January 2010, <http://www.rfc-editor.org/info/rfc5751>.
[RFC5751]Ramsdell，B.和S.Turner，“安全/多用途Internet邮件扩展（S/MIME）版本3.2消息规范”，RFC 5751，DOI 10.17487/RFC5751，2010年1月<http://www.rfc-editor.org/info/rfc5751>.
[RFC5754] Turner, S., "Using SHA2 Algorithms with Cryptographic Message Syntax", RFC 5754, DOI 10.17487/RFC5754, January 2010, <http://www.rfc-editor.org/info/rfc5754>.
[RFC5754]Turner，S.，“使用具有加密消息语法的SHA2算法”，RFC 5754，DOI 10.17487/RFC5754，2010年1月<http://www.rfc-editor.org/info/rfc5754>.
[RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August 2012, <http://www.rfc-editor.org/info/rfc6698>.
[RFC6698]Hoffman，P.和J.Schlyter，“基于DNS的命名实体认证（DANE）传输层安全（TLS）协议：TLSA”，RFC 6698，DOI 10.17487/RFC6698，2012年8月<http://www.rfc-editor.org/info/rfc6698>.
[RFC7671] Dukhovni, V. and W. Hardaker, "The DNS-Based Authentication of Named Entities (DANE) Protocol: Updates and Operational Guidance", RFC 7671, DOI 10.17487/RFC7671, October 2015, <http://www.rfc-editor.org/info/rfc7671>.
[RFC7671]Dukhovni，V.和W.Hardaker，“基于DNS的命名实体认证（DANE）协议：更新和操作指南”，RFC 7671，DOI 10.17487/RFC7671，2015年10月<http://www.rfc-editor.org/info/rfc7671>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <http://www.rfc-editor.org/info/rfc8174>.
[RFC8174]Leiba，B.，“RFC 2119关键词中大写与小写的歧义”，BCP 14，RFC 8174，DOI 10.17487/RFC8174，2017年5月<http://www.rfc-editor.org/info/rfc8174>.
[Rainbow] Oechslin, P., "Making a Faster Cryptanalytic Time-Memory Trade-Off", DOI 10.1007/978-3-540-45146-4_36, 2003, <http://www.iacr.org/cryptodb/archive/2003/ CRYPTO/1615/1615.ps>.
[Rainbow]Oechslin，P.，“进行更快的密码分析时间-内存权衡”，DOI 10.1007/978-3-540-45146-436，2003年<http://www.iacr.org/cryptodb/archive/2003/ CRYPTO/1615/1615.ps>。
[RFC4262] Santesson, S., "X.509 Certificate Extension for Secure/ Multipurpose Internet Mail Extensions (S/MIME) Capabilities", RFC 4262, DOI 10.17487/RFC4262, December 2005, <http://www.rfc-editor.org/info/rfc4262>.
[RFC4262]Santesson，S.，“用于安全/多用途Internet邮件扩展（S/MIME）功能的X.509证书扩展”，RFC 4262，DOI 10.17487/RFC4262，2005年12月<http://www.rfc-editor.org/info/rfc4262>.
[RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS Security (DNSSEC) Hashed Authenticated Denial of Existence", RFC 5155, DOI 10.17487/RFC5155, March 2008, <http://www.rfc-editor.org/info/rfc5155>.
[RFC5155]Laurie，B.，Sisson，G.，Arends，R.，和D.Blacka，“DNS安全（DNSSEC）哈希认证拒绝存在”，RFC 5155，DOI 10.17487/RFC5155，2008年3月<http://www.rfc-editor.org/info/rfc5155>.
[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, DOI 10.17487/RFC5321, October 2008, <http://www.rfc-editor.org/info/rfc5321>.
[RFC5321]Klensin，J.，“简单邮件传输协议”，RFC 5321DOI 10.17487/RFC5321，2008年10月<http://www.rfc-editor.org/info/rfc5321>.
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, DOI 10.17487/RFC5322, October 2008, <http://www.rfc-editor.org/info/rfc5322>.
[RFC5322]Resnick，P.，Ed.，“互联网信息格式”，RFC 5322，DOI 10.17487/RFC5322，2008年10月<http://www.rfc-editor.org/info/rfc5322>.
[RFC6530] Klensin, J. and Y. Ko, "Overview and Framework for Internationalized Email", RFC 6530, DOI 10.17487/RFC6530, February 2012, <http://www.rfc-editor.org/info/rfc6530>.
[RFC6530]Klensin，J.和Y.Ko，“国际化电子邮件的概述和框架”，RFC 6530，DOI 10.17487/RFC6530，2012年2月<http://www.rfc-editor.org/info/rfc6530>.
[RFC6672] Rose, S. and W. Wijngaards, "DNAME Redirection in the DNS", RFC 6672, DOI 10.17487/RFC6672, June 2012, <http://www.rfc-editor.org/info/rfc6672>.
[RFC6672]Rose，S.和W.Wijngaards，“DNS中的DNAME重定向”，RFC 6672，DOI 10.17487/RFC6672，2012年6月<http://www.rfc-editor.org/info/rfc6672>.
[RFC7218] Gudmundsson, O., "Adding Acronyms to Simplify Conversations about DNS-Based Authentication of Named Entities (DANE)", RFC 7218, DOI 10.17487/RFC7218, April 2014, <http://www.rfc-editor.org/info/rfc7218>.
[RFC7218]Gudmundsson，O.，“添加首字母缩略词以简化有关基于DNS的命名实体身份验证（DANE）的对话”，RFC 7218，DOI 10.17487/RFC7218，2014年4月<http://www.rfc-editor.org/info/rfc7218>.
[RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 2014, <http://www.rfc-editor.org/info/rfc7258>.
[RFC7258]Farrell，S.和H.Tschofenig，“普遍监控是一种攻击”，BCP 188，RFC 7258，DOI 10.17487/RFC7258，2014年5月<http://www.rfc-editor.org/info/rfc7258>.
[RFC7873] Eastlake 3rd, D. and M. Andrews, "Domain Name System (DNS) Cookies", RFC 7873, DOI 10.17487/RFC7873, May 2016, <http://www.rfc-editor.org/info/rfc7873>.
[RFC7873]Eastlake 3rd，D.和M.Andrews，“域名系统（DNS）Cookies”，RFC 7873，DOI 10.17487/RFC7873，2016年5月<http://www.rfc-editor.org/info/rfc7873>.
[RFC7929] Wouters, P., "DNS-Based Authentication of Named Entities (DANE) Bindings for OpenPGP", RFC 7929, DOI 10.17487/RFC7929, August 2016, <http://www.rfc-editor.org/info/rfc7929>.
[RFC7929]Wouters，P.，“OpenPGP命名实体（DANE）绑定的基于DNS的认证”，RFC 7929，DOI 10.17487/RFC79292016年8月<http://www.rfc-editor.org/info/rfc7929>.
[UNICODE] The Unicode Consortium, "The Unicode Standard", <http://www.unicode.org/versions/latest/>.
[UNICODE]UNICODE联盟，“UNICODE标准”<http://www.unicode.org/versions/latest/>.
Acknowledgements
致谢
A great deal of material in this document is copied from [RFC7929]. That material was created by Paul Wouters and other participants in the IETF DANE WG.
本文件中的大量材料是从[RFC7929]复制的。该材料由Paul Wouters和IETF DANE工作组的其他参与者创建。
Brian Dickson, Stephen Farrell, Miek Gieben, Martin Pels, and Jim Schaad contributed technical ideas and support to this document.
Brian Dickson、Stephen Farrell、Miek Gieben、Martin Pels和Jim Schaad为本文档提供了技术想法和支持。
Authors' Addresses
作者地址
Paul Hoffman ICANN
保罗·霍夫曼·伊坎
Email: paul.hoffman@icann.org
Email: paul.hoffman@icann.org
Jakob Schlyter Kirei AB
雅各布·施莱特·基雷律师事务所
Email: jakob@kirei.se
Email: jakob@kirei.se