Internet Engineering Task Force (IETF) A. Melnikov
Request for Comments: 7817 Isode Ltd
Updates: 2595, 3207, 3501, 5804 March 2016
Category: Standards Track
ISSN: 2070-1721
Internet Engineering Task Force (IETF) A. Melnikov
Request for Comments: 7817 Isode Ltd
Updates: 2595, 3207, 3501, 5804 March 2016
Category: Standards Track
ISSN: 2070-1721
Updated Transport Layer Security (TLS) Server Identity Check Procedure for Email-Related Protocols
更新了电子邮件相关协议的传输层安全（TLS）服务器身份检查过程
Abstract
摘要
This document describes the Transport Layer Security (TLS) server identity verification procedure for SMTP Submission, IMAP, POP, and ManageSieve clients. It replaces Section 2.4 (Server Identity Check) of RFC 2595 and updates Section 4.1 (Processing After the STARTTLS Command) of RFC 3207, Section 11.1 (STARTTLS Security Considerations) of RFC 3501, and Section 2.2.1 (Server Identity Check) of RFC 5804.
本文档介绍SMTP提交、IMAP、POP和ManageSeeve客户端的传输层安全性（TLS）服务器身份验证过程。它取代了RFC 2595的第2.4节（服务器身份检查），并更新了RFC 3207的第4.1节（STARTTLS命令后的处理）、RFC 3501的第11.1节（STARTTLS安全注意事项）和RFC 5804的第2.2.1节（服务器身份检查）。
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/rfc7817.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7817.
Copyright Notice
版权公告
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2016 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. Conventions Used in This Document . . . . . . . . . . . . . . 3
3. Email Server Certificate Verification Rules . . . . . . . . . 3
4. Compliance Checklist for Certification Authorities . . . . . 5
4.1. Notes on Handling of Delegated Email Services by
Certification Authorities . . . . . . . . . . . . . . . . 5
5. Compliance Checklist for Mail Service Providers and
Certificate Signing Request Generation Tools . . . . . . . . 6
5.1. Notes on Hosting Multiple Domains . . . . . . . . . . . . 7
6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 8
7. Operational Considerations . . . . . . . . . . . . . . . . . 9
8. Security Considerations . . . . . . . . . . . . . . . . . . . 9
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
9.1. Normative References . . . . . . . . . . . . . . . . . . 9
9.2. Informative References . . . . . . . . . . . . . . . . . 11
Appendix A. Changes to RFCs 2595, 3207, 3501, and 5804 . . . . . 12
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 13
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions Used in This Document . . . . . . . . . . . . . . 3
3. Email Server Certificate Verification Rules . . . . . . . . . 3
4. Compliance Checklist for Certification Authorities . . . . . 5
4.1. Notes on Handling of Delegated Email Services by
Certification Authorities . . . . . . . . . . . . . . . . 5
5. Compliance Checklist for Mail Service Providers and
Certificate Signing Request Generation Tools . . . . . . . . 6
5.1. Notes on Hosting Multiple Domains . . . . . . . . . . . . 7
6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 8
7. Operational Considerations . . . . . . . . . . . . . . . . . 9
8. Security Considerations . . . . . . . . . . . . . . . . . . . 9
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
9.1. Normative References . . . . . . . . . . . . . . . . . . 9
9.2. Informative References . . . . . . . . . . . . . . . . . 11
Appendix A. Changes to RFCs 2595, 3207, 3501, and 5804 . . . . . 12
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 13
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 13
Use of TLS by SMTP Submission, IMAP, POP, and ManageSieve clients is described in [RFC3207], [RFC3501], [RFC2595], and [RFC5804], respectively. Each of the documents describes slightly different rules for server certificate identity verification (or doesn't define any rules at all). In reality, email client and server developers implement many of these protocols at the same time, so it would be good to define modern and consistent rules for verifying email server identities using TLS.
[RFC3207]、[RFC3501]、[RFC2595]和[RFC5804]中分别介绍了SMTP提交、IMAP、POP和ManageSeeve客户端对TLS的使用。每个文档描述的服务器证书身份验证规则略有不同（或者根本没有定义任何规则）。实际上，电子邮件客户机和服务器开发人员同时实现了许多这样的协议，因此最好定义使用TLS验证电子邮件服务器身份的现代且一致的规则。
This document describes the updated TLS server identity verification procedure for SMTP Submission [RFC6409] [RFC3207], IMAP [RFC3501], POP [RFC1939], and ManageSieve [RFC5804] clients. Section 3 of this document replaces Section 2.4 of [RFC2595].
本文档描述了SMTP提交[RFC6409][RFC3207]、IMAP[RFC3501]、POP[RFC1939]和ManageSeeve[RFC5804]客户端的更新TLS服务器身份验证过程。本文件第3节取代[RFC2595]第2.4节。
Note that this document doesn't apply to use of TLS in MTA-to-MTA SMTP.
请注意，本文档不适用于在MTA到MTA SMTP中使用TLS。
This document provides a consistent TLS server identity verification procedure across multiple email-related protocols. This should make it easier for Certification Authorities (CAs) and ISPs to deploy TLS for email use and would enable email client developers to write more secure code.
本文档提供了跨多个电子邮件相关协议的一致TLS服务器身份验证过程。这将使认证机构（CA）和ISP更容易为电子邮件使用部署TLS，并使电子邮件客户端开发人员能够编写更安全的代码。
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 [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
The following terms or concepts are used through the document:
本文件使用了以下术语或概念：
reference identifier: One of the domain names that the email client (an SMTP, IMAP, POP3, or ManageSieve client) associates with the target email server. For some identifier types, the identifier also includes an application service type. Reference identifiers are used for performing name checks on server certificates. (This term is formally defined in [RFC6125].)
引用标识符：电子邮件客户端（SMTP、IMAP、POP3或ManageSieve客户端）与目标电子邮件服务器关联的域名之一。对于某些标识符类型，标识符还包括应用程序服务类型。引用标识符用于对服务器证书执行名称检查。（该术语在[RFC6125]中有正式定义。）
CN-ID, DNS-ID, SRV-ID, and URI-ID are identifier types (see [RFC6125] for details). For convenience, their short definitions from [RFC6125] are listed below:
CN-ID、DNS-ID、SRV-ID和URI-ID是标识符类型（有关详细信息，请参阅[RFC6125]）。为方便起见，[RFC6125]中的简短定义如下：
CN-ID: A Relative Distinguished Name (RDN) in the certificate subject field that contains one and only one attribute-type-and-value pair of type Common Name (CN), where the value matches the overall form of a domain name (informally, dot-separated, letter-digit-hyphen labels).
CN-ID:certificate subject字段中的相对可分辨名称（RDN），它包含且仅包含一个属性类型和通用名称（CN）类型的值对，其中的值与域名的整体形式匹配（非正式的点分隔字母-数字连字符标签）。
DNS-ID: A subjectAltName entry of type dNSName
DNS-ID:dNSName类型的subjectAltName条目
SRV-ID: A subjectAltName entry of type otherName whose name form is SRVName
SRV-ID:otherName类型的subjectAltName条目，其名称形式为SRVName
URI-ID: A subjectAltName entry of type uniformResourceIdentifier whose value includes both (i) a "scheme" and (ii) a "host" component (or its equivalent) that matches the "reg-name" rule (where the quoted terms represent the associated [RFC5234] productions from [RFC3986]).
URI-ID:uniformResourceIdentifier类型的subjectAltName条目，其值包括（i）一个“方案”和（ii）一个与“注册名称”规则匹配的“主机”组件（或其等效项）（其中引用的术语表示来自[RFC3986]的相关[RFC5234]产品）。
During a TLS negotiation, an email client (i.e., an SMTP, IMAP, POP3, or ManageSieve client) MUST check its understanding of the server identity (client's reference identifiers) against the server's identity as presented in the server Certificate message in order to prevent man-in-the-middle attacks. This check is only performed after the server certificate passes certification path validation as described in Section 6 of [RFC5280]. Matching is performed according to the rules specified in Section 6 of [RFC6125], including the relative order of matching of different identifier types, "certificate pinning", and the procedure on failure to match. The
在TLS协商期间，电子邮件客户端（即SMTP、IMAP、POP3或ManageSife客户端）必须对照服务器证书消息中显示的服务器标识检查其对服务器标识（客户端参考标识）的理解，以防中间人攻击。此检查仅在服务器证书通过[RFC5280]第6节所述的认证路径验证后执行。根据[RFC6125]第6节规定的规则执行匹配，包括不同标识符类型匹配的相对顺序，“证书固定”，以及匹配失败的程序。这个
following inputs are used by the verification procedure used in [RFC6125]:
[RFC6125]中使用的验证程序使用以下输入：
1. For DNS-ID and CN-ID identifier types, the client MUST use one or more of the following as "reference identifiers": (a) the domain portion of the user's email address, (b) the hostname it used to open the connection (without CNAME canonicalization). The client MAY also use (c) a value securely derived from (a) or (b), such as using "secure" DNSSEC [RFC4033] [RFC4034] [RFC4035] validated lookup.
1. 对于DNS-ID和CN-ID标识符类型，客户端必须使用以下一个或多个作为“参考标识符”：（a）用户电子邮件地址的域部分，（b）用于打开连接的主机名（无CNAME规范化）。客户端还可以使用（c）从（a）或（b）安全派生的值，例如使用“安全”DNSSEC[RFC4033][RFC4034][RFC4035]验证查找。
2. When using email service discovery procedure specified in [RFC6186], the client MUST also use the domain portion of the user's email address as another "reference identifier" to compare against an SRV-ID identifier in the server certificate.
2. 当使用[RFC6186]中指定的电子邮件服务发现过程时，客户端还必须使用用户电子邮件地址的域部分作为另一个“参考标识符”，以与服务器证书中的SRV-ID标识符进行比较。
The rules and guidelines defined in [RFC6125] apply to an email server certificate with the following supplemental rules:
[RFC6125]中定义的规则和指南适用于电子邮件服务器证书，并附带以下补充规则：
1. Support for the DNS-ID identifier type (subjectAltName of dNSName type [RFC5280]) is REQUIRED in email client software implementations.
1. 电子邮件客户端软件实现中需要支持DNS-ID标识符类型（dNSName类型的subjectAltName[RFC5280]）。
2. Support for the SRV-ID identifier type (subjectAltName of SRVName type [RFC4985]) is REQUIRED for email client software implementations that support [RFC6186]. A list of SRV-ID types for email services is specified in [RFC6186]. For the ManageSieve protocol, the service name "sieve" is used.
2. 支持[RFC6186]的电子邮件客户端软件实现需要支持SRV-ID标识符类型（subjectAltName为SRVName类型[RFC4985]）。[RFC6186]中规定了电子邮件服务的SRV-ID类型列表。对于ManageSieve协议，使用服务名称“sieve”。
3. A URI-ID identifier type (subjectAltName of uniformResourceIdentifier type [RFC5280]) MUST NOT be used by clients for server verification, as URI-IDs were not historically used for email.
3. 客户端不得将URI-ID标识符类型（uniformResourceIdentifier类型[RFC5280]的subjectAltName）用于服务器验证，因为URI ID过去未用于电子邮件。
4. For backward compatibility with deployed software, a CN-ID identifier type (CN attribute from the subject name, see [RFC6125]) MAY be used for server identity verification.
4. 为了与部署的软件向后兼容，可以使用CN-ID标识符类型（主题名称的CN属性，请参见[RFC6125]）进行服务器身份验证。
5. Email protocols allow use of certain wildcards in identifiers presented by email servers. The "*" wildcard character MAY be used as the left-most name component of a DNS-ID or CN-ID in the certificate. For example, a DNS-ID of "*.example.com" would match "a.example.com", "foo.example.com", etc., but would not match "example.com". Note that the wildcard character MUST NOT be used as a fragment of the left-most name component (e.g., "*oo.example.com", "f*o.example.com", or "foo*.example.com").
5. 电子邮件协议允许在电子邮件服务器提供的标识符中使用某些通配符。“*”通配符可以用作证书中DNS-ID或CN-ID的最左侧名称组件。例如，“*.example.com”的DNS-ID将与“a.example.com”、“foo.example.com”等匹配，但与“example.com”不匹配。请注意，通配符不得用作最左侧名称组件（例如“*oo.example.com”、“f*o.example.com”或“foo*.example.com”）的片段。
1. CAs MUST support issuance of server certificates with a DNS-ID identifier type (subjectAltName of dNSName type [RFC5280]). (Note that some DNS-IDs may refer to domain portions of email addresses, so they might not have corresponding A/AAAA DNS records.)
1. CA必须支持使用DNS-ID标识符类型（dNSName类型[RFC5280]的subjectAltName）颁发服务器证书。（请注意，某些DNS ID可能引用电子邮件地址的域部分，因此它们可能没有相应的A/AAAA DNS记录。）
2. CAs MUST support issuance of server certificates with an SRV-ID identifier type (subjectAltName of SRVName type [RFC4985]) for each type of email service. See Section 4.1 for more discussion on what this means for CAs.
2. CA必须支持为每种类型的电子邮件服务颁发具有SRV-ID标识符类型（subjectAltName为SRVName类型[RFC4985]）的服务器证书。有关这对CAs意味着什么的更多讨论，请参见第4.1节。
3. For backward compatibility with a deployed client base, CAs MUST support issuance of server certificates with a CN-ID identifier type (CN attribute from the subject name, see [RFC6125]).
3. 为了向后兼容已部署的客户端，CAs必须支持使用CN-ID标识符类型（主题名称的CN属性，请参见[RFC6125]）颁发服务器证书。
4. CAs MAY allow "*" (wildcard) as the left-most name component of a DNS-ID or CN-ID in server certificates it issues.
4. CAs可能允许“*”（通配符）作为其颁发的服务器证书中DNS-ID或CN-ID的最左边的名称组件。
4.1. Notes on Handling of Delegated Email Services by Certification Authorities
4.1. 关于证书颁发机构处理委托电子邮件服务的说明
[RFC6186] provides an easy way for organizations to autoconfigure email clients. It also allows for delegation of email services to an email hosting provider. When connecting to such delegated hosting service, an email client that attempts to verify TLS server identity needs to know that if it connects to "imap.hosting.example.net", such server is authorized to provide email access for an email such as alice@example.org. In absence of SRV-IDs, users of compliant email clients would be forced to manually confirm exceptions because the TLS server certificate verification procedures specified in this document would result in failure to match the TLS server certificate against the expected domain(s). One way to provide such authorization is for the TLS certificate for "imap.hosting.example.net" to include SRV-ID(s) (or a DNS-ID) for the "example.org" domain. Note that another way is for DNS Service Record (SRV) lookups to be protected by DNSSEC, but this solution depends on ubiquitous use of DNSSEC and availability of DNSSEC-aware APIs and thus is not discussed in this document. A future update to this document might rectify this.
[RFC6186]为组织提供了一种自动配置电子邮件客户端的简便方法。它还允许将电子邮件服务委托给电子邮件托管提供商。当连接到此类委托托管服务时，尝试验证TLS服务器身份的电子邮件客户端需要知道，如果它连接到“imap.hosting.example.net”，则该服务器有权提供电子邮件访问，例如alice@example.org. 在没有SRV ID的情况下，兼容电子邮件客户端的用户将被迫手动确认异常，因为本文档中指定的TLS服务器证书验证过程将导致无法将TLS服务器证书与预期域匹配。提供此类授权的一种方法是“imap.hosting.example.net”的TLS证书包含“example.org”域的SRV-ID（或DNS-ID）。请注意，另一种方法是由DNSSEC保护DNS服务记录（SRV）查找，但此解决方案取决于DNSSEC的普遍使用和DNSSEC感知API的可用性，因此本文档中不讨论。此文档的未来更新可能会纠正此问题。
A CA that receives a Certificate Signing Request containing multiple unrelated DNS-IDs and/or SRV-IDs (e.g., a DNS-ID of "example.org" and a DNS-ID of "example.com") needs to verify that the entity that supplied such Certificate Signing Request is authorized to provide email service for all requested domains.
接收包含多个不相关DNS ID和/或SRV ID（例如，DNS-ID为“example.org”和DNS-ID为“example.com”）的证书签名请求的CA需要验证提供此类证书签名请求的实体是否有权为所有请求的域提供电子邮件服务。
The ability to issue certificates that contain an SRV-ID (or a DNS-ID for the domain part of email addresses) implies the ability to verify that entities requesting them are authorized to run email service for these SRV-IDs/DNS-IDs. In particular, CAs that can't verify such authorization (whether for a particular domain or in general) MUST NOT include such email SRV-IDs/DNS-IDs in certificates they issue. This document doesn't specify exact mechanism(s) that can be used to achieve this. However, a few special case recommendations are listed below.
能够颁发包含SRV-ID（或电子邮件地址域部分的DNS-ID）的证书意味着能够验证请求它们的实体是否有权为这些SRV ID/DNS ID运行电子邮件服务。特别是，无法验证此类授权（无论是针对特定域还是一般域）的CA不得在其颁发的证书中包含此类电子邮件SRV ID/DNS ID。本文档未指定可用于实现此目的的确切机制。但是，下面列出了一些特殊情况建议。
A CA willing to sign a certificate containing a particular DNS-ID SHOULD also support signing a certificate containing one or more of the email SRV-IDs for the same domain because the SRV-ID effectively provides more restricted access to an email service for the domain (as opposed to unrestricted use of any services for the same domain, as specified by the DNS-ID).
愿意签署包含特定DNS-ID的证书的CA还应支持签署包含同一域的一个或多个电子邮件SRV ID的证书，因为SRV-ID有效地为该域的电子邮件服务提供了更受限的访问权限（与DNS-ID指定的对同一域的任何服务的无限制使用相反）。
A CA that also provides DNS service for a domain can use DNS information to validate SRV-IDs/DNS-IDs for the domain.
还为域提供DNS服务的CA可以使用DNS信息验证域的SRV ID/DNS ID。
A CA that is also a Mail Service Provider for a hosted domain can use that knowledge to validate SRV-IDs/DNS-IDs for the domain.
同时也是托管域的邮件服务提供商的CA可以使用该知识验证域的SRV ID/DNS ID。
5. Compliance Checklist for Mail Service Providers and Certificate Signing Request Generation Tools
5. 邮件服务提供商和证书签名请求生成工具的合规性检查表
Mail Service Providers and Certificate Signing Request generation tools:
邮件服务提供商和证书签名请求生成工具：
1. MUST include the DNS-ID identifier type in Certificate Signing Requests for the host name(s) where the email server(s) are running. They SHOULD include the DNS-ID identifier type in Certificate Signing Requests for the domain portion of served email addresses.
1. 必须在运行电子邮件服务器的主机名的证书签名请求中包含DNS-ID标识符类型。它们应该在所服务电子邮件地址的域部分的证书签名请求中包含DNS-ID标识符类型。
2. MUST include the SRV-ID identifier type for each type of email service in Certificate Signing Requests if the email services provided are discoverable using DNS SRV as specified in [RFC6186].
2. 如果使用[RFC6186]中指定的DNS SRV可以发现提供的电子邮件服务，则必须在证书签名请求中包含每种类型电子邮件服务的SRV-ID标识符类型。
3. SHOULD include the CN-ID identifier type for the host name where the email server(s) is running in Certificate Signing Requests for backward compatibility with deployed email clients. (Note, a certificate can only include a single CN-ID, so if a mail service is running on multiple hosts, either each host has to use different certificate with its own CN-ID, a single certificate with multiple DNS-IDs, or a single certificate with wildcard in a CN-ID can be used).
3. 应包括电子邮件服务器在证书签名请求中运行的主机名的CN-ID标识符类型，以便与部署的电子邮件客户端向后兼容。（注意，一个证书只能包含一个CN-ID，因此，如果一个邮件服务在多个主机上运行，则每个主机必须使用具有自己CN-ID的不同证书、具有多个DNS ID的单个证书，或者可以使用CN-ID中具有通配符的单个证书）。
4. MAY include "*" (wildcard) as the left-most name component of a DNS-ID or CN-ID in Certificate Signing Requests.
4. 在证书签名请求中，可以将“*”（通配符）作为DNS-ID或CN-ID最左边的名称组件。
A server that hosts multiple domains needs to do one of the following (or some combination thereof):
承载多个域的服务器需要执行以下操作之一（或其组合）：
1. Use DNS SRV records to redirect each hosted email service to a fixed domain, deploy TLS certificate(s) for that single domain, and instruct users to configure their clients with appropriate pinning (unless the SRV records can always be obtained via DNSSEC). Some email clients come with preloaded lists of pinned certificates for some popular domains; this can avoid the need for manual confirmation.
1. 使用DNS SRV记录将每个托管电子邮件服务重定向到固定域，为单个域部署TLS证书，并指示用户使用适当的固定配置其客户端（除非始终可以通过DNSSEC获得SRV记录）。一些电子邮件客户端带有一些流行域的预加载固定证书列表；这可以避免手动确认的需要。
2. Use a single TLS certificate that includes a complete list of all the domains it is serving.
2. 使用一个TLS证书，该证书包含它所服务的所有域的完整列表。
3. Serve each domain on its own IP/port, using separate TLS certificates on each IP/port.
3. 在每个IP/端口上使用单独的TLS证书，在其自己的IP/端口上为每个域提供服务。
4. Use the Server Name Indication (SNI) TLS extension [RFC6066] to select the right certificate to return during TLS negotiation. Each domain has its own TLS certificate in this case.
4. 使用服务器名称指示（SNI）TLS扩展[RFC6066]在TLS协商期间选择要返回的正确证书。在这种情况下，每个域都有自己的TLS证书。
Each of these deployment choices have their scaling disadvantages when the list of domains changes. Use of DNS SRV without an SRV-ID requires manual confirmation from users. While preloading pinned certificates avoids the need for manual confirmation, this information can get stale quickly or would require support for a new mechanism for distributing preloaded pinned certificates. A single certificate (the second choice) requires that when a domain is added, then a new Certificate Signing Request that includes a complete list of all the domains needs to be issued and passed to a CA in order to generate a new certificate. A separate IP/port can avoid regenerating the certificate but requires more transport layer resources. Use of TLS SNI requires each email client to use it.
当域列表更改时，这些部署选项中的每一个都有其扩展缺点。使用没有SRV-ID的DNS SRV需要用户手动确认。虽然预加载固定证书可以避免手动确认，但此信息可能会很快过时，或者需要支持用于分发预加载固定证书的新机制。单个证书（第二种选择）要求在添加域时，需要发出一个新的证书签名请求，该请求包括所有域的完整列表，并传递给CA以生成新证书。单独的IP/端口可以避免重新生成证书，但需要更多的传输层资源。TLS SNI的使用要求每个电子邮件客户端都使用它。
Several Mail Service Providers host hundreds and even thousands of domains. This document, as well as its predecessors, RFCs 2595, 3207, 3501, and 5804, don't address scaling issues caused by use of TLS in multi-tenanted environments. Further work is needed to address this issue, possibly using DNSSEC or something like PKIX over Secure HTTP (POSH) [RFC7711].
几个邮件服务提供商拥有数百甚至数千个域。本文档及其前身RFCs 2595、3207、3501和5804没有解决在多租户环境中使用TLS引起的扩展问题。需要进一步的工作来解决这个问题，可能需要使用DNSSEC或类似于安全HTTP上的PKIX（POSH）[RFC7711]。
Consider an IMAP-accessible email server that supports both IMAP and IMAP-over-TLS (IMAPS) at the host "mail.example.net" servicing email addresses of the form "user@example.net". A certificate for this service needs to include DNS-IDs of "example.net" (because it is the domain portion of emails) and "mail.example.net" (this is what a user of this server enters manually if not using [RFC6186]). It might also include a CN-ID of "mail.example.net" for backward compatibility with deployed infrastructure.
考虑一个IMAP可访问电子邮件服务器，它既支持IMAP和IMAP，又支持在主机“mail .Simul.Net”上服务于表单的电子邮件地址的TLS（IMAPS）。user@example.net". 此服务的证书需要包括“example.net”（因为它是电子邮件的域部分）和“mail.example.net”（这是此服务器的用户在不使用[RFC6186]的情况下手动输入的DNS ID）。它还可能包含一个CN-ID“mail.example.net”，以便与部署的基础设施向后兼容。
Consider the IMAP-accessible email server from the previous paragraph that is additionally discoverable via DNS SRV lookups in domain "example.net" (using DNS SRV records "_imap._tcp.example.net" and "_imaps._tcp.example.net"). In addition to the DNS-ID/CN-ID identity types specified above, a certificate for this service also needs to include SRV-IDs of "_imap.example.net" (when STARTTLS is used on the IMAP port) and "_imaps.example.net" (when TLS is used on IMAPS port). See [RFC6186] for more details. (Note that unlike DNS SRV there is no "_tcp" component in SRV-IDs).
考虑前面段落中的IMAP可访问电子邮件服务器，它可以通过“示例.NET”域中的DNS SRV查找来发现（使用DNS SRV记录）“IMAP。除了上面指定的DNS-ID/CN-ID标识类型外，此服务的证书还需要包括SRV ID“_imap.example.net”（当在imap端口上使用STARTTLS时）和“_imaps.example.net”（当在imaps端口上使用TLS时）。有关更多详细信息，请参见[RFC6186]。（请注意，与DNS SRV不同，SRV ID中没有“_tcp”组件）。
Consider the IMAP-accessible email server from the first paragraph that is running on a host also known as "mycompany.example.com". In addition to the DNS-ID identity types specified above, a certificate for this service also needs to include a DNS-ID of "mycompany.example.com" (this is what a user of this server enters manually if not using [RFC6186]). It might also include a CN-ID of "mycompany.example.com" instead of the CN-ID "mail.example.net" for backward compatibility with deployed infrastructure. (This is so, because a certificate can only include a single CN-ID)
考虑从主机上运行的第一段开始的IMAP可访问电子邮件服务器，也称为“MyPosial.Simult.com”。除了上面指定的DNS-ID标识类型外，此服务的证书还需要包含“mycompany.example.com”的DNS-ID（如果不使用[RFC6186]，此服务器的用户将手动输入此ID）。它还可能包含一个CN-ID“mycompany.example.com”，而不是CN-ID“mail.example.net”，以便与部署的基础设施向后兼容。（之所以如此，是因为一个证书只能包含一个CN-ID）
Consider an SMTP Submission server at the host "submit.example.net" servicing email addresses of the form "user@example.net" and discoverable via DNS SRV lookups in domain "example.net" (using DNS SRV record "_submission._tcp.example.net"). A certificate for this service needs to include SRV-IDs of "_submission.example.net" (see [RFC6186]) along with DNS-IDs of "example.net" and "submit.example.net". It might also include a CN-ID of "submit.example.net" for backward compatibility with deployed infrastructure.
考虑在SMTP提交服务器在主机“提交.Studio.Net”服务的电子邮件地址的形式“user@example.net并可通过域“example.net”（使用DNS SRV记录“\u submission.\u tcp.example.net”）中的DNS SRV查找来发现。此服务的证书需要包括“_submission.example.net”（参见[RFC6186]）的SRV ID以及“example.net”和“submit.example.net”的DNS ID。它还可能包含一个CN-ID“submit.example.net”，以便与部署的基础设施向后兼容。
Consider a host "mail.example.net" servicing email addresses of the form "user@example.net" and discoverable via DNS SRV lookups in domain "example.net", which runs SMTP Submission, IMAPS and POP3S (POP3-over-TLS), and ManageSieve services. Each of the servers can use their own certificate specific to their service (see examples above). Alternatively, they can all share a single certificate that would include SRV-IDs of "_submission.example.net",
考虑一个主机“邮件.Studio.net”服务表单的电子邮件地址user@example.net并可通过域“example.net”中的DNS SRV查找进行发现，该域运行SMTP提交、IMAPS和POP3（通过TLS的POP3）以及ManageSeeve服务。每个服务器都可以使用自己的特定于其服务的证书（参见上面的示例）。或者，它们可以共享一个证书，其中包含SRV ID“\u submission.example.net”，
"_imaps.example.net", "_pop3s.example.net", and "_sieve.example.net" along with DNS-IDs of "example.net" and "mail.example.net". It might also include a CN-ID of "mail.example.net" for backward compatibility with deployed infrastructure.
“_imaps.example.net”、“_pop3s.example.net”和“_sieve.example.net”以及DNS ID“example.net”和“mail.example.net”。它还可能包含一个CN-ID“mail.example.net”，以便与部署的基础设施向后兼容。
Section 5 covers operational considerations (in particular, use of DNS SRV for autoconfiguration) related to generating TLS certificates for email servers so that they can be successfully verified by email clients. Additionally, Section 5.1 talks about operational considerations related to hosting multiple domains.
第5节介绍了与为电子邮件服务器生成TLS证书相关的操作注意事项（特别是使用DNS SRV进行自动配置），以便电子邮件客户端能够成功验证这些证书。此外，第5.1节讨论了与托管多个域相关的操作注意事项。
The goal of this document is to improve interoperability and thus security of email clients wishing to access email servers over TLS-protected email protocols by specifying a consistent set of rules that email service providers, email client writers, and CAs can use when creating server certificates.
本文档的目标是通过指定电子邮件服务提供商、电子邮件客户端编写者和CA在创建服务器证书时可以使用的一组一致规则，提高希望通过受TLS保护的电子邮件协议访问电子邮件服务器的电子邮件客户端的互操作性和安全性。
The TLS server identity check for email relies on use of trustworthy DNS hostnames when constructing "reference identifiers" that are checked against an email server certificate. Such trustworthy names are either entered manually (for example, if they are advertised on a Mail Service Provider's website), explicitly confirmed by the user (e.g., if they are a target of a DNS SRV lookup), or derived using a secure third party service (e.g., DNSSEC-protected SRV records that are verified by the client or trusted local resolver). Future work in this area might benefit from integration with DNS-Based Authentication of Named Entities (DANE) [RFC6698], but it is not covered by this document.
电子邮件的TLS服务器身份检查依赖于在构造“参考标识符”时使用可靠的DNS主机名，该“参考标识符”根据电子邮件服务器证书进行检查。此类可信名称可以手动输入（例如，如果它们在邮件服务提供商的网站上发布）、由用户明确确认（例如，如果它们是DNS SRV查找的目标），或者使用安全的第三方服务（例如，由客户端或可信的本地解析程序验证的DNSSEC保护的SRV记录）派生. 与基于DNS的命名实体身份验证（DANE）[RFC6698]的集成可能会使该领域的未来工作受益匪浅，但本文档并未对此进行介绍。
[RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version 3", STD 53, RFC 1939, DOI 10.17487/RFC1939, May 1996, <http://www.rfc-editor.org/info/rfc1939>.
[RFC1939]迈尔斯，J.和M.罗斯，“邮局协议-第3版”，STD 53，RFC 1939，DOI 10.17487/RFC1939，1996年5月<http://www.rfc-editor.org/info/rfc1939>.
[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>.
[RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over Transport Layer Security", RFC 3207, DOI 10.17487/RFC3207, February 2002, <http://www.rfc-editor.org/info/rfc3207>.
[RFC3207]Hoffman，P.，“传输层安全SMTP的SMTP服务扩展”，RFC 3207，DOI 10.17487/RFC3207，2002年2月<http://www.rfc-editor.org/info/rfc3207>.
[RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003, <http://www.rfc-editor.org/info/rfc3501>.
[RFC3501]Crispin，M.，“互联网消息访问协议-版本4rev1”，RFC 3501，DOI 10.17487/RFC3501，2003年3月<http://www.rfc-editor.org/info/rfc3501>.
[RFC4985] Santesson, S., "Internet X.509 Public Key Infrastructure Subject Alternative Name for Expression of Service Name", RFC 4985, DOI 10.17487/RFC4985, August 2007, <http://www.rfc-editor.org/info/rfc4985>.
[RFC4985]Santesson，S.，“互联网X.509公钥基础设施主体服务名称表达的备选名称”，RFC 4985，DOI 10.17487/RFC4985，2007年8月<http://www.rfc-editor.org/info/rfc4985>.
[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>.
[RFC5804] Melnikov, A., Ed. and T. Martin, "A Protocol for Remotely Managing Sieve Scripts", RFC 5804, DOI 10.17487/RFC5804, July 2010, <http://www.rfc-editor.org/info/rfc5804>.
[RFC5804]Melnikov，A.，Ed.和T.Martin，“远程管理筛选脚本的协议”，RFC 5804，DOI 10.17487/RFC5804，2010年7月<http://www.rfc-editor.org/info/rfc5804>.
[RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) Extensions: Extension Definitions", RFC 6066, DOI 10.17487/RFC6066, January 2011, <http://www.rfc-editor.org/info/rfc6066>.
[RFC6066]Eastlake 3rd，D.，“传输层安全（TLS）扩展：扩展定义”，RFC 6066，DOI 10.17487/RFC6066，2011年1月<http://www.rfc-editor.org/info/rfc6066>.
[RFC6125] Saint-Andre, P. and J. Hodges, "Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 2011, <http://www.rfc-editor.org/info/rfc6125>.
[RFC6125]Saint Andre，P.和J.Hodges，“在传输层安全（TLS）环境下使用X.509（PKIX）证书在互联网公钥基础设施内表示和验证基于域的应用程序服务身份”，RFC 6125，DOI 10.17487/RFC6125，2011年3月<http://www.rfc-editor.org/info/rfc6125>.
[RFC6186] Daboo, C., "Use of SRV Records for Locating Email Submission/Access Services", RFC 6186, DOI 10.17487/RFC6186, March 2011, <http://www.rfc-editor.org/info/rfc6186>.
[RFC6186]Daboo，C.“使用SRV记录查找电子邮件提交/访问服务”，RFC 6186，DOI 10.17487/RFC6186，2011年3月<http://www.rfc-editor.org/info/rfc6186>.
[RFC6409] Gellens, R. and J. Klensin, "Message Submission for Mail", STD 72, RFC 6409, DOI 10.17487/RFC6409, November 2011, <http://www.rfc-editor.org/info/rfc6409>.
[RFC6409]Gellens，R.和J.Klensin，“邮件的邮件提交”，STD 72，RFC 6409，DOI 10.17487/RFC6409，2011年11月<http://www.rfc-editor.org/info/rfc6409>.
[RFC2595] Newman, C., "Using TLS with IMAP, POP3 and ACAP", RFC 2595, DOI 10.17487/RFC2595, June 1999, <http://www.rfc-editor.org/info/rfc2595>.
[RFC2595]Newman，C.，“将TLS与IMAP、POP3和ACAP一起使用”，RFC 2595，DOI 10.17487/RFC2595，1999年6月<http://www.rfc-editor.org/info/rfc2595>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, <http://www.rfc-editor.org/info/rfc3986>.
[RFC3986]Berners Lee，T.，Fielding，R.，和L.Masinter，“统一资源标识符（URI）：通用语法”，STD 66，RFC 3986，DOI 10.17487/RFC3986，2005年1月<http://www.rfc-editor.org/info/rfc3986>.
[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>.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, <http://www.rfc-editor.org/info/rfc5234>.
[RFC5234]Crocker，D.，Ed.和P.Overell，“语法规范的扩充BNF:ABNF”，STD 68，RFC 5234，DOI 10.17487/RFC5234，2008年1月<http://www.rfc-editor.org/info/rfc5234>.
[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>.
[RFC7711] Miller, M. and P. Saint-Andre, "PKIX over Secure HTTP (POSH)", RFC 7711, DOI 10.17487/RFC7711, November 2015, <http://www.rfc-editor.org/info/rfc7711>.
[RFC7711]Miller，M.和P.Saint Andre，“安全HTTP上的PKIX（POSH）”，RFC 7711，DOI 10.17487/RFC7711，2015年11月<http://www.rfc-editor.org/info/rfc7711>.
Appendix A. Changes to RFCs 2595, 3207, 3501, and 5804
附录A.对RFCs 2595、3207、3501和5804的变更
This section lists detailed changes this document applies to RFCs 2595, 3207, 3501, and 5804.
本节列出了本文件适用于RFCs 2595、3207、3501和5804的详细变更。
The entire Section 2.4 of RFC 2595 is replaced with the following text:
RFC 2595第2.4节全部替换为以下内容：
During the TLS negotiation, the client checks its understanding of the server identity against the provided server's identity as specified in Section 3 of [RFC7817].
在TLS协商期间，客户机根据[RFC7817]第3节中规定的提供的服务器标识检查其对服务器标识的理解。
The 3rd paragraph (and its subparagraphs) in Section 11.1 of RFC 3501 is replaced with the following text:
RFC 3501第11.1节第3段（及其子段）替换为以下文本：
During the TLS negotiation, the IMAP client checks its understanding of the server identity against the provided server's identity as specified in Section 3 of [RFC7817].
在TLS协商期间，IMAP客户端根据[RFC7817]第3节中规定的提供的服务器标识检查其对服务器标识的理解。
The 3rd paragraph (and its subparagraphs) in Section 4.1 of RFC 3207 is replaced with the following text:
RFC 3207第4.1节第3段（及其分段）替换为以下文本：
During the TLS negotiation, the Submission client checks its understanding of the server identity against the provided server's identity as specified in Section 3 of [RFC7817].
在TLS协商期间，提交客户端根据[RFC7817]第3节中规定的提供的服务器标识检查其对服务器标识的理解。
Sections 2.2.1 and 2.2.1.1 of RFC 5804 are replaced with the following text:
RFC 5804第2.2.1节和第2.2.1.1节替换为以下文本：
During the TLS negotiation, the ManageSieve client checks its understanding of the server identity against the server's identity as specified in Section 3 of [RFC7817]. When the reference identity is an IP address, the iPAddress subjectAltName SHOULD be used by the client for comparison. The comparison is performed as described in Section 2.2.1.2 of RFC 5804.
在TLS协商期间，ManageSeeve客户端根据[RFC7817]第3节中指定的服务器标识检查其对服务器标识的理解。当引用标识是IP地址时，客户端应使用iPAddress subjectAltName进行比较。按照RFC 5804第2.2.1.2节所述进行比较。
Acknowledgements
致谢
Thank you to Chris Newman, Viktor Dukhovni, Sean Turner, Russ Housley, Alessandro Vesely, Harald Alvestrand, and John Levine for comments on this document.
感谢Chris Newman、Viktor Dukhovni、Sean Turner、Russ Housley、Alessandro Vesely、Harald Alvestrand和John Levine对本文件的评论。
The editor of this document copied lots of text from RFCs 2595 and 6125, so the hard work of editors of these documents is appreciated.
本文件的编辑从RFCs 2595和6125中复制了大量文本，因此感谢这些文件编辑的辛勤工作。
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