Internet Engineering Task Force (IETF) S. Lawrence
Request for Comments: 5924
Category: Experimental V. Gurbani
ISSN: 2070-1721 Bell Laboratories, Alcatel-Lucent
June 2010
Internet Engineering Task Force (IETF) S. Lawrence
Request for Comments: 5924
Category: Experimental V. Gurbani
ISSN: 2070-1721 Bell Laboratories, Alcatel-Lucent
June 2010
Extended Key Usage (EKU) for Session Initiation Protocol (SIP) X.509 Certificates
会话启动协议（SIP）X.509证书的扩展密钥使用（EKU）
Abstract
摘要
This memo documents an extended key usage (EKU) X.509 certificate extension for restricting the applicability of a certificate to use with a Session Initiation Protocol (SIP) service. As such, in addition to providing rules for SIP implementations, this memo also provides guidance to issuers of certificates for use with SIP.
本备忘录记录了一个扩展密钥使用（EKU）X.509证书扩展，用于限制证书的适用性，以便与会话启动协议（SIP）服务一起使用。因此，除了为SIP实施提供规则外，本备忘录还为SIP使用的证书颁发者提供指导。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
本文件不是互联网标准跟踪规范；它是为检查、实验实施和评估而发布的。
This document defines an Experimental Protocol for the Internet community. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文档为互联网社区定义了一个实验协议。本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5924.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc5924.
Copyright Notice
版权公告
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2010 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许可证中所述的无担保。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。
Table of Contents
目录
1. Introduction ....................................................3
2. Terminology .....................................................3
2.1. Key Words ..................................................3
2.2. Abstract Syntax Notation ...................................3
3. Problem Statement ...............................................3
4. Restricting Usage to SIP ........................................4
4.1. Extended Key Usage Values for SIP Domains ..................5
5. Using the SIP EKU in a Certificate ..............................5
6. Implications for a Certification Authority ......................6
7. Security Considerations .........................................6
8. IANA Considerations .............................................6
9. Acknowledgments .................................................7
10. Normative References ...........................................7
Appendix A. ASN.1 Module ..........................................8
1. Introduction ....................................................3
2. Terminology .....................................................3
2.1. Key Words ..................................................3
2.2. Abstract Syntax Notation ...................................3
3. Problem Statement ...............................................3
4. Restricting Usage to SIP ........................................4
4.1. Extended Key Usage Values for SIP Domains ..................5
5. Using the SIP EKU in a Certificate ..............................5
6. Implications for a Certification Authority ......................6
7. Security Considerations .........................................6
8. IANA Considerations .............................................6
9. Acknowledgments .................................................7
10. Normative References ...........................................7
Appendix A. ASN.1 Module ..........................................8
This memo documents an extended key usage (EKU) X.509 certificate extension for restricting the applicability of a certificate to use with a Session Initiation Protocol (SIP) service. As such, in addition to providing rules for SIP implementations, this memo also provides guidance to issuers of certificates for use with SIP.
本备忘录记录了一个扩展密钥使用（EKU）X.509证书扩展，用于限制证书的适用性，以便与会话启动协议（SIP）服务一起使用。因此，除了为SIP实施提供规则外，本备忘录还为SIP使用的证书颁发者提供指导。
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 [1].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[1]中所述进行解释。
Additionally, the following term is defined:
此外，定义了以下术语：
SIP domain identity: A subject identity in the X.509 certificate that conveys to a recipient of the certificate that the certificate owner is authoritative for SIP services in the domain named by that subject identity.
SIP域标识：X.509证书中的主体标识，向证书接收者传达证书所有者对该主体标识命名的域中的SIP服务具有权威性。
All X.509 certificate X.509 [4] extensions are defined using ASN.1 X.680 [5], and X.690 [6].
所有X.509证书X.509[4]扩展都是使用ASN.1 X.680[5]和X.690[6]定义的。
Consider the SIP RFC 3261 [2] actors shown in Figure 1.
考虑图1所示的SIPRFC 3261（2）行动者。
Proxy-A.example.com Proxy-B.example.net
+-------+ +-------+
| Proxy |--------------------| Proxy |
+----+--+ +---+---+
| |
| |
| |
| +---+
0---0 | |
/-\ |___|
+---+ / /
+----+
alice@example.com bob@example.net
Proxy-A.example.com Proxy-B.example.net
+-------+ +-------+
| Proxy |--------------------| Proxy |
+----+--+ +---+---+
| |
| |
| |
| +---+
0---0 | |
/-\ |___|
+---+ / /
+----+
alice@example.com bob@example.net
Figure 1: SIP Trapezoid
图1:SIP梯形
Assume that alice@example.com creates an INVITE for bob@example.net; her user agent routes the request to some proxy in her domain, example.com. Suppose also that example.com is a large organization that maintains several SIP proxies, and her INVITE arrived at an outbound proxy Proxy-A.example.com. In order to route the request onward, Proxy-A uses RFC 3263 [7] resolution and finds that Proxy-B.example.net is a valid proxy for example.net that uses Transport Layer Security (TLS). Proxy-A.example.com requests a TLS connection to Proxy-B.example.net, and in the TLS handshake each one presents a certificate to authenticate that connection. The validation of these certificates by each proxy to determine whether or not their peer is authoritative for the appropriate SIP domain is defined in "Domain Certificates in the Session Initiation Protocol (SIP)" [8].
假定alice@example.com为创建邀请bob@example.net; 她的用户代理将请求路由到她的域example.com中的某个代理。假设example.com是一个维护多个SIP代理的大型组织，她的邀请到达一个出站代理-a.example.com。为了向前路由请求，Proxy-A使用RFC 3263[7]解析，并发现Proxy-B.example.net是example.net的有效代理，该代理使用传输层安全性（TLS）。Proxy-A.example.com请求到Proxy-B.example.net的TLS连接，在TLS握手中，每个人都提供一个证书来验证该连接。“会话初始化协议（SIP）中的域证书”中定义了每个代理对这些证书的验证，以确定其对等方是否对适当的SIP域具有权威性[8]。
A SIP domain name is frequently textually identical to the same DNS name used for other purposes. For example, the DNS name example.com can serve as a SIP domain name, an email domain name, and a web service name. Since these different services within a single organization might be administered independently and hosted separately, it is desirable that a certificate be able to bind the DNS name to its usage as a SIP domain name without creating the implication that the entity presenting the certificate is also authoritative for some other purpose. A mechanism is needed to allow the certificate issued to a proxy to be restricted such that the subject name(s) that the certificate contains are valid only for use in SIP. In our example, Proxy-B possesses a certificate making Proxy-B authoritative as a SIP server for the domain example.net; furthermore, Proxy-B has a policy that requires the client's SIP domain be authenticated through a similar certificate. Proxy-A is authoritative as a SIP server for the domain example.com; when Proxy-A makes a TLS connection to Proxy-B, the latter accepts the connection based on its policy.
SIP域名通常在文本上与用于其他目的的相同DNS名称相同。例如，DNS name example.com可以用作SIP域名、电子邮件域名和web服务名称。由于单个组织内的这些不同服务可以独立地管理并单独托管，因此期望证书能够将DNS名称与其作为SIP域名的使用绑定，而不产生表示证书的实体也具有某些其他用途的权威性的暗示。需要一种机制来允许对颁发给代理的证书进行限制，以便证书包含的使用者名称仅在SIP中有效。在我们的示例中，Proxy-B拥有一个证书，使Proxy-B作为域example.net的SIP服务器具有权威性；此外，Proxy-B有一个策略，要求客户端的SIP域通过类似的证书进行身份验证。Proxy-A作为域example.com的SIP服务器具有权威性；当Proxy-A与Proxy-B建立TLS连接时，Proxy-B根据其策略接受连接。
This memo defines a certificate profile for restricting the usage of a domain name binding to usage as a SIP domain name. RFC 5280 [3], Section 4.2.1.12, defines a mechanism for this purpose: an "Extended Key Usage" (EKU) attribute, where the purpose of the EKU extension is described as:
此备忘录定义了一个证书配置文件，用于将域名绑定的使用限制为SIP域名。RFC 5280[3]第4.2.1.12节定义了用于此目的的机制：“扩展密钥使用”（EKU）属性，其中EKU扩展的目的描述为：
If the extension is present, then the certificate MUST only be used for one of the purposes indicated. If multiple purposes are indicated the application need not recognize all purposes indicated, as long as the intended purpose is present. Certificate using applications MAY require that the extended key
如果存在扩展，则证书只能用于指定的目的之一。如果指示了多个目的，则只要存在预期目的，应用程序就不需要识别所指示的所有目的。使用证书的应用程序可能需要扩展密钥
usage extension be present and that a particular purpose be indicated in order for the certificate to be acceptable to that application.
应存在使用扩展，并指明特定用途，以便该证书可被该应用程序接受。
A Certificate Authority issuing a certificate whose purpose is to bind a SIP domain identity without binding other non-SIP identities MUST include an id-kp-sipDomain attribute in the Extended Key Usage extension value (see Section 4.1).
颁发旨在绑定SIP域标识而不绑定其他非SIP标识的证书的证书颁发机构必须在扩展密钥使用扩展值中包含id kp sipDomain属性（参见第4.1节）。
RFC 5280 [3] specifies the EKU X.509 certificate extension for use in the Internet. The extension indicates one or more purposes for which the certified public key is valid. The EKU extension can be used in conjunction with the key usage extension, which indicates how the public key in the certificate is used, in a more basic cryptographic way.
RFC 5280[3]指定在Internet中使用的EKU X.509证书扩展。扩展名表示认证公钥有效的一个或多个目的。EKU扩展可以与密钥使用扩展一起使用，它以更基本的加密方式指示如何使用证书中的公钥。
The EKU extension syntax is repeated here for convenience:
为方便起见，此处重复EKU扩展语法：
ExtKeyUsageSyntax ::= SEQUENCE SIZE (1..MAX) OF KeyPurposeId
ExtKeyUsageSyntax ::= SEQUENCE SIZE (1..MAX) OF KeyPurposeId
KeyPurposeId ::= OBJECT IDENTIFIER
KeyPurposeId ::= OBJECT IDENTIFIER
This specification defines the KeyPurposeId id-kp-sipDomain. Inclusion of this KeyPurposeId in a certificate indicates that the use of any Subject names in the certificate is restricted to use by a SIP service (along with any usages allowed by other EKU values).
本规范定义了KeyPurposeId kp sipDomain。证书中包含此KeyPurposeId表示证书中任何使用者名称的使用仅限于SIP服务使用（以及其他EKU值允许的任何使用）。
id-kp OBJECT IDENTIFIER ::=
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) 3 }
id-kp OBJECT IDENTIFIER ::=
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) 3 }
id-kp-sipDomain OBJECT IDENTIFIER ::= { id-kp 20 }
id-kp-sipDomain OBJECT IDENTIFIER ::= { id-kp 20 }
Section 7.1 of Domain Certificates in the Session Initiation Protocol [8] contains the steps for finding an identity (or a set of identities) in an X.509 certificate for SIP. In order to determine whether the usage of a certificate is restricted to serve as a SIP certificate only, implementations MUST perform the steps given below as a part of the certificate validation:
会话启动协议[8]中的域证书第7.1节包含在SIP的X.509证书中查找标识（或标识集）的步骤。为了确定证书的使用是否仅限于用作SIP证书，实现必须执行以下步骤作为证书验证的一部分：
The implementation MUST examine the Extended Key Usage value(s):
实现必须检查扩展密钥使用值：
o If the certificate does not contain any EKU values (the Extended Key Usage extension does not exist), it is a matter of local policy whether or not to accept the certificate for use as a SIP certificate. Note that since certificates not following this specification will not have the id-kp-sipDomain EKU value, and many do not have any EKU values, the more interoperable local policy would be to accept the certificate.
o 如果证书不包含任何EKU值（扩展密钥使用扩展不存在），则是否接受证书作为SIP证书是本地策略的问题。请注意，由于不遵循此规范的证书将不具有id kp sipDomain EKU值，并且许多证书没有任何EKU值，因此更具互操作性的本地策略是接受证书。
o If the certificate contains the id-kp-sipDomain EKU extension, then implementations of this specification MUST consider the certificate acceptable for use as a SIP certificate.
o 如果证书包含ID KP SIPDATA EKU扩展，那么该规范的实现必须考虑可接受的证书作为SIP证书的使用。
o If the certificate does not contain the id-kp-sipDomain EKU value, but does contain the id-kp-anyExtendedKeyUsage EKU value, it is a matter of local policy whether or not to consider the certificate acceptable for use as a SIP certificate.
o 如果证书不包含ID KP SIPDATA EKU值，但确实包含ID KP AyExpReDeKEY用法EKU值，则本地策略的问题是是否考虑作为SIP证书使用的可接受的证书。
o If the EKU extension exists, but does not contain any of the id-kp-sipDomain or id-kp-anyExtendedKeyUsage EKU values, then the certificate MUST NOT be accepted as valid for use as a SIP certificate.
o 如果EKU扩展存在，但不包含任何id kp sipDomain或id kp anyExtendedKeyUsage EKU值，则该证书不能被接受为有效的SIP证书。
The procedures and practices employed by a certification authority MUST ensure that the correct values for the EKU extension and subjectAltName are inserted in each certificate that is issued. For certificates that indicate authority over a SIP domain, but not over services other than SIP, certificate authorities MUST include the id-kp-sipDomain EKU extension.
证书颁发机构采用的程序和实践必须确保在颁发的每个证书中插入EKU扩展名和subjectAltName的正确值。对于表示对SIP域（而不是SIP以外的服务）的权限的证书，证书权限必须包括id kp SIP域EKU扩展。
This memo defines an EKU X.509 certificate extension that restricts the usage of a certificate to a SIP service belonging to an autonomous domain. Relying parties can execute applicable policies (such as those related to billing) on receiving a certificate with the id-kp-sipDomain EKU value. An id-kp-sipDomain EKU value does not introduce any new security or privacy concerns.
此备忘录定义了EKU X.509证书扩展，该扩展将证书的使用限制为属于自治域的SIP服务。依赖方可以在收到id为kp SIPEKU值的证书时执行适用的策略（例如与计费相关的策略）。id kp域SIPEKU值不会引入任何新的安全或隐私问题。
The id-kp-sipDomain purpose requires an object identifier (OID). The objects are defined in an arc delegated by IANA to the PKIX working group. No further action is necessary by IANA.
id kp sipDomain用途需要对象标识符（OID）。这些对象在IANA委托给PKIX工作组的arc中定义。IANA无需采取进一步行动。
The following IETF contributors provided substantive input to this document: Jeroen van Bemmel, Michael Hammer, Cullen Jennings, Paul Kyzivat, Derek MacDonald, Dave Oran, Jon Peterson, Eric Rescorla, Jonathan Rosenberg, Russ Housley, Paul Hoffman, and Stephen Kent.
以下IETF贡献者为本文件提供了实质性投入：Jeroen van Bemmel、Michael Hammer、Cullen Jennings、Paul Kyzivat、Derek MacDonald、Dave Oran、Jon Peterson、Eric Rescorla、Jonathan Rosenberg、Russ Housley、Paul Hoffman和Stephen Kent。
Sharon Boyen and Trevor Freeman reviewed the document and facilitated the discussion on id-kp-anyExtendedKeyUsage, id-kpServerAuth and id-kp-ClientAuth purposes in certificates.
Sharon Boyen和Trevor Freeman审阅了该文档，并促进了关于证书中id kp anyExtendedKeyUsage、id kpServerAuth和id kp ClientAuth用途的讨论。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[2] Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，和E.Schooler，“SIP：会话启动协议”，RFC 3261，2002年6月。
[3] 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, May 2008.
[3] Cooper，D.，Santesson，S.，Farrell，S.，Boeyen，S.，Housley，R.，和W.Polk，“互联网X.509公钥基础设施证书和证书撤销列表（CRL）配置文件”，RFC 52802008年5月。
[4] International Telecommunications Union, "Information technology - Open Systems Interconnection - The Directory: Public-key and attribute certificate frameworks", ITU-T Recommendation X.509, ISO Standard 9594-8, March 2000.
[4] 国际电信联盟，“信息技术-开放系统互连-目录：公钥和属性证书框架”，ITU-T建议X.509，ISO标准9594-8，2000年3月。
[5] International International Telephone and Telegraph Consultative Committee, "Abstract Syntax Notation One (ASN.1): Specification of basic notation", CCITT Recommendation X.680, July 2002.
[5] 国际电话电报咨询委员会，“抽象语法符号一（ASN.1）：基本符号规范”，CCITT建议X.680，2002年7月。
[6] International International Telephone and Telegraph Consultative Committee, "ASN.1 encoding rules: Specification of basic encoding Rules (BER), Canonical encoding rules (CER) and Distinguished encoding rules (DER)", CCITT Recommendation X.690, July 2002.
[6] 国际电话电报咨询委员会，“ASN.1编码规则：基本编码规则（BER）、规范编码规则（CER）和区分编码规则（DER）规范”，CCITT建议X.690，2002年7月。
[7] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol (SIP): Locating SIP Servers", RFC 3263, June 2002.
[7] Rosenberg，J.和H.Schulzrinne，“会话启动协议（SIP）：定位SIP服务器”，RFC3263，2002年6月。
[8] Gurbani, V., Lawrence, S., and A. Jeffrey, "Domain Certificates in the Session Initiation Protocol (SIP)", RFC 5922, June 2010.
[8] Gurbani，V.，Lawrence，S.，和A.Jeffrey，“会话启动协议（SIP）中的域证书”，RFC 5922，2010年6月。
SIPDomainCertExtn
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-sip-domain-extns2007(62) }
SIPDomainCertExtn
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-sip-domain-extns2007(62) }
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
-- OID Arcs
--弧线
id-kp OBJECT IDENTIFIER ::=
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) 3 }
id-kp OBJECT IDENTIFIER ::=
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) 3 }
-- Extended Key Usage Values
--扩展密钥使用值
id-kp-sipDomain OBJECT IDENTIFIER ::= { id-kp 20 }
id-kp-sipDomain OBJECT IDENTIFIER ::= { id-kp 20 }
END
终止
Authors' Addresses
作者地址
Scott Lawrence
斯科特·劳伦斯
EMail: scott-ietf@skrb.org
EMail: scott-ietf@skrb.org
Vijay K. Gurbani Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane Room 9C-533 Naperville, IL 60566 USA
Vijay K.Gurbani Bell实验室，阿尔卡特朗讯1960朗讯巷，美国伊利诺伊州纳珀维尔9C-533室，邮编：60566
Phone: +1 630 224-0216
EMail: vkg@bell-labs.com
Phone: +1 630 224-0216
EMail: vkg@bell-labs.com