Internet Engineering Task Force (IETF) V. Gurbani
Request for Comments: 5922 Bell Laboratories, Alcatel-Lucent
Updates: 3261 S. Lawrence
Category: Standards Track
ISSN: 2070-1721 A. Jeffrey
Bell Laboratories, Alcatel-Lucent
June 2010
Domain Certificates in the Session Initiation Protocol (SIP)
Abstract
抽象
This document describes how to construct and interpret certain information in a PKIX-compliant (Public Key Infrastructure using X.509) certificate for use in a Session Initiation Protocol (SIP) over Transport Layer Security (TLS) connection. More specifically, this document describes how to encode and extract the identity of a SIP domain in a certificate and how to use that identity for SIP domain authentication. As such, this document is relevant both to implementors of SIP and to issuers of certificates.
この文書では、トランスポート層セキュリティ（TLS）接続を介してセッション開始プロトコル（SIP）に使用する証明書（X.509を使用して公開鍵インフラストラクチャ）PKIX準拠の中で特定の情報を構築し、解釈する方法について説明します。具体的には、この文書では、エンコードし、証明書にSIPドメインのIDを抽出し、どのようにSIPドメイン認証のためにそのIDを使用する方法について説明します。そのため、このドキュメントは、SIPの実装者へと証明書の発行体の両方に関連しています。
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 5741.
このドキュメントはインターネットエンジニアリングタスクフォース（IETF）の製品です。これは、IETFコミュニティの総意を表しています。これは、公開レビューを受けており、インターネットエンジニアリング運営グループ（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/rfc5922.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc5922で取得することができます。
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ライセンスのテキストを含める必要があり、この文書から抽出されました。
Table of Contents
目次
1. Introduction ....................................................3
2. Terminology .....................................................3
2.1. Key Words ..................................................3
3. Problem Statement ...............................................3
4. SIP Domain to Host Resolution ...................................5
5. The Need for Mutual Interdomain Authentication ..................6
6. Certificate Usage by a SIP Service Provider .....................7
7. Behavior of SIP Entities ........................................8
7.1. Finding SIP Identities in a Certificate ....................8
7.2. Comparing SIP Identities ...................................9
7.3. Client Behavior ...........................................10
7.4. Server Behavior ...........................................11
7.5. Proxy Behavior ............................................12
7.6. Registrar Behavior ........................................12
7.7. Redirect Server Behavior ..................................12
7.8. Virtual SIP Servers and Certificate Content ...............12
8. Security Considerations ........................................13
8.1. Connection Authentication Using Digest ....................13
9. Acknowledgments ................................................14
10. References ....................................................14
10.1. Normative References .....................................14
10.2. Informative References ...................................15
Appendix A. Editorial Guidance (Non-Normative) ...................16
A.1. Additions .................................................16
A.2. Changes ...................................................16
A.2.1. Changes to Section 26.3.1 .............................16
RFC 5246 [5] Transport Layer Security (TLS) is available in an increasing number of Session Initiation Protocol (SIP) RFC 3261 [2] implementations. In order to use the authentication capabilities of TLS, certificates as defined by the Internet X.509 Public Key Infrastructure, see RFC 5280 [6], are required.
RFC 5246 [5]は、トランスポート層セキュリティ（TLS）は、セッション開始プロトコル（SIP）RFC 3261 [2]実装の増加に利用可能です。インターネットX.509公開鍵インフラストラクチャによって定義されているTLSの認証機能を使用するためには、証明書は、RFC 5280 [6]、必要とされている参照してください。
Existing SIP specifications do not sufficiently specify how to use certificates for domain (as opposed to host) authentication. This document provides guidance to ensure interoperability and uniform conventions for the construction and interpretation of certificates used to identify their holders as being authoritative for the domain.
既存のSIPの仕様は十分に認証（ホストではなく）をドメインに証明書を使用する方法を指定しないでください。この文書では、ドメインの権威あるものとして彼らの所有者を識別するために使用される証明書の建設や解釈のための相互運用性と均一な規則を確実にするためのガイダンスを提供します。
The discussion in this document is pertinent to an X.509 PKIX-compliant certificate used for a TLS connection; this document does not define use of such certificates for any other purpose (such as Secure/Multipurpose Internet Mail Extensions (S/MIME)).
このドキュメントの議論は、TLS接続に使用されるX.509 PKIX準拠の証明書に適切です。この文書は、（セキュア/多目的インターネットメール拡張（S / MIME）のような）他の目的のために、このような証明書の使用を定義していません。
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]。
Additional definition(s):
追加の定義（S）：
SIP domain identity: An identity (e.g., "sip:example.com") contained in an X.509 certificate bound to a subject that identifies the subject as an authoritative SIP server for a domain.
SIPドメインアイデンティティ：アイデンティティ（例えば、「SIP：example.com」）ドメインのための権限のSIPサーバとしての被写体を識別する被写体に結合したX.509証明書に含まれます。
TLS uses RFC 5280 [6] X.509 Public Key Infrastructure to bind an identity or a set of identities, to the subject of an X.509 certificate. While RFC 3261 provides adequate guidance on the use of X.509 certificates for S/MIME, it is relatively silent on the use of such certificates for TLS. With respect to certificates for TLS, RFC 3261 (Section 26.3.1) says:
TLSは、X.509証明書のサブジェクトに、アイデンティティやアイデンティティのセットをバインドするためにRFC 5280 [6] X.509公開鍵インフラストラクチャを使用しています。 RFC 3261は、S / MIMEのためのX.509証明書の使用に十分なガイダンスを提供していますが、それはTLSのために、このような証明書の使用では比較的静かです。 TLSの証明書に関しては、RFC 3261（セクション26.3.1）は言います：
Proxy servers, redirect servers, and registrars SHOULD possess a site certificate whose subject corresponds to their canonical hostname.
プロキシサーバー、サーバーのリダイレクト、およびレジストラがその対象と自分の正規のホスト名に対応して、サイトの証明書を有していなければなりません。
The security properties of TLS and S/MIME as used in SIP are different: X.509 certificates for S/MIME are generally used for end-to-end authentication and encryption; thus, they serve to bind the identity of a user to the certificate and RFC 3261 is sufficiently clear that in certificates used for S/MIME, the subjectAltName field will contain the appropriate identity. On the other hand, X.509 certificates used for TLS serve to bind the identities of the per-hop domain sending or receiving the SIP messages. However, the lack of guidelines in RFC 3261 on exactly where to put identities -- in the subjectAltName field or carried as a Common Name (CN) in the Subject field -- of an X.509 certificate created ambiguities. Following the accepted practice of the time, legacy X.509 certificates were allowed to store the identity in the CN field of the certificate instead of the currently specified subjectAltName extension. Lack of further guidelines on how to interpret the identities, which identity to choose if more than one identity is present in the certificate, the behavior when multiple identities with different schemes were present in the certificate, etc., lead to ambiguities when attempting to interpret the certificate in a uniform manner for TLS use.
SIPで使用されるTLSとS / MIMEのセキュリティ特性が異なっている：S / MIMEのためのX.509証明書は、一般に、エンドツーエンドの認証および暗号化のために使用されます。このように、彼らは、証明書にユーザーのIDをバインドするのに役立つとRFC 3261は、S / MIMEのために使用される証明書には、のsubjectAltNameフィールドが適切なIDが含まれていることを十分に明確です。一方、TLSに使用するX.509証明書は、SIPメッセージの送信または受信ホップごとのドメインのアイデンティティをバインドするのに役立ちます。しかし、正確にアイデンティティを置くためにRFC 3261のガイドラインの欠如 - のsubjectAltNameフィールドまたはSubjectフィールドで共通名（CN）として運ば - X.509証明書のは、あいまいさを作成しました。当時の慣例に続いて、従来のX.509証明書は、証明書の代わりに、現在指定subjectAltName拡張のCNフィールドにIDを保存させました。などのIDを解釈する方法についての更なるガイドラインの欠如、複数のアイデンティティが証明書に存在している場合は選択するアイデンティティ、異なるスキームを持つ複数のアイデンティティが証明書に存在していた行動、解釈しようとしたときにあいまいさにつながりますTLSを使用するために一定の方法で証明書。
This document shows how the certificates are to be used for mutual authentication when both the client and server possess appropriate certificates, and normative behavior for matching the DNS query string with an identity stored in the X.509 certificate. Furthermore, a certificate can contain multiple identities for the subject in the subjectAltName extension (the "subject" of a certificate identifies the entity associated with the public key stored in the public key field). As such, this document specifies appropriate matching rules to encompass various subject identity representation options. And finally, this document also provides guidelines to service providers for assigning certificates to SIP servers.
このドキュメントでは、証明書は、クライアントとサーバーの両方が適切な証明書を持って相互認証、およびX.509証明書に格納されているIDを持つDNSクエリ文字列をマッチングするための規範的な行動のために使用される方法を示しています。また、証明書は、（証明書の「対象」の公開鍵フィールドに格納された公開鍵に関連付けられたエンティティを識別する）subjectAltName拡張に被写体の複数のIDを含むことができます。そのようなものとして、この文書は、様々な対象アイデンティティ表現オプションを包含するように、適切なマッチング規則を指定します。そして最後に、この文書はまた、SIPサーバに証明書を割り当てるためのサービスプロバイダにガイドラインを提供します。
The rest of this document is organized as follows: the next section provides an overview of the most primitive case of a client using DNS to access a SIP server and the resulting authentication steps. Section 5 looks at the reason why mutual inter-domain authentication is desired in SIP, and the lack of normative text and behavior in RFC 3261 for doing so. Section 6 outlines normative guidelines for a service provider assigning certificates to SIP servers. Section 7 provides normative behavior on the SIP entities (user agent clients, user agent servers, registrars, redirect servers, and proxies) that need perform authentication based on X.509 certificates. Section 8 includes the security considerations.
このドキュメントの残りは以下の通り構成されています。次のセクションでは、SIPサーバにアクセスするためにDNSを使用して、クライアントの中で最も原始的なケースと結果の認証手順の概要を説明します。第5節は、相互間のドメイン認証はSIPに希望する理由、そしてそうするためのRFC 3261で規範的なテキストや行動の欠如を見ます。第6節は、SIPサーバに証明書を割り当てるサービスプロバイダのための規範的な指針を概説します。第7節は、X.509証明書に基づく認証を行う必要があるSIPエンティティ（ユーザエージェントクライアント、ユーザエージェントサーバ、レジストラサーバのリダイレクト、およびプロキシ）上の規範的な動作を提供します。第8章では、セキュリティ上の考慮事項が含まれています。
Routing in SIP is performed by having the client execute RFC 3263 [8] procedures on a URI, called the "Application Unique String (AUS)" (c.f. Section 8 of RFC 3263 [8]). These procedures take as input a SIP AUS (the SIP URI), extract the domain portion of that URI for use as a lookup key, and query the Domain Name Service (DNS) to obtain an ordered set of one or more IP addresses with a port number and transport corresponding to each IP address in the set (the "Expected Output"). If the transport indicates the use of TLS, then a TLS connection is opened to the server on a specific IP address and port. The server presents an X.509 certificate to the client for verification as part of the initial TLS handshake.
クライアントは、URIにRFC 3263 [8]の手順を実行することによって実行されるSIPのルーティング、 "アプリケーション固有の文字列（AUS）" と呼ばれる（RFC 3263のC.F.セクション8 [8]）。これらの手順は、検索キーとして使用するためにそのURIのドメイン部分を抽出し、入力としてSIP AUS（SIP URI）を取り、1つのまたは複数のIPアドレスの順序集合を得るために、ドメインネームサービス（DNS）を照会しますセット内の各IPアドレス（「予想される出力」）に対応するポート番号と輸送。トランスポートはTLSの使用を示す場合、TLS接続は、特定のIPアドレスとポート上のサーバーに開放されています。サーバーは、最初のTLSハンドシェイクの一環として、検証のためにクライアントにX.509証明書を提示します。
The client extracts identifiers from the Subject and any subjectAltName extension in the certificate (see Section 7.1) and compares these values to the domain part extracted from the original SIP URI (the AUS). If any identifier match is found, the server is considered to be authenticated and subsequent signaling can now proceed over the TLS connection. Matching rules for X.509 certificates and the normative behavior for clients is specified in Section 7.3.
クライアントは、被写体からの識別子と、証明書のいずれかのsubjectAltName拡張（セクション7.1を参照）を抽出し、元のSIP URI（AUS）から抽出されたドメイン部分にこれらの値を比較します。任意の識別子の一致が見つかった場合、サーバーは認証されたとみなされ、その後のシグナリングは今TLS接続を介して進むことができます。 X.509証明書とクライアントのための規範的な行動のためのマッチングルールは、7.3節で指定されています。
As an example, consider a request that is to be routed to the SIP address "sips:alice@example.com". This address requires a secure connection to the SIP domain "example.com" (the 'sips' scheme mandates a secure connection). Through a series of DNS manipulations, the domain name is mapped to a set of host addresses and transports. The entity attempting to create the connection selects an address appropriate for use with TLS from this set. When the connection is established to that server, the server presents a certificate asserting the identity "sip:example.com". Since the domain part of the SIP AUS matches the subject of the certificate, the server is authenticated (see Section 7.2 for the normative rules that govern this comparison).
一例として、SIPアドレス「：alice@example.comすする」にルーティングされる要求を検討します。このアドレスは、SIPドメイン「example.com」（「SIPS」スキームは安全な接続を義務付け）への安全な接続が必要です。 DNSの一連の操作によって、ドメイン名がホストアドレスとトランスポートのセットにマッピングされています。接続を作成しようとするエンティティは、このセットからTLSで使用するための適切なアドレスを選択します。接続がそのサーバーに確立されると、サーバはアイデンティティ「：example.com一口に」アサート証明書を提示します。 SIP AUSのドメイン部分は、証明書の主題と一致するので、サーバ（この比較を支配する規範的なルールについてはセクション7.2を参照）が認証されます。
Session Initiation Protocol Secure (SIPS) borrows this pattern of server certificate matching from HTTPS. However, RFC 2818 [7] prefers that the identity be conveyed as a subjectAltName extension of type dNSName rather than the common practice of conveying the identity in the CN field of the Subject field. Similarly, this document recommends that the SIP domain identity be conveyed as a subjectAltName extension of type uniformResourceIdentifier (c.f. Sections 6 and 7.1).
セッション開始プロトコルセキュア（SIPS）は、HTTPSからサーバ証明書マッチングのこのパターンを借用します。しかし、RFC 2818 [7]アイデンティティは型のdNSNameのsubjectAltName拡張はなく、件名フィールドのCNフィールドのアイデンティティを搬送する一般的な方法として搬送されることを好みます。同様に、この文書は、SIPドメインIDがタイプuniformResourceIdentifierでのsubjectAltName拡張（C.F.部6および7.1）のように搬送することをお勧めします。
A domain name in an X.509 certificates is properly interpreted only as a sequence of octets to be compared to the URI used to reach the host. No inference can be made based on the DNS name hierarchy. For example, a valid certificate for "example.com" does not imply that the owner of that certificate has any relationship at all to "subname.example.com".
X.509証明書のドメイン名が正しくホストだけに到達するために使用されるURIと比較されるべきオクテットのシーケンスとして解釈されます。いかなる推論は、DNS名の階層に基づいて行うことはできません。たとえば、「example.com」の有効な証明書は、その証明書の所有者が「subname.example.com」にまったく関係があることを意味するものではありません。
Consider the SIP trapezoid shown in Figure 1.
図1に示すSIP台形を考えます。
Proxy-A.example.com Proxy-B.example.net
+-------+ +-------+
| Proxy |--------------------| Proxy |
+----+--+ +---+---+
| |
| |
| |
| +---+
0---0 | |
/-\ |___|
+---+ / /
+----+
alice@example.com bob@example.net
Figure 1: SIP Trapezoid
図1：SIP台形
A user, alice@example.com, invites bob@example.net for a multimedia communication session. Alice's outbound proxy, Proxy-A.example.com, uses normal RFC 3263 [8] resolution rules to find a proxy -- Proxy-B.example.net -- in the example.net domain that uses TLS. Proxy-A actively establishes an interdomain TLS connection with Proxy-B and each presents a certificate to authenticate that connection.
ユーザー、alice@example.comは、マルチメディア通信セッションのためのbob@example.netを誘います。 TLSを使用していますexample.netドメインに - Proxy-B.example.net - アリスのアウトバウンドプロキシ、Proxy-A.example.comは、[8]解像度のルールがプロキシを見つけるために、通常のRFC 3263を使用しています。プロキシAが活発プロキシBとのドメイン間のTLS接続を確立し、それぞれがその接続を認証する証明書を提示します。
RFC 3261 [2], Section 26.3.2.2, "Interdomain Requests" states that when a TLS connection is created between two proxies:
RFC 3261 [2]、セクション26.3.2.2、「ドメイン間の要求は、」TLS接続が2つのプロキシ間で作成されたときと述べています：
Each side of the connection SHOULD verify and inspect the certificate of the other, noting the domain name that appears in the certificate for comparison with the header fields of SIP messages.
接続の各側は、SIPメッセージのヘッダフィールドとの比較のために証明書に表示されるドメイン名を指摘、他の証明書を検証し、検査するべきです。
However, RFC 3261 is silent on whether to use the subjectAltName or CN of the certificate to obtain the domain name, and which takes precedence when there are multiple names identifying the holder of the certificate.
しかし、RFC 3261には、ドメイン名を取得する証明書のsubjectAltNameまたはCNを使用するかどうかについて沈黙している、そしてそれは、証明書の所有者を識別する複数の名前が存在する場合に優先されます。
The authentication problem for Proxy-A is straightforward: in the certificate Proxy-A receives from Proxy-B, Proxy-A looks for an identity that is a SIP URI ("sip:example.net") or a DNS name ("example.net") that asserts Proxy-B's authority over the example.net domain. Normative behavior for a TLS client like Proxy-A is specified in Section 7.3.
プロキシ-Aの認証の問題は簡単である：またはDNS名（「例：プロキシ-Aプロキシ-Bから受信した証明書に、プロキシ-Aは、SIP URI（「example.net SIP」）であるアイデンティティを探しexample.netドメイン上でプロキシ-Bの権限をアサート.NET」）。プロキシ-AのようなTLSクライアントのための規範的行動は、7.3節で指定されています。
The problem for Proxy-B is slightly more complex since it accepts the TLS request passively. Thus, Proxy-B does not possess an equivalent AUS that it can use as an anchor in matching identities from Proxy-A's certificate.
それは受動的にTLS要求を受け付けるためのプロキシ-Bの問題は、やや複雑です。このように、プロキシ-Bは、それがプロキシ-Aの証明書からIDをマッチングにアンカーとして使用できる同等のAUSを持ちません。
RFC 3261 [2], Section 26.3.2.2, only tells Proxy-B to "compare the domain asserted by the certificate with the 'domainname' portion of the From header field in the INVITE request". The difficulty with that instruction is that the domainname in the From header field is not always that of the domain from which the request is received.
RFC 3261 [2]、セクション26.3.2.2、唯一「INVITE要求内からヘッダフィールドの 『ドメイン名』部分と証明書によってアサートドメインを比較」にプロキシ-Bに伝えます。その命令の難点は、Fromヘッダーフィールド内のドメインが常に要求が受信されたドメインのものではないということです。
The normative behavior for a TLS server like Proxy-B that passively accepts a TLS connection and requires authentication of the sending peer domain is provided in Section 7.4.
受動的にTLS接続を受け付け、送信ピアのドメインの認証を必要とするプロキシ-BのようなTLSサーバーの規範的動作は、セクション7.4に提供されます。
It is possible for service providers to continue the practice of using existing certificates for SIP usage with the identity conveyed only in the Subject field, but they should carefully consider the following advantages of conveying identity in the subjectAltName extension field:
サービスプロバイダはアイデンティティとSIPの利用のために既存の証明書を使用しての練習を継続することは件名フィールドにのみ伝え可能ですが、彼らは慎重にsubjectAltName拡張フィールドにアイデンティティを伝える、次のような利点を考慮する必要があります。
o The subjectAltName extension can hold multiple values, so the same certificate can identify multiple servers or sip domains.
同じ証明書が複数のサーバまたはSIPドメインを識別できるように、O subjectAltName拡張は、複数の値を保持することができます。
o There is no fixed syntax specified for the Subject field, so issuers vary in how the field content is set. This forces a recipient to use heuristics to extract the identity, again increasing opportunities for misinterpretation.
Oあり件名フィールドに指定決まった構文ではありませんので、発行体は、フィールドの内容が設定されている方法が異なります。これは、再び誤った解釈の機会を増やし、アイデンティティを抽出するために、ヒューリスティックを使用するための受信者を強制します。
Because of these advantages, service providers are strongly encouraged to obtain certificates that contain the identity or identities in the subjectAltName extension field.
これらの利点から、サービスプロバイダは強くsubjectAltName拡張フィールド内の同一性またはアイデンティティを含む証明書を取得することをお勧めします。
When assigning certificates to authoritative servers, a SIP service provider MUST ensure that the SIP domain used to reach the server appears as an identity in the subjectAltName field, or for compatibility with existing certificates, the Subject field of the certificate. In practice, this means that a service provider distributes to its users SIP URIs whose domain portion corresponds to an identity for which the service provider has been issued a certificate.
権威サーバに証明書を割り当てる場合、SIPサービスプロバイダは、サーバに到達するために使用されるSIPドメインがのsubjectAltNameフィールドでIDとして表示され、または既存の証明書、証明書のサブジェクトフィールドとの互換性のために確実にしなければなりません。実際には、これは、サービスプロバイダがそのユーザそのドメイン部分サービスプロバイダが証明書を発行されたIDに対応するSIP URIに分配することを意味します。
This section normatively specifies the behavior of SIP entities when using X.509 certificates to determine an authenticated SIP domain identity.
認証されたSIPドメインの同一性を決定するためにX.509証明書を使用する場合は、このセクションでは、規範的にSIPエンティティの動作を指定します。
The first two subsections apply to all SIP implementations that use TLS to authenticate the peer: Section 7.1 describes how to extract a set of SIP identities from the certificate obtained from a TLS peer, and Section 7.2 specifies how to compare SIP identities. The remaining subsections provide context for how and when these rules are to be applied by entities in different SIP roles.
最初の2つのサブセクションは、ピアを認証するためにTLSを使用するすべてのSIP実装に適用：7.1節は、TLSピアから取得した証明書からSIPアイデンティティのセットを抽出する方法を説明し、そして7.2節は、SIPアイデンティティを比較する方法を指定します。残りのサブセクションでは、どのように、これらのルールは、異なるSIPロール内のエンティティによって適用する場合のためのコンテキストを提供します。
Implementations (both clients and server) MUST determine the validity of a certificate by following the procedures described in RFC 5280 [6].
実装は（クライアントとサーバの両方）RFC 5280に記載の手順に従って、証明書の有効性を決定しなければならない[6]。
As specified by RFC 5280 [6], Section 4.2.1.12, implementations MUST check for restrictions on certificate usage declared by any extendedKeyUsage extensions in the certificate. The SIP Extended Key Usage (EKU) document [12] defines an extendedKeyUsage for SIP.
[6]、セクション4.2.1.12は、RFC 5280で規定されているように、実装は証明書のいずれかのextendedKeyUsageの拡張によって宣言された証明書の使用方法の制限のためにチェックしなければなりません。 SIP拡張キー使用法（EKU）ドキュメント[12]はSIPのためのextendedKeyUsageのを規定します。
Given an X.509 certificate that the above checks have found to be acceptable, the following describes how to determine what SIP domain identity or identities the certificate contains. A single certificate can serve more than one purpose -- that is, the certificate might contain identities not acceptable as SIP, domain identities and/or might contain one or more identities that are acceptable for use as SIP domain identities.
上記のチェックを許容できることを発見したX.509証明書を考えると、次はどのようなSIPドメインの同一性を決定する方法を説明したり、証明書が含まれていなIDを。単一の証明書は、複数の目的を果たすことができる - つまり、証明書は、SIPとして受け入れられないアイデンティティが含まれているドメインのアイデンティティおよび/またはSIPドメインアイデンティティとして使用するために許容される1人の以上のアイデンティティが含まれている場合があります。
1. Examine each value in the subjectAltName field. The subjectAltName field and the constraints on its values are defined in Section 4.2.1.6 of RFC 5280 [6]. The subjectAltName field can be absent or can contain one or more values. Each value in the subjectAltName has a type; the only types acceptable for encoding a SIP domain identity SHALL be:
1.のsubjectAltNameフィールドにそれぞれの値を調べます。 subjectAltNameフィールドとその値の制約は、RFC 5280のセクション4.2.1.6で定義されている[6]。 subjectAltNameフィールドが不在であってもよく、または1つ以上の値を含めることができます。 subjectAltNameの各値は、タイプを有します。 SIPドメインIDをエンコードするための許容可能な唯一のタイプがなければなりません。
URI If the scheme of the URI is not "sip", then the
implementation MUST NOT accept the value as a SIP domain
identity.
If the scheme of the URI value is "sip", and the URI value
that contains a userpart (there is an '@'), the
implementation MUST NOT accept the value as a SIP domain
identity (a value with a userpart identifies an individual
user, not a domain).
If the scheme of the URI value is "sip", and there is no userinfo component in the URI (there is no '@'), then the implementation MUST accept the hostpart as a SIP domain identity.
URI値の方式が「SIP」であり、URIにはユーザー情報の成分（NO「@」が存在しない）が存在しない場合、実装は、SIPドメインIDとしてhostpartを受け入れなければなりません。
Note: URI scheme tokens are always case insensitive.
注意：URIスキームトークンは常に大文字と小文字を区別しません。
DNS An implementation MUST accept a domain name system identifier as a SIP domain identity if and only if no other identity is found that matches the "sip" URI type described above.
DNS実装があればSIPドメインIDとしてドメイン名システム識別子を受け入れなければならなくて、他のアイデンティティは、上記の「SIP」URIタイプと一致することが見出されていない場合のみ。
2. If and only if the subjectAltName does not appear in the certificate, the implementation MAY examine the CN field of the certificate. If a valid DNS name is found there, the implementation MAY accept this value as a SIP domain identity. Accepting a DNS name in the CN value is allowed for backward compatibility, but when constructing new certificates, consider the advantages of using the subjectAltName extension field (see Section 6).
2.とのsubjectAltNameが証明書に表示されない場合にのみ場合は、インプリメンテーションは、証明書のCNフィールドを調べることができます。有効なDNS名が見つかった場合、実装は、SIPドメインIDとしてこの値を受け入れることができます。 CN値のDNS名を受け入れると下位互換性のために許可されますが、新しい証明書を作成するときに、（セクション6を参照）subjectAltName拡張フィールドを使用することの利点を検討しています。
The above procedure yields a set containing zero or more identities from the certificate. A client uses these identities to authenticate a server (see Section 7.3) and a server uses them to authenticate a client (see Section 7.4).
上記の手順は、証明書から、ゼロ以上のアイデンティティを含むセットを生成します。 （7.4節を参照）、クライアントはサーバーを認証するためにこれらのIDを使用しています（7.3節を参照）、サーバがクライアントを認証するためにそれらを使用しています。
When an implementation (either client or server) compares two values as SIP domain identities:
実装（クライアントまたはサーバ）は、SIPドメインのIDとして2つの値を比較した場合：
Implementations MUST compare only the DNS name component of each SIP domain identifier; an implementation MUST NOT use any scheme or parameters in the comparison.
実装は、各SIPドメイン識別子のみDNS名コンポーネントを比較しなければなりません。実装は、比較のいずれかの方式やパラメータを使用してはなりません。
Implementations MUST compare the values as DNS names, which means that the comparison is case insensitive as specified by RFC 4343 [3]. Implementations MUST handle Internationalized Domain Names (IDNs) in accordance with Section 7.2 of RFC 5280 [6].
実装は、[3] RFC 4343で指定された比較は大文字小文字を区別しないことを意味する、DNS名として値を比較しなければなりません。実装は、RFC 5280のセクション7.2に従って、国際化ドメイン名（IDNドメイン）を処理しなければならない[6]。
Implementations MUST match the values in their entirety:
実装は、その全体の値と一致する必要があります。
Implementations MUST NOT match suffixes. For example, "foo.example.com" does not match "example.com".
実装はサフィックスと一致してはなりません。たとえば、「foo.example.com」「example.com」一致していません。
Implementations MUST NOT match any form of wildcard, such as a leading "." or "*." with any other DNS label or sequence of labels. For example, "*.example.com" matches only "*.example.com" but not "foo.example.com". Similarly, ".example.com" matches only ".example.com", and does not match "foo.example.com".
実装は、このような大手として、ワイルドカードのいずれかの形式を一致させることはできません「」または "*。"ラベルの他のDNSラベルまたは配列と。たとえば、 "* .example.comとは、" のみ "* .example.comと" ではなく "foo.example.com" にマッチします。同様に、「.example.comとは」「.example.comと」のみマッチし、 『foo.example.com』と一致していません。
RFC 2818 [7] (HTTP over TLS) allows the dNSName component to contain a wildcard; e.g., "DNS:*.example.com". RFC 5280 [6], while not disallowing this explicitly, leaves the interpretation of wildcards to the individual specification. RFC 3261 [2] does not provide any guidelines on the presence of wildcards in certificates. Through the rule above, this document prohibits such wildcards in certificates for SIP domains.
RFC 2818 [7]（TLS over HTTPを）のdNSNameコンポーネントはワイルドカードを含めることができます。例えば、 "DNS：。* example.com"。 RFC 5280 [6]、これを明示的に禁止されていないが、個々の仕様にワイルドカードの解釈を残します。 RFC 3261 [2]の証明書でワイルドカードの存在上の任意のガイドラインを提供していません。上記のルールを経て、この文書は、SIPドメインの証明書では、このようなワイルドカードを禁止しています。
A client uses the domain portion of the SIP AUS to query a (possibly untrusted) DNS to obtain a result set, which is one or more SRV and A records identifying the server for the domain (see Section 4 for an overview).
クライアントは、ドメイン（概要についてはセクション4を参照）サーバを識別する一つ以上のSRVおよびAレコードである結果セットを取得するために（おそらく信頼できない）DNSを照会するSIP AUSのドメイン部分を使用します。
The SIP server, when establishing a TLS connection, presents its certificate to the client for authentication. The client MUST determine the SIP domain identities in the server certificate using the procedure in Section 7.1. Then, the client MUST compare the original domain portion of the SIP AUS used as input to the RFC 3263 [8] server location procedures to the SIP domain identities obtained from the certificate.
TLS接続を確立するSIPサーバは、認証のためにクライアントに証明書を提示します。クライアントは、7.1節の手順を使用して、サーバ証明書内のSIPドメインのアイデンティティを決定する必要があります。次に、クライアントは、RFC 3263への入力として使用されるSIP AUSの元のドメイン部分を比較しなければならない[8]証明書から取得したSIPドメインアイデンティティに対するサーバの位置手続き。
o If there were no identities found in the server certificate, the server is not authenticated.
サーバ証明書が見つかりませんアイデンティティがなかった場合は、O、サーバが認証されていません。
o If the domain extracted from the AUS matches any SIP domain identity obtained from the certificate when compared as described in Section 7.2, the server is authenticated for the domain.
AUSから抽出されたドメインは、セクション7.2で説明したように比較した場合、証明書から得られる任意のSIPドメインアイデンティティと一致する場合、O、サーバは、ドメインの認証されています。
If the server is not authenticated, the client MUST close the connection immediately.
サーバが認証されない場合、クライアントはすぐに接続を閉じる必要があります。
When a server accepts a TLS connection, the server presents its own X.509 certificate to the client. Servers that wish to authenticate the client will ask the client for a certificate. If the client possesses a certificate, that certificate is presented to the server. If the client does not present a certificate, the client MUST NOT be considered authenticated.
サーバはTLS接続を受け入れると、サーバはクライアントに、独自のX.509証明書を提示します。クライアントを認証したいサーバーは、証明書をクライアントに要求されます。クライアントが証明書を持っている場合は、その証明書をサーバに提示されます。クライアントが証明書を提示しない場合、クライアントは、認証されたとみなされてはなりません。
Whether or not to close a connection if the client does not present a certificate is a matter of local policy, and depends on the authentication needs of the server for the connection. Some currently deployed servers use Digest authentication to authenticate individual requests on the connection, and choose to treat the connection as authenticated by those requests for some purposes (but see Section 8.1).
証明書を提示していないクライアントは、ローカルポリシーの問題である、との接続のためのサーバの認証ニーズに依存している場合かどうかは、接続を閉じます。いくつかの現在展開されたサーバーは、接続上の個々の要求を認証し、いくつかの目的のために、これらの要求によって認証されたような接続を処理することを選択した（ただし、8.1節を参照）してダイジェスト認証を使用します。
If the local server policy requires client authentication for some local purpose, then one element of such a local policy might be to allow the connection only if the client is authenticated. For example, if the server is an inbound proxy that has peering relationships with the outbound proxies of other specific domains, the server might allow only connections authenticated as coming from those domains.
ローカルサーバポリシーは、いくつかの地元の目的のためにクライアント認証を必要とする場合は、そのような局所的な政策の一つの要素は、クライアントが認証されている場合にのみ接続を許可するかもしれません。サーバーが他の特定のドメインのアウトバウンドプロキシとの関係をピアリングしている着信プロキシであれば、例えば、サーバは、それらのドメインから来るとして認証のみ接続を許可することがあります。
When authenticating the client, the server MUST obtain the set of SIP domain identities from the client certificate as described in Section 7.1. Because the server accepted the TLS connection passively, unlike a client, the server does not possess an AUS for comparison. Nonetheless, server policies can use the set of SIP domain identities gathered from the certificate in Section 7.1 to make authorization decisions.
クライアントを認証する場合は、セクション7.1で説明したように、サーバーは、クライアント証明書からのSIPドメインIDのセットを取得する必要があります。サーバは受動的にTLS接続を受け入れているため、クライアントとは異なり、サーバは、比較のためにAUSを持ちません。それにもかかわらず、サーバポリシーは、許可の決定を行うために7.1節で証明書から収集したSIPドメインIDのセットを使用することができます。
For example, a very open policy could be to accept an X.509 certificate and validate the certificate using the procedures in RFC 5280 [6]. If the certificate is valid, the identity set is logged.
例えば、非常にオープンポリシーは、X.509証明書を受け入れ、[6] RFC 5280に記載されている手順を使用して証明書を検証することができました。証明書が有効である場合は、アイデンティティセットが記録されます。
Alternatively, the server could have a list of all SIP domains the server is allowed to accept connections from; when a client presents its certificate, for each identity in the client certificate, the server searches for the identity in the list of acceptable domains to decide whether or not to accept the connection. Other policies that make finer distinctions are possible.
また、サーバは、SIPは、サーバがからの接続を受け入れるように許可されているドメインのすべてのリストを持っている可能性があり、クライアントは、その証明書を提示したときに、クライアント証明書内の各アイデンティティのために、許容可能なドメインのリストで身元のサーバー検索は、接続を受け入れるかどうかを決定します。細かい区別を作る他のポリシーが可能です。
The decision of whether or not the authenticated connection to the client is appropriate for use to route new requests to the client domain is independent of whether or not the connection is authenticated; the connect-reuse [10] document discusses this aspect in more detail.
クライアントへの接続に認証がクライアントのドメインへのルート新しい要求への使用に適しているか否かの判断は、接続が認証されているかどうかとは無関係です。接続再利用する[10]文書は、より詳細にこの局面を論じています。
A proxy MUST use the procedures defined for a User Agent Server (UAS) in Section 7.4 when authenticating a connection from a client.
クライアントからの接続を認証するときに、プロキシは、セクション7.4にユーザエージェントサーバ（UAS）のために定義された手順を使用しなければなりません。
A proxy MUST use the procedures defined for a User Agent Client (UAC) in Section 7.3 when requesting an authenticated connection to a UAS.
プロキシは、UASへの接続に認証を要求するとき、セクション7.3でユーザエージェントクライアント（UAC）のために定義された手順を使用しなければなりません。
If a proxy adds a Record-Route when forwarding a request with the expectation that the route is to use secure connections, the proxy MUST insert into the Record-Route header a URI that corresponds to an identity for which the proxy has a certificate; if the proxy does not insert such a URI, then creation of a secure connection using the value from the Record-Route as the AUS will be impossible.
ルートがセキュア接続を使用することを期待して要求を転送するとき、プロキシは、レコードルートを追加した場合、プロキシは、プロキシ証明書を持っているIDに対応するURIヘッダレコードルートに挿入しなければなりません。プロキシは、そのようなURIを挿入しない場合、AUSとして記録し、ルートからの値を使用してセキュアな接続の作成が不可能になります。
A SIP registrar, acting as a server, follows the normative behavior of Section 7.4. When the SIP registrar accepts a TLS connection from the client, the SIP registrar presents its certificate. Depending on the registrar policies, the SIP registrar can challenge the client with HTTP Digest.
SIPレジストラは、サーバーとして動作し、7.4節の規範的な行動に従います。 SIPレジストラは、クライアントからのTLS接続を受け入れると、SIPレジストラは、その証明書を提示します。レジストラポリシーによって、SIPレジストラは、HTTPダイジェストをクライアントに挑戦することができます。
A SIP redirect server follows the normative behavior of a UAS as specified in Section 7.4.
SIPリダイレクトサーバはセクション7.4で指定されるようにUASの規範的動作に従います。
In the "virtual hosting" cases where multiple domains are managed by a single application, a certificate can contain multiple subjects by having distinct identities in the subjectAltName field as specified in RFC 4474 [9]. Clients seeking to authenticate a server on such a virtual host can still follow the directions in Section 7.3 to find the identity matching the SIP AUS used to query DNS.
複数のドメインは、単一のアプリケーションによって管理されている「仮想ホスティング」のケースでは、証明書[9] RFC 4474に指定されているのsubjectAltNameフィールドに異なるアイデンティティを有することによって、複数の対象を含むことができます。 SIP AUSに一致するアイデンティティを見つけるために、まだ7.3節の指示に従うことができ、このような仮想ホスト上のサーバーを認証しようとしているクライアントは、DNSを照会するために使用しました。
Alternatively, if the TLS client hello "server_name" extension as defined in RFC 4366 [4] is supported, the client SHOULD use that extension to request a certificate corresponding to the specific domain (from the SIP AUS) with which the client is seeking to establish a connection.
[4]がサポートされているRFC 4366で定義されているTLSクライアントハロー「サーバ名」拡張場合あるいは、クライアントは、クライアントが求めていると（SIP AUSから）特定のドメインに対応する証明書を要求するために、その拡張機能を使用すべきです接続を確立します。
The goals of TLS (when used with X.509 certificates) include the following security guarantees at the transport layer:
（X.509証明書を使用）TLSの目標は、トランスポート層で、次のセキュリティの保証が含まれます。
Confidentiality: packets tunneled through TLS can be read only by the sender and receiver.
機密性：TLSを介してトンネリングパケットのみを送信者と受信者が読み取ることができます。
Integrity: packets tunneled through TLS cannot be undetectably modified on the connection between the sender and receiver.
整合性：TLSを介してトンネリングパケットが検出できない送信者と受信者との間の接続に変更することができません。
Authentication: each principal is authenticated to the other as possessing a private key for which a certificate has been issued. Moreover, this certificate has not been revoked, and is verifiable by a certificate chain leading to a (locally configured) trust anchor.
認証：各プリンシパルは証明書が発行された秘密鍵を有するものとして他に認証されます。また、この証明書は失効し、（ローカルで設定）トラストアンカーに至る証明書チェーンによって検証されていません。
We expect appropriate processing of domain certificates to provide the following security guarantees at the application level:
私たちは、アプリケーションレベルで次のセキュリティ保証を提供するために、ドメイン証明書の適切な処理を期待します：
Confidentiality: SIPS messages from alice@example.com to bob@example.net can be read only by alice@example.com, bob@example.net, and SIP proxies issued with domain certificates for example.com or example.net.
機密性：alice@example.com、bob@example.netによってのみ読み取ることができbob@example.netするalice@example.comからのメッセージをSIPS、およびSIPプロキシは、example.comまたはexample.netのドメイン証明書を発行しました。
Integrity: SIPS messages from alice@example.com to bob@example.net cannot be undetectably modified on the links between alice@example.com, bob@example.net, and SIP proxies issued with domain certificates for example.com or example.net.
整合性：alice@example.comからbob@example.netへのメッセージが検出できないほどexample.comまたは、例えば、ドメイン証明書を発行したalice@example.com、bob@example.net、およびSIPプロキシ間のリンクに変更することはできませんSIPS。ネット。
Authentication: alice@example.com and proxy.example.com are mutually authenticated; moreover, proxy.example.com is authenticated to alice@example.com as an authoritative proxy for domain example.com. Similar mutual authentication guarantees are given between proxy.example.com and proxy.example.net and between proxy.example.net and bob@example.net. As a result, alice@example.com is transitively mutually authenticated to bob@example.net (assuming trust in the authoritative proxies for example.com and example.net).
認証：alice@example.comとproxy.example.comは、相互認証されました。さらに、proxy.example.comは、ドメインexample.comに対して権限のプロキシとしてalice@example.comに認証されます。同様の相互認証保証はproxy.example.comとproxy.example.netとproxy.example.netとbob@example.netの間に与えられています。結果として、alice@example.comは推移互いに（example.comおよびexample.netに対する権限プロキシの信頼を想定）bob@example.netに認証されます。
Digest authentication in SIP provides for authentication of the message sender to the challenging UAS. As commonly deployed, digest authentication provides only very limited integrity protection of the authenticated message, and has no provision for binding the authentication to any attribute of the transport. Many existing SIP deployments have chosen to use the Digest authentication of one or more messages on a particular transport connection as a way to authenticate the connection itself -- by implication, authenticating other (unauthenticated) messages on that connection. Some even choose to similarly authenticate a UDP source address and port based on the digest authentication of another message received from that address and port. This use of digest goes beyond the assurances that the Digest Authentication mechanism was designed to provide. A SIP implementation SHOULD NOT use the Digest Authentication of one message on a TCP connection or from a UDP peer to infer any authentication of any other messages on that connection or from that peer. Authentication of the domain at the other end of a connection SHOULD be accomplished using TLS and the certificate validation rules described by this specification instead.
SIPにおけるダイジェスト認証は、挑戦的なUASへのメッセージ送信者の認証を提供します。一般的に展開されたように、認証は、認証されたメッセージの非常に限られた完全性保護を提供し、交通機関のいずれかの属性に認証を結合するための規定を持っていないダイジェスト。暗示によって、その接続で他の（認証されていない）のメッセージを認証する - 多くの既存のSIP展開は、接続自体を認証するための方法として、特定のトランスポート接続上の1つまたは複数のメッセージのダイジェスト認証を使用することを選択しました。一部では、同様に、そのアドレスとポートから受信した別のメッセージのダイジェスト認証に基づいてUDPの送信元アドレスとポートを認証することを選択します。ダイジェストの使用はダイジェスト認証機構を提供するように設計された保証を超えました。 SIP実装は、その接続上またはそのピアから他のメッセージのいずれかの認証を推測するためにTCP接続またはUDPピアからの1つのメッセージのダイジェスト認証を使用しないでください。接続の他端のドメインの認証は、TLS、代わりに、本明細書によって記載された証明書の検証ルールを使用して達成されるべきです。
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, and Russ Housley. Special acknowledgement goes to Stephen Kent for extensively reviewing document versions and suggesting invaluable feedback, edits, and comments.
イェルーンバンBemmel、マイケル・ハマー、カレン・ジェニングス、ポールKyzivat、デレク・マクドナルド、デイブ・オラン、ジョンピーターソン、エリックレスコラ、ジョナサン・ローゼンバーグ、およびラスHousley：以下のIETFの貢献者は、この文書に実質的な入力を提供します。特別な承認は、広範囲にドキュメントのバージョンを見直し、貴重なフィードバック、編集、コメントを示唆するためにスティーブン・ケントに行きます。
Paul Hoffman, Eric Rescorla, and Robert Sparks provided many valuable WGLC comments.
ポール・ホフマン、エリックレスコラ、およびロバート・スパークスは、多くの貴重なWGLCのコメントを提供しました。
[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] Eastlake, D., "Domain Name System (DNS) Case Insensitivity Clarification", RFC 4343, January 2006.
[3]イーストレイク、D.、 "ドメインネームシステム（DNS）大文字小文字の明確化"、RFC 4343、2006年1月。
[4] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., and T. Wright, "Transport Layer Security (TLS) Extensions", RFC 4366, April 2006.
[4]ブレイク・ウィルソン、S.、Nystrom、M.、ホップウッド、D.、ミケルセン、J.、およびT.ライト、 "トランスポート層セキュリティ（TLS）拡張機能"、RFC 4366、2006年4月。
[5] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[5]ダークス、T.およびE.レスコラ、 "トランスポート層セキュリティ（TLS）プロトコルバージョン1.2"、RFC 5246、2008年8月。
[6] 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.
[6]クーパー、D.、Santesson、S.、ファレル、S.、Boeyen、S.、Housley氏、R.、およびW.ポーク、「インターネットX.509公開鍵暗号基盤証明書と証明書失効リスト（CRL）のプロフィール」、RFC 5280、2008年5月。
[7] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[7]レスコラ、E.、 "HTTPオーバーTLS"、RFC 2818、2000年5月。
[8] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol (SIP): Locating SIP Servers", RFC 3263, June 2002.
[8]ローゼンバーグ、J.、およびH. Schulzrinneと、 "セッション開始プロトコル（SIP）：SIPサーバの検索"、RFC 3263、2002年6月。
[9] Peterson, J. and C. Jennings, "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)", RFC 4474, August 2006.
[9]ピーターソン、J.とC.ジェニングスを、RFC 4474 "セッション開始プロトコル（SIP）で認証されたアイデンティティ管理のための機能強化"、2006年8月。
[10] Mahy, R., Gurbani, V., and B. Tate, "Connection Reuse in the Session Initiation Protocol", RFC 5923, June 2010.
[10]マーイ、R.、Gurbani、V.、およびB.テート、 "セッション開始プロトコルにおける接続の再利用"、RFC 5923、2010年6月。
[11] Drage, K., "A Process for Handling Essential Corrections to the Session Initiation Protocol (SIP)", Work in Progress, July 2008.
[11]糖剤、K.、進歩、2008年7月に仕事「セッション開始プロトコル（SIP）に必須の訂正を処理するプロセス」。
[12] Lawrence, S. and V. Gurbani, "Using Extended Key Usage (EKU) for Session Initiation Protocol (SIP) X.509 Certificates", RFC 5924, June 2010.
[12]ローレンス、S.及びV. Gurbani、RFC 5924、2010年6月 "セッション開始プロトコル（SIP）X.509証明書の拡張キー使用法（EKU）の使用"。
Appendix A. Editorial Guidance (Non-Normative)
付録A.編集ガイダンス（規範性なし）
This document is intended to update RFC 3261 in accordance with the SIP Working Group procedures described in [11] or its successor.
この文書は、SIPワーキンググループ[11]に記載の手順またはその後継に従ってRFC 3261を更新することを意図しています。
This appendix provides guidance to the editor of the next comprehensive update to RFC 3261 [2] on how to incorporate the changes provided by this document.
この付録では、[2]この文書で提供変更を組み込む方法については、RFC 3261の次の包括的な更新のエディタにガイダンスを提供しています。
A.1. Additions
A.1。追加
The content of Sections 4 through 7 inclusive can be incorporated as subsections within a section that describes SIP domain authentication.
包括7を介してセクション4の内容は、SIPドメイン認証を記述するセクション内のサブセクションとして組み込むことができます。
The contents of Section 8.1 can be incorporated into the Security Considerations section of the new document.
8.1節の内容は、新しいドキュメントのSecurity Considerations部に組み込むことができます。
All normative references from this document can be carried forward to its successor.
このドキュメントからすべての引用規格は、その後継者に繰り越すことができます。
A.2. Changes
A.2。変更
The following subsections describe changes in specific sections of RFC 3261 [2] that need to be modified in the successor document to align them with the content of this document. In each of the following, the token <domain-authentication> is a reference to the section added as described in Appendix A.1.
以下のサブセクションでは、この文書の内容とそれらを整列させるために後継文書に変更する必要があり[2] RFC 3261の特定のセクションの変化を記述する。付録A.1に記載されているように、以下のそれぞれにおいて、トークン<ドメイン認証>セクションへの参照が追加されます。
A.2.1. Changes to
A.2.1。への変更
The current text says:
現在のテキストは言います：
Proxy servers, redirect servers and registrars SHOULD possess a site certificate whose subject corresponds to their canonical hostname.
プロキシサーバは、サーバをリダイレクトし、レジストラがその対象と自分の正規のホスト名に対応して、サイトの証明書を有していなければなりません。
The suggested replacement for the above is:
上記の推奨交換は次のとおりです。
Proxy servers, redirect servers, registrars, and any other server that is authoritative for some SIP purpose in a given domain SHOULD possess a certificate whose subjects include the name of that SIP domain.
プロキシサーバー、サーバーにリダイレクトし、登録機関、および特定のドメイン内のいくつかのSIPの目的のために権威のある他のサーバは、その被験者そのSIPドメインの名前が含まれた証明書を有していなければなりません。
Authors' Addresses
著者のアドレス
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@alcatel-lucent.com
電話：+1 630 224-0216 Eメール：vkg@alcatel-lucent.com
Scott Lawrence
スコット・ローレンス
EMail: scott-ietf@skrb.org
メールアドレス：scott-ietf@skrb.org
Alan S.A. Jeffrey Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane Room 9C-533 Naperville, IL 60566 USA
アランS.A.社ジェフリー・ベル研究所、アルカテル・ルーセント1960ルーセントレーンルーム9C-533ネーパーヴィル、IL 60566 USA
EMail: ajeffrey@alcatel-lucent.com
メールアドレス：ajeffrey@alcatel-lucent.com