[要約] RFC 5922は、SIPにおけるドメイン証明書に関する標準仕様です。このRFCの目的は、SIPセッションのセキュリティを向上させ、ドメインの信頼性を確保することです。
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)
セッション開始プロトコル（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を使用してX.509を使用して公開キーインフラストラクチャ）証明書で特定の情報を構築および解釈する方法について説明します。より具体的には、このドキュメントでは、証明書に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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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.
Copyright（c）2010 IETF Trustおよび文書著者として特定された人。全著作権所有。
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 Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション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]実装で増加しています。TLSの認証機能を使用するには、インターネットX.509公開キーインフラストラクチャで定義されている証明書を使用するには、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準拠の証明書に関連しています。このドキュメントでは、そのような証明書の使用は、他の目的（Secure/Multipurpose Internet Mail Extensions（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].
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、RFC 2119 [1]に記載されているように解釈される。
Additional definition(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ドメインID：ID.509証明書に含まれるID（例：「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は、RFC 5280 [6] X.509公開キーインフラストラクチャを使用して、X.509証明書の主題にIDまたはIDのセットを結合します。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証明書は、通常、エンドツーエンド認証と暗号化に使用されます。したがって、それらはユーザーの身元を証明書に結合するのに役立ち、RFC 3261はS/MIMEに使用される証明書では、subjectaltnameフィールドに適切なアイデンティティが含まれることを十分に明確にします。一方、TLSに使用されるX.509証明書は、SIPメッセージを送信または受信するPERホップドメインのIDをバインドするのに役立ちます。ただし、X.509証明書の曖昧さを作成したX.509の証明書の識別フィールドまたは共通名（CN）としてのIDを正確に配置する場所に関するRFC 3261のガイドラインの欠如。当時の受け入れられたプラクティスに続いて、Legacy X.509証明書は、現在指定されているSubjectAltName拡張機能の代わりに、証明書のCNフィールドに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を含めることができます（証明書の「主題」は、公開キーフィールドに保存されている公開鍵に関連するエンティティを識別します）。そのため、このドキュメントは、さまざまなサブジェクト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.
このドキュメントの残りの部分は次のように整理されています。次のセクションでは、DNSを使用してSIPサーバーと結果の認証手順にアクセスするクライアントの最も原始的なケースの概要を示します。セクション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.
SIPのルーティングは、クライアントに「アプリケーションユニークな文字列（AUS）」と呼ばれるURIでRFC 3263 [8]手順を実行することにより実行されます（C.F. RFC 3263 [8]）。これらの手順は、SIP AUS（SIP URI）を入力し、そのURIのドメイン部分をルックアップキーとして使用するために抽出し、ドメイン名サービス（DNS）をクエリして、1つ以上のIPアドレスの順序付けられたセットを取得します。セット内の各IPアドレスに対応するポート番号とトランスポート（「予想される出力」）。トランスポートがTLSの使用を示している場合、特定のIPアドレスとポートでサーバーにTLS接続が開かれます。サーバーは、最初の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.
クライアントは、被験者から識別子を抽出し、証明書の任意のsubjectName拡張機能（セクション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アドレス「sips：alice@example.com」にルーティングされるリクエストを検討してください。このアドレスには、SIPドメイン「Example.com」への安全な接続が必要です（「SIP」スキームは安全な接続を義務付けます）。一連のDNS操作により、ドメイン名はホストアドレスとトランスポートのセットにマッピングされます。接続を作成しようとするエンティティは、このセットからTLSで使用するのに適したアドレスを選択します。接続がそのサーバーに確立されると、サーバーはアイデンティティ「SIP：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).
セッション開始プロトコルセキュア（SIP）は、HTTPSから一致するサーバー証明書のこのパターンを借用します。ただし、RFC 2818 [7]は、被験者フィールドのCNフィールドでアイデンティティを伝える一般的な慣行ではなく、タイプDNSNAMEの主題拡張としてIDを伝えることを好みます。同様に、このドキュメントでは、SIPドメインのIDを、統一されたタイプの統一ルシデントファイアのsumbutaltname拡張として伝達することを推奨しています（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を招待します。Aliceのアウトバウンドプロキシ、Proxy-A.example.comは、通常のRFC 3263 [8]解像度ルールを使用して、TLSを使用するExample.Netドメインでプロキシ-Proxy-B.example.netを見つけます。Proxy-A Proxy-Bとのドメイン間の接続を積極的に確立し、それぞれがその接続を認証するために証明書を提示します。
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は、証明書の件名または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の認証問題は簡単です：証明書でproxy-aがproxy-bから受信する、proxy-aはsip uri（ "sip：example.net"）またはdns name（ "exampleのアイデンティティを探します。.net "）それは、example.netドメインに対するプロキシ-Bの権限を主張します。プロキシ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.
Proxy-Bの問題は、受動的にTLS要求を受け入れるため、わずかに複雑です。したがって、Proxy-Bには、Proxy-Aの証明書の一致するアイデンティティのアンカーとして使用できる同等の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は、Proxy-Bに「証明書によって主張されたドメインを、招待リクエストのHeaderフィールドの「ドメイン」部分と比較する」と指示するだけです。その命令の難しさは、From Headerフィールドのドメイン名は、要求が受信されたドメインのドメインではないことです。
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接続を受動的に受け入れ、送信ピアドメインの認証を必要とするProxy-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使用のために既存の証明書を使用して、被験者フィールドでのみ伝達されるIDを使用し続けることができますが、subjectaltname拡張フィールドでアイデンティティを伝えるという次の利点を慎重に考慮する必要があります。
o The subjectAltName extension can hold multiple values, so the same certificate can identify multiple servers or sip domains.
o subjectaltname拡張機能は複数の値を保持できるため、同じ証明書が複数のサーバーまたはSIPドメインを識別できます。
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拡張フィールドにIDまたはIDを含む証明書を取得することを強く奨励されています。
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ドメインが、件名フィールドのIDとして、または既存の証明書と互換性があるため、証明書の主題フィールドと互換性があることを確認する必要があります。実際には、これは、サービスプロバイダーがユーザーに分配され、ドメイン部分がサービスプロバイダーに証明書を発行されたIDに対応するURIをSIPすることを意味します。
This section normatively specifies the behavior of SIP entities when using X.509 certificates to determine an authenticated SIP domain identity.
このセクションは、X.509証明書を使用して認証されたSIPドメインIDを決定する場合の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.
RFC 5280 [6]、セクション4.2.1.12で指定されているように、実装は、証明書の拡張KeyUsage拡張機能によって宣言された証明書の使用に関する制限を確認する必要があります。SIP Extended Key使用量（EKU）ドキュメント[12]は、SIPの拡張KeyUsageを定義します。
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またはIDを決定する方法について説明します。単一の証明書には複数の目的を提供できます。つまり、証明書には、SIPとして受け入れられないアイデンティティ、ドメインのアイデンティティ、および/またはSIPドメインのアイデンティティとして使用できる1つ以上のIDが含まれる場合があります。
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フィールドの各値を調べます。対象のフィールドとその値の制約は、RFC 5280 [6]のセクション4.2.1.6で定義されています。subjectaltnameフィールドはなく、1つ以上の値を含めることができます。sumbercaltnameの各値にはタイプがあります。SIPドメインアイデンティティをエンコードするために許容できる唯一のタイプは次のとおりです。
URI If the scheme of the URI is not "sip", then the implementation MUST NOT accept the value as a SIP domain identity.
URI URIのスキームが「SIP」ではない場合、実装はSIPドメインIDとして値を受け入れてはなりません。
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).
URI値のスキームが「SIP」であり、ユーザーパートを含むURI値（ '@'があります）の場合、実装はSIPドメインIDとして値を受け入れてはなりません（ユーザーパートの値は個人を識別しますユーザー、ドメインではありません）。
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にuserInfoコンポーネントがない場合（ '@'はありません）、実装はSIPドメインアイデンティティとして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」URIタイプと一致する他のIDが見つからない場合にのみ、SIPドメインIDとしてドメイン名システム識別子を受け入れる必要があります。
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名を受け入れると、後方互換性が許可されますが、新しい証明書を構築する場合は、subjectaltname拡張フィールドを使用することの利点を考慮してください（セクション6を参照）。
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.3を参照）、サーバーはそれらを使用してクライアントを認証します（セクション7.4を参照）。
When an implementation (either client or server) compares two values as SIP domain identities:
実装（クライアントまたはサーバーのいずれか）が2つの値をSIPドメインのアイデンティティとして比較する場合：
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].
実装は、値をDNS名として比較する必要があります。つまり、RFC 4343 [3]で指定されているように、比較は症例ではありません。実装は、RFC 5280 [6]のセクション7.2に従って、国際化ドメイン名（IDN）を処理する必要があります。
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を超える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).
クライアントは、SIP AUSのドメイン部分を使用してA（おそらく信頼されていない）DNSを照会して結果セットを取得します。これは1つ以上のSRVであり、ドメインのサーバーを識別するレコードです（概要についてはセクション4を参照）。
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.
SIPサーバーは、TLS接続を確立するときに、認証のために証明書をクライアントに提示します。クライアントは、セクション7.1の手順を使用して、サーバー証明書のSIPドメインIDを決定する必要があります。次に、クライアントは、RFC 3263 [8]サーバーの位置手順への入力として使用されたSIP AUSの元のドメイン部分を、証明書から取得したSIPドメインアイデンティティと比較する必要があります。
o If there were no identities found in the server certificate, the server is not authenticated.
o サーバー証明書にIDが見つからなかった場合、サーバーは認証されていません。
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.
o AUSから抽出されたドメインが、セクション7.2で説明されているように、証明書から取得したSIPドメインIDと一致する場合、サーバーはドメインに対して認証されます。
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.
ローカルサーバーポリシーがローカルの目的でクライアント認証を必要とする場合、そのようなローカルポリシーの1つの要素は、クライアントが認証されている場合にのみ接続を許可することです。たとえば、サーバーが他の特定のドメインのアウトバウンドプロキシとのピアーリング関係を持つインバウンドプロキシである場合、サーバーはそれらのドメインから来ると認証された接続のみを許可する場合があります。
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ドメインのアイデンティティのセットを使用して、許可決定を下すことができます。
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証明書を受け入れ、RFC 5280 [6]の手順を使用して証明書を検証することです。証明書が有効な場合、IDセットが記録されます。
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ドメインのリストを持つことができます。クライアントが証明書を提示すると、クライアント証明書の各アイデンティティについて、サーバーは、接続を受け入れるかどうかを決定するために、許容可能なドメインのリストのIDを検索します。より細かい区別を作成する他のポリシーが可能です。
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.
クライアントへの認証された接続がクライアントドメインに新しい要求をルーティングするために使用するのに適しているかどうかの決定は、接続が認証されているかどうかに依存しません。Connect-Reuse [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.
ルートが安全な接続を使用することを期待してリクエストを転送する際にプロキシがレコードルートを追加する場合、プロキシは、プロキシに証明書を持っているアイデンティティに対応する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.
複数のドメインが単一のアプリケーションによって管理される「仮想ホスティング」の場合、証明書には、RFC 4474で指定されているように、subjectaltnameフィールドに明確なアイデンティティを持つことにより、複数の被験者を含めることができます[9]。このような仮想ホストでサーバーを認証しようとするクライアントは、セクション7.3の指示に従って、DNSを照会するために使用されるSIP AUSに一致するアイデンティティを見つけることができます。
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.
または、RFC 4366 [4]で定義されているTLSクライアントのHello "Server_Name"拡張機能がサポートされている場合、クライアントはその拡張機能を使用して、クライアントが求めている特定のドメイン（SIP AUSから）に対応する証明書を要求する必要があります。接続を確立します。
The goals of TLS (when used with X.509 certificates) include the following security guarantees at the transport layer:
TLSの目標（X.509証明書で使用する場合）には、輸送層で次のセキュリティ保証が含まれます。
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からメッセージをsipすることは、alice@example.com、bob@example.net、およびdomain証明書で発行されたSIPプロキシでのみ読み取ることができます。
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にメッセージをSIPSすることは、alice@example.com、bob@example.net、およびdomain証明書で発行されたsipプロキシの間のリンクで、例えば、domain証明書で発行されることはありません。ネット。
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は、domain example.comの権威あるプロキシとしてalice@example.comに認証されています。proxy.example.comとproxy.example.net、およびproxy.example.netとbob@example.netの間に同様の相互認証保証が与えられます。その結果、alice@example.comは、bob@example.netに相互に相互に認証されています（emply.comおよび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へのメッセージ送信者の認証を提供します。一般的に展開されているように、Digest Authenticationは、認証されたメッセージの非常に限られた整合性保護のみを提供し、輸送の属性に認証を拘束するための規定はありません。多くの既存の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.
次のIETF貢献者は、この文書への実質的な情報を提供しました：Jeroen Van Bemmel、Michael Hammer、Cullen Jennings、Paul Kyzivat、Derek Macdonald、Dave Oran、Jon Peterson、Eric Rescorla、Jonathan Rosenberg、Russ Housley。ドキュメントバージョンを広範囲にレビューし、貴重なフィードバック、編集、コメントを提案するために、Stephen Kentに特別な謝辞が行われます。
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] 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：SESSION INITIATION Protocol」、RFC 3261、2002年6月。
[3] Eastlake, D., "Domain Name System (DNS) Case Insensitivity Clarification", RFC 4343, January 2006.
[3] Eastlake、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] Blake-Wilson、S.、Nystrom、M.、Hopwood、D.、Mikkelsen、J。、およびT. Wright、「Transport Layer Security（TLS）Extensions」、RFC 4366、2006年4月。
[5] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[5] Dierks、T。およびE. Rescorla、「The Transport Layer Security（TLS）Protocolバージョン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] Cooper、D.、Santesson、S.、Farrell、S.、Boeyen、S.、Housley、R。、およびW. Polk、「インターネットX.509公開キーインフラストラクチャ証明書および証明書取消リスト（CRL）プロファイル」、RFC5280、2008年5月。
[7] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[7] Rescorla、E。、「TLS上のHTTP」、RFC 2818、2000年5月。
[8] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol (SIP): Locating SIP Servers", RFC 3263, June 2002.
[8] Rosenberg、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] Peterson、J。and C. Jennings、「セッション開始プロトコル（SIP）における認証されたアイデンティティ管理の強化」、RFC 4474、2006年8月。
[10] Mahy, R., Gurbani, V., and B. Tate, "Connection Reuse in the Session Initiation Protocol", RFC 5923, June 2010.
[10] Mahy、R.、Gurbani、V。、およびB. Tate、「セッション開始プロトコルでの接続の再利用」、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] Drage、K。、「セッション開始プロトコル（SIP）の本質的な修正を処理するプロセス」、2008年7月、進行中の作業。
[12] Lawrence, S. and V. Gurbani, "Using Extended Key Usage (EKU) for Session Initiation Protocol (SIP) X.509 Certificates", RFC 5924, June 2010.
[12] Lawrence、S。and V. Gurbani、「セッション開始プロトコル（SIP）X.509証明書に拡張キー使用量（EKU）を使用」、RFC 5924、2010年6月。
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.
このドキュメントは、[11]またはその後継者に記載されているSIPワーキンググループの手順に従って、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.
この付録は、このドキュメントによって提供された変更を組み込む方法について、RFC 3261 [2]の次の包括的なアップデートの編集者にガイダンスを提供します。
The content of Sections 4 through 7 inclusive can be incorporated as subsections within a section that describes SIP domain authentication.
セクション4〜7のコンテンツは、SIPドメイン認証を説明するセクション内にサブセクションとして組み込むことができます。
The contents of Section 8.1 can be incorporated into the Security Considerations section of the new document.
セクション8.1の内容は、新しいドキュメントのセキュリティに関する考慮事項セクションに組み込むことができます。
All normative references from this document can be carried forward to its successor.
このドキュメントからのすべての規範的参照は、その後継者に繰り越すことができます。
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.
以下のサブセクションでは、RFC 3261 [2]の特定のセクションの変更について説明します。これは、後継者文書で変更して、このドキュメントの内容に合わせて変更する必要があります。以下のそれぞれにおいて、Token <Domain-Authentication>は、付録A.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
Vijay K. Gurbani Bell Laboratories、Alcatel-Lucent 1960 Lucent Lane Room 9C-533 Naperville、IL 60566 USA
Phone: +1 630 224-0216
EMail: vkg@alcatel-lucent.com
Scott Lawrence
スコット・ローレンス
EMail: scott-ietf@skrb.org
Alan S.A. Jeffrey Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane Room 9C-533 Naperville, IL 60566 USA
Alan S.A. Jeffrey Bell Laboratories、Alcatel-Lucent 1960 Lucent Lane Room 9C-533 Naperville、IL 60566 USA
EMail: ajeffrey@alcatel-lucent.com