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
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.
このメモは、セッション開始プロトコル（SIP）サービスで使用する証明書の適用可能性を制限するための拡張キー使用法（EKU）X.509証明書拡張について説明します。このように、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.
この文書は、インターネットコミュニティのためにExperimentalプロトコルを定義します。このドキュメントはインターネットエンジニアリングタスクフォース（IETF）の製品です。これは、IETFコミュニティの総意を表しています。これは、公開レビューを受けており、インターネットエンジニアリング運営グループ（IESG）によって公表のために承認されています。 IESGによって承認されていないすべての文書がインターネットStandardのどんなレベルの候補です。 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ドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明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.
この材料の一部がIETFトラストにこのような材料の変更を許可する権利を与えられていない可能性がありますにこの文書は、2008年、IETFドキュメントまたは11月10日以前に発行または公開さ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
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.
このメモは、セッション開始プロトコル（SIP）サービスで使用する証明書の適用可能性を制限するための拡張キー使用法（EKU）X.509証明書拡張について説明します。このように、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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります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ドメインのアイデンティティ：証明書の所有者は、その対象のIDで指定されたドメイン内のSIPサービスのための権限を持っていることの証明書の受信者に伝えるX.509証明書のサブジェクトの識別情報。
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]の拡張機能は、[6] [5] ASN.1のX.680を使用して定義され、そしてX.690れます。
Consider the SIP RFC 3261 [2] actors shown in Figure 1.
SIPのRFC 3261 [2]アクターが図1に示さを考えます。
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のためのINVITE作成を前提としています。彼女のユーザーエージェント路線彼女のドメインでいくつかのプロキシ、example.comへの要求。 example.comは、いくつかのSIPプロキシを維持して大規模な組織であり、そして彼女は、アウトバウンドプロキシProxy-A.example.comに到着したINVITEことも想定。ルートするために、要求は、以降、プロキシ-Aは、RFC 3263 [7]の解像度を使用しProxy-B.example.netは、トランスポート層セキュリティ（TLS）を使用example.netための有効なプロキシであることを認めます。 Proxy-A.example.comはProxy-B.example.netへのTLS接続を要求し、TLSハンドシェイクで各1は、その接続を認証するために証明書を提示します。それらのピアが適切な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名example.comは、SIPドメイン名、電子メールドメイン名、およびWebサービス名として使用することができます。単一の組織内でこれらの異なるサービスが独立して管理し、個別にホストされるかもしれないので、証明書が証明書を提示するエンティティも権限を持っていることを意味を作成せずにSIPドメイン名とその使用法にDNS名を結合することが可能であることが望ましいです他のいくつかの目的のために。メカニズムは、プロキシに発行された証明書は、証明書が含まれていることをサブジェクト名（複数可）のみSIPで使用するために有効であるように制限することができるようにするために必要とされています。この例では、プロキシ-Bは、ドメインexample.netのためのSIPサーバとして権威プロキシ-Bを作る証明書を持っています。さらに、プロキシ-Bは、同様の証明書によって認証されたクライアントのSIPドメインを要求するポリシーを持っています。プロキシ-Aは、ドメインexample.comのSIPサーバ等の権威あります。プロキシ-Aプロキシ-BへのTLS接続を行う場合、後者は、そのポリシーに基づいて接続を受け入れます。
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をバインドしている拡張キー使用法の拡張値の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]インターネットでの使用のためのEKU X.509証明書拡張を指定します。拡張子は、認定公開鍵が有効であるために1つ以上の目的を示します。 EKU拡張は、より基本的な暗号化方法で、証明書の公開鍵が使用されているかを示す鍵用途拡張と組み合わせて使用することができます。
The EKU extension syntax is repeated here for convenience:
EKU拡張構文は利便性のためにここで繰り返されます。
ExtKeyUsageSyntax ::= SEQUENCE SIZE (1..MAX) OF KeyPurposeId
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 ID-KP-sipDomainを規定します。証明書このKeyPurposeIdを含めることは、証明書内の任意のサブジェクト名の使用は、（他のEKU値によって許容任意の用途と共に）SIPサービスでの使用に制限されていることを示しています。
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 }
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証明書のID（またはIDの集合）を見つけるための手順を含んでいます。証明書の使用のみ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.
証明書はどのEKU値を（拡張キー使用法の拡張子が存在しない）が含まれていない場合は、O、それは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.
証明書は、ID-KP-sipDomain EKU拡張機能が含まれている場合は、O、次いで、この仕様の実装は、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-sipDomain EKU値が含まれていませんが、ID-KP-anyExtendedKeyUsage 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.
EKU拡張が存在するが、ID-KP-sipDomainまたはID-KP-anyExtendedKeyUsage EKU値のいずれかが含まれていない場合、O、証明書は、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-sipDomain 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.
このメモは、自律ドメインに属するSIPサービスへの証明書の使用を制限EKU X.509証明書拡張を定義します。依拠当事者は、ID-KP-sipDomain EKU値と証明書を受信すると（例えば、課金に関連するもののような）適用可能なポリシーを実行することができます。 ID-KP-sipDomain EKU値は、新しいセキュリティやプライバシーの懸念を導入していません。
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）を必要とします。オブジェクトは、PKIXワーキンググループにIANAによって委任円弧で定義されています。これ以上のアクションは、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.
イェルーンバンBemmel、マイケル・ハマー、カレン・ジェニングス、ポールKyzivat、デレク・マクドナルド、デイブ・オラン、ジョンピーターソン、エリックレスコラ、ジョナサン・ローゼンバーグ、ラスHousley、ポール・ホフマン、そしてスティーブン・ケント：以下のIETFの貢献者は、この文書に実質的な入力を提供します。
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.
シャロンBoyenとトレバー・フリーマンは、文書を見直し、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]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[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]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "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]クーパー、D.、Santesson、S.、ファレル、S.、Boeyen、S.、Housley氏、R.、およびW.ポーク、「インターネットX.509公開鍵暗号基盤証明書と証明書失効リスト（CRL）のプロフィール」、RFC 5280、2008年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]国際国際電信電話諮問委員会、「抽象構文記法1（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）の仕様、Canonicalの符号化規則（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]ローゼンバーグ、J.、およびH. Schulzrinneと、 "セッション開始プロトコル（SIP）：SIPサーバの検索"、RFC 3263、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.、ローレンス、S.、およびA.ジェフリー、 "セッション開始プロトコル（SIP）にドメイン証明書"、RFC 5922、2010年6月。
Appendix A. ASN.1 Module
付録A. ASN.1モジュール
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）同定された組織（3）DOD（6）インターネット（1）セキュリティ（5）メカニズム（5）PKIX（7）ID-MOD（0）ID-MOD-SIP-ドメインextns2007（62） }
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
-- OID Arcs
- OIDアーク
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 }
END
終わり
Authors' Addresses
著者のアドレス
Scott Lawrence
スコット・ローレンス
EMail: scott-ietf@skrb.org
メールアドレス：scott-ietf@skrb.org
Vijay K. Gurbani Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane Room 9C-533 Naperville, IL 60566 USA
ビジェイK. Gurbaniベル研究所、アルカテル・ルーセント1960ルーセントレーンルーム9C-533ネーパーヴィル、IL 60566 USA
Phone: +1 630 224-0216 EMail: vkg@bell-labs.com
電話：+1 630 224-0216 Eメール：vkg@bell-labs.com