Internet Engineering Task Force (IETF) R. Housley
Request for Comments: 8399 Vigil Security
Updates: 5280 May 2018
Category: Standards Track
ISSN: 2070-1721
Internet Engineering Task Force (IETF) R. Housley
Request for Comments: 8399 Vigil Security
Updates: 5280 May 2018
Category: Standards Track
ISSN: 2070-1721
Internationalization Updates to RFC 5280
RFC 5280的国际化更新
Abstract
摘要
The updates to RFC 5280 described in this document provide alignment with the 2008 specification for Internationalized Domain Names (IDNs) and add support for internationalized email addresses in X.509 certificates.
本文档中描述的对RFC 5280的更新与2008年国际域名（IDN）规范保持一致，并在X.509证书中添加了对国际电子邮件地址的支持。
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 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（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 https://www.rfc-editor.org/info/rfc8399.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问https://www.rfc-editor.org/info/rfc8399.
Copyright Notice
版权公告
Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2018 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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文件的法律规定的约束(https://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。
Table of Contents
目录
1. Introduction ....................................................3
1.1. Terminology ................................................3
2. Updates to RFC 5280 .............................................3
2.1. Update in the Introduction (Section 1) .....................4
2.2. Update in Name Constraints (Section 4.2.1.10) ..............4
2.3. Update in IDNs in GeneralName (Section 7.2) ................5
2.4. Update in IDNs in Distinguished Names (Section 7.3) ........6
2.5. Update in Internationalized Electronic Mail
Addresses (Section 7.5) ....................................6
3. Security Considerations .........................................7
4. IANA Considerations .............................................8
5. References ......................................................8
5.1. Normative References .......................................8
5.2. Informative References .....................................9
Acknowledgements ...................................................9
Author's Address ...................................................9
1. Introduction ....................................................3
1.1. Terminology ................................................3
2. Updates to RFC 5280 .............................................3
2.1. Update in the Introduction (Section 1) .....................4
2.2. Update in Name Constraints (Section 4.2.1.10) ..............4
2.3. Update in IDNs in GeneralName (Section 7.2) ................5
2.4. Update in IDNs in Distinguished Names (Section 7.3) ........6
2.5. Update in Internationalized Electronic Mail
Addresses (Section 7.5) ....................................6
3. Security Considerations .........................................7
4. IANA Considerations .............................................8
5. References ......................................................8
5.1. Normative References .......................................8
5.2. Informative References .....................................9
Acknowledgements ...................................................9
Author's Address ...................................................9
This document updates the Introduction in Section 1, the Name Constraints certificate extension discussion in Section 4.2.1.10, and the Processing Rules for Internationalized Names in Section 7 of RFC 5280 [RFC5280] to provide alignment with the 2008 specification for Internationalized Domain Names (IDNs) and add support for internationalized email addresses in X.509 certificates.
本文件更新了RFC 5280[RFC5280]第1节中的引言、第4.2.1.10节中的名称约束证书扩展讨论以及第7节中的国际化名称处理规则，以与2008年的国际化域名（IDN）规范保持一致并在X.509证书中添加对国际化电子邮件地址的支持。
An IDN in Unicode (native character) form contains at least one U-label [RFC5890]. With one exception, IDNs are carried in certificates in ACE-encoded form. That is, all U-labels within an IDN are converted to A-labels. Conversion of a U-label to an A-label is described in [RFC5891].
Unicode（本机字符）形式的IDN至少包含一个U标签[RFC5890]。除了一个例外，IDN是以ACE编码的形式在证书中携带的。也就是说，IDN中的所有U型标签都转换为A型标签。[RFC5891]中描述了U型标签到a型标签的转换。
The GeneralName structure supports many different name forms, including otherName for extensibility. RFC 8398 [RFC8398] specifies the SmtpUTF8Mailbox for internationalized email addresses, which includes IDNs with U-labels.
GeneralName结构支持许多不同的名称形式，包括用于扩展性的otherName。RFC 8398[RFC8398]为国际化电子邮件地址指定SMTPUTF8邮箱，其中包括带有U标签的IDN。
Note that Internationalized Domain Names in Applications specifications published in 2003 (IDNA2003) [RFC3490] and 2008 (IDNA2008) [RFC5890] both refer to the Punycode algorithm for conversion [RFC3492].
请注意，2003年（IDNA2003）[RFC3490]和2008年（IDNA2008）[RFC5890]发布的应用程序规范中的国际化域名均指用于转换的Punycode算法[RFC3492]。
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 section provides updates to several paragraphs of RFC 5280 [RFC5280]. For clarity, if the entire section is not replaced, then the original text and the replacement text are shown.
本节提供了RFC 5280[RFC5280]中几个段落的更新。为清楚起见，如果未替换整个部分，则显示原始文本和替换文本。
This update provides references for IDNA2008.
此更新提供了IDNA2008的参考。
OLD
古老的
* Enhanced support for internationalized names is specified in Section 7, with rules for encoding and comparing Internationalized Domain Names, Internationalized Resource Identifiers (IRIs), and distinguished names. These rules are aligned with comparison rules established in current RFCs, including [RFC3490], [RFC3987], and [RFC4518].
* 第7节规定了对国际化名称的增强支持，以及编码和比较国际化域名、国际化资源标识符（IRI）和可分辨名称的规则。这些规则与当前RFC中建立的比较规则一致，包括[RFC3490]、[RFC3987]和[RFC4518]。
NEW
刚出现的
* Enhanced support for internationalized names is specified in Section 7, with rules for encoding and comparing Internationalized Domain Names, Internationalized Resource Identifiers (IRIs), and distinguished names. These rules are aligned with comparison rules established in current RFCs, including [RFC3987], [RFC4518], [RFC5890], and [RFC5891].
* 第7节规定了对国际化名称的增强支持，以及编码和比较国际化域名、国际化资源标识符（IRI）和可分辨名称的规则。这些规则与当前RFC中建立的比较规则一致，包括[RFC3987]、[RFC4518]、[RFC5890]和[RFC5891]。
This update removes the ability to include constraints for a particular mailbox. This capability was not used, and removing it allows name constraints to apply to email addresses in rfc822Name and SmtpUTF8Mailbox [RFC8398] within otherName.
此更新将删除包含特定邮箱约束的功能。未使用此功能，删除此功能允许将名称约束应用于otherName中rfc822Name和SmtpUTF8Mailbox[RFC8398]中的电子邮件地址。
OLD
古老的
A name constraint for Internet mail addresses MAY specify a particular mailbox, all addresses at a particular host, or all mailboxes in a domain. To indicate a particular mailbox, the constraint is the complete mail address. For example, "root@example.com" indicates the root mailbox on the host "example.com". To indicate all Internet mail addresses on a particular host, the constraint is specified as the host name. For example, the constraint "example.com" is satisfied by any mail address at the host "example.com". To specify any address within a domain, the constraint is specified with a leading period (as with URIs). For example, ".example.com" indicates all the Internet mail addresses in the domain "example.com", but not Internet mail addresses on the host "example.com".
Internet邮件地址的名称约束可以指定特定邮箱、特定主机上的所有地址或域中的所有邮箱。要指示特定邮箱，约束条件是完整的邮件地址。例如，”root@example.com表示主机“example.com”上的根邮箱。要指示特定主机上的所有Internet邮件地址，将约束指定为主机名。例如，主机“example.com”上的任何邮件地址都满足约束“example.com”。若要指定域中的任何地址，将使用前导句点指定约束（与URI一样）。例如，“.example.com”表示域“example.com”中的所有Internet邮件地址，但不表示主机“example.com”上的Internet邮件地址。
NEW
刚出现的
A name constraint for Internet mail addresses MAY specify all addresses at a particular host or all mailboxes in a domain. To indicate all Internet mail addresses on a particular host, the constraint is specified as the host name. For example, the constraint "example.com" is satisfied by any mail address at the host "example.com". To specify any address within a domain, the constraint is specified with a leading period (as with URIs). For example, ".example.com" indicates all the Internet mail addresses in the domain "example.com" but not Internet mail addresses on the host "example.com".
Internet邮件地址的名称约束可以指定特定主机上的所有地址或域中的所有邮箱。要指示特定主机上的所有Internet邮件地址，将约束指定为主机名。例如，主机“example.com”上的任何邮件地址都满足约束“example.com”。若要指定域中的任何地址，将使用前导句点指定约束（与URI一样）。例如，“.example.com”表示域“example.com”中的所有Internet邮件地址，但不表示主机“example.com”上的Internet邮件地址。
This update aligns with IDNA2008. Since all of Section 7.2 is replaced, the OLD text is not provided.
此更新与IDNA2008保持一致。由于第7.2节全部替换，因此未提供旧文本。
NEW
刚出现的
Internationalized Domain Names (IDNs) may be included in certificates and CRLs in the subjectAltName and issuerAltName extensions, name constraints extension, authority information access extension, subject information access extension, CRL distribution points extension, and issuing distribution point extension. Each of these extensions uses the GeneralName type; one choice in GeneralName is the dNSName field, which is defined as type IA5String.
国际化域名（IDN）可以包含在subjectAltName和issuerAltName扩展、名称约束扩展、权限信息访问扩展、主题信息访问扩展、CRL分发点扩展和发布分发点扩展中的证书和CRL中。每个扩展都使用GeneralName类型；GeneralName中的一个选项是dNSName字段，该字段定义为IA5String类型。
IA5String is limited to the set of ASCII characters. To accommodate IDNs, U-labels are converted to A-labels. The A-label is the encoding of the U-label according to the Punycode algorithm [RFC3492] with the ACE prefix "xn--" added at the beginning of the string.
IA5String仅限于ASCII字符集。为了适应IDN，U型标签转换为A型标签。A标签是根据Punycode算法[RFC3492]对U标签进行编码，并在字符串开头添加ACE前缀“xn--”。
When comparing DNS names for equality, conforming implementations MUST perform a case-insensitive exact match on the entire DNS name. When evaluating name constraints, conforming implementations MUST perform a case-insensitive exact match on a label-by-label basis. As noted in Section 4.2.1.10, any DNS name that may be constructed by adding labels to the left-hand side of the domain name given as the constraint is considered to fall within the indicated subtree.
在比较DNS名称是否相等时，一致性实现必须对整个DNS名称执行不区分大小写的精确匹配。在评估名称约束时，一致性实现必须逐个标签执行不区分大小写的精确匹配。如第4.2.1.10节所述，通过在作为约束条件给出的域名左侧添加标签来构造的任何DNS名称都被视为属于指定子树。
Implementations SHOULD convert IDNs to Unicode before display. Specifically, conforming implementations convert A-labels to U-labels for display.
实现应在显示之前将IDN转换为Unicode。具体而言，一致性实现将A标签转换为U标签以供显示。
Implementation consideration: There are increased memory requirements for IDNs. An IDN ACE label will begin with the four additional characters "xn--", and an IDN can require as many as five ASCII characters to specify a single international character.
实施考虑：IDN的内存需求增加。IDN ACE标签将以四个附加字符“xn--”开头，IDN可能需要多达五个ASCII字符来指定单个国际字符。
This update aligns with IDNA2008.
此更新与IDNA2008保持一致。
OLD
古老的
Domain Names may also be represented as distinguished names using domain components in the subject field, the issuer field, the subjectAltName extension, or the issuerAltName extension. As with the dNSName in the GeneralName type, the value of this attribute is defined as an IA5String. Each domainComponent attribute represents a single label. To represent a label from an IDN in the distinguished name, the implementation MUST perform the "ToASCII" label conversion specified in Section 4.1 of RFC 3490. The label SHALL be considered a "stored string". That is, the AllowUnassigned flag SHALL NOT be set.
域名也可以使用subject字段、issuer字段、subjectAltName扩展名或issuerAltName扩展名中的域组件表示为可分辨名称。与GeneralName类型中的dNSName一样，此属性的值定义为IA5String。每个domainComponent属性表示一个标签。要以可分辨名称表示IDN中的标签，实现必须执行RFC 3490第4.1节中规定的“ToASCII”标签转换。标签应视为“存储字符串”。也就是说，不应设置AllowUnassigned标志。
NEW
刚出现的
Domain names may also be represented as distinguished names using domain components in the subject field, the issuer field, the subjectAltName extension, or the issuerAltName extension. As with the dNSName in the GeneralName type, the value of this attribute is defined as an IA5String. Each domainComponent attribute represents a single label. To represent a label from an IDN in the distinguished name, the implementation MUST convert all U-labels to A-labels.
域名也可以使用subject字段、issuer字段、subjectAltName扩展名或issuerAltName扩展名中的域组件表示为可分辨名称。与GeneralName类型中的dNSName一样，此属性的值定义为IA5String。每个domainComponent属性表示一个标签。要以可分辨名称表示IDN中的标签，实现必须将所有U标签转换为a标签。
2.5. Update in Internationalized Electronic Mail Addresses (Section 7.5)
2.5. 更新国际化电子邮件地址（第7.5节）
This update aligns with IDNA2008 and RFC 8398 [RFC8398]. Since all of Section 7.5 is replaced, the OLD text is not provided.
此更新与IDNA2008和RFC 8398[RFC8398]保持一致。由于第7.5节的所有内容均已替换，因此未提供旧文本。
NEW
刚出现的
Electronic Mail addresses may be included in certificates and CRLs in the subjectAltName and issuerAltName extensions, name constraints extension, authority information access extension, subject information access extension, issuing distribution point extension, or CRL distribution points extension. Each of these extensions uses the GeneralName construct. If the email address includes an IDN but the local-part of the email address can be represented in ASCII, then the email address is placed in the rfc822Name choice of GeneralName,
电子邮件地址可能包含在subjectAltName和issuerAltName扩展、name constraints扩展、authority information access扩展、subject information access扩展、issuing distribution point扩展或CRL distribution points扩展中的证书和CRL中。每个扩展都使用GeneralName构造。如果电子邮件地址包括IDN，但电子邮件地址的本地部分可以用ASCII表示，则电子邮件地址将放置在GeneralName的rfc822Name选项中，
which is defined as type IA5String. If the local-part of the internationalized email address cannot be represented in ASCII, then the internationalized email address is placed in the otherName choice of GeneralName using the conventions in RFC 8398 [RFC8398].
定义为IA5String类型的。如果国际化电子邮件地址的本地部分不能用ASCII表示，则使用RFC 8398[RFC8398]中的约定将国际化电子邮件地址放置在GeneralName的otherName选项中。
7.5.1. Local-Part Contains Only ASCII Characters
7.5.1. 本地部分仅包含ASCII字符
Where the host-part contains an IDN, conforming implementations MUST convert all U-labels to A-labels.
如果主机部件包含IDN，则一致性实施必须将所有U型标签转换为A型标签。
Two email addresses are considered to match if:
如果出现以下情况，则认为两个电子邮件地址匹配：
1) the local-part of each name is an exact match, AND
1) 每个名称的本地部分完全匹配，并且
2) the host-part of each name matches using a case-insensitive ASCII comparison.
2) 每个名称的主机部分使用不区分大小写的ASCII比较进行匹配。
Implementations SHOULD convert the host-part of internationalized email addresses specified in these extensions to Unicode before display. Specifically, conforming implementations convert A-labels to U-labels for display.
在显示之前，实现应该将这些扩展中指定的国际化电子邮件地址的主机部分转换为Unicode。具体而言，一致性实现将A标签转换为U标签以供显示。
7.5.2. Local-Part Contains Non-ASCII Characters
7.5.2. 本地部分包含非ASCII字符
When the local-part contains non-ASCII characters, conforming implementations MUST place the internationalized email address in the SmtpUTF8Mailbox within the otherName choice of GeneralName as specified in Section 3 of RFC 8398 [RFC8398]. Note that the UTF8 encoding of the internationalized email address MUST NOT contain a Byte-Order-Mark (BOM) [RFC3629] to aid comparison.
当本地部分包含非ASCII字符时，按照RFC 8398[RFC8398]第3节的规定，一致性实现必须将国际化电子邮件地址放置在SMTPUTF8邮箱中的通用名称的otherName选项中。请注意，国际化电子邮件地址的UTF8编码不得包含字节顺序标记（BOM）[RFC3629]以帮助比较。
The comparison of two internationalized email addresses is specified in Section 5 of RFC 8398 [RFC8398].
RFC 8398[RFC8398]第5节规定了两个国际化电子邮件地址的比较。
Implementations SHOULD convert the host-part of internationalized email addresses specified in these extensions to Unicode before display. Specifically, conforming implementations convert A-labels to U-labels for display.
在显示之前，实现应该将这些扩展中指定的国际化电子邮件地址的主机部分转换为Unicode。具体而言，一致性实现将A标签转换为U标签以供显示。
Conforming CAs SHOULD ensure that IDNs are valid. This can be done by validating all code points according to IDNA2008 [RFC5892]. Failure to use valid A-labels and valid U-labels may yield a domain name that cannot be correctly represented in the Domain Name System (DNS). In addition, the CA/Browser Forum offers some guidance regarding internal server names in certificates [CABF].
合格的CA应确保IDN有效。这可以通过根据IDNA2008[RFC5892]验证所有代码点来实现。未能使用有效的A标签和有效的U标签可能会产生无法在域名系统（DNS）中正确表示的域名。此外，CA/浏览器论坛还提供了有关证书[CABF]中的内部服务器名称的一些指导。
This document has no IANA actions.
本文档没有IANA操作。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<https://www.rfc-editor.org/info/rfc2119>.
[RFC3492] Costello, A., "Punycode: A Bootstring encoding of Unicode for Internationalized Domain Names in Applications (IDNA)", RFC 3492, DOI 10.17487/RFC3492, March 2003, <https://www.rfc-editor.org/info/rfc3492>.
[RFC3492]Costello，A.，“Punycode：应用程序中国际化域名的Unicode引导字符串编码（IDNA）”，RFC 3492，DOI 10.17487/RFC3492，2003年3月<https://www.rfc-editor.org/info/rfc3492>.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 2003, <https://www.rfc-editor.org/info/rfc3629>.
[RFC3629]Yergeau，F.，“UTF-8，ISO 10646的转换格式”，STD 63，RFC 3629，DOI 10.17487/RFC3629，2003年11月<https://www.rfc-editor.org/info/rfc3629>.
[RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource Identifiers (IRIs)", RFC 3987, DOI 10.17487/RFC3987, January 2005, <https://www.rfc-editor.org/info/rfc3987>.
[RFC3987]Duerst，M.和M.Suignard，“国际化资源标识符（IRIs）”，RFC 3987，DOI 10.17487/RFC3987，2005年1月<https://www.rfc-editor.org/info/rfc3987>.
[RFC4518] Zeilenga, K., "Lightweight Directory Access Protocol (LDAP): Internationalized String Preparation", RFC 4518, DOI 10.17487/RFC4518, June 2006, <https://www.rfc-editor.org/info/rfc4518>.
[RFC4518]Zeilenga，K.，“轻量级目录访问协议（LDAP）：国际化字符串准备”，RFC 4518，DOI 10.17487/RFC4518，2006年6月<https://www.rfc-editor.org/info/rfc4518>.
[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, <https://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月<https://www.rfc-editor.org/info/rfc5280>.
[RFC5890] Klensin, J., "Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework", RFC 5890, DOI 10.17487/RFC5890, August 2010, <https://www.rfc-editor.org/info/rfc5890>.
[RFC5890]Klensin，J.，“应用程序的国际化域名（IDNA）：定义和文档框架”，RFC 5890，DOI 10.17487/RFC5890，2010年8月<https://www.rfc-editor.org/info/rfc5890>.
[RFC5891] Klensin, J., "Internationalized Domain Names in Applications (IDNA): Protocol", RFC 5891, DOI 10.17487/RFC5891, August 2010, <https://www.rfc-editor.org/info/rfc5891>.
[RFC5891]Klensin，J.，“应用程序中的国际化域名（IDNA）：协议”，RFC 5891，DOI 10.17487/RFC5891，2010年8月<https://www.rfc-editor.org/info/rfc5891>.
[RFC5892] Faltstrom, P., Ed., "The Unicode Code Points and Internationalized Domain Names for Applications (IDNA)", RFC 5892, DOI 10.17487/RFC5892, August 2010, <https://www.rfc-editor.org/info/rfc5892>.
[RFC5892]Faltstrom，P.，Ed.“Unicode码点和应用程序的国际化域名（IDNA）”，RFC 5892，DOI 10.17487/RFC5892，2010年8月<https://www.rfc-editor.org/info/rfc5892>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174]Leiba，B.，“RFC 2119关键词中大写与小写的歧义”，BCP 14，RFC 8174，DOI 10.17487/RFC8174，2017年5月<https://www.rfc-editor.org/info/rfc8174>.
[RFC8398] Melnikov, A., Ed. and W. Chuang, Ed., "Internationalized Email Addresses in X.509 Certificates", DOI 10.17487/RFC8398, May 2016, <http://www.rfc-editor.org/info/rfc8398>.
[RFC8398]Melnikov，A.，Ed.和W.Chuang，Ed.，“X.509证书中的国际化电子邮件地址”，DOI 10.17487/RFC8398，2016年5月<http://www.rfc-editor.org/info/rfc8398>.
[CABF] CA/Browser Forum, "Internal Server Names and IP Address Requirements for SSL: Guidance on the Deprecation of Internal Server Names and Reserved IP Addresses provided by the CA/Browser Forum", Version 1.0, June 2012, <https://cabforum.org/internal-names/>.
[CABF]CA/浏览器论坛，“SSL的内部服务器名称和IP地址要求：CA/浏览器论坛提供的内部服务器名称和保留IP地址的弃用指南”，版本1.0，2012年6月<https://cabforum.org/internal-names/>.
[RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, "Internationalizing Domain Names in Applications (IDNA)", RFC 3490, DOI 10.17487/RFC3490, March 2003, <https://www.rfc-editor.org/info/rfc3490>.
[RFC3490]Faltstrom，P.，Hoffman，P.，和A.Costello，“应用程序中的域名国际化（IDNA）”，RFC 3490，DOI 10.17487/RFC3490，2003年3月<https://www.rfc-editor.org/info/rfc3490>.
Acknowledgements
致谢
Thanks to Alexey Melnikov for the encouragement to write this update. Thanks to John Klensin and Patrik Falstrom for confirming many of the details in this update. Thanks to Ben Campbell, Wei Chuang, Spencer Dawkins, Phillip Hallam-Baker, Warren Kumari, Alexey Melnikov, Adam Roach, Tim Ruehsen, and Sean Turner for their careful review and comments.
感谢Alexey Melnikov鼓励编写此更新。感谢John Klensin和Patrik Falstrom确认本更新中的许多细节。感谢Ben Campbell、Wei Chuang、Spencer Dawkins、Phillip Hallam Baker、Warren Kumari、Alexey Melnikov、Adam Roach、Tim Ruehsen和Sean Turner的仔细审查和评论。
Author's Address
作者地址
Russ Housley Vigil Security, LLC 918 Spring Knoll Drive Herndon, VA 20170 United States of America
Russ Housley Vigil Security，LLC 918 Spring Knoll Drive Herndon，弗吉尼亚州，美利坚合众国，20170
Email: housley@vigilsec.com
Email: housley@vigilsec.com