Internet Engineering Task Force (IETF) J. Lennox
Request for Comments: 8122 Vidyo
Obsoletes: 4572 C. Holmberg
Category: Standards Track Ericsson
ISSN: 2070-1721 March 2017
Internet Engineering Task Force (IETF) J. Lennox
Request for Comments: 8122 Vidyo
Obsoletes: 4572 C. Holmberg
Category: Standards Track Ericsson
ISSN: 2070-1721 March 2017
Connection-Oriented Media Transport over the Transport Layer Security (TLS) Protocol in the Session Description Protocol (SDP)
会话描述协议（SDP）中传输层安全（TLS）协议上的面向连接的媒体传输
Abstract
摘要
This document specifies how to establish secure connection-oriented media transport sessions over the Transport Layer Security (TLS) protocol using the Session Description Protocol (SDP). It defines the SDP protocol identifier, 'TCP/TLS'. It also defines the syntax and semantics for an SDP 'fingerprint' attribute that identifies the certificate that will be presented for the TLS session. This mechanism allows media transport over TLS connections to be established securely, so long as the integrity of session descriptions is assured.
本文档指定如何使用会话描述协议（SDP）通过传输层安全（TLS）协议建立安全的面向连接的媒体传输会话。它定义了SDP协议标识符“TCP/TLS”。它还定义了SDP“指纹”属性的语法和语义，该属性标识将为TLS会话提供的证书。这种机制允许通过TLS连接安全地建立媒体传输，只要会话描述的完整性得到保证。
This document obsoletes RFC 4572 by clarifying the usage of multiple fingerprints.
本文件通过澄清多重指纹的使用，淘汰了RFC 4572。
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 http://www.rfc-editor.org/info/rfc8122.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc8122.
Copyright Notice
版权公告
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2017 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Changes from RFC 4572 . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. SDP Operational Modes . . . . . . . . . . . . . . . . . . 4
3.2. Threat Model . . . . . . . . . . . . . . . . . . . . . . 5
3.3. The Need for Self-Signed Certificates . . . . . . . . . . 6
3.4. Example SDP Description for TLS Connection . . . . . . . 6
4. Protocol Identifiers . . . . . . . . . . . . . . . . . . . . 7
5. Fingerprint Attribute . . . . . . . . . . . . . . . . . . . . 7
5.1. Multiple Fingerprints . . . . . . . . . . . . . . . . . . 9
6. Endpoint Identification . . . . . . . . . . . . . . . . . . . 10
6.1. Certificate Choice . . . . . . . . . . . . . . . . . . . 10
6.2. Certificate Presentation . . . . . . . . . . . . . . . . 11
7. Security Considerations . . . . . . . . . . . . . . . . . . . 12
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
9.1. Normative References . . . . . . . . . . . . . . . . . . 15
9.2. Informative References . . . . . . . . . . . . . . . . . 16
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Changes from RFC 4572 . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. SDP Operational Modes . . . . . . . . . . . . . . . . . . 4
3.2. Threat Model . . . . . . . . . . . . . . . . . . . . . . 5
3.3. The Need for Self-Signed Certificates . . . . . . . . . . 6
3.4. Example SDP Description for TLS Connection . . . . . . . 6
4. Protocol Identifiers . . . . . . . . . . . . . . . . . . . . 7
5. Fingerprint Attribute . . . . . . . . . . . . . . . . . . . . 7
5.1. Multiple Fingerprints . . . . . . . . . . . . . . . . . . 9
6. Endpoint Identification . . . . . . . . . . . . . . . . . . . 10
6.1. Certificate Choice . . . . . . . . . . . . . . . . . . . 10
6.2. Certificate Presentation . . . . . . . . . . . . . . . . 11
7. Security Considerations . . . . . . . . . . . . . . . . . . . 12
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
9.1. Normative References . . . . . . . . . . . . . . . . . . 15
9.2. Informative References . . . . . . . . . . . . . . . . . 16
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
The Session Description Protocol (SDP) [8] provides a general-purpose format for describing multimedia sessions in announcements or invitations. For many applications, it is desirable to establish, as part of a multimedia session, a media stream that uses a connection-oriented transport. RFC 4145, "TCP-Based Media Transport in the Session Description Protocol (SDP)" [7], specifies a general mechanism for describing and establishing such connection-oriented streams; however, the only transport protocol it directly supports is TCP. In many cases, session participants wish to provide confidentiality, data integrity, and authentication for their media sessions. Therefore, this document extends the TCP-Based Media specification to allow session descriptions to describe media sessions that use the Transport Layer Security (TLS) protocol [10].
会话描述协议（SDP）[8]提供了一种通用格式，用于描述公告或邀请中的多媒体会话。对于许多应用，希望建立使用面向连接的传输的媒体流，作为多媒体会话的一部分。RFC 4145，“会话描述协议（SDP）中基于TCP的媒体传输”[7]，规定了用于描述和建立此类面向连接流的通用机制；但是，它直接支持的唯一传输协议是TCP。在许多情况下，会话参与者希望为其媒体会话提供机密性、数据完整性和身份验证。因此，本文档扩展了基于TCP的媒体规范，允许会话描述描述使用传输层安全（TLS）协议的媒体会话[10]。
The TLS protocol allows applications to communicate over a channel that provides confidentiality and data integrity. The TLS specification, however, does not specify how specific protocols establish and use this secure channel; particularly, TLS leaves the question of how to interpret and validate authentication certificates as an issue for the protocols that run over TLS. This document specifies such usage for the case of connection-oriented media transport.
TLS协议允许应用程序通过提供机密性和数据完整性的通道进行通信。然而，TLS规范并未规定特定协议如何建立和使用该安全通道；特别是，TLS将如何解释和验证身份验证证书的问题留给了在TLS上运行的协议。本文档规定了面向连接的媒体传输的这种用法。
Complicating this issue, endpoints exchanging media will often be unable to obtain authentication certificates signed by a well-known root certification authority (CA). Most certificate authorities charge for signed certificates, particularly host-based certificates; additionally, there is a substantial administrative overhead to obtaining signed certificates, as certification authorities must be able to confirm that they are issuing the signed certificates to the correct party. Furthermore, in many cases the endpoints' IP addresses and host names are dynamic, for example, they may be obtained from DHCP. It is impractical to obtain a CA-signed certificate valid for the duration of a DHCP lease. For such hosts, self-signed certificates are usually the only option. This specification defines a mechanism that allows self-signed certificates to be used securely, provided that the integrity of the SDP description is assured. It allows for endpoints to include a secure hash of their certificate, known as the "certificate fingerprint", within the session description. Provided that the fingerprint of the offered certificate matches the one in the session description, end hosts can trust even self-signed certificates.
使此问题复杂化的是，交换媒体的端点通常无法获得由知名的根证书颁发机构（CA）签署的身份验证证书。大多数证书颁发机构对签名证书，特别是基于主机的证书收取费用；此外，由于认证机构必须能够确认他们正在向正确的一方颁发已签署的证书，因此获取已签署的证书需要大量的管理开销。此外，在许多情况下，端点的IP地址和主机名是动态的，例如，它们可以从DHCP获得。获取在DHCP租约期间有效的CA签名证书是不切实际的。对于此类主机，自签名证书通常是唯一的选择。本规范定义了一种允许安全使用自签名证书的机制，前提是确保SDP描述的完整性。它允许端点在会话描述中包含其证书的安全哈希，称为“证书指纹”。如果提供的证书的指纹与会话描述中的指纹匹配，则终端主机甚至可以信任自签名证书。
The rest of this document is laid out as follows. An overview of the problem and threat model is given in Section 3. Section 4 gives the basic mechanism for establishing TLS-based connected-oriented media in SDP. Section 5 describes the SDP fingerprint attribute, which, assuming that the integrity of the SDP content is assured, allows the secure use of self-signed certificates. Section 6 describes which X.509 certificates are presented and how they are used in TLS. Section 7 discusses additional security considerations.
本文件的其余部分如下所示。第3节概述了问题和威胁模型。第4节给出了在SDP中建立基于TLS的面向连接媒体的基本机制。第5节描述了SDP指纹属性，假设SDP内容的完整性得到保证，该属性允许安全使用自签名证书。第6节描述了提供的X.509证书以及它们在TLS中的使用方式。第7节讨论了其他安全注意事项。
This document obsoletes RFC 4572 [20] but remains backwards compatible with older implementations. The changes from RFC 4572 [20] are as follows:
本文档淘汰了RFC 4572[20]，但仍与旧版本的实现向后兼容。RFC 4572[20]的变化如下：
o clarifies that multiple 'fingerprint' attributes can be used to carry fingerprints (calculated using different hash functions) associated with a given certificate and to carry fingerprints associated with multiple certificates.
o 阐明多个“指纹”属性可用于携带与给定证书关联的指纹（使用不同的哈希函数计算），以及携带与多个证书关联的指纹。
o clarifies the fingerprint matching procedure when multiple fingerprints are provided.
o 阐明提供多个指纹时的指纹匹配过程。
o updates the preferred hash function with a stronger cipher suite and removes the requirement to use the same hash function for calculating a certificate fingerprint and certificate signature.
o 使用更强的密码套件更新首选哈希函数，并删除使用相同哈希函数计算证书指纹和证书签名的要求。
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 RFC 2119 [3].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[3]中所述进行解释。
This section discusses the threat model that motivates TLS transport for connection-oriented media streams. It also discusses, in more detail, the need for end systems to use self-signed certificates.
本节讨论激励面向连接的媒体流TLS传输的威胁模型。它还更详细地讨论了终端系统使用自签名证书的必要性。
There are two principal operational modes for multimedia sessions: advertised and offer-answer. Advertised sessions are the simpler mode. In this mode, a server publishes, in some manner, an SDP session description of a multimedia session it is making available. The classic example of this mode of operation is the Session Announcement Protocol (SAP) [15], in which SDP session descriptions are periodically transmitted to a well-known multicast group.
多媒体会话有两种主要的操作模式：广告和提供答案。广告会话是更简单的模式。在这种模式下，服务器以某种方式发布其所提供的多媒体会话的SDP会话描述。这种操作模式的典型示例是会话公告协议（SAP）[15]，在该协议中，SDP会话描述定期传输到知名的多播组。
Traditionally, these descriptions involve multicast conferences, but unicast sessions are also possible. (Obviously, connection-oriented media cannot use multicast.) Recipients of a session description connect to the addresses published in the session description. These recipients may not have been previously known to the advertiser of the session description.
传统上，这些描述涉及多播会议，但单播会话也是可能的。（显然，面向连接的媒体不能使用多播。）会话描述的收件人连接到会话描述中发布的地址。会话描述的广告客户可能以前不知道这些收件人。
Alternatively, SDP conferences can operate in offer-answer mode [4]. This mode allows two participants in a multimedia session to negotiate the multimedia session between them. In this model, one participant offers the other a description of the desired session from its perspective, and the other participant answers with the desired session from its own perspective. In this mode, each of the participants in the session has knowledge of the other one. This is the mode of operation used by the Session Initiation Protocol (SIP) [17].
或者，SDP会议可以在提供-应答模式下运行[4]。此模式允许多媒体会话中的两个参与者协商他们之间的多媒体会话。在这个模型中，一个参与者从自己的角度向另一个参与者提供所需会话的描述，另一个参与者从自己的角度回答所需会话。在这种模式下，会话中的每个参与者都知道另一个。这是会话启动协议（SIP）[17]使用的操作模式。
Participants in multimedia conferences often wish to guarantee confidentiality, data integrity, and authentication for their media sessions. This section describes various types of attackers and the ways they attempt to violate these guarantees. It then describes how the TLS protocol can be used to thwart the attackers.
多媒体会议的参与者通常希望保证其媒体会话的机密性、数据完整性和身份验证。本节介绍各种类型的攻击者以及他们试图违反这些保证的方式。然后描述了如何使用TLS协议阻止攻击者。
The simplest type of attacker is one who listens passively to the traffic associated with a multimedia session. This attacker might, for example, be on the same local-area or wireless network as one of the participants in a conference. This sort of attacker does not threaten a connection's data integrity or authentication, and almost any operational mode of TLS can provide media-stream confidentiality.
最简单的攻击者类型是被动监听与多媒体会话相关的流量的攻击者。例如，该攻击者可能与会议参与者之一位于同一局域网或无线网络上。此类攻击者不会威胁连接的数据完整性或身份验证，并且几乎任何TLS操作模式都可以提供媒体流机密性。
More sophisticated is an attacker who can send his own data traffic over the network, but who cannot modify or redirect valid traffic. In SDP's 'advertised' operational mode, this can barely be considered an attack; media sessions are expected to be initiated from anywhere on the network. In SDP's offer-answer mode, however, this type of attack is more serious. An attacker could initiate a connection to one or both of the endpoints of a session, thus impersonating an endpoint or acting as a man in the middle to listen in on their communications. To thwart these attacks, TLS uses endpoint certificates. So long as the certificates' private keys have not been compromised, the endpoints have an externally trusted mechanism (most commonly, a mutually trusted certification authority) to validate certificates. Because the endpoints know what certificate identity to expect, endpoints can be certain that such an attack has not taken place.
更复杂的是，攻击者可以通过网络发送自己的数据流量，但不能修改或重定向有效流量。在SDP的“广告”作战模式下，这几乎不能被视为攻击；媒体会话预计将从网络上的任何位置启动。然而，在SDP的提供-应答模式下，这种类型的攻击更为严重。攻击者可以启动连接到会话的端点中的一个或两个端点，从而模拟端点或充当中间人来监听它们的通信。为了阻止这些攻击，TLS使用端点证书。只要证书的私钥没有被泄露，端点就有一个外部可信机制（最常见的是相互信任的证书颁发机构）来验证证书。因为端点知道预期的证书标识，所以端点可以确定没有发生此类攻击。
Finally, the most serious type of attacker is one who can modify or redirect session descriptions: for example, a compromised or malicious SIP proxy server. Neither TLS itself nor any mechanisms that use it can protect an SDP session against such an attacker. Instead, the SDP description itself must be secured through some mechanism; SIP, for example, defines how S/MIME [22] can be used to secure session descriptions.
最后，最严重的攻击者类型是能够修改或重定向会话描述的攻击者：例如，受损或恶意的SIP代理服务器。TLS本身和使用它的任何机制都无法保护SDP会话免受此类攻击者的攻击。相反，SDP描述本身必须通过某种机制加以保护；例如，SIP定义了如何使用S/MIME[22]来保护会话描述。
SDP session descriptions are created by any endpoint that needs to participate in a multimedia session. In many cases, such as SIP phones, such endpoints have dynamically configured IP addresses and host names and must be deployed with nearly zero configuration. For such an endpoint, it is, for practical purposes, impossible to obtain a certificate signed by a well-known certification authority.
SDP会话描述由需要参与多媒体会话的任何端点创建。在许多情况下，例如SIP电话，这样的端点具有动态配置的IP地址和主机名，并且必须以几乎为零的配置进行部署。对于这样一个端点，出于实际目的，不可能获得由知名的证书颁发机构签署的证书。
If two endpoints have no prior relationship, self-signed certificates cannot generally be trusted, as there is no guarantee that an attacker is not launching a man-in-the-middle attack. Fortunately, however, if the integrity of SDP session descriptions can be assured, it is possible to consider those SDP descriptions themselves as a prior relationship: certificates can be securely described in the session description itself. This is done by providing a secure hash of a certificate, or "certificate fingerprint", as an SDP attribute; this mechanism is described in Section 5.
如果两个端点没有优先关系，则自签名证书通常不可信，因为无法保证攻击者不会发起中间人攻击。然而，幸运的是，如果可以确保SDP会话描述的完整性，则可以将这些SDP描述本身看作先验关系：证书可以在会话描述本身中安全地描述。这是通过提供证书的安全散列或“证书指纹”作为SDP属性来实现的；第5节介绍了该机制。
Figure 1 illustrates an SDP offer that signals the availability of a T.38 fax session over TLS. For the purpose of brevity, the main portion of the session description is omitted in the example, showing only the 'm' line and its attributes. (This example is the same as the first one in RFC 4145 [7], except for the proto parameter and the fingerprint attribute.) See the subsequent sections for explanations of the example's TLS-specific attributes.
图1显示了一个SDP产品，它通过TLS发出T.38传真会话可用性的信号。为简洁起见，本例中省略了会话描述的主要部分，仅显示“m”行及其属性。（该示例与RFC 4145[7]中的第一个示例相同，但proto参数和指纹属性除外。）有关示例TLS特定属性的解释，请参阅后续章节。
Note: due to RFC formatting conventions, this document splits SDP across lines whose content would exceed 72 characters. A backslash character marks where this line folding has taken place. This backslash and its trailing CRLF and whitespace would not appear in actual SDP content.
注意：由于RFC格式约定，本文档在内容超过72个字符的行之间拆分SDP。反斜杠字符标记此折线发生的位置。此反斜杠及其尾部的CRLF和空格不会出现在实际的SDP内容中。
m=image 54111 TCP/TLS t38
c=IN IP4 192.0.2.2
a=setup:passive
a=connection:new
a=fingerprint:SHA-256 \
12:DF:3E:5D:49:6B:19:E5:7C:AB:4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF: \
3E:5D:49:6B:19:E5:7C:AB:4A:AD
a=fingerprint:SHA-1 \
4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB
m=image 54111 TCP/TLS t38
c=IN IP4 192.0.2.2
a=setup:passive
a=connection:new
a=fingerprint:SHA-256 \
12:DF:3E:5D:49:6B:19:E5:7C:AB:4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF: \
3E:5D:49:6B:19:E5:7C:AB:4A:AD
a=fingerprint:SHA-1 \
4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB
Figure 1: Example SDP Description Offering a TLS Media Stream
图1：提供TLS媒体流的示例SDP描述
The 'm' line in SDP specifies, among other items, the transport protocol to be used for the media in the session. See the "Media Descriptions" section of SDP [8] for a discussion on transport protocol identifiers.
SDP中的“m”行指定会话中媒体使用的传输协议，以及其他项。有关传输协议标识符的讨论，请参阅SDP[8]的“媒体描述”部分。
This specification defines the protocol identifier, 'TCP/TLS', which indicates that the media described will use the Transport Layer Security protocol [10] over TCP. (Using TLS over other transport protocols is not discussed in this document.) The 'TCP/TLS' protocol identifier describes only the transport protocol, not the upper-layer protocol. An 'm' line that specifies 'TCP/TLS' MUST further qualify the protocol using an fmt identifier to indicate the application being run over TLS.
本规范定义了协议标识符“TCP/TLS”，表示所述介质将通过TCP使用传输层安全协议[10]。（本文档不讨论在其他传输协议上使用TLS。）“TCP/TLS”协议标识符仅描述传输协议，而不描述上层协议。指定“TCP/TLS”的“m”行必须使用fmt标识符进一步限定协议，以指示正在TLS上运行的应用程序。
Media sessions described with this identifier follow the procedures defined in RFC 4145 [7]. They also use the SDP attributes defined in that specification, 'setup' and 'connection'.
使用此标识符描述的媒体会话遵循RFC 4145[7]中定义的过程。它们还使用该规范中定义的SDP属性“setup”和“connection”。
Parties to a TLS session indicate their identities by presenting authentication certificates as part of the TLS handshake procedure. Authentication certificates are X.509 [2] certificates, as profiled by RFCs 3279 [5], 5280 [11], and 4055 [6].
作为TLS握手过程的一部分，TLS会话的各方通过出示身份验证证书来指示其身份。身份验证证书是X.509[2]证书，如RFCs 3279[5]、5280[11]和4055[6]所述。
In order to associate media streams with connections and to prevent unauthorized barge-in attacks on the media streams, endpoints MUST provide a certificate fingerprint. If the X.509 certificate presented for the TLS connection matches the fingerprint presented in the SDP, the endpoint can be confident that the author of the SDP is indeed the initiator of the connection.
为了将媒体流与连接相关联，并防止对媒体流进行未经授权的闯入攻击，端点必须提供证书指纹。如果为TLS连接提供的X.509证书与SDP中提供的指纹匹配，则端点可以确信SDP的作者确实是连接的发起人。
A certificate fingerprint is a secure one-way hash of the Distinguished Encoding Rules (DER) form of the certificate. (Certificate fingerprints are widely supported by tools that manipulate X.509 certificates; for instance, the command "openssl x509 -fingerprint" causes the command-line tool of the openssl package to print a certificate fingerprint, and the certificate managers for Mozilla and Internet Explorer display them when viewing the details of a certificate.)
证书指纹是证书的可分辨编码规则（DER）形式的安全单向散列。（操作X.509证书的工具广泛支持证书指纹；例如，命令“openssl x509-fingerprint”使openssl包的命令行工具打印证书指纹，Mozilla和Internet Explorer的证书管理器在查看证书详细信息时显示指纹。）
A fingerprint is represented in SDP as an attribute (an 'a' line). It consists of the name of the hash function used, followed by the hash value itself. The hash value is represented as a sequence of uppercase hexadecimal bytes, separated by colons. The number of bytes is defined by the hash function. (This is the syntax used by openssl and by the browsers' certificate managers. It is different from the syntax used to represent hash values in, for example, HTTP digest authentication [24], which uses unseparated lowercase hexadecimal bytes. Consistency with other applications of fingerprints was considered more important.)
指纹在SDP中表示为属性（“A”行）。它由使用的哈希函数的名称，后跟哈希值本身组成。哈希值表示为大写十六进制字节序列，用冒号分隔。字节数由哈希函数定义。（这是openssl和浏览器的证书管理器使用的语法。它不同于HTTP摘要身份验证[24]中用于表示哈希值的语法，后者使用未分离的小写十六进制字节。与指纹的其他应用程序的一致性被认为更为重要。）
The formal syntax of the fingerprint attribute is given in Augmented Backus-Naur Form [9] in Figure 2. This syntax extends the BNF syntax of SDP [8].
指纹属性的形式语法在图2中以增广的Backus-Naur形式[9]给出。此语法扩展了SDP的BNF语法[8]。
attribute =/ fingerprint-attribute
属性=/指纹属性
fingerprint-attribute = "fingerprint" ":" hash-func SP fingerprint
指纹属性=“指纹”“：”哈希函数SP指纹
hash-func = "sha-1" / "sha-224" / "sha-256" /
"sha-384" / "sha-512" /
"md5" / "md2" / token
; Additional hash functions can only come
; from updates to RFC 3279
hash-func = "sha-1" / "sha-224" / "sha-256" /
"sha-384" / "sha-512" /
"md5" / "md2" / token
; Additional hash functions can only come
; from updates to RFC 3279
fingerprint = 2UHEX *(":" 2UHEX) ; Each byte in upper-case hex, separated ; by colons.
指纹=2UHEX*（“：”2UHEX）；每个字节以大写十六进制表示，分开；科隆。
UHEX = DIGIT / %x41-46 ; A-F uppercase
UHEX = DIGIT / %x41-46 ; A-F uppercase
Figure 2: Augmented Backus-Naur Syntax for the Fingerprint Attribute
图2:Fingerprint属性的扩展Backus Naur语法
Following RFC 3279 [5] as updated by RFC 4055 [6], the defined hash functions are 'SHA-1' [1] [16], 'SHA-224' [1], 'SHA-256' [1], 'SHA-384' [1], 'SHA-512' [1], 'MD5' [13], and 'MD2' [23], with 'SHA-256' preferred. A new IANA registry, named "Hash Function Textual Names",
在RFC 4055[6]更新的RFC 3279[5]之后，定义的哈希函数是'SHA-1'[1][16]、'SHA-224'[1]、'SHA-256'[1]、'SHA-384'[1]、'SHA-512'[1]、'MD5'[13]和'MD2'[23]，首选'SHA-256'。一个新的IANA注册表，名为“哈希函数文本名称”，
specified in Section 8, allows for the addition of future tokens, but they may only be added if they are included in RFCs that update or obsolete RFC 3279 [5].
第8节中规定，允许添加未来的令牌，但只有当它们包含在更新或废弃RFC 3279[5]的RFC中时，才可以添加它们。
Implementations compliant with this specification MUST NOT use the MD2 and MD5 hash functions to calculate fingerprints or to verify received fingerprints that have been calculated using them.
符合此规范的实现不得使用MD2和MD5哈希函数来计算指纹或验证已使用它们计算的接收指纹。
Note: The MD2 and MD5 hash functions are listed in this specification so that implementations can recognize them. Implementations that log unused hash functions might log occurrences of these algorithms differently to unknown hash algorithms.
注意：本规范中列出了MD2和MD5哈希函数，以便实现能够识别它们。记录未使用的散列函数的实现可能会以与未知散列算法不同的方式记录这些算法的出现。
The fingerprint attribute may be either a session-level or a media-level SDP attribute. If it is a session-level attribute, it applies to all TLS sessions for which no media-level fingerprint attribute is defined.
指纹属性可以是会话级或媒体级SDP属性。如果它是会话级属性，则适用于未定义媒体级指纹属性的所有TLS会话。
Multiple SDP fingerprint attributes can be associated with an 'm' line. This can occur if multiple fingerprints have been calculated for a certificate using different hash functions. It can also occur if one or more fingerprints associated with multiple certificates have been calculated. This might be needed if multiple certificates will be used for media associated with an 'm' line (e.g., if separate certificates are used for RTP and the RTP Control Protocol (RTCP)) or where it is not known which certificate will be used when the fingerprints are exchanged. In such cases, one or more fingerprints MUST be calculated for each possible certificate.
多个SDP指纹属性可以与“m”线关联。如果使用不同的哈希函数为证书计算了多个指纹，则可能会发生这种情况。如果计算了与多个证书关联的一个或多个指纹，也可能发生这种情况。如果多个证书将用于与“m”线相关联的介质（例如，如果RTP和RTP控制协议（RTCP）使用单独的证书），或者在交换指纹时不知道将使用哪个证书，则可能需要这样做。在这种情况下，必须为每个可能的证书计算一个或多个指纹。
An endpoint MUST, as a minimum, calculate a fingerprint using both the 'SHA-256' hash function algorithm and the hash function used to generate the signature on the certificate for each possible certificate. Including the hash from the signature algorithm ensures interoperability with strict implementations of RFC 4572 [20]. Either of these fingerprints MAY be omitted if the endpoint includes a hash with a stronger hash algorithm that it knows that the peer supports, if it is known that the peer does not support the hash algorithm, or if local policy mandates use of stronger algorithms.
端点必须至少使用“SHA-256”哈希函数算法和用于为每个可能的证书生成证书签名的哈希函数计算指纹。包括来自签名算法的哈希确保了与严格的RFC 4572实现的互操作性[20]。如果端点包括其知道对等方支持的具有更强散列算法的散列，如果已知对等方不支持散列算法，或者如果本地策略要求使用更强的算法，则可以省略这些指纹中的任何一个。
If fingerprints associated with multiple certificates are calculated, the same set of hash functions MUST be used to calculate fingerprints for each certificate associated with the 'm' line.
如果计算与多个证书关联的指纹，则必须使用同一组哈希函数来计算与“m”行关联的每个证书的指纹。
An endpoint MUST select the set of fingerprints that use its most preferred hash function (out of those offered by the peer) and verify that each certificate used matches one fingerprint out of that set.
端点必须选择使用其最首选散列函数（从对等方提供的散列函数中）的指纹集，并验证使用的每个证书是否与该集中的一个指纹匹配。
If a certificate does not match any such fingerprint, the endpoint MUST NOT establish the TLS connection.
如果证书与任何此类指纹不匹配，则端点不得建立TLS连接。
Note: The SDP fingerprint attribute does not contain a reference to a specific certificate. Endpoints need to compare the fingerprint with a certificate hash in order to look for a match.
注意：SDP指纹属性不包含对特定证书的引用。端点需要将指纹与证书哈希进行比较，以查找匹配项。
An X.509 certificate binds an identity and a public key. If SDP describing a TLS session is transmitted over a mechanism that provides integrity protection, a certificate asserting any syntactically valid identity MAY be used. For example, an SDP description sent over HTTP/TLS [14] or secured by S/MIME [22] MAY assert any identity in the certificate securing the media connection.
X.509证书绑定身份和公钥。如果描述TLS会话的SDP通过提供完整性保护的机制传输，则可以使用断言任何语法有效标识的证书。例如，通过HTTP/TLS[14]发送或由S/MIME[22]保护的SDP描述可以在保护媒体连接的证书中断言任何标识。
Security protocols that provide only hop-by-hop integrity protection (e.g., the SIPS scheme [17], SIP over TLS) are considered sufficiently secure to allow the mode in which any valid identity is accepted. However, see Section 7 for a discussion of some security implications of this fact.
仅提供逐跳完整性保护的安全协议（例如，SIPS方案[17]，TLS上的SIP）被视为足够安全，以允许接受任何有效身份的模式。但是，有关这一事实的一些安全影响的讨论，请参见第7节。
In situations where the SDP is not integrity-protected, the certificate provided for a TLS connection MUST certify an appropriate identity for the connection. In these scenarios, the certificate presented by an endpoint MUST certify either the SDP connection address or the identity of the creator of the SDP message, as follows:
在SDP不受完整性保护的情况下，为TLS连接提供的证书必须证明连接的适当身份。在这些场景中，端点提供的证书必须证明SDP连接地址或SDP消息创建者的身份，如下所示：
o If the connection address for the media description is specified as an IP address, the endpoint MAY use a certificate with an iPAddress subjectAltName that exactly matches the IP in the connection-address in the session description's 'c' line. Similarly, if the connection address for the media description is specified as a fully qualified domain name, the endpoint MAY use a certificate with a dNSName subjectAltName matching the specified 'c' line connection-address exactly. (Wildcard patterns MUST NOT be used.)
o 如果将媒体描述的连接地址指定为IP地址，则终结点可以使用IP地址subjectAltName与会话描述的“c”行中连接地址中的IP完全匹配的证书。类似地，如果将媒体描述的连接地址指定为完全限定的域名，则端点可以使用dNSName subjectAltName与指定的“c”行连接地址完全匹配的证书。（不得使用通配符模式。）
o Alternately, if the SDP session description of the session was transmitted over a protocol (such as SIP [17]) for which the identities of session participants are defined by Uniform Resource Identifiers (URIs), the endpoint MAY use a certificate with a uniformResourceIdentifier subjectAltName corresponding to the identity of the endpoint that generated the SDP. The details of
o 或者，如果会话的SDP会话描述是通过协议（例如SIP[17]）传输的，对于该协议，会话参与者的身份由统一资源标识符（uri）定义，端点可以使用具有uniformResourceIdentifier subjectAltName的证书，该证书对应于生成SDP的端点的标识。细节
what URIs are valid are dependent on the transmitting protocol. (For more details on the validity of URIs, see Section 7.
有效的URI取决于传输协议。（有关URI有效性的更多详细信息，请参见第7节。
Identity matching is performed using the matching rules specified by RFC 5280 [11]. If more than one identity of a given type is present in the certificate (e.g., more than one dNSName name), a match in any one of the set is considered acceptable. To support the use of certificate caches, as described in Section 7, endpoints SHOULD consistently provide the same certificate for each identity they support.
使用RFC 5280[11]指定的匹配规则执行身份匹配。如果证书中存在给定类型的多个标识（例如，多个dNSName名称），则可以接受集合中任何一个的匹配。如第7节所述，为了支持证书缓存的使用，端点应始终为其支持的每个标识提供相同的证书。
In all cases, an endpoint acting as the TLS server (i.e., one taking the 'setup:passive' role, in the terminology of connection-oriented media) MUST present a certificate during TLS initiation, following the rules presented in Section 6.1. If the certificate does not match the original fingerprint, the client endpoint MUST terminate the media connection with a bad_certificate error.
在所有情况下，充当TLS服务器的端点（即，在面向连接的媒体术语中，扮演“设置：被动”角色的端点）必须按照第6.1节中的规则在TLS启动期间提供证书。如果证书与原始指纹不匹配，客户端终结点必须终止媒体连接，并出现错误的\u证书错误。
If the SDP offer/answer model [4] is being used, the client (the endpoint with the 'setup:active' role) MUST also present a certificate following the rules of Section 6.1. The server MUST request a certificate; if the client does not provide one, or if the certificate does not match a provided fingerprint, the server endpoint MUST terminate the media connection with a bad_certificate error.
如果使用SDP提供/应答模型[4]，则客户端（具有“设置：活动”角色的端点）还必须按照第6.1节的规则提供证书。服务器必须请求证书；如果客户端未提供指纹，或者证书与提供的指纹不匹配，则服务器端点必须终止媒体连接，并出现错误的\u证书错误。
Note that when the offer/answer model is being used, it is possible for a media connection to outrace the answer back to the offerer. Thus, if the offerer has offered a 'setup:passive' or 'setup:actpass' role, it MUST (as specified in RFC 4145 [7]) begin listening for an incoming connection as soon as it sends its offer. However, it MUST NOT assume that the data transmitted over the TLS connection is valid until it has received a matching fingerprint in an SDP answer. If the fingerprint, once it arrives, does not match the client's certificate, the server endpoint MUST terminate the media connection with a bad_certificate error, as stated in the previous paragraph.
请注意，在使用报价/应答模型时，媒体连接可能会超出报价人的应答。因此，如果报价人提供了“设置：被动”或“设置：actpass”角色，则其必须（如RFC 4145[7]中所述）在发送报价后立即开始侦听传入连接。但是，在收到SDP应答中的匹配指纹之前，不得假设通过TLS连接传输的数据有效。如果指纹到达后与客户端的证书不匹配，则服务器端点必须终止媒体连接，并出现bad_证书错误，如前一段所述。
If offer/answer is not being used (e.g., if the SDP was sent over the Session Announcement Protocol [15]), there is no secure channel available for clients to communicate certificate fingerprints to servers. In this case, servers MAY request client certificates, which SHOULD be signed by a well-known certification authority, or MAY allow clients to connect without a certificate.
如果未使用提供/应答（例如，如果SDP是通过会话公告协议[15]发送的），则没有安全通道可供客户端将证书指纹传送到服务器。在这种情况下，服务器可能会请求客户端证书，该证书应由知名的证书颁发机构签名，或者可能会允许客户端在没有证书的情况下进行连接。
This entire document concerns itself with security. The problem to be solved is addressed in Section 1, and a high-level overview is presented in Section 3. See the SDP specification [8] for security considerations applicable to SDP in general.
整个文件都涉及到安全问题。第1节讨论了要解决的问题，第3节介绍了高层次的概述。有关一般适用于SDP的安全注意事项，请参见SDP规范[8]。
Offering a TCP/TLS connection in SDP (or agreeing to one in the SDP offer/answer mode) does not create an obligation for an endpoint to accept any TLS connection with the given fingerprint. Instead, the endpoint must engage in the standard TLS negotiation procedure to ensure that the TLS stream cipher and MAC algorithm chosen meet the security needs of the higher-level application. (For example, an offered stream cipher of TLS_NULL_WITH_NULL_NULL SHOULD be rejected in almost every application scenario.)
在SDP中提供TCP/TLS连接（或同意在SDP提供/应答模式下提供TCP/TLS连接）不会产生端点接受具有给定指纹的任何TLS连接的义务。相反，端点必须参与标准TLS协商过程，以确保选择的TLS流密码和MAC算法满足更高级别应用程序的安全需求。（例如，在几乎所有应用场景中，都应拒绝提供TLS_NULL_与_NULL_NULL的流密码。）
Like all SDP messages, SDP messages describing TLS streams are conveyed in an encapsulating application protocol (e.g., SIP, Media Gateway Control Protocol (MGCP), etc.). It is the responsibility of the encapsulating protocol to ensure the integrity of the SDP security descriptions. Therefore, the application protocol SHOULD either invoke its own security mechanisms (e.g., secure multiparts) or, alternatively, utilize a lower-layer security service (e.g., TLS or IPsec). This security service SHOULD provide strong message authentication as well as effective replay protection.
与所有SDP消息一样，描述TLS流的SDP消息在封装的应用程序协议（例如SIP、媒体网关控制协议（MGCP））中传输。封装协议负责确保SDP安全描述的完整性。因此，应用程序协议应调用其自身的安全机制（例如，安全多部分），或者，利用较低层的安全服务（例如，TLS或IPsec）。此安全服务应提供强大的消息身份验证以及有效的重播保护。
However, such integrity protection is not always possible. For these cases, end systems SHOULD maintain a cache of certificates that other parties have previously presented using this mechanism. If possible, users SHOULD be notified when an unsecured certificate associated with a previously unknown end system is presented and SHOULD be strongly warned if a different unsecured certificate is presented by a party with which they have communicated in the past. In this way, even in the absence of integrity protection for SDP, the security of this document's mechanism is equivalent to that of the Secure Shell (SSH) protocol [18], which is vulnerable to man-in-the-middle attacks when two parties first communicate but can detect ones that occur subsequently. (Note that a precise definition of the "other party" depends on the application protocol carrying the SDP message.) Users SHOULD NOT, however, in any circumstances be notified about certificates described in the SDP descriptions sent over an integrity-protected channel.
然而，这种完整性保护并不总是可能的。对于这些情况，终端系统应该维护其他方以前使用此机制提供的证书缓存。如果可能，当出现与以前未知的终端系统相关联的不安全证书时，应通知用户，并且如果过去与用户通信的一方出现了不同的不安全证书，则应强烈警告用户。这样，即使在SDP没有完整性保护的情况下，本文档机制的安全性也相当于安全外壳（SSH）协议[18]，当双方首次通信时，该协议容易受到中间人攻击，但可以检测到随后发生的攻击。（请注意，“另一方”的精确定义取决于承载SDP消息的应用程序协议。）但是，在任何情况下，都不应通知用户通过完整性保护通道发送的SDP描述中描述的证书。
To aid interoperability and deployment, security protocols that provide only hop-by-hop integrity protection (e.g., the SIPS scheme [17], SIP over TLS) are considered sufficiently secure to allow the mode in which any syntactically valid identity is accepted in a certificate. This decision was made because SIPS is currently the
为了帮助互操作性和部署，仅提供逐跳完整性保护的安全协议（例如SIPS方案[17]，SIP over TLS）被认为是足够安全的，以允许在证书中接受任何语法有效身份的模式。之所以作出这一决定，是因为SIPS目前是
integrity mechanism most likely to be used in deployed networks in the short to medium term. However, in this mode, SDP integrity is vulnerable to attacks by compromised or malicious middleboxes, e.g., SIP proxy servers. End systems MAY warn users about SDP sessions that are secured in only a hop-by-hop manner, and definitions of media formats running over TCP/TLS MAY specify that only end-to-end integrity mechanisms be used.
完整性机制最有可能在中短期内用于已部署的网络。但是，在此模式下，SDP完整性容易受到受损或恶意中间盒（例如SIP代理服务器）的攻击。终端系统可能会警告用户SDP会话仅以逐跳方式进行保护，并且TCP/TLS上运行的媒体格式定义可能会指定仅使用端到端完整性机制。
Depending on how SDP messages are transmitted, it is not always possible to determine whether or not a subjectAltName presented in a remote certificate is expected for the remote party. In particular, given call forwarding, third-party call control, or session descriptions generated by endpoints controlled by the Gateway Control Protocol [21], it is not always possible in SIP to determine what entity ought to have generated a remote SDP response. In general, when not using authenticity and integrity protection of the SDP descriptions, a certificate transmitted over SIP SHOULD assert the endpoint's SIP Address of Record as a uniformResourceIndicator subjectAltName. When an endpoint receives a certificate over SIP asserting an identity (including an iPAddress or dNSName identity) other than the one to which it placed or received the call, it SHOULD alert the user and ask for confirmation. This applies whether certificates are self-signed or signed by certification authorities; a certificate for "sip:bob@example.com" may be legitimately signed by a certification authority, but it may still not be acceptable for a call to "sip:alice@example.com". (This issue is not one specific to this specification; the same consideration applies for S/MIME-signed SDP carried over SIP.)
根据SDP消息的传输方式，并不总是能够确定远程方是否需要远程证书中显示的subjectAltName。特别是，给定由网关控制协议控制的端点生成的呼叫转发、第三方呼叫控制或会话描述[21]，在SIP中并不总是能够确定哪个实体应该生成远程SDP响应。通常，当不使用SDP描述的真实性和完整性保护时，通过SIP传输的证书应将端点的SIP记录地址声明为uniformResourceIndicator subjectAltName。当端点通过SIP接收到一个证书，该证书断言一个身份（包括iPAddress或dNSName身份），而不是它拨打或接收呼叫的身份，它应该提醒用户并请求确认。这适用于证书是自签名还是由认证机构签名；“sip:bob@example.com可以由证书颁发机构合法签署，但调用“sip:alice@example.com". （此问题并非本规范的特定问题；同样的考虑也适用于SIP中携带的S/MIME签名SDP。）
This document does not define a mechanism for securely transporting RTP and RTCP packets over a connection-oriented channel. Please see RFC 7850 [19] for more details.
本文档未定义通过面向连接的通道安全传输RTP和RTCP数据包的机制。更多详情请参见RFC 7850[19]。
TLS is not always the most appropriate choice for secure connection-oriented media; in some cases, a higher- or lower-level security protocol may be appropriate.
TLS并不总是面向安全连接的媒体的最合适选择；在某些情况下，更高或更低级别的安全协议可能是合适的。
This document improves security from RFC 4572 [20]. It updates the preferred hash function from SHA-1 to SHA-256 and deprecates the usage of the MD2 and MD5 hash functions.
本文件改进了RFC 4572[20]的安全性。它将首选哈希函数从SHA-1更新为SHA-256，并反对使用MD2和MD5哈希函数。
By clarifying the usage and handling of multiple fingerprints, the document also enables hash agility and incremental deployment of newer and more secure hash functions.
通过澄清多个指纹的使用和处理，该文档还实现了哈希灵活性和更新、更安全的哈希函数的增量部署。
IANA has updated the registrations defined in RFC 4572 [20] to refer to this specification.
IANA已更新RFC 4572[20]中定义的注册，以参考本规范。
This document defines an SDP proto value: 'TCP/TLS'. Its format is defined in Section 4. This proto value has been registered by IANA under the "proto" registry within the "Session Description Protocol (SDP) Parameters" registry.
本文档定义了一个SDP协议值：“TCP/TLS”。其格式见第4节。IANA已在“会话描述协议（SDP）参数”注册表中的“proto”注册表下注册此proto值。
This document defines an SDP session and media-level attribute: 'fingerprint'. Its format is defined in Section 5. This attribute has been registered by IANA under the "att-field (both session and media level)" registry within the "Session Description Protocol (SDP) Parameters" registry.
此文档定义SDP会话和媒体级别属性：“指纹”。其格式见第5节。IANA已在“会话描述协议（SDP）参数”注册表中的“att字段（会话和媒体级别）”注册表下注册此属性。
The SDP specification [8] states that specifications defining new proto values, like the 'TCP/TLS' proto value defined in this one, must define the rules by which their media format (fmt) namespace is managed. For the TCP/TLS protocol, new formats SHOULD have an associated MIME registration. Use of an existing MIME subtype for the format is encouraged. If no MIME subtype exists, it is RECOMMENDED that a suitable one be registered through the IETF process [12] by production of, or reference to, a Standards Track RFC that defines the transport protocol for the format.
SDP规范[8]指出，定义新协议值的规范（如本规范中定义的“TCP/TLS”协议值）必须定义管理其媒体格式（fmt）命名空间的规则。对于TCP/TLS协议，新格式应具有相关的MIME注册。鼓励对该格式使用现有的MIME子类型。如果不存在MIME子类型，建议通过IETF过程[12]通过生成或引用定义格式传输协议的标准跟踪RFC来注册合适的MIME子类型。
IANA has updated the "Hash Function Textual Names" registry (which was originally created in [20]) to refer to this document.
IANA更新了“哈希函数文本名称”注册表（最初在[20]中创建），以参考本文档。
The names of hash functions used for certificate fingerprints are registered by the IANA. Hash functions MUST be defined by Standards Track RFCs that update or obsolete RFC 3279 [5].
用于证书指纹的哈希函数的名称由IANA注册。哈希函数必须由更新或废弃RFC 3279的标准跟踪RFC定义[5]。
When registering a new hash function textual name, the following information MUST be provided:
注册新的哈希函数文本名称时，必须提供以下信息：
o The textual name of the hash function.
o 哈希函数的文本名称。
o The Object Identifier (OID) of the hash function as used in X.509 certificates.
o 在X.509证书中使用的哈希函数的对象标识符（OID）。
o A reference to the Standards Track RFC that updates or obsoletes RFC 3279 [5] and defines the use of the hash function in X.509 certificates.
o 对标准的引用跟踪更新或淘汰RFC 3279[5]的RFC，并定义在X.509证书中使用哈希函数。
Table 1 contains the initial values of this registry.
表1包含此注册表的初始值。
+--------------------+------------------------+-----------+
| Hash Function Name | OID | Reference |
+--------------------+------------------------+-----------+
| "md2" | 1.2.840.113549.2.2 | RFC 3279 |
| "md5" | 1.2.840.113549.2.5 | RFC 3279 |
| "sha-1" | 1.3.14.3.2.26 | RFC 3279 |
| "sha-224" | 2.16.840.1.101.3.4.2.4 | RFC 4055 |
| "sha-256" | 2.16.840.1.101.3.4.2.1 | RFC 4055 |
| "sha-384" | 2.16.840.1.101.3.4.2.2 | RFC 4055 |
| "sha-512" | 2.16.840.1.101.3.4.2.3 | RFC 4055 |
+--------------------+------------------------+-----------+
+--------------------+------------------------+-----------+
| Hash Function Name | OID | Reference |
+--------------------+------------------------+-----------+
| "md2" | 1.2.840.113549.2.2 | RFC 3279 |
| "md5" | 1.2.840.113549.2.5 | RFC 3279 |
| "sha-1" | 1.3.14.3.2.26 | RFC 3279 |
| "sha-224" | 2.16.840.1.101.3.4.2.4 | RFC 4055 |
| "sha-256" | 2.16.840.1.101.3.4.2.1 | RFC 4055 |
| "sha-384" | 2.16.840.1.101.3.4.2.2 | RFC 4055 |
| "sha-512" | 2.16.840.1.101.3.4.2.3 | RFC 4055 |
+--------------------+------------------------+-----------+
Table 1: IANA Hash Function Textual Name Registry
表1:IANA哈希函数文本名称注册表
[1] National Institute of Standards and Technology, "Secure Hash Standard (SHS)", FIPS PUB 180-4, DOI 10.6028/NIST.FIPS.180-4, August 2015, <http://nvlpubs.nist.gov/nistpubs/FIPS/ NIST.FIPS.180-4.pdf>.
[1] 国家标准与技术研究所，“安全哈希标准（SHS）”，FIPS PUB 180-4，DOI 10.6028/NIST.FIPS.180-42015年8月<http://nvlpubs.nist.gov/nistpubs/FIPS/ NIST.FIPS.180-4.pdf>。
[2] International Organization for Standardization, "Information technology -- Open Systems Interconnection -- The Directory -- Part 8: Public-key and attribute certificate frameworks", ISO/IEC 9594-8:2014, March 2014, <https://www.iso.org/standard/64854.html>.
[2] 国际标准化组织，“信息技术——开放系统互连——目录——第8部分：公钥和属性证书框架”，ISO/IEC 9594-8:2014，2014年3月<https://www.iso.org/standard/64854.html>.
[3] 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>.
[3] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[4] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, DOI 10.17487/RFC3264, June 2002, <http://www.rfc-editor.org/info/rfc3264>.
[4] Rosenberg，J.和H.Schulzrinne，“具有会话描述协议（SDP）的提供/应答模型”，RFC 3264，DOI 10.17487/RFC3264，2002年6月<http://www.rfc-editor.org/info/rfc3264>.
[5] Bassham, L., Polk, W., and R. Housley, "Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3279, DOI 10.17487/RFC3279, April 2002, <http://www.rfc-editor.org/info/rfc3279>.
[5] Bassham，L.，Polk，W.，和R.Housley，“互联网X.509公钥基础设施证书和证书撤销列表（CRL）配置文件的算法和标识符”，RFC 3279，DOI 10.17487/RFC3279，2002年4月<http://www.rfc-editor.org/info/rfc3279>.
[6] Schaad, J., Kaliski, B., and R. Housley, "Additional Algorithms and Identifiers for RSA Cryptography for use in the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 4055, DOI 10.17487/RFC4055, June 2005, <http://www.rfc-editor.org/info/rfc4055>.
[6] Schaad，J.，Kaliski，B.，和R.Housley，“互联网X.509公钥基础设施证书和证书撤销列表（CRL）配置文件中使用的RSA加密的其他算法和标识符”，RFC 4055，DOI 10.17487/RFC4055，2005年6月<http://www.rfc-editor.org/info/rfc4055>.
[7] Yon, D. and G. Camarillo, "TCP-Based Media Transport in the Session Description Protocol (SDP)", RFC 4145, DOI 10.17487/RFC4145, September 2005, <http://www.rfc-editor.org/info/rfc4145>.
[7] Yon，D.和G.Camarillo，“会话描述协议（SDP）中基于TCP的媒体传输”，RFC 4145，DOI 10.17487/RFC4145，2005年9月<http://www.rfc-editor.org/info/rfc4145>.
[8] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, DOI 10.17487/RFC4566, July 2006, <http://www.rfc-editor.org/info/rfc4566>.
[8] Handley，M.，Jacobson，V.，和C.Perkins，“SDP：会话描述协议”，RFC 4566，DOI 10.17487/RFC4566，2006年7月<http://www.rfc-editor.org/info/rfc4566>.
[9] 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>.
[9] Crocker，D.，Ed.和P.Overell，“语法规范的扩充BNF:ABNF”，STD 68，RFC 5234，DOI 10.17487/RFC5234，2008年1月<http://www.rfc-editor.org/info/rfc5234>.
[10] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, <http://www.rfc-editor.org/info/rfc5246>.
[10] Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.2”，RFC 5246，DOI 10.17487/RFC5246，2008年8月<http://www.rfc-editor.org/info/rfc5246>.
[11] 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>.
[11] 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>.
[12] Freed, N., Klensin, J., and T. Hansen, "Media Type Specifications and Registration Procedures", BCP 13, RFC 6838, DOI 10.17487/RFC6838, January 2013, <http://www.rfc-editor.org/info/rfc6838>.
[12] Freed，N.，Klensin，J.和T.Hansen，“介质类型规范和注册程序”，BCP 13，RFC 6838，DOI 10.17487/RFC6838，2013年1月<http://www.rfc-editor.org/info/rfc6838>.
[13] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, DOI 10.17487/RFC1321, April 1992, <http://www.rfc-editor.org/info/rfc1321>.
[13] Rivest，R.，“MD5消息摘要算法”，RFC 1321，DOI 10.17487/RFC1321，1992年4月<http://www.rfc-editor.org/info/rfc1321>.
[14] Rescorla, E., "HTTP Over TLS", RFC 2818, DOI 10.17487/RFC2818, May 2000, <http://www.rfc-editor.org/info/rfc2818>.
[14] Rescorla，E.，“TLS上的HTTP”，RFC 2818，DOI 10.17487/RFC2818，2000年5月<http://www.rfc-editor.org/info/rfc2818>.
[15] Handley, M., Perkins, C., and E. Whelan, "Session Announcement Protocol", RFC 2974, DOI 10.17487/RFC2974, October 2000, <http://www.rfc-editor.org/info/rfc2974>.
[15] Handley，M.，Perkins，C.，和E.Whelan，“会话公告协议”，RFC 2974，DOI 10.17487/RFC2974，2000年10月<http://www.rfc-editor.org/info/rfc2974>.
[16] Eastlake 3rd, D. and P. Jones, "US Secure Hash Algorithm 1 (SHA1)", RFC 3174, DOI 10.17487/RFC3174, September 2001, <http://www.rfc-editor.org/info/rfc3174>.
[16] Eastlake 3rd，D.和P.Jones，“美国安全哈希算法1（SHA1）”，RFC 3174，DOI 10.17487/RFC3174，2001年9月<http://www.rfc-editor.org/info/rfc3174>.
[17] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, DOI 10.17487/RFC3261, June 2002, <http://www.rfc-editor.org/info/rfc3261>.
[17] Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，和E.Schooler，“SIP：会话启动协议”，RFC 3261，DOI 10.17487/RFC3261，2002年6月<http://www.rfc-editor.org/info/rfc3261>.
[18] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) Protocol Architecture", RFC 4251, DOI 10.17487/RFC4251, January 2006, <http://www.rfc-editor.org/info/rfc4251>.
[18] “安全外壳（SSH）协议架构”，RFC 4251，DOI 10.17487/RFC4251，2006年1月<http://www.rfc-editor.org/info/rfc4251>.
[19] Lazzaro, J., "Framing Real-time Transport Protocol (RTP) and RTP Control Protocol (RTCP) Packets over Connection-Oriented Transport", RFC 4571, DOI 10.17487/RFC4571, July 2006, <http://www.rfc-editor.org/info/rfc4571>.
[19] Lazzaro，J.，“面向连接传输上的帧实时传输协议（RTP）和RTP控制协议（RTCP）数据包”，RFC 4571，DOI 10.17487/RFC4571，2006年7月<http://www.rfc-editor.org/info/rfc4571>.
[20] Lennox, J., "Connection-Oriented Media Transport over the Transport Layer Security (TLS) Protocol in the Session Description Protocol (SDP)", RFC 4572, DOI 10.17487/RFC4572, July 2006, <http://www.rfc-editor.org/info/rfc4572>.
[20] Lennox，J.，“会话描述协议（SDP）中传输层安全（TLS）协议上的面向连接的媒体传输”，RFC 4572，DOI 10.17487/RFC4572，2006年7月<http://www.rfc-editor.org/info/rfc4572>.
[21] Taylor, T., "Reclassification of RFC 3525 to Historic", RFC 5125, DOI 10.17487/RFC5125, February 2008, <http://www.rfc-editor.org/info/rfc5125>.
[21] Taylor，T.“将RFC 3525重新分类为历史”，RFC 5125，DOI 10.17487/RFC5125，2008年2月<http://www.rfc-editor.org/info/rfc5125>.
[22] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification", RFC 5751, DOI 10.17487/RFC5751, January 2010, <http://www.rfc-editor.org/info/rfc5751>.
[22] Ramsdell，B.和S.Turner，“安全/多用途Internet邮件扩展（S/MIME）版本3.2消息规范”，RFC 5751，DOI 10.17487/RFC5751，2010年1月<http://www.rfc-editor.org/info/rfc5751>.
[23] Turner, S. and L. Chen, "MD2 to Historic Status", RFC 6149, DOI 10.17487/RFC6149, March 2011, <http://www.rfc-editor.org/info/rfc6149>.
[23] Turner，S.和L.Chen，“MD2的历史地位”，RFC 6149，DOI 10.17487/RFC6149，2011年3月<http://www.rfc-editor.org/info/rfc6149>.
[24] Shekh-Yusef, R., Ed., Ahrens, D., and S. Bremer, "HTTP Digest Access Authentication", RFC 7616, DOI 10.17487/RFC7616, September 2015, <http://www.rfc-editor.org/info/rfc7616>.
[24] Shekh Yusef，R.，Ed.，Ahrens，D.，和S.Bremer，“HTTP摘要访问认证”，RFC 7616，DOI 10.17487/RFC76162015年9月<http://www.rfc-editor.org/info/rfc7616>.
Acknowledgments
致谢
This document included significant contributions by Cullen Jennings, Paul Kyzivat, Roman Shpount, and Martin Thomson. Elwyn Davies performed the Gen-ART review of the document.
该文件包括Cullen Jennings、Paul Kyzivat、Roman Spont和Martin Thomson的重要贡献。Elwyn Davies对该文件进行了一般艺术审查。
Authors' Addresses
作者地址
Jonathan Lennox Vidyo
乔纳森·伦诺克斯·维迪奥
Email: jonathan@vidyo.com
Email: jonathan@vidyo.com
Christer Holmberg Ericsson
克里斯特·霍姆伯格·爱立信
Email: christer.holmberg@ericsson.com
Email: christer.holmberg@ericsson.com