Internet Engineering Task Force (IETF) J. Salowey
Request for Comments: 8447 Tableau Software
Updates: 3749, 5077, 4680, 5246, 5705, S. Turner
5878, 6520, 7301 sn3rd
Category: Standards Track August 2018
ISSN: 2070-1721
Internet Engineering Task Force (IETF) J. Salowey
Request for Comments: 8447 Tableau Software
Updates: 3749, 5077, 4680, 5246, 5705, S. Turner
5878, 6520, 7301 sn3rd
Category: Standards Track August 2018
ISSN: 2070-1721
IANA Registry Updates for TLS and DTLS
TLS和DTL的IANA注册表更新
Abstract
摘要
This document describes a number of changes to TLS and DTLS IANA registries that range from adding notes to the registry all the way to changing the registration policy. These changes were mostly motivated by WG review of the TLS- and DTLS-related registries undertaken as part of the TLS 1.3 development process.
本文档描述了对TLS和DTLS IANA注册表的一些更改，从向注册表添加注释到更改注册策略。这些变化主要是由于工作组审查了TLS和DTL相关登记册，作为TLS 1.3开发过程的一部分。
This document updates the following RFCs: 3749, 5077, 4680, 5246, 5705, 5878, 6520, and 7301.
本文档更新了以下RFC:3749、5077、4680、5246、5705、5878、6520和7301。
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/rfc8447.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问https://www.rfc-editor.org/info/rfc8447.
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许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Adding "TLS" to Registry Names . . . . . . . . . . . . . . . 3
4. Aligning with RFC 8126 . . . . . . . . . . . . . . . . . . . 4
5. Adding "Recommended" Column . . . . . . . . . . . . . . . . . 4
6. Session Ticket TLS Extension . . . . . . . . . . . . . . . . 4
7. TLS ExtensionType Values . . . . . . . . . . . . . . . . . . 5
8. TLS Cipher Suites Registry . . . . . . . . . . . . . . . . . 8
9. TLS Supported Groups . . . . . . . . . . . . . . . . . . . . 10
10. TLS ClientCertificateType Identifiers . . . . . . . . . . . . 11
11. New Session Ticket TLS Handshake Message Type . . . . . . . . 12
12. TLS Exporter Labels Registry . . . . . . . . . . . . . . . . 12
13. Adding Missing Item to TLS Alerts Registry . . . . . . . . . 13
14. TLS Certificate Types . . . . . . . . . . . . . . . . . . . . 14
15. Orphaned Registries . . . . . . . . . . . . . . . . . . . . . 15
16. Additional Notes . . . . . . . . . . . . . . . . . . . . . . 16
17. Designated Expert Pool . . . . . . . . . . . . . . . . . . . 16
18. Security Considerations . . . . . . . . . . . . . . . . . . . 17
19. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
20. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
20.1. Normative References . . . . . . . . . . . . . . . . . . 18
20.2. Informative References . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Adding "TLS" to Registry Names . . . . . . . . . . . . . . . 3
4. Aligning with RFC 8126 . . . . . . . . . . . . . . . . . . . 4
5. Adding "Recommended" Column . . . . . . . . . . . . . . . . . 4
6. Session Ticket TLS Extension . . . . . . . . . . . . . . . . 4
7. TLS ExtensionType Values . . . . . . . . . . . . . . . . . . 5
8. TLS Cipher Suites Registry . . . . . . . . . . . . . . . . . 8
9. TLS Supported Groups . . . . . . . . . . . . . . . . . . . . 10
10. TLS ClientCertificateType Identifiers . . . . . . . . . . . . 11
11. New Session Ticket TLS Handshake Message Type . . . . . . . . 12
12. TLS Exporter Labels Registry . . . . . . . . . . . . . . . . 12
13. Adding Missing Item to TLS Alerts Registry . . . . . . . . . 13
14. TLS Certificate Types . . . . . . . . . . . . . . . . . . . . 14
15. Orphaned Registries . . . . . . . . . . . . . . . . . . . . . 15
16. Additional Notes . . . . . . . . . . . . . . . . . . . . . . 16
17. Designated Expert Pool . . . . . . . . . . . . . . . . . . . 16
18. Security Considerations . . . . . . . . . . . . . . . . . . . 17
19. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
20. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
20.1. Normative References . . . . . . . . . . . . . . . . . . 18
20.2. Informative References . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
Per this document, IANA has made changes to a number of IANA registries related to Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS). These changes were almost entirely motivated by the development of TLS 1.3 [RFC8446].
根据本文档，IANA对与传输层安全性（TLS）和数据报传输层安全性（DTLS）相关的许多IANA注册中心进行了更改。这些变化几乎完全是由TLS 1.3[RFC8446]的开发推动的。
The changes introduced by this document range from simple, e.g., adding notes, to complex, e.g., changing a registry's registration policy. Instead of listing the changes and their rationale here in the introduction, each section provides rationale for the proposed change(s).
本文档引入的更改范围从简单（例如添加注释）到复杂（例如更改注册表的注册策略）。不是在导言中列出变更及其基本原理，而是每个部分提供拟议变更的基本原理。
This document proposes no changes to the registration policies for TLS Alerts [RFC8446], TLS ContentType [RFC8446], TLS HandshakeType [RFC8446], and TLS Certificate Status Types [RFC6961] registries; the existing policies (Standards Action for the first three; IETF Review for the last), are appropriate for these one-byte code points because of their scarcity.
本文件不建议更改TLS警报[RFC8446]、TLS内容类型[RFC8446]、TLS握手类型[RFC8446]和TLS证书状态类型[RFC6961]注册表的注册策略；现有的政策（前三项的标准行动；最后一项的IETF审查）适用于这些单字节代码点，因为它们的稀缺性。
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]所述进行解释。
For consistency amongst TLS registries, IANA has prepended "TLS" to the following registries:
为确保TLS注册中心之间的一致性，IANA在以下注册中心前添加了“TLS”：
o Application-Layer Protocol Negotiation (ALPN) Protocol IDs [RFC7301],
o 应用层协议协商（ALPN）协议ID[RFC7301]，
o ExtensionType Values,
o ExtensionType值，
o Heartbeat Message Types [RFC6520], and
o 心跳消息类型[RFC6520]，以及
o Heartbeat Modes [RFC6520].
o 心跳模式[RFC6520]。
IANA has updated the reference for these four registries to also refer to this document. The remainder of this document will use the registry names with the "TLS" prefix.
IANA已更新了这四个注册中心的参考资料，以同时参考本文件。本文档的其余部分将使用带有“TLS”前缀的注册表名。
Many of the TLS-related IANA registries had the registration procedure "IETF Consensus", which was changed to "IETF Review" by [RFC8126]. To align with the new terminology, IANA has updated the following registries to "IETF Review":
许多与TLS相关的IANA注册处都有注册程序“IETF共识”，该程序由[RFC8126]更改为“IETF审查”。为了与新术语保持一致，IANA已将以下注册表更新为“IETF审查”：
o TLS Authorization Data Formats [RFC4680]
o TLS授权数据格式[RFC4680]
o TLS Supplemental Data Formats (SupplementalDataType) [RFC5878]
o TLS补充数据格式（补充数据类型）[RFC5878]
This is not a universal change, as some registries originally defined with "IETF Consensus" are undergoing other changes either as a result of this document, [RFC8446], or [RFC8422].
这并不是一个普遍性的变化，因为一些最初定义为“IETF共识”的注册中心正在经历本文件[RFC8446]或[RFC8422]的其他变化。
IANA has updated the reference for these two registries to also refer to this document.
IANA已更新了这两个注册中心的参考资料，以同时参考本文件。
Per this document, a "Recommended" column has been added to many of the TLS registries to indicate parameters that are generally recommended for implementations to support. Adding a "Recommended" parameter (i.e., "Y") to a registry or updating a parameter to "Recommended" status requires Standards Action. Not all parameters defined in Standards Track documents need to be marked as "Recommended".
根据本文档，许多TLS注册表中都添加了一个“推荐”列，以指示通常建议实现支持的参数。将“推荐”参数（即“Y”）添加到注册表或将参数更新为“推荐”状态需要标准操作。并非标准跟踪文件中定义的所有参数都需要标记为“推荐”。
If an item is not marked as "Recommended" (i.e., "N"), it does not necessarily mean that it is flawed; rather, it indicates that the item either has not been through the IETF consensus process, has limited applicability, or is intended only for specific use cases.
如果一个项目未标记为“推荐”（即“N”），则不一定意味着它有缺陷；相反，它表明该项目要么未通过IETF共识过程，要么适用性有限，要么仅用于特定用例。
The nomenclature for the registry entries in the TLS ExtensionType Values registry correspond to the presentation language field name except for entry 35. To ensure that the values in the registry are consistently identified in the registry, IANA:
TLS ExtensionType值注册表中注册表项的命名与表示语言字段名相对应，条目35除外。为确保注册表中的值在注册表中得到一致识别，IANA：
o has renamed entry 35 to "session_ticket (renamed from "SessionTicket TLS")" [RFC5077].
o 已将条目35重命名为“session_票证（从“SessionTicket TLS”重命名）”[RFC5077]。
o has added a reference to this document in the "Reference" column for entry 35.
o 在条目35的“参考”栏中添加了对本文件的参考。
Experience has shown that the IETF Review registry policy for TLS extensions was too strict. Based on WG consensus, the decision was taken to change the registration policy to Specification Required [RFC8126] while reserving a small part of the code space for private use. Therefore, IANA has updated the TLS ExtensionType Values registry as follows:
经验表明，针对TLS扩展的IETF审查注册表策略过于严格。基于工作组的共识，决定将注册政策更改为所需规范[RFC8126]，同时保留一小部分代码空间供私人使用。因此，IANA更新了TLS ExtensionType值注册表，如下所示：
o Changed the registry policy to:
o 将注册表策略更改为：
Values with the first byte in the range 0-254 (decimal) are assigned via Specification Required [RFC8126]. Values with the first byte 255 (decimal) are reserved for Private Use [RFC8126].
第一个字节在0-254（十进制）范围内的值通过所需规范[RFC8126]分配。第一个字节为255（十进制）的值保留供私人使用[RFC8126]。
o Updated the "Reference" to also refer to this document.
o 更新了“参考”以同时参考本文件。
See Section 17 for additional information about the designated expert pool.
有关指定专家库的更多信息，请参见第17节。
Despite wanting to "loosen" the registration policies for TLS extensions, it is still useful to indicate in the IANA registry which extensions the WG recommends be supported. Therefore, IANA has updated the TLS ExtensionType Values registry as follows:
尽管希望“放松”TLS扩展的注册策略，但在IANA注册表中指出工作组建议支持哪些扩展仍然很有用。因此，IANA更新了TLS ExtensionType值注册表，如下所示：
o Added a "Recommended" column with the contents as listed below. This table has been generated by marking Standards Track RFCs as "Y" and all others as "N". The "Recommended" column is assigned a value of "N" unless explicitly requested, and adding a value with a "Recommended" value of "Y" requires Standards Action [RFC8126]. IESG Approval is REQUIRED for a Y->N transition.
o 增加了一个“推荐”栏，内容如下所示。此表是通过将标准轨道RFC标记为“Y”，将所有其他标记为“N”生成的。除非明确要求，“推荐”列的值为“N”，添加“推荐”值为“Y”的值需要标准操作[RFC8126]。Y->N转换需要IESG批准。
+----------------------------------------+-------------+
| Extension | Recommended |
+----------------------------------------+-------------+
| server_name | Y |
| | |
| max_fragment_length | N |
| | |
| client_certificate_url | Y |
| | |
| trusted_ca_keys | Y |
| | |
| truncated_hmac | Y |
| | |
| status_request | Y |
| | |
| user_mapping | Y |
+----------------------------------------+-------------+
| Extension | Recommended |
+----------------------------------------+-------------+
| server_name | Y |
| | |
| max_fragment_length | N |
| | |
| client_certificate_url | Y |
| | |
| trusted_ca_keys | Y |
| | |
| truncated_hmac | Y |
| | |
| status_request | Y |
| | |
| user_mapping | Y |
+----------------------------------------+-------------+
| Extension | Recommended |
+----------------------------------------+-------------+
| client_authz | N |
| | |
| server_authz | N |
| | |
| cert_type | N |
| | |
| supported_groups | Y |
| | |
| ec_point_formats | Y |
| | |
| srp | N |
| | |
| signature_algorithms | Y |
| | |
| use_srtp | Y |
| | |
| heartbeat | Y |
| | |
| application_layer_protocol_negotiation | Y |
| | |
| status_request_v2 | Y |
| | |
| signed_certificate_timestamp | N |
| | |
| client_certificate_type | Y |
| | |
| server_certificate_type | Y |
| | |
| padding | Y |
| | |
| encrypt_then_mac | Y |
| | |
| extended_master_secret | Y |
| | |
| cached_info | Y |
| | |
| session_ticket | Y |
| | |
| renegotiation_info | Y |
+----------------------------------------+-------------+
+----------------------------------------+-------------+
| Extension | Recommended |
+----------------------------------------+-------------+
| client_authz | N |
| | |
| server_authz | N |
| | |
| cert_type | N |
| | |
| supported_groups | Y |
| | |
| ec_point_formats | Y |
| | |
| srp | N |
| | |
| signature_algorithms | Y |
| | |
| use_srtp | Y |
| | |
| heartbeat | Y |
| | |
| application_layer_protocol_negotiation | Y |
| | |
| status_request_v2 | Y |
| | |
| signed_certificate_timestamp | N |
| | |
| client_certificate_type | Y |
| | |
| server_certificate_type | Y |
| | |
| padding | Y |
| | |
| encrypt_then_mac | Y |
| | |
| extended_master_secret | Y |
| | |
| cached_info | Y |
| | |
| session_ticket | Y |
| | |
| renegotiation_info | Y |
+----------------------------------------+-------------+
IANA has added the following notes:
IANA增加了以下注释：
Note: The role of the designated expert is described in RFC 8447. The designated expert [RFC8126] ensures that the specification is publicly available. It is sufficient to have an Internet-Draft (that is posted and never published as an RFC) or a document from another standards body, industry consortium, university site, etc. The expert may provide more in-depth reviews, but their approval should not be taken as an endorsement of the extension.
注：RFC 8447中描述了指定专家的角色。指定的专家[RFC8126]确保规范是公开的。只要有一份互联网草案（发布且从未作为RFC发布）或另一标准机构、行业联盟、大学网站等的文件就足够了。专家可以提供更深入的审查，但他们的批准不应被视为对扩展的认可。
Note: As specified in [RFC8126], assignments made in the Private Use space are not generally useful for broad interoperability. It is the responsibility of those making use of the Private Use range to ensure that no conflicts occur (within the intended scope of use). For widespread experiments, temporary reservations are available.
注：如[RFC8126]中所述，在私人使用空间中进行的分配对于广泛的互操作性通常不有用。使用私人使用范围的人有责任确保不会发生冲突（在预期使用范围内）。对于广泛的实验，可以临时保留。
Note: If an item is not marked as "Recommended", it does not necessarily mean that it is flawed; rather, it indicates that the item either has not been through the IETF consensus process, has limited applicability, or is intended only for specific use cases.
注：如果一个项目没有标记为“推荐”，并不一定意味着它有缺陷；相反，它表明该项目要么未通过IETF共识过程，要么适用性有限，要么仅用于特定用例。
The extensions added by [RFC8446] are omitted from the above table; additionally, token_binding is omitted, since [TOKBIND] specifies the value of the "Recommended" column for this extension.
上表中省略了[RFC8446]添加的扩展名；此外，由于[TOKBIND]指定了此扩展的“推荐”列的值，因此省略了标记_绑定。
[RFC8446] also uses the TLS ExtensionType Values registry originally created in [RFC4366]. The following text is from [RFC8446] and is included here to ensure alignment between these specifications.
[RFC8446]还使用最初在[RFC4366]中创建的TLS ExtensionType值注册表。以下文本来自[RFC8446]，包含在此处以确保这些规范之间的一致性。
o IANA has updated this registry to include the "key_share", "pre_shared_key", "psk_key_exchange_modes", "early_data", "cookie", "supported_versions", "certificate_authorities", "oid_filters", "post_handshake_auth", and "signature_algorithms_cert" extensions with the values defined in [RFC8446] and the "Recommended" value of "Y".
o IANA已更新此注册表，以包括“密钥共享”、“预共享密钥”、“psk密钥交换模式”、“早期密钥数据”、“cookie”、“支持的密钥版本”、“证书颁发机构”、“oid筛选器”、“后握手认证”和“签名算法证书”扩展，扩展值在[RFC8446]中定义，“建议”值为“Y”。
o IANA has updated this registry to include a "TLS 1.3" column that lists the messages in which the extension may appear. This column has been initially populated from the table in Section 4.2 of [RFC8446] with any extension not listed there marked as "-" to indicate that it is not used by TLS 1.3.
o IANA已更新此注册表，以包含一个“TLS 1.3”列，其中列出了扩展可能出现的消息。该列最初是根据[RFC8446]第4.2节中的表填充的，其中未列出的扩展名标记为“-”，以表示TLS 1.3未使用该列。
Experience has shown that the IETF Consensus registry policy for TLS Cipher Suites was too strict. Based on WG consensus, the decision was taken to change the TLS Cipher Suites registry's registration policy to Specification Required [RFC8126] while reserving a small part of the code space for private use. Therefore, IANA has updated the TLS Cipher Suites registry's policy as follows:
经验表明，针对TLS密码套件的IETF共识注册表策略过于严格。基于工作组的一致意见，决定将TLS Cipher Suite注册表的注册策略更改为规范要求[RFC8126]，同时保留一小部分代码空间供私人使用。因此，IANA更新了TLS Cipher Suite注册表的策略，如下所示：
Values with the first byte in the range 0-254 (decimal) are assigned via Specification Required [RFC8126]. Values with the first byte 255 (decimal) are reserved for Private Use [RFC8126].
第一个字节在0-254（十进制）范围内的值通过所需规范[RFC8126]分配。第一个字节为255（十进制）的值保留供私人使用[RFC8126]。
See Section 17 for additional information about the designated expert pool.
有关指定专家库的更多信息，请参见第17节。
The TLS Cipher Suites registry has grown significantly and will continue to do so. To better guide those not intimately involved in TLS, IANA has updated the TLS Cipher Suites registry as follows:
TLS Cipher Suite注册表已显著增长，并将继续增长。为了更好地指导那些不密切参与TLS的人，IANA更新了TLS密码套件注册表，如下所示：
o Added a "Recommended" column to the TLS Cipher Suites registry. The cipher suites that follow in the two tables are marked as "Y". All other cipher suites are marked as "N". The "Recommended" column is assigned a value of "N" unless explicitly requested, and adding a value with a "Recommended" value of "Y" requires Standards Action [RFC8126]. IESG Approval is REQUIRED for a Y->N transition.
o 在TLS密码套件注册表中添加了“推荐”列。两个表中后面的密码套件标记为“Y”。所有其他密码套件都标记为“N”。除非明确要求，“推荐”列的值为“N”，添加“推荐”值为“Y”的值需要标准操作[RFC8126]。Y->N转换需要IESG批准。
The cipher suites that follow are Standards Track server-authenticated (and optionally client-authenticated) cipher suites that are currently available in TLS 1.2.
下面的密码套件是TLS 1.2中当前可用的标准跟踪服务器验证（以及可选的客户端验证）密码套件。
Cipher Suite Name | Value
----------------------------------------------+------------
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 | {0x00,0x9E}
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 | {0x00,0x9F}
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 | {0xC0,0x2B}
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 | {0xC0,0x2C}
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 | {0xC0,0x2F}
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 | {0xC0,0x30}
TLS_DHE_RSA_WITH_AES_128_CCM | {0xC0,0x9E}
TLS_DHE_RSA_WITH_AES_256_CCM | {0xC0,0x9F}
TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 | {0xCC,0xA8}
TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 | {0xCC,0xA9}
TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256 | {0xCC,0xAA}
Cipher Suite Name | Value
----------------------------------------------+------------
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 | {0x00,0x9E}
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 | {0x00,0x9F}
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 | {0xC0,0x2B}
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 | {0xC0,0x2C}
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 | {0xC0,0x2F}
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 | {0xC0,0x30}
TLS_DHE_RSA_WITH_AES_128_CCM | {0xC0,0x9E}
TLS_DHE_RSA_WITH_AES_256_CCM | {0xC0,0x9F}
TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 | {0xCC,0xA8}
TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 | {0xCC,0xA9}
TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256 | {0xCC,0xAA}
The cipher suites that follow are Standards Track ephemeral pre-shared key cipher suites that are available in TLS 1.2.
下面的密码套件是TLS 1.2中提供的标准跟踪临时预共享密钥密码套件。
Cipher Suite Name | Value
----------------------------------------------+------------
TLS_DHE_PSK_WITH_AES_128_GCM_SHA256 | {0x00,0xAA}
TLS_DHE_PSK_WITH_AES_256_GCM_SHA384 | {0x00,0xAB}
TLS_DHE_PSK_WITH_AES_128_CCM | {0xC0,0xA6}
TLS_DHE_PSK_WITH_AES_256_CCM | {0xC0,0xA7}
TLS_ECDHE_PSK_WITH_AES_128_GCM_SHA256 | {0xD0,0x01}
TLS_ECDHE_PSK_WITH_AES_256_GCM_SHA384 | {0xD0,0x02}
TLS_ECDHE_PSK_WITH_AES_128_CCM_SHA256 | {0xD0,0x05}
TLS_ECDHE_PSK_WITH_CHACHA20_POLY1305_SHA256 | {0xCC,0xAC}
TLS_DHE_PSK_WITH_CHACHA20_POLY1305_SHA256 | {0xCC,0xAD}
Cipher Suite Name | Value
----------------------------------------------+------------
TLS_DHE_PSK_WITH_AES_128_GCM_SHA256 | {0x00,0xAA}
TLS_DHE_PSK_WITH_AES_256_GCM_SHA384 | {0x00,0xAB}
TLS_DHE_PSK_WITH_AES_128_CCM | {0xC0,0xA6}
TLS_DHE_PSK_WITH_AES_256_CCM | {0xC0,0xA7}
TLS_ECDHE_PSK_WITH_AES_128_GCM_SHA256 | {0xD0,0x01}
TLS_ECDHE_PSK_WITH_AES_256_GCM_SHA384 | {0xD0,0x02}
TLS_ECDHE_PSK_WITH_AES_128_CCM_SHA256 | {0xD0,0x05}
TLS_ECDHE_PSK_WITH_CHACHA20_POLY1305_SHA256 | {0xCC,0xAC}
TLS_DHE_PSK_WITH_CHACHA20_POLY1305_SHA256 | {0xCC,0xAD}
The TLS 1.3 cipher suites specified by [RFC8446] are not listed here; that document provides for their "Recommended" status.
此处未列出[RFC8446]指定的TLS 1.3密码套件；该文件规定了它们的“建议”状态。
Despite the following behavior being misguided, experience has shown that some customers use the IANA registry as a checklist against which to measure an implementation's completeness, and some implementers blindly implement cipher suites. Therefore, IANA has added the following warning to the registry:
尽管以下行为被误导，但经验表明，一些客户使用IANA注册中心作为衡量实现完整性的检查表，而一些实现者盲目地实现密码套件。因此，IANA在注册表中添加了以下警告：
WARNING: Cryptographic algorithms and parameters will be broken or weakened over time. Blindly implementing cipher suites listed here is not advised. Implementers and users need to check that the cryptographic algorithms listed continue to provide the expected level of security.
警告：随着时间的推移，加密算法和参数将被破坏或削弱。不建议盲目实现此处列出的密码套件。实现者和用户需要检查列出的加密算法是否继续提供预期的安全级别。
IANA has added the following note to ensure that those that focus on IANA registries are aware that TLS 1.3 [RFC8446] uses the same registry but defines ciphers differently:
IANA增加了以下注释，以确保关注IANA注册中心的人知道TLS 1.3[RFC8446]使用相同的注册中心，但对密码的定义不同：
Note: Although TLS 1.3 uses the same cipher suite space as previous versions of TLS, TLS 1.3 cipher suites are defined differently, only specifying the symmetric ciphers and hash function, and cannot be used for TLS 1.2. Similarly, TLS 1.2 and lower cipher suite values cannot be used with TLS 1.3.
注意：尽管TLS 1.3使用与TLS早期版本相同的密码套件空间，但TLS 1.3密码套件的定义不同，仅指定对称密码和哈希函数，不能用于TLS 1.2。同样，TLS 1.2和更低的密码套件值不能与TLS 1.3一起使用。
IANA has added the following notes to document the rules for populating the "Recommended" column:
IANA添加了以下注释，以记录填充“推荐”列的规则：
Note: CCM_8 cipher suites are not marked as "Recommended". These cipher suites have a significantly truncated authentication tag that represents a security trade-off that may not be appropriate for general environments.
注：CCM_8密码套件未标记为“推荐”。这些密码套件具有明显截断的身份验证标记，表示可能不适合于一般环境的安全权衡。
Note: If an item is not marked as "Recommended", it does not necessarily mean that it is flawed; rather, it indicates that the item either has not been through the IETF consensus process, has limited applicability, or is intended only for specific use cases.
注：如果一个项目没有标记为“推荐”，并不一定意味着它有缺陷；相反，它表明该项目要么未通过IETF共识过程，要么适用性有限，要么仅用于特定用例。
IANA has added the following notes for additional information:
IANA已添加以下注释以获取更多信息：
Note: The role of the designated expert is described in RFC 8447. The designated expert [RFC8126] ensures that the specification is publicly available. It is sufficient to have an Internet-Draft (that is posted and never published as an RFC) or a document from another standards body, industry consortium, university site, etc. The expert may provide more in-depth reviews, but their approval should not be taken as an endorsement of the cipher suite.
注：RFC 8447中描述了指定专家的角色。指定的专家[RFC8126]确保规范是公开的。只要有一份互联网草案（发布后从未以RFC形式发布）或来自其他标准机构、行业联盟、大学网站等的文件就足够了。专家可以提供更深入的审查，但他们的批准不应被视为对密码套件的认可。
Note: As specified in [RFC8126], assignments made in the Private Use space are not generally useful for broad interoperability. It is the responsibility of those making use of the Private Use range to ensure that no conflicts occur (within the intended scope of use). For widespread experiments, temporary reservations are available.
注：如[RFC8126]中所述，在私人使用空间中进行的分配对于广泛的互操作性通常不有用。使用私人使用范围的人有责任确保不会发生冲突（在预期使用范围内）。对于广泛的实验，可以临时保留。
IANA has updated the reference for this registry to also refer to this document.
IANA已更新了该注册中心的参考，以同时参考本文件。
Similar to cipher suites, supported groups have proliferated over time, and some use the registry to measure implementations. Therefore, IANA has added a "Recommended" column with a "Y" for secp256r1, secp384r1, x25519, and x448, while all others are "N". These "Y" groups are taken from Standards Track RFCs; [RFC8422] elevates secp256r1 and secp384r1 to Standards Track. Not all groups from [RFC8422], which is Standards Track, are marked as "Y"; these groups apply to TLS 1.3 [RFC8446] and previous versions of TLS. The "Recommended" column is assigned a value of "N" unless explicitly requested, and adding a value with a "Recommended" value of "Y" requires Standards Action [RFC8126]. IESG Approval is REQUIRED for a Y->N transition.
与密码套件类似，受支持的组随着时间的推移而激增，一些组使用注册表来衡量实现。因此，IANA为secp256r1、secp384r1、x25519和x448添加了一个带有“Y”的“推荐”列，而其他所有列均为“N”。这些“Y”组取自标准轨道RFC；[RFC8422]将secp256r1和secp384r1提升到标准轨道。并非[RFC8422]中的所有组（标准轨道）都标记为“Y”；这些组适用于TLS 1.3[RFC8446]和TLS的早期版本。除非明确要求，“推荐”列的值为“N”，添加“推荐”值为“Y”的值需要标准操作[RFC8126]。Y->N转换需要IESG批准。
IANA has added the following notes:
IANA增加了以下注释：
Note: If an item is not marked as "Recommended", it does not necessarily mean that it is flawed; rather, it indicates that the item either has not been through the IETF consensus process, has limited applicability, or is intended only for specific use cases.
注：如果一个项目没有标记为“推荐”，并不一定意味着它有缺陷；相反，它表明该项目要么未通过IETF共识过程，要么适用性有限，要么仅用于特定用例。
Note: The role of the designated expert is described in RFC 8447. The designated expert [RFC8126] ensures that the specification is publicly available. It is sufficient to have an Internet-Draft (that is posted and never published as an RFC) or a document from another standards body, industry consortium, university site, etc. The expert may provide more in-depth reviews, but their approval should not be taken as an endorsement of the supported group.
注：RFC 8447中描述了指定专家的角色。指定的专家[RFC8126]确保规范是公开的。只要有一份互联网草案（发布且从未作为RFC发布）或另一标准机构、行业联盟、大学网站等的文件就足够了。专家可以提供更深入的审查，但他们的批准不应被视为支持小组的认可。
Despite the following behavior being misguided, experience has shown that some customers use the IANA registry as a checklist against which to measure an implementation's completeness, and some implementers blindly implement supported groups. Therefore, IANA has added the following warning to the registry:
尽管以下行为被误导，但经验表明，一些客户使用IANA注册中心作为衡量实现完整性的检查表，而一些实现者盲目地实现受支持的组。因此，IANA在注册表中添加了以下警告：
WARNING: Cryptographic algorithms and parameters will be broken or weakened over time. Blindly implementing supported groups listed here is not advised. Implementers and users need to check that the cryptographic algorithms listed continue to provide the expected level of security.
警告：随着时间的推移，加密算法和参数将被破坏或削弱。不建议盲目实施此处列出的受支持组。实现者和用户需要检查列出的加密算法是否继续提供预期的安全级别。
IANA has updated the reference for this registry to also refer to this document.
IANA已更新了该注册中心的参考，以同时参考本文件。
The value 0 (0x0000) has been marked as reserved.
值0（0x0000）已标记为保留。
Experience has shown that the IETF Consensus registry policy for TLS ClientCertificateType Identifiers is too strict. Based on WG consensus, the decision was taken to change the registration policy to Specification Required [RFC8126] while reserving some of the code space for Standards Track usage and a small part of the code space for private use. Therefore, IANA has updated the TLS ClientCertificateType Identifiers registry's policy as follows:
经验表明，针对TLS ClientCertificateType标识符的IETF一致注册策略过于严格。根据工作组的共识，决定将注册政策更改为规范要求[RFC8126]，同时保留部分代码空间供标准轨道使用，保留一小部分代码空间供私人使用。因此，IANA更新了TLS ClientCertificateType标识符注册表的策略，如下所示：
Values in the range 0-63 are assigned via Standards Action. Values 64-223 are assigned via Specification Required [RFC8126]. Values 224-255 are reserved for Private Use.
0-63范围内的值通过标准操作分配。通过所需规范[RFC8126]分配值64-223。值224-255保留供私人使用。
See Section 17 for additional information about the designated expert pool.
有关指定专家库的更多信息，请参见第17节。
IANA has added the following notes:
IANA增加了以下注释：
Note: The role of the designated expert is described in RFC 8447. The designated expert [RFC8126] ensures that the specification is publicly available. It is sufficient to have an Internet-Draft (that is posted and never published as an RFC) or a document from another standards body, industry consortium, university site, etc. The expert may provide more in-depth reviews, but their approval should not be taken as an endorsement of the identifier.
注：RFC 8447中描述了指定专家的角色。指定的专家[RFC8126]确保规范是公开的。只要有一份互联网草案（发布后从未作为RFC发布）或另一标准机构、行业联盟、大学网站等的文件就足够了。专家可以提供更深入的审查，但他们的批准不应被视为对标识符的认可。
Note: As specified in [RFC8126], assignments made in the Private Use space are not generally useful for broad interoperability. It is the responsibility of those making use of the Private Use range to ensure that no conflicts occur (within the intended scope of use). For widespread experiments, temporary reservations are available.
注：如[RFC8126]中所述，在私人使用空间中进行的分配对于广泛的互操作性通常不有用。使用私人使用范围的人有责任确保不会发生冲突（在预期使用范围内）。对于广泛的实验，可以临时保留。
To align with TLS implementations and to align the naming nomenclature with other Handshake message types, IANA:
要与TLS实现保持一致，并将命名术语与其他握手消息类型保持一致，IANA：
o has renamed entry 4 in the TLS HandshakeType registry to "new_session_ticket (renamed from NewSessionTicket)" [RFC5077].
o 已将TLS握手类型注册表中的条目4重命名为“new_session_ticket（从NewSessionTicket重命名）”[RFC5077]。
o has added a reference to this document in the "Reference" column for entry 4 in the TLS HandshakeType registry.
o 在TLS握手类型注册表项4的“引用”列中添加了对本文档的引用。
To aid those reviewers who start with the IANA registry, IANA has added:
为了帮助那些从IANA注册中心开始的审查人员，IANA增加了：
o The following note to the TLS Exporter Labels registry:
o TLS Exporter标签注册表的以下注释：
Note: [RFC5705] defines keying material exporters for TLS in terms of the TLS PRF. [RFC8446] replaced the PRF with HKDF, thus requiring a new construction. The exporter interface remains the same; however, the value is computed differently.
注：[RFC5705]根据TLS PRF定义TLS的键控材料导出器。[RFC8446]将PRF替换为HKDF，因此需要新的施工。导出器接口保持不变；但是，该值的计算方式不同。
o A "Recommended" column to the TLS Exporter Labels registry. The table that follows has been generated by marking Standards Track RFCs as "Y" and all others as "N". The "Recommended" column is assigned a value of "N" unless explicitly requested, and adding a value with a "Recommended" value of "Y" requires Standards Action [RFC8126]. IESG Approval is REQUIRED for a Y->N transition.
o TLS Exporter标签注册表的“推荐”列。下表是通过将标准轨道RFC标记为“Y”，将所有其他标记为“N”而生成的。除非明确要求，“推荐”列的值为“N”，添加“推荐”值为“Y”的值需要标准操作[RFC8126]。Y->N转换需要IESG批准。
Exporter Value | Recommended |
--------------------------------|-------------|
client finished | Y |
server finished | Y |
master secret | Y |
key expansion | Y |
client EAP encryption | Y |
ttls keying material | N |
ttls challenge | N |
EXTRACTOR-dtls_srtp | Y |
EXPORTER_DTLS_OVER_SCTP | Y |
EXPORTER: teap session key seed | Y |
Exporter Value | Recommended |
--------------------------------|-------------|
client finished | Y |
server finished | Y |
master secret | Y |
key expansion | Y |
client EAP encryption | Y |
ttls keying material | N |
ttls challenge | N |
EXTRACTOR-dtls_srtp | Y |
EXPORTER_DTLS_OVER_SCTP | Y |
EXPORTER: teap session key seed | Y |
To provide additional information for the designated experts, IANA has added the following notes:
为了向指定专家提供更多信息，IANA增加了以下注释：
Note: The role of the designated expert is described in RFC 8447. The designated expert [RFC8126] ensures that the specification is publicly available. It is sufficient to have an Internet-Draft (that is posted and never published as an RFC) or a document from another standards body, industry consortium, university site, etc. The expert may provide more in-depth reviews, but their approval should not be taken as an endorsement of the exporter label. The expert also verifies that the label is a string consisting of printable ASCII characters beginning with "EXPORTER". IANA MUST also verify that one label is not a prefix of any other label. For example, labels "key" or "master secretary" are forbidden.
注：RFC 8447中描述了指定专家的角色。指定的专家[RFC8126]确保规范是公开的。只要有一份互联网草案（以RFC形式发布且从未发布）或来自其他标准机构、行业联盟、大学网站等的文件就足够了。专家可以提供更深入的审查，但他们的批准不应被视为对出口商标签的认可。专家还验证标签是否是由以“EXPORTER”开头的可打印ASCII字符组成的字符串。IANA还必须验证一个标签不是任何其他标签的前缀。例如，禁止使用“钥匙”或“总秘书”标签。
Note: If an item is not marked as "Recommended", it does not necessarily mean that it is flawed; rather, it indicates that the item either has not been through the IETF consensus process, has limited applicability, or is intended only for specific use cases.
注：如果一个项目没有标记为“推荐”，并不一定意味着它有缺陷；相反，它表明该项目要么未通过IETF共识过程，要么适用性有限，要么仅用于特定用例。
IANA has updated the reference for this registry to also refer to this document.
IANA已更新了该注册中心的参考，以同时参考本文件。
IANA has added the following entry to the TLS Alerts registry; the entry was omitted from the IANA instructions in [RFC7301]:
IANA已将以下条目添加到TLS警报注册表中：；[RFC7301]中的IANA指令省略了该条目：
120 no_application_protocol Y [RFC7301] [RFC8447]
120无应用程序协议Y[RFC7301][RFC8447]
Experience has shown that the IETF Consensus registry policy for TLS Certificate Types is too strict. Based on WG consensus, the decision was taken to change registration policy to Specification Required [RFC8126] while reserving a small part of the code space for private use. Therefore, IANA has changed the TLS Certificate Types registry as follows:
经验表明，针对TLS证书类型的IETF一致注册策略过于严格。基于工作组的共识，决定将注册政策更改为所需规范[RFC8126]，同时保留一小部分代码空间供私人使用。因此，IANA已将TLS证书类型注册表更改如下：
o Changed the registry policy to:
o 将注册表策略更改为：
Values in the range 0-223 (decimal) are assigned via Specification Required [RFC8126]. Values in the range 224-255 (decimal) are reserved for Private Use [RFC8126].
0-223（十进制）范围内的值通过所需规范[RFC8126]分配。224-255（十进制）范围内的值保留供私人使用[RFC8126]。
o Added a "Recommended" column to the registry. X.509 and Raw Public Key are "Y". All others are "N". The "Recommended" column is assigned a value of "N" unless explicitly requested, and adding a value with a "Recommended" value of "Y" requires Standards Action [RFC8126]. IESG Approval is REQUIRED for a Y->N transition.
o 在注册表中添加了“推荐”列。X.509和原始公钥为“Y”。其他的都是“N”。除非明确要求，“推荐”列的值为“N”，添加“推荐”值为“Y”的值需要标准操作[RFC8126]。Y->N转换需要IESG批准。
See Section 17 for additional information about the designated expert pool.
有关指定专家库的更多信息，请参见第17节。
IANA has added the following notes:
IANA增加了以下注释：
Note: The role of the designated expert is described in RFC 8447. The designated expert [RFC8126] ensures that the specification is publicly available. It is sufficient to have an Internet-Draft (that is posted and never published as an RFC) or a document from another standards body, industry consortium, university site, etc. The expert may provide more in-depth reviews, but their approval should not be taken as an endorsement of the certificate type.
注：RFC 8447中描述了指定专家的角色。指定的专家[RFC8126]确保规范是公开的。只要有一份互联网草案（发布且从未作为RFC发布）或另一标准机构、行业联盟、大学网站等提供的文件就足够了。专家可以提供更深入的审查，但他们的批准不应被视为对证书类型的认可。
Note: If an item is not marked as "Recommended", it does not necessarily mean that it is flawed; rather, it indicates that the item either has not been through the IETF consensus process, has limited applicability, or is intended only for specific use cases.
注：如果一个项目没有标记为“推荐”，并不一定意味着它有缺陷；相反，它表明该项目要么未通过IETF共识过程，要么适用性有限，要么仅用于特定用例。
IANA has updated the reference for this registry to also refer this document.
IANA已更新此注册表的参考，以同时参考此文档。
To make it clear that (D)TLS 1.3 has orphaned certain registries (i.e., they are only applicable to version of (D)TLS protocol versions prior to 1.3), IANA:
为了明确说明（D）TLS 1.3已孤立了某些注册表（即，它们仅适用于（D）TLS 1.3之前的协议版本），IANA：
o has added the following to the TLS Compression Method Identifiers registry [RFC3749]:
o 已将以下内容添加到TLS压缩方法标识符注册表[RFC3749]：
Note: Value 0 (NULL) is the only value in this registry applicable to (D)TLS protocol version 1.3 or later.
注意：值0（NULL）是此注册表中唯一适用于（D）TLS协议版本1.3或更高版本的值。
o has added the following to the TLS HashAlgorithm [RFC5246] and TLS SignatureAlgorithm registries [RFC5246]:
o 已将以下内容添加到TLS哈希算法[RFC5246]和TLS签名算法注册表[RFC5246]：
Note: The values in this registry are only applicable to (D)TLS protocol versions prior to 1.3. (D)TLS 1.3 and later versions' values are registered in the TLS SignatureScheme registry.
注：此注册表中的值仅适用于1.3之前的（D）TLS协议版本。（D） TLS 1.3及更高版本的值在TLS SignatureScheme注册表中注册。
o has updated the "Reference" field in the TLS Compression Method Identifiers, TLS HashAlgorithm and TLS SignatureAlgorithm registries to also refer to this document.
o 更新了TLS压缩方法标识符、TLS HashAlgorithm和TLS SignatureAlgorithm注册表中的“Reference”字段，以同时参考本文档。
o has updated the TLS HashAlgorithm registry to list values 7 and 9-223 as "Reserved" and the TLS SignatureAlgorithm registry to list values 4-6 and 9-223 as "Reserved".
o 已更新TLS HashAlgorithm注册表，将值7和9-223列为“保留”，并更新TLS SignatureAlgorithm注册表，将值4-6和9-223列为“保留”。
o has added the following to the TLS ClientCertificateType Identifiers registry [RFC5246]:
o 已将以下内容添加到TLS ClientCertificateType标识符注册表[RFC5246]：
Note: The values in this registry are only applicable to (D)TLS protocol versions prior to 1.3.
注：此注册表中的值仅适用于1.3之前的（D）TLS协议版本。
Despite the fact that the TLS HashAlgorithm and SignatureAlgorithm registries are orphaned, it is still important to warn implementers of pre-TLS1.3 implementations about the dangers of blindly implementing cryptographic algorithms. Therefore, IANA has added the following warning to the TLS HashAlgorithm and SignatureAlgorithm registries:
尽管TLS HashAlgorithm和SignatureAlgorithm注册表是孤立的，但仍有必要提醒TLS1.3之前实现的实现者盲目实现加密算法的危险。因此，IANA向TLS HashAlgorithm和SignatureAlgorithm注册表添加了以下警告：
WARNING: Cryptographic algorithms and parameters will be broken or weakened over time. Blindly implementing the cryptographic algorithms listed here is not advised. Implementers and users need to check that the cryptographic algorithms listed continue to provide the expected level of security.
警告：随着时间的推移，加密算法和参数将被破坏或削弱。不建议盲目实施此处列出的加密算法。实现者和用户需要检查列出的加密算法是否继续提供预期的安全级别。
IANA has added the following warning and note to the TLS SignatureScheme registry:
IANA在TLS SignatureScheme注册表中添加了以下警告和注释：
WARNING: Cryptographic algorithms and parameters will be broken or weakened over time. Blindly implementing signature schemes listed here is not advised. Implementers and users need to check that the cryptographic algorithms listed continue to provide the expected level of security.
警告：随着时间的推移，加密算法和参数将被破坏或削弱。不建议盲目实现此处列出的签名方案。实现者和用户需要检查列出的加密算法是否继续提供预期的安全级别。
Note: As specified in [RFC8126], assignments made in the Private Use space are not generally useful for broad interoperability. It is the responsibility of those making use of the Private Use range to ensure that no conflicts occur (within the intended scope of use). For widespread experiments, temporary reservations are available.
注：如[RFC8126]中所述，在私人使用空间中进行的分配对于广泛的互操作性通常不有用。使用私人使用范围的人有责任确保不会发生冲突（在预期使用范围内）。对于广泛的实验，可以临时保留。
IANA has added the following notes to the TLS PskKeyExchangeMode registry:
IANA已将以下注释添加到TLS PskKeyExchangeMode注册表中：
Note: If an item is not marked as "Recommended", it does not necessarily mean that it is flawed; rather, it indicates that the item either has not been through the IETF consensus process, has limited applicability, or is intended only for specific use cases.
注：如果一个项目没有标记为“推荐”，并不一定意味着它有缺陷；相反，它表明该项目要么未通过IETF共识过程，要么适用性有限，要么仅用于特定用例。
Note: The role of the designated expert is described in RFC 8447. The designated expert [RFC8126] ensures that the specification is publicly available. It is sufficient to have an Internet-Draft (that is posted and never published as an RFC) or a document from another standards body, industry consortium, university site, etc. The expert may provide more in depth reviews, but their approval should not be taken as an endorsement of the key exchange mode.
注：RFC 8447中描述了指定专家的角色。指定的专家[RFC8126]确保规范是公开的。只要有一份互联网草案（以RFC形式发布且从未发布）或来自其他标准机构、行业联盟、大学网站等的文件就足够了。专家可以提供更深入的审查，但他们的批准不应被视为对密钥交换模式的认可。
Specification Required [RFC8126] registry requests are registered after a three-week review period on the <tls-reg-review@ietf.org> mailing list, on the advice of one or more designated experts. However, to allow for the allocation of values prior to publication, the designated experts may approve registration once they are satisfied that such a specification will be published.
所需规范[RFC8126]注册表请求在三周审查期后在<tls reg-review@ietf.org>根据一名或多名指定专家的建议，提供邮件列表。但是，为了允许在发布之前分配值，指定专家在确信此类规范将发布后，可批准注册。
Registration requests sent to the mailing list for review SHOULD use an appropriate subject (e.g., "Request to register value in TLS bar registry").
发送至邮件列表供审查的注册请求应使用适当的主题（例如，“请求在TLS bar注册表中注册值”）。
Within the review period, the designated experts will either approve or deny the registration request, communicating this decision to the review list and IANA. Denials SHOULD include an explanation and, if applicable, suggestions as to how to make the request successful. Registration requests that are undetermined for a period longer than 21 days can be brought to the IESG's attention (using the <iesg@ietf.org> mailing list) for resolution.
在审查期内，指定专家将批准或拒绝注册请求，并将此决定告知审查名单和IANA。拒绝应包括解释，以及（如适用）关于如何使请求成功的建议。超过21天未确定的注册请求可提请IESG注意（使用<iesg@ietf.org>邮件列表）以供解决。
Criteria that SHOULD be applied by the designated experts includes determining whether the proposed registration duplicates existing functionality, whether it is likely to be of general applicability or useful only for a single application, and whether the registration description is clear.
指定专家应适用的标准包括确定拟议登记是否与现有功能重复，是否可能具有普遍适用性或仅对单一申请有用，以及登记说明是否明确。
IANA MUST only accept registry updates from the designated experts and SHOULD direct all requests for registration to the review mailing list.
IANA必须只接受指定专家的注册更新，并将所有注册请求发送至审查邮件列表。
It is suggested that multiple designated experts be appointed who are able to represent the perspectives of different applications using this specification, in order to enable broadly informed review of registration decisions. In cases where a registration decision could be perceived as creating a conflict of interest for a particular Expert, that Expert SHOULD defer to the judgment of the other Experts.
建议任命多名指定专家，他们能够代表使用本规范的不同应用的观点，以便对注册决定进行广泛知情的审查。如果注册决定可能被视为对某一专家造成利益冲突，该专家应服从其他专家的判断。
The change to Specification Required from IETF Review lowers the amount of review provided by the WG for cipher suites and supported groups. This change reflects reality in that the WG essentially provided no cryptographic review of the cipher suites or supported groups. This was especially true of national cipher suites.
IETF评审要求的规范变更降低了工作组对密码套件和受支持组的评审量。这一变化反映了一个现实，即工作组基本上没有对密码套件或受支持的组进行密码审查。国家密码套件尤其如此。
Recommended algorithms are regarded as secure for general use at the time of registration; however, cryptographic algorithms and parameters will be broken or weakened over time. It is possible that the "Recommended" status in the registry lags behind the most recent advances in cryptanalysis. Implementers and users need to check that the cryptographic algorithms listed continue to provide the expected level of security.
推荐的算法在注册时被视为安全的通用算法；然而，随着时间的推移，加密算法和参数将被破坏或削弱。注册表中的“推荐”状态可能落后于密码分析的最新进展。实现者和用户需要检查列出的加密算法是否继续提供预期的安全级别。
Designated experts ensure the specification is publicly available. They may provide more in-depth reviews. Their review should not be taken as an endorsement of the cipher suite, extension, supported group, etc.
指定的专家确保规范是公开的。它们可能提供更深入的审查。他们的审查不应被视为对密码套件、扩展、支持组等的认可。
This document is entirely about changes to TLS-related IANA registries.
本文档完全是关于TLS相关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>.
[RFC3749] Hollenbeck, S., "Transport Layer Security Protocol Compression Methods", RFC 3749, DOI 10.17487/RFC3749, May 2004, <https://www.rfc-editor.org/info/rfc3749>.
[RFC3749]Hollenbeck，S.，“传输层安全协议压缩方法”，RFC 3749，DOI 10.17487/RFC3749，2004年5月<https://www.rfc-editor.org/info/rfc3749>.
[RFC4680] Santesson, S., "TLS Handshake Message for Supplemental Data", RFC 4680, DOI 10.17487/RFC4680, October 2006, <https://www.rfc-editor.org/info/rfc4680>.
[RFC4680]Santesson，S.，“补充数据的TLS握手信息”，RFC 4680，DOI 10.17487/RFC4680，2006年10月<https://www.rfc-editor.org/info/rfc4680>.
[RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, "Transport Layer Security (TLS) Session Resumption without Server-Side State", RFC 5077, DOI 10.17487/RFC5077, January 2008, <https://www.rfc-editor.org/info/rfc5077>.
[RFC5077]Salowey，J.，Zhou，H.，Eronen，P.，和H.Tschofenig，“无服务器端状态的传输层安全（TLS）会话恢复”，RFC 5077，DOI 10.17487/RFC5077，2008年1月<https://www.rfc-editor.org/info/rfc5077>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, <https://www.rfc-editor.org/info/rfc5246>.
[RFC5246]Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.2”，RFC 5246，DOI 10.17487/RFC5246，2008年8月<https://www.rfc-editor.org/info/rfc5246>.
[RFC5705] Rescorla, E., "Keying Material Exporters for Transport Layer Security (TLS)", RFC 5705, DOI 10.17487/RFC5705, March 2010, <https://www.rfc-editor.org/info/rfc5705>.
[RFC5705]Rescorla，E.“传输层安全（TLS）关键材料导出器”，RFC 5705，DOI 10.17487/RFC5705，2010年3月<https://www.rfc-editor.org/info/rfc5705>.
[RFC5878] Brown, M. and R. Housley, "Transport Layer Security (TLS) Authorization Extensions", RFC 5878, DOI 10.17487/RFC5878, May 2010, <https://www.rfc-editor.org/info/rfc5878>.
[RFC5878]Brown，M.和R.Housley，“传输层安全（TLS）授权扩展”，RFC 5878，DOI 10.17487/RFC5878，2010年5月<https://www.rfc-editor.org/info/rfc5878>.
[RFC6520] Seggelmann, R., Tuexen, M., and M. Williams, "Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) Heartbeat Extension", RFC 6520, DOI 10.17487/RFC6520, February 2012, <https://www.rfc-editor.org/info/rfc6520>.
[RFC6520]Seggelmann，R.，Tuexen，M.和M.Williams，“传输层安全性（TLS）和数据报传输层安全性（DTLS）心跳扩展”，RFC 6520，DOI 10.17487/RFC6520，2012年2月<https://www.rfc-editor.org/info/rfc6520>.
[RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, "Transport Layer Security (TLS) Application-Layer Protocol Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, July 2014, <https://www.rfc-editor.org/info/rfc7301>.
[RFC7301]Friedl，S.，Popov，A.，Langley，A.，和E.Stephan，“传输层安全（TLS）应用层协议协商扩展”，RFC 7301，DOI 10.17487/RFC7301，2014年7月<https://www.rfc-editor.org/info/rfc7301>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>.
[RFC8126]Cotton，M.，Leiba，B.，和T.Narten，“在RFC中编写IANA考虑事项部分的指南”，BCP 26，RFC 8126，DOI 10.17487/RFC8126，2017年6月<https://www.rfc-editor.org/info/rfc8126>.
[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>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, <https://www.rfc-editor.org/info/rfc8446>.
[RFC8446]Rescorla，E.“传输层安全（TLS）协议版本1.3”，RFC 8446，DOI 10.17487/RFC8446，2018年8月<https://www.rfc-editor.org/info/rfc8446>.
[RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., and T. Wright, "Transport Layer Security (TLS) Extensions", RFC 4366, DOI 10.17487/RFC4366, April 2006, <https://www.rfc-editor.org/info/rfc4366>.
[RFC4366]Blake Wilson，S.，Nystrom，M.，Hopwood，D.，Mikkelsen，J.，和T.Wright，“传输层安全（TLS）扩展”，RFC 4366，DOI 10.17487/RFC4366，2006年4月<https://www.rfc-editor.org/info/rfc4366>.
[RFC6961] Pettersen, Y., "The Transport Layer Security (TLS) Multiple Certificate Status Request Extension", RFC 6961, DOI 10.17487/RFC6961, June 2013, <https://www.rfc-editor.org/info/rfc6961>.
[RFC6961]Pettersen，Y，“传输层安全性（TLS）多证书状态请求扩展”，RFC 6961，DOI 10.17487/RFC69611913年6月<https://www.rfc-editor.org/info/rfc6961>.
[RFC8422] Nir, Y., Josefsson, S., and M. Pegourie-Gonnard, "Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS) Versions 1.2 and Earlier", RFC 8422, DOI 10.17487/RFC8422, August 2018, <https://www.rfc-editor.org/info/rfc8422>.
[RFC8422]Nir，Y.，Josefsson，S.，和M.Pegourie Gonnard，“传输层安全（TLS）版本1.2及更早版本的椭圆曲线密码（ECC）套件”，RFC 8422，DOI 10.17487/RFC8422，2018年8月<https://www.rfc-editor.org/info/rfc8422>.
[TOKBIND] Popov, A., Nystrom, M., Balfanz, D., and A. Langley, "Transport Layer Security (TLS) Extension for Token Binding Protocol Negotiation", Work in Progress, draft-ietf-tokbind-negotiation-14, May 2018.
[TOKBIND]Popov，A.，Nystrom，M.，Balfanz，D.，和A.Langley，“令牌绑定协议协商的传输层安全（TLS）扩展”，正在进行的工作，草案-ietf-TOKBIND-Negotiation-14，2018年5月。
Authors' Addresses
作者地址
Joe Salowey Tableau Software
Joe Salowey Tableau软件
Email: joe@salowey.net
Email: joe@salowey.net
Sean Turner sn3rd
肖恩·特纳
Email: sean@sn3rd.com
Email: sean@sn3rd.com