[要約] RFC 6125は、TLS環境下でX.509証明書を用いてドメインベースのアプリケーションサービスを認証するための、識別子の表現と検証手順を規定しています。従来のCommon Name（CN）に代わり、subjectAltName（dNSNameやSRVNameなど）を用いた一貫性のある検証方法を推奨しています。ウェブやメール等の様々なサービスにおいて、中間者攻撃を防ぎ安全な通信を確立するための標準的な指針を提供します。
Internet Engineering Task Force (IETF) P. Saint-Andre
Request for Comments: 6125 Cisco
Category: Standards Track J. Hodges
ISSN: 2070-1721 PayPal
March 2011
Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)
トランスポート層セキュリティ（TLS）の文脈における、X.509（PKIX）証明書を用いたインターネット公開鍵基盤内でのドメインベースのアプリケーションサービス識別子の表現と検証
Abstract
概要
Many application technologies enable secure communication between two entities by means of Internet Public Key Infrastructure Using X.509 (PKIX) certificates in the context of Transport Layer Security (TLS). This document specifies procedures for representing and verifying the identity of application services in such interactions.
多くのアプリケーションテクノロジーは、輸送層セキュリティ（TLS）のコンテキストでX.509（PKIX）証明書を使用したインターネット公開キーインフラストラクチャを使用して、2つのエンティティ間の安全な通信を可能にします。このドキュメントは、そのような相互作用におけるアプリケーションサービスのIDを表現および検証するための手順を指定します。
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/rfc6125.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http://www.rfc-editor.org/info/rfc6125で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2011 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 1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Audience . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.3. How to Read This Document . . . . . . . . . . . . . . . . 4 1.4. Applicability . . . . . . . . . . . . . . . . . . . . . . 5 1.5. Overview of Recommendations . . . . . . . . . . . . . . . 5 1.6. Generalization from Current Technologies . . . . . . . . . 6 1.7. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 7 1.7.1. In Scope . . . . . . . . . . . . . . . . . . . . . . . 7 1.7.2. Out of Scope . . . . . . . . . . . . . . . . . . . . . 7 1.8. Terminology . . . . . . . . . . . . . . . . . . . . . . . 9 2. Naming of Application Services . . . . . . . . . . . . . . . . 13 2.1. Naming Application Services . . . . . . . . . . . . . . . 13 2.2. DNS Domain Names . . . . . . . . . . . . . . . . . . . . . 14 2.3. Subject Naming in PKIX Certificates . . . . . . . . . . . 15 2.3.1. Implementation Notes . . . . . . . . . . . . . . . . . 17 3. Designing Application Protocols . . . . . . . . . . . . . . . 18 4. Representing Server Identity . . . . . . . . . . . . . . . . . 18 4.1. Rules . . . . . . . . . . . . . . . . . . . . . . . . . . 18 4.2. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 20 5. Requesting Server Certificates . . . . . . . . . . . . . . . . 21 6. Verifying Service Identity . . . . . . . . . . . . . . . . . . 21 6.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 21 6.2. Constructing a List of Reference Identifiers . . . . . . . 22 6.2.1. Rules . . . . . . . . . . . . . . . . . . . . . . . . 22 6.2.2. Examples . . . . . . . . . . . . . . . . . . . . . . . 24 6.3. Preparing to Seek a Match . . . . . . . . . . . . . . . . 25 6.4. Matching the DNS Domain Name Portion . . . . . . . . . . . 26 6.4.1. Checking of Traditional Domain Names . . . . . . . . . 27 6.4.2. Checking of Internationalized Domain Names . . . . . . 27 6.4.3. Checking of Wildcard Certificates . . . . . . . . . . 27 6.4.4. Checking of Common Names . . . . . . . . . . . . . . . 28 6.5. Matching the Application Service Type Portion . . . . . . 28 6.5.1. SRV-ID . . . . . . . . . . . . . . . . . . . . . . . . 29 6.5.2. URI-ID . . . . . . . . . . . . . . . . . . . . . . . . 29 6.6. Outcome . . . . . . . . . . . . . . . . . . . . . . . . . 29 6.6.1. Case #1: Match Found . . . . . . . . . . . . . . . . . 29 6.6.2. Case #2: No Match Found, Pinned Certificate . . . . . 29 6.6.3. Case #3: No Match Found, No Pinned Certificate . . . . 30 6.6.4. Fallback . . . . . . . . . . . . . . . . . . . . . . . 30 7. Security Considerations . . . . . . . . . . . . . . . . . . . 30 7.1. Pinned Certificates . . . . . . . . . . . . . . . . . . . 30 7.2. Wildcard Certificates . . . . . . . . . . . . . . . . . . 31 7.3. Internationalized Domain Names . . . . . . . . . . . . . . 32 7.4. Multiple Identifiers . . . . . . . . . . . . . . . . . . . 32 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 33 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 33 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34 10.1. Normative References . . . . . . . . . . . . . . . . . . . 34 10.2. Informative References . . . . . . . . . . . . . . . . . . 34 Appendix A. Sample Text . . . . . . . . . . . . . . . . . . . . . 40 Appendix B. Prior Art . . . . . . . . . . . . . . . . . . . . . . 42 B.1. IMAP, POP3, and ACAP (1999) . . . . . . . . . . . . . . . 42 B.2. HTTP (2000) . . . . . . . . . . . . . . . . . . . . . . . 43 B.3. LDAP (2000/2006) . . . . . . . . . . . . . . . . . . . . . 44 B.4. SMTP (2002/2007) . . . . . . . . . . . . . . . . . . . . . 47 B.5. XMPP (2004) . . . . . . . . . . . . . . . . . . . . . . . 49 B.6. NNTP (2006) . . . . . . . . . . . . . . . . . . . . . . . 50 B.7. NETCONF (2006/2009) . . . . . . . . . . . . . . . . . . . 51 B.8. Syslog (2009) . . . . . . . . . . . . . . . . . . . . . . 52 B.9. SIP (2010) . . . . . . . . . . . . . . . . . . . . . . . . 54 B.10. SNMP (2010) . . . . . . . . . . . . . . . . . . . . . . . 55 B.11. GIST (2010) . . . . . . . . . . . . . . . . . . . . . . . 55
The visible face of the Internet largely consists of services that employ a client-server architecture in which an interactive or automated client communicates with an application service in order to retrieve or upload information, communicate with other entities, or access a broader network of services. When a client communicates with an application service using Transport Layer Security [TLS] or Datagram Transport Layer Security [DTLS], it references some notion of the server's identity (e.g., "the website at example.com") while attempting to establish secure communication. Likewise, during TLS negotiation, the server presents its notion of the service's identity in the form of a public-key certificate that was issued by a certification authority (CA) in the context of the Internet Public Key Infrastructure using X.509 [PKIX]. Informally, we can think of these identities as the client's "reference identity" and the server's "presented identity" (these rough ideas are defined more precisely later in this document through the concept of particular identifiers). In general, a client needs to verify that the server's presented identity matches its reference identity so it can authenticate the communication.
インターネットの目に見える顔は、主に、インタラクティブまたは自動化されたクライアントがアプリケーションサービスと通信して、情報を取得またはアップロードしたり、他のエンティティと通信したり、より広範なサービスネットワークにアクセスしたりするためにアプリケーションサービスと通信するサービスで構成されています。クライアントがトランスポートレイヤーセキュリティ[TLS]またはデータグラムトランスポートレイヤーセキュリティ[DTLS]を使用してアプリケーションサービスと通信すると、安全な通信を確立しようとする間、サーバーのID（例：「WebサイトのExample.com」）の概念を参照します。。同様に、TLS交渉中に、サーバーは、X.509 [PKIX]を使用してインターネット公開キーインフラストラクチャのコンテキストで認証機関（CA）によって発行された公開鍵証明書の形でサービスのIDの概念を提示します[PKIX]。非公式には、これらのアイデンティティをクライアントの「参照アイデンティティ」およびサーバーの「提示されたアイデンティティ」と考えることができます（これらの大まかなアイデアは、特定の識別子の概念を通じてこのドキュメントのより正確に定義されています）。一般に、クライアントは、サーバーが提示されたアイデンティティが参照IDと一致していることを確認する必要があります。これにより、通信を認証できるようにします。
Many application technologies adhere to the pattern just outlined. Such protocols have traditionally specified their own rules for representing and verifying application service identity. Unfortunately, this divergence of approaches has caused some confusion among certification authorities, application developers, and protocol designers.
多くのアプリケーションテクノロジーは、概説されているパターンに準拠しています。このようなプロトコルは、従来、アプリケーションサービスIDを表現および検証するための独自のルールを指定してきました。残念ながら、このアプローチの相違は、認証当局、アプリケーション開発者、およびプロトコル設計者の間である程度の混乱を引き起こしています。
Therefore, to codify secure procedures for the implementation and deployment of PKIX-based authentication, this document specifies recommended procedures for representing and verifying application service identity in certificates intended for use in application protocols employing TLS.
したがって、PKIXベースの認証の実装と展開のための安全な手順を成文化するために、このドキュメントは、TLSを使用するアプリケーションプロトコルで使用することを目的とした証明書でアプリケーションサービスIDを表現および検証するための推奨手順を指定します。
The primary audience for this document consists of application protocol designers, who can reference this document instead of defining their own rules for the representation and verification of application service identity. Secondarily, the audience consists of certification authorities, service providers, and client developers from technology communities that might reuse the recommendations in this document when defining certificate issuance policies, generating certificate signing requests, or writing software algorithms for identity matching.
このドキュメントの主要なオーディエンスは、アプリケーションサービスIDの表現と検証に関する独自のルールを定義する代わりに、このドキュメントを参照できるアプリケーションプロトコル設計者で構成されています。第二に、視聴者は、証明書の発行ポリシーを定義し、証明書の署名要求を生成する、または身元マッチングのソフトウェアアルゴリズムを作成する際に、このドキュメントの推奨事項を再利用する可能性のあるテクノロジーコミュニティの認定当局、サービスプロバイダー、およびクライアント開発者で構成されています。
This document is longer than the authors would have liked because it was necessary to carefully define terminology, explain the underlying concepts, define the scope, and specify recommended behavior for both certification authorities and application software implementations. The following sections are of special interest to various audiences:
このドキュメントは、用語を慎重に定義し、根本的な概念を説明し、範囲を定義し、認証当局とアプリケーションソフトウェアの実装の両方に推奨される動作を指定する必要があるため、著者が望んでいたよりも長いです。次のセクションは、さまざまな視聴者にとって特別な関心事です。
o Protocol designers might want to first read the checklist in Section 3.
o プロトコル設計者は、最初にセクション3のチェックリストを読みたい場合があります。
o Certification authorities might want to first read the recommendations for representation of server identity in Section 4.
o 認証当局は、セクション4のサーバーIDの表現に関する推奨事項を最初に読みたい場合があります。
o Service providers might want to first read the recommendations for requesting of server certificates in Section 5.
o サービスプロバイダーは、セクション5でサーバー証明書を要求するための推奨事項を最初に読みたい場合があります。
o Software implementers might want to first read the recommendations for verification of server identity in Section 6.
o ソフトウェアの実装者は、セクション6のサーバーIDの検証に関する推奨事項を最初に読みたい場合があります。
The sections on terminology (Section 1.8), naming of application services (Section 2), document scope (Section 1.7), and the like provide useful background information regarding the recommendations and guidelines that are contained in the above-referenced sections, but are not absolutely necessary for a first reading of this document.
用語に関するセクション（セクション1.8）、アプリケーションサービスの命名（セクション2）、ドキュメントスコープ（セクション1.7）などは、上記のセクションに含まれるが、そうではない推奨事項とガイドラインに関する有用な背景情報を提供します。このドキュメントを最初に読むために絶対に必要です。
This document does not supersede the rules for certificate issuance or validation provided in [PKIX]. Therefore, [PKIX] is authoritative on any point that might also be discussed in this document. Furthermore, [PKIX] also governs any certificate-related topic on which this document is silent, including but not limited to certificate syntax, certificate extensions such as name constraints and extended key usage, and handling of certification paths.
このドキュメントは、[PKIX]で提供される証明書発行または検証の規則に取って代わるものではありません。したがって、[pkix]は、このドキュメントでも説明される可能性のあるあらゆるポイントで権威あるものです。さらに、[PKIX]は、証明書の構文、名前の制約や拡張キー使用量などの証明書拡張、および認証パスの処理など、このドキュメントがサイレントである証明書関連のトピックも規制しています。
This document addresses only name forms in the leaf "end entity" server certificate, not any name forms in the chain of certificates used to validate the server certificate. Therefore, in order to ensure proper authentication, application clients need to verify the entire certification path per [PKIX].
このドキュメントでは、Leaf "End Entity" Server証明書の名前のみを扱います。これは、サーバー証明書を検証するために使用される証明書のチェーンには名前フォームではありません。したがって、適切な認証を確保するために、アプリケーションクライアントは[PKIX]ごとに認証パス全体を検証する必要があります。
This document also does not supersede the rules for verifying service identity provided in specifications for existing application protocols published prior to this document, such as those excerpted under Appendix B. However, the procedures described here can be referenced by future specifications, including updates to specifications for existing application protocols if the relevant technology communities agree to do so.
また、このドキュメントは、付録Bに基づいて抜粋する手順など、このドキュメントの前に公開された既存のアプリケーションプロトコルの仕様で提供されるサービスIDを検証するためのルールに取って代わるものではありませんが、ここで説明する手順は、仕様の更新を含む将来の仕様で参照できます関連するテクノロジーコミュニティがそうすることに同意した場合、既存のアプリケーションプロトコルの場合。
To orient the reader, this section provides an informational overview of the recommendations contained in this document.
読者を方向付けるために、このセクションでは、このドキュメントに含まれる推奨事項の情報概要を説明します。
For the primary audience of application protocol designers, this document provides recommended procedures for the representation and verification of application service identity within PKIX certificates used in the context of TLS.
アプリケーションプロトコルデザイナーの主要な聴衆のために、このドキュメントは、TLSのコンテキストで使用されるPKIX証明書内のアプリケーションサービスIDの表現と検証に推奨される手順を提供します。
For the secondary audiences, in essence this document encourages certification authorities, application service providers, and application client developers to coalesce on the following practices:
中等視聴者の場合、本質的にこのドキュメントは、認定当局、アプリケーションサービスプロバイダー、およびアプリケーションクライアント開発者が次のプラクティスについて合体することを奨励しています。
o Move away from including and checking strings that look like domain names in the subject's Common Name.
o 被験者の共通名にドメイン名のように見える文字列を含めてチェックすることから離れます。
o Move toward including and checking DNS domain names via the subjectAlternativeName extension designed for that purpose: dNSName.
o その目的のために設計されたsubjectAlternativeName拡張機能を介して、DNSドメイン名を含めてチェックするように移行します：DNSNAME。
o Move toward including and checking even more specific subjectAlternativeName extensions where appropriate for using the protocol (e.g., uniformResourceIdentifier and the otherName form SRVName).
o プロトコルを使用するために必要に応じて、さらに具体的な科目Alternativename拡張機能を含めてチェックすることに向けて移動します（例：UnifortResourceIdentifierおよびotherNameフォームSRVNAME）。
o Move away from the issuance of so-called wildcard certificates (e.g., a certificate containing an identifier for "*.example.com").
o いわゆるワイルドカード証明書の発行から離れます（たとえば、「*.example.com」の識別子を含む証明書）。
These suggestions are not entirely consistent with all practices that are currently followed by certification authorities, client developers, and service providers. However, they reflect the best aspects of current practices and are expected to become more widely adopted in the coming years.
これらの提案は、現在認定当局、クライアント開発者、およびサービスプロバイダーが続いているすべての慣行と完全に一致していません。しかし、それらは現在の慣行の最良の側面を反映しており、今後数年間でより広く採用されることが期待されています。
This document attempts to generalize best practices from the many application technologies that currently use PKIX certificates with TLS. Such technologies include, but are not limited to:
このドキュメントは、現在TLSを使用してPKIX証明書を使用している多くのアプリケーションテクノロジーからベストプラクティスを一般化しようとします。このようなテクノロジーには、以下が含まれますが、これらに限定されません。
o The Internet Message Access Protocol [IMAP] and the Post Office Protocol [POP3]; see also [USINGTLS]
o インターネットメッセージアクセスプロトコル[IMAP]および郵便局プロトコル[POP3];[使用]も参照してください
o The Hypertext Transfer Protocol [HTTP]; see also [HTTP-TLS]
o ハイパーテキスト転送プロトコル[HTTP];[http-tls]も参照してください
o The Lightweight Directory Access Protocol [LDAP]; see also [LDAP-AUTH] and its predecessor [LDAP-TLS]
o 軽量ディレクトリアクセスプロトコル[LDAP];[LDAP-Auth]とその前身[LDAP-TLS]も参照してください
o The Simple Mail Transfer Protocol [SMTP]; see also [SMTP-AUTH] and [SMTP-TLS]
o 単純なメール転送プロトコル[SMTP];[smtp-auth]および[smtp-tls]も参照してください
o The Extensible Messaging and Presence Protocol [XMPP]; see also [XMPP-OLD]
o 拡張可能なメッセージングと存在プロトコル[XMPP];[XMPP-Old]も参照してください
o The Network News Transfer Protocol [NNTP]; see also [NNTP-TLS]
o ネットワークニュース転送プロトコル[NNTP];[NNTP-TLS]も参照してください
o The NETCONF Configuration Protocol [NETCONF]; see also [NETCONF-SSH] and [NETCONF-TLS]
o NetConf構成プロトコル[NetConf];[netconf-ssh]および[netconf-tls]も参照してください
o The Syslog Protocol [SYSLOG]; see also [SYSLOG-TLS] and [SYSLOG-DTLS]
o syslogプロトコル[syslog];[syslog-tls]および[syslog-dtls]も参照してください
o The Session Initiation Protocol [SIP]; see also [SIP-CERTS]
o セッション開始プロトコル[SIP];[sip-certs]も参照してください
o The Simple Network Management Protocol [SNMP]; see also [SNMP-TLS]
o シンプルなネットワーク管理プロトコル[SNMP];[SNMP-TLS]も参照してください
o The General Internet Signalling Transport [GIST] However, as noted, this document does not supersede the rules for verifying service identity provided in specifications for those application protocols.
o ただし、一般的なインターネットシグナリングトランスポート[GIST]は、前述のように、このドキュメントは、それらのアプリケーションプロトコルの仕様で提供されるサービスIDを検証するためのルールに取って代わるものではありません。
This document applies only to service identities associated with fully qualified DNS domain names, only to TLS and DTLS (or the older Secure Sockets Layer (SSL) technology), and only to PKIX-based systems. As a result, the scenarios described in the following section are out of scope for this specification (although they might be addressed by future specifications).
このドキュメントは、完全に適格なDNSドメイン名に関連付けられたサービスIDにのみ適用され、TLSおよびDTL（または古いSecure Socketsレイヤー（SSL）テクノロジー）にのみ、PKIXベースのシステムにのみ適用されます。その結果、次のセクションで説明されているシナリオは、この仕様の範囲外です（ただし、将来の仕様で対処される可能性があります）。
The following topics are out of scope for this specification:
次のトピックは、この仕様の範囲外です。
o Client or end-user identities.
o クライアントまたはエンドユーザーのアイデンティティ。
Certificates representing client or end-user identities (e.g., the rfc822Name identifier) can be used for mutual authentication between a client and server or between two clients, thus enabling stronger client-server security or end-to-end security. However, certification authorities, application developers, and service operators have less experience with client certificates than with server certificates, thus giving us fewer models from which to generalize and a less solid basis for defining best practices.
クライアントまたはエンドユーザーのIDを表す証明書（たとえば、rfc822Name識別子など）は、クライアントとサーバー間または2つのクライアント間の相互認証に使用でき、クライアントサーバーセキュリティまたはエンドツーエンドのセキュリティを強化できます。ただし、認定当局、アプリケーション開発者、およびサービスオペレーターは、サーバー証明書よりもクライアント証明書の経験が少ないため、一般化するモデルが少なくなり、ベストプラクティスを定義するための堅実な基礎が少なくなります。
o Identifiers other than fully qualified DNS domain names.
o 完全に適格なDNSドメイン名以外の識別子。
Some certification authorities issue server certificates based on IP addresses, but preliminary evidence indicates that such certificates are a very small percentage (less than 1%) of issued certificates. Furthermore, IP addresses are not necessarily reliable identifiers for application services because of the existence of private internets [PRIVATE], host mobility, multiple interfaces on a given host, Network Address Translators (NATs) resulting in different addresses for a host from different locations on the network, the practice of grouping many hosts together behind a single IP address, etc. Most fundamentally, most users find DNS domain names much easier to work with than IP addresses, which is why the domain name system was designed in the first place. We prefer to define best practices for the much more common use case and not to complicate the rules in this specification.
一部の認定当局は、IPアドレスに基づいてサーバー証明書を発行しますが、予備的な証拠は、そのような証明書が発行された証明書の非常に少ない割合（1％未満）であることを示しています。さらに、IPアドレスは、プライベートインターネット[プライベート]、ホストモビリティ、特定のホスト上の複数のインターフェイス、ネットワークアドレス翻訳者（NAT）の存在により、必ずしもアプリケーションサービスの信頼できる識別子ではありません。ほとんどのユーザーは、ほとんどのユーザーがDNSドメイン名をIPアドレスよりもはるかに操作しやすいと感じているため、多くのホストを単一のIPアドレスなどの後ろにグループ化するというネットワークがあります。そのため、ドメイン名システムがそもそも設計された理由です。私たちは、はるかに一般的なユースケースのベストプラクティスを定義し、この仕様のルールを複雑にしないことを好みます。
Furthermore, we focus here on application service identities, not specific resources located at such services. Therefore this document discusses Uniform Resource Identifiers [URI] only as a way to communicate a DNS domain name (via the URI "host" component or its equivalent), not as a way to communicate other aspects of a service such as a specific resource (via the URI "path" component) or parameters (via the URI "query" component).
さらに、このようなサービスにある特定のリソースではなく、アプリケーションサービスのIDに焦点を当てています。したがって、このドキュメントは、特定のリソースなどのサービスの他の側面を通信する方法としてではなく、DNSドメイン名（URI「ホスト」コンポーネントまたはその同等物を介して）を通信する方法としてのみ、均一なリソース識別子[URI]について説明します（URI]URIの「パス」コンポーネントを介して）またはパラメーター（URI「クエリ」コンポーネントを介して）。
We also do not discuss attributes unrelated to DNS domain names, such as those defined in [X.520] and other such specifications (e.g., organizational attributes, geographical attributes, company logos, and the like).
また、[x.520]やその他のそのような仕様（組織属性、地理的属性、会社のロゴなど）で定義されているものなど、DNSドメイン名とは無関係の属性についても説明しません。
o Security protocols other than [TLS], [DTLS], or the older Secure Sockets Layer (SSL) technology.
o [TLS]、[DTLS]、または古いセキュアソケット層（SSL）テクノロジー以外のセキュリティプロトコル。
Although other secure, lower-layer protocols exist and even employ PKIX certificates at times (e.g., IPsec [IPSEC]), their use cases can differ from those of TLS-based and DTLS-based application technologies. Furthermore, application technologies have less experience with IPsec than with TLS, thus making it more difficult to gather feedback on proposed best practices.
他の安全な、低層プロトコルは存在し、時々PKIX証明書を使用することさえありますが（例：IPSEC [IPSEC]）、それらのユースケースはTLSベースのアプリケーションテクノロジーとDTLSベースのアプリケーションテクノロジーとは異なります。さらに、アプリケーションテクノロジーは、TLSよりもIPSECの経験が少ないため、提案されたベストプラクティスに関するフィードバックを収集することがより困難になります。
o Keys or certificates employed outside the context of PKIX-based systems.
o PKIXベースのシステムのコンテキスト外で採用されているキーまたは証明書。
Some deployed application technologies use a web of trust model based on or similar to OpenPGP [OPENPGP], or use self-signed certificates, or are deployed on networks that are not directly connected to the public Internet and therefore cannot depend on Certificate Revocation Lists (CRLs) or the Online Certificate Status Protocol [OCSP] to check CA-issued certificates. However, the method for binding a public key to an identifier in OpenPGP differs essentially from the method in X.509, the data in self-signed certificates has not been certified by a third party in any way, and checking of CA-issued certificates via CRLs or OCSP is critically important to maintaining the security of PKIX-based systems. Attempting to define best practices for such technologies would unduly complicate the rules defined in this specification.
一部の展開されたアプリケーションテクノロジーは、OpenPGP [openPGP]に基づいてまたは同様のWeb of Trustモデルを使用するか、自己署名証明書を使用するか、パブリックインターネットに直接接続されていないため、証明書の取り消しリストに依存できないネットワークに展開されます（CRLS）またはCA発行証明書を確認するオンライン証明書ステータスプロトコル[OCSP]。ただし、公開鍵をOpenPGPの識別子に結合する方法は、X.509のメソッドと本質的に異なります。自己署名証明書のデータは、第三者によっていかなる方法でも認定されていません。CRLSまたはOCSPを介して、PKIXベースのシステムのセキュリティを維持するためには非常に重要です。このようなテクノロジーのベストプラクティスを定義しようとすると、この仕様で定義されているルールが不当に複雑になります。
o Certification authority policies, such as:
o 次のような認証当局のポリシー
* What types or "classes" of certificates to issue and whether to apply different policies for them (e.g., allow the wildcard character in certificates issued to individuals who have provided proof of identity but do not allow the wildcard character in "Extended Validation" certificates [EV-CERTS]).
* 発行する証明書の種類または「クラス」、およびそれらに異なるポリシーを適用するかどうか（たとえば、アイデンティティの証明を提供したが「拡張検証」証明書でワイルドカード文字を許可しない個人に発行された証明書のワイルドカード文字を許可します[ev-certs]）。
* Whether to issue certificates based on IP addresses (or some other form, such as relative domain names) in addition to fully qualified DNS domain names.
* 完全に適格なDNSドメイン名に加えて、IPアドレス（または相対ドメイン名などの他のフォーム）に基づいて証明書を発行するかどうか。
* Which identifiers to include (e.g., whether to include SRV-IDs or URI-IDs as defined in the body of this specification).
* これには、この仕様の本文で定義されているSRV-IDまたはURI-IDを含めるかどうかなど）を含む識別子。
* How to certify or validate fully qualified DNS domain names and application service types.
* 完全に適格なDNSドメイン名とアプリケーションサービスタイプを証明または検証する方法。
* How to certify or validate other kinds of information that might be included in a certificate (e.g., organization name).
* 証明書に含まれる可能性のある他の種類の情報を証明または検証する方法（組織名など）。
o Resolution of DNS domain names.
o DNSドメイン名の解像度。
Although the process whereby a client resolves the DNS domain name of an application service can involve several steps (e.g., this is true of resolutions that depend on DNS SRV resource records, Naming Authority Pointer (NAPTR) DNS resource records [NAPTR], and related technologies such as [S-NAPTR]), for our purposes we care only about the fact that the client needs to verify the identity of the entity with which it communicates as a result of the resolution process. Thus the resolution process itself is out of scope for this specification.
クライアントがアプリケーションサービスのDNSドメイン名を解決するプロセスにはいくつかのステップが含まれますが（これは、これはDNS SRVリソースレコード、命名機関ポインター（NAPTR）DNSリソースレコード[NAPTR]、および関連する解像度に当てはまります。[s-naptr]などのテクノロジー）、私たちの目的のために、私たちは、クライアントが解決プロセスの結果として通信するエンティティのアイデンティティを検証する必要があるという事実のみを気にします。したがって、解像度プロセス自体は、この仕様の範囲外です。
o User interface issues.
o ユーザーインターフェイスの問題。
In general, such issues are properly the responsibility of client software developers and standards development organizations dedicated to particular application technologies (see, for example, [WSC-UI]).
一般に、このような問題は、特定のアプリケーションテクノロジー専用のクライアントソフトウェア開発者と標準開発組織の責任です（たとえば、[WSC-UI]を参照）。
Because many concepts related to "identity" are often too vague to be actionable in application protocols, we define a set of more concrete terms for use in this specification.
「アイデンティティ」に関連する多くの概念は、アプリケーションプロトコルで実行可能ではないことが多すぎることが多いため、この仕様で使用するためのより具体的な用語のセットを定義します。
application service: A service on the Internet that enables interactive and automated clients to connect for the purpose of retrieving or uploading information, communicating with other entities, or connecting to a broader network of services.
アプリケーションサービス：インタラクティブで自動化されたクライアントが情報の取得またはアップロード、他のエンティティとの通信、またはより広範なサービスネットワークへの接続を目的として接続できるようにするインターネット上のサービス。
application service provider: An organization or individual that hosts or deploys an application service.
アプリケーションサービスプロバイダー：アプリケーションサービスをホストまたは展開する組織または個人。
application service type: A formal identifier for the application protocol used to provide a particular kind of application service at a domain; the application service type typically takes the form of a Uniform Resource Identifier scheme [URI] or a DNS SRV Service [DNS-SRV].
アプリケーションサービスタイプ：ドメインで特定の種類のアプリケーションサービスを提供するために使用されるアプリケーションプロトコルの正式な識別子。アプリケーションサービスタイプは、通常、均一なリソース識別子スキーム[URI]またはDNS SRVサービス[DNS-SRV]の形式を取得します。
attribute-type-and-value pair: A colloquial name for the ASN.1-based construction comprising a Relative Distinguished Name (RDN), which itself is a building-block component of Distinguished Names. See Section 2 of [LDAP-DN].
属性タイプと価値のペア：相対的な著名な名前（RDN）を含むASN.1ベースの構造の口語名（RDN）自体が識別名の建物ブロックコンポーネントです。[LDAP-DN]のセクション2を参照してください。
automated client: A software agent or device that is not directly controlled by a human user.
自動クライアント：人間のユーザーによって直接制御されないソフトウェアエージェントまたはデバイス。
delegated domain: A domain name or host name that is explicitly configured for communicating with the source domain, by either (a) the human user controlling an interactive client or (b) a trusted administrator. In case (a), one example of delegation is an account setup that specifies the domain name of a particular host to be used for retrieving information or connecting to a network, which might be different from the server portion of the user's account name (e.g., a server at mailhost.example.com for connecting to an IMAP server hosting an email address of juliet@example.com). In case (b), one example of delegation is an admin-configured host-to-address/address-to-host lookup table.
委任ドメイン：（a）インタラクティブなクライアントを制御する人間のユーザー、または（b）信頼できる管理者のいずれかによって、ソースドメインと通信するために明示的に構成されたドメイン名またはホスト名。（a）の場合、代表団の1つの例は、情報の取得またはネットワークへの接続に使用される特定のホストのドメイン名を指定するアカウントセットアップです。これは、ユーザーのアカウント名のサーバー部分とは異なる場合があります（例：、juliet@example.comのメールアドレスをホストするIMAPサーバーに接続するためのmailhost.example.comのサーバー。ケース（b）では、代表団の1つの例は、管理されているhost-to-address/address-to-hostルックアップテーブルです。
derived domain: A domain name or host name that a client has derived from the source domain in an automated fashion (e.g., by means of a [DNS-SRV] lookup).
派生ドメイン：クライアントが自動化された方法でソースドメインから派生したドメイン名またはホスト名（たとえば、[DNS-SRV]ルックアップなど）。
identifier: A particular instance of an identifier type that is either presented by a server in a certificate or referenced by a client for matching purposes.
識別子：証明書にサーバーによって提示されるか、一致する目的でクライアントが参照する識別子タイプの特定のインスタンス。
identifier type: A formally defined category of identifier that can be included in a certificate and therefore that can also be used for matching purposes. For conciseness and convenience, we define the following identifier types of interest, which are based on those found in the PKIX specification [PKIX] and various PKIX extensions.
識別子タイプ：証明書に含めることができる、したがって一致する目的にも使用できる正式に定義された識別子のカテゴリ。簡潔さと利便性のために、PKIX仕様[PKIX]およびさまざまなPKIX拡張機能に見られるものに基づいた関心のある識別子タイプを定義します。
* CN-ID = a Relative Distinguished Name (RDN) in the certificate subject field that contains one and only one attribute-type-and-value pair of type Common Name (CN), where the value matches the overall form of a domain name (informally, dot-separated letter-digit-hyphen labels); see [PKIX] and also [LDAP-SCHEMA]
* cn-id =型型型識別名（rdn）の相対著名な名前（RDN）フィールドには、1つの属性タイプと値の一般名（CN）の属性タイプと価値のペアが1つずつ含まれています。値は、ドメイン名の全体的な形式と一致します（非公式には、ドット分離された文字桁のハイフェンラベル）;[pkix]および[ldap-schema]を参照してください
* DNS-ID = a subjectAltName entry of type dNSName; see [PKIX]
* dns-id = dnsnameのタイプのsubjectAltNameエントリ。[pkix]を参照してください
* SRV-ID = a subjectAltName entry of type otherName whose name form is SRVName; see [SRVNAME]
* srv-id =名前フォームがsrvnameであるタイプの他の名前のsubjectAltNameエントリ。[srvname]を参照してください
* URI-ID = a subjectAltName entry of type uniformResourceIdentifier whose value includes both (i) a "scheme" and (ii) a "host" component (or its equivalent) that matches the "reg-name" rule (where the quoted terms represent the associated [ABNF] productions from [URI]); see [PKIX] and [URI]
* uri-id =（i）「スキーム」と（ii）「ホスト」コンポーネント（または同等）の両方を含むタイプのuniformResourceIdentifierのsubjectAltNameエントリのエントリ（reg-name」ルール（引用された用語が表す場合は、[uri]からの関連[abnf]プロダクション;[pkix]と[uri]を参照してください
interactive client: A software agent or device that is directly controlled by a human user. (Other specifications related to security and application protocols, such as [WSC-UI], often refer to this entity as a "user agent".)
インタラクティブクライアント：人間のユーザーが直接制御するソフトウェアエージェントまたはデバイス。（[WSC-UI]などのセキュリティおよびアプリケーションプロトコルに関連するその他の仕様は、多くの場合、このエンティティを「ユーザーエージェント」と呼んでいます。）
pinning: The act of establishing a cached name association between the application service's certificate and one of the client's reference identifiers, despite the fact that none of the presented identifiers matches the given reference identifier. Pinning is accomplished by allowing a human user to positively accept the mismatch during an attempt to communicate with the application service. Once a cached name association is established, the certificate is said to be pinned to the reference identifier and in future communication attempts the client simply verifies that the service's presented certificate matches the pinned certificate, as described under Section 6.6.2. (A similar definition of "pinning" is provided in [WSC-UI].)
ピン留め：アプリケーションサービスの証明書とクライアントの参照識別子の1つとの間にキャッシュされた名前関連を確立する行為。ピン留めは、アプリケーションサービスと通信する試み中に、人間のユーザーがミスマッチを積極的に受け入れることができるようにすることで達成されます。Cached Name Associationが確立されると、証明書は参照識別子に固定されていると言われ、将来の通信試行では、セクション6.6.2で説明されているように、クライアントが提示された証明書がピン留め証明書と一致することを単純に検証します。（[WSC-UI]で「ピン留め」の同様の定義が提供されています。）
PKIX: PKIX is a short name for the Internet Public Key Infrastructure using X.509 defined in RFC 5280 [PKIX], which comprises a profile of the X.509v3 certificate specifications and X.509v2 certificate revocation list (CRL) specifications for use in the Internet.
PKIX：PKIXは、RFC 5280 [PKIX]で定義されたX.509を使用したインターネット公開キーインフラストラクチャの短い名前であり、X.509V3証明書仕様とX.509V2証明書取消リスト（CRL）仕様のプロファイルを構成します。インターネット。
PKIX-based system: A software implementation or deployed service that makes use of X.509v3 certificates and X.509v2 certificate revocation lists (CRLs).
PKIXベースのシステム：X.509V3証明書とX.509V2証明書の取り消しリスト（CRL）を使用するソフトウェア実装または展開サービス。
PKIX certificate: An X.509v3 certificate generated and employed in the context of PKIX.
PKIX証明書：PKIXのコンテキストで生成および採用されたX.509V3証明書。
presented identifier: An identifier that is presented by a server to a client within a PKIX certificate when the client attempts to establish secure communication with the server; the certificate can include one or more presented identifiers of different types, and if the server hosts more than one domain then the certificate might present distinct identifiers for each domain.
提示された識別子：クライアントがサーバーとの安全な通信を確立しようとしたときに、PKIX証明書内のクライアントにサーバーによって提示される識別子。証明書には、異なるタイプの1つ以上の提示された識別子を含めることができ、サーバーが複数のドメインをホストしている場合、証明書は各ドメインの異なる識別子を提示する場合があります。
reference identifier: An identifier, constructed from a source domain and optionally an application service type, used by the client for matching purposes when examining presented identifiers.
参照識別子：ソースドメインから構築された識別子、およびオプションでは、提示された識別子を調べる際に一致する目的でクライアントが使用するアプリケーションサービスタイプ。
source domain: The fully qualified DNS domain name that a client expects an application service to present in the certificate (e.g., "www.example.com"), typically input by a human user, configured into a client, or provided by reference such as in a hyperlink. The combination of a source domain and, optionally, an application service type enables a client to construct one or more reference identifiers.
ソースドメイン：クライアントがアプリケーションサービスが証明書に表示されることを期待する完全に適格なDNSドメイン名（例：www.example.com」）、通常、クライアントに構成された、またはそのような参照によって提供される人間のユーザーによる入力、またはハイパーリンクのように。ソースドメインの組み合わせと、オプションでは、アプリケーションサービスタイプを使用すると、クライアントは1つ以上の参照識別子を構築できます。
subjectAltName entry: An identifier placed in a subjectAltName extension.
subjectAltNameエントリ：subjectAltName拡張子に配置された識別子。
subjectAltName extension: A standard PKIX certificate extension [PKIX] enabling identifiers of various types to be bound to the certificate subject -- in addition to, or in place of, identifiers that may be embedded within or provided as a certificate's subject field.
subjectAltName拡張子：標準のPKIX証明書拡張[PKIX]は、証明書のサブジェクトフィールドに埋め込まれている、または提供される可能性のある識別子に加えて、またはその代わりに、証明書の件名に加えて、またはその代わりに、さまざまなタイプの識別子を有効にすることができます。
subject field: The subject field of a PKIX certificate identifies the entity associated with the public key stored in the subject public key field (see Section 4.1.2.6 of [PKIX]).
件名フィールド：PKIX証明書の件名フィールドは、サブジェクト公開キーフィールドに保存されている公開キーに関連付けられたエンティティを識別します（[PKIX]のセクション4.1.2.6を参照）。
subject name: In an overall sense, a subject's name(s) can be represented by or in the subject field, the subjectAltName extension, or both (see [PKIX] for details). More specifically, the term often refers to the name of a PKIX certificate's subject, encoded as the X.501 type Name and conveyed in a certificate's subject field (see Section 4.1.2.6 of [PKIX]).
件名：全体的な意味では、サブジェクトの名前は、被験者フィールド、またはsubjectAltName拡張機能、またはその両方で表すことができます（詳細については[pkix]を参照）。より具体的には、この用語は、多くの場合、X.501タイプ名としてエンコードされ、証明書の件名フィールドで伝えられるPKIX証明書の件名の名前を指します（[PKIX]のセクション4.1.2.6を参照）。
TLS client: An entity that assumes the role of a client in a Transport Layer Security [TLS] negotiation. In this specification we generally assume that the TLS client is an (interactive or automated) application client; however, in application protocols that enable server-to-server communication, the TLS client could be a peer application service.
TLSクライアント：輸送層のセキュリティ[TLS]交渉におけるクライアントの役割を想定するエンティティ。この仕様では、一般に、TLSクライアントは（インタラクティブまたは自動化された）アプリケーションクライアントであると想定しています。ただし、サーバー間通信を可能にするアプリケーションプロトコルでは、TLSクライアントはピアアプリケーションサービスになる可能性があります。
TLS server: An entity that assumes the role of a server in a Transport Layer Security [TLS] negotiation; in this specification we assume that the TLS server is an application service.
TLSサーバー：トランスポートレイヤーセキュリティ[TLS]ネゴシエーションにおけるサーバーの役割を想定するエンティティ。この仕様では、TLSサーバーがアプリケーションサービスであると想定しています。
Most security-related terms in this document are to be understood in the sense defined in [SECTERMS]; such terms include, but are not limited to, "attack", "authentication", "authorization", "certification authority", "certification path", "certificate", "credential", "identity", "self-signed certificate", "trust", "trust anchor", "trust chain", "validate", and "verify".
このドキュメントのほとんどのセキュリティ関連の用語は、[secterms]で定義されている意味で理解されるべきです。このような条件には、「攻撃」、「認証」、「認証」、「認定機関」、「認定パス」、「証明書」、「資格情報」、「身元」、「自己署名証明書」が含まれますが、これらに限定されません。、「信頼」、「信頼アンカー」、「信頼チェーン」、「検証」、「検証」。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [KEYWORDS].
このドキュメントのキーワード "MUST"、"MUST NOT"、"REQUIRED"、"SHALL"、"SHALL NOT"、"SHOULD"、"SHOULD NOT"、"RECOMMENDED"、"NOT RECOMMENDED"、"MAY"、および "OPTIONAL" は、RFC 2119 [KEYWORDS] で説明されているように解釈されるものとします。
This section discusses naming of application services on the Internet, followed by a brief tutorial about subject naming in PKIX.
このセクションでは、インターネット上のアプリケーションサービスの命名について説明し、その後、PKIXでの主題の命名に関する簡単なチュートリアルについて説明します。
This specification assumes that the name of an application service is based on a DNS domain name (e.g., "example.com") -- supplemented in some circumstances by an application service type (e.g., "the IMAP server at example.com").
この仕様では、アプリケーションサービスの名前はDNSドメイン名（例：「Example.com」）に基づいていることを前提としています - アプリケーションサービスタイプによって状況によって補足されます（例：「Example.comのIMAPサーバー」）。
From the perspective of the application client or user, some names are direct because they are provided directly by a human user (e.g., via runtime input, prior configuration, or explicit acceptance of a client communication attempt), whereas other names are indirect because they are automatically resolved by the client based on user input (e.g., a target name resolved from a source name using DNS SRV or NAPTR records). This dimension matters most for certificate consumption, specifically verification as discussed in this document.
アプリケーションクライアントまたはユーザーの観点から見ると、一部の名前は、人間のユーザーが直接提供されるため（ランタイム入力、以前の構成、またはクライアント通信の試みの明示的な受け入れを介して）直接的ですが、他の名前は間接的であるため、それらは間接的です。ユーザーの入力に基づいてクライアントによって自動的に解決されます（たとえば、DNS SRVまたはNAPTRレコードを使用してソース名から解決されたターゲット名）。このディメンションは、証明書の消費、特にこのドキュメントで説明されている検証に最も重要です。
From the perspective of the application service, some names are unrestricted because they can be used in any type of service (e.g., a certificate might be reused for both the HTTP service and the IMAP service at example.com), whereas other names are restricted because they can be used in only one type of service (e.g., a special-purpose certificate that can be used only for an IMAP service). This dimension matters most for certificate issuance.
アプリケーションサービスの観点から見ると、一部の名前は、あらゆる種類のサービスで使用できるため、制限されていません（たとえば、Example.comのHTTPサービスとIMAPサービスの両方で証明書が再利用される場合があります）、他の名前は制限されています。これらは1つのタイプのサービスでのみ使用できるためです（たとえば、IMAPサービスにのみ使用できる特別な目的の証明書など）。この次元は、証明書発行にとって最も重要です。
Therefore, we can categorize the identifier types of interest as follows:
したがって、次のように、識別子タイプの関心を分類できます。
o A CN-ID is direct and unrestricted.
o CN-IDは直接的で無制限です。
o A DNS-ID is direct and unrestricted.
o DNS-IDは直接的で無制限です。
o An SRV-ID can be either direct or (more typically) indirect, and is restricted.
o SRV-IDは、直接または（より一般的に）間接的であり、制限されています。
o A URI-ID is direct and restricted.
o URI-IDは直接的で制限されています。
We summarize this taxonomy in the following table.
この分類法を次の表にまとめます。
+-----------+-----------+---------------+
| | Direct | Restricted |
+-----------+-----------+---------------+
| CN-ID | Yes | No |
+-----------+-----------+---------------+
| DNS-ID | Yes | No |
+-----------+-----------+---------------+
| SRV-ID | Either | Yes |
+-----------+-----------+---------------+
| URI-ID | Yes | Yes |
+-----------+-----------+---------------+
When implementing software, deploying services, and issuing certificates for secure PKIX-based authentication, it is important to keep these distinctions in mind. In particular, best practices differ somewhat for application server implementations, application client implementations, application service providers, and certification authorities. Ideally, protocol specifications that reference this document will specify which identifiers are mandatory-to-implement by servers and clients, which identifiers ought to be supported by certificate issuers, and which identifiers ought to be requested by application service providers. Because these requirements differ across applications, it is impossible to categorically stipulate universal rules (e.g., that all software implementations, service providers, and certification authorities for all application protocols need to use or support DNS-IDs as a baseline for the purpose of interoperability).
ソフトウェアの実装、サービスの展開、安全なPKIXベースの認証のための証明書の発行の場合、これらの区別を念頭に置いておくことが重要です。特に、アプリケーションサーバーの実装、アプリケーションクライアントの実装、アプリケーションサービスプロバイダー、および認定当局のベストプラクティスは多少異なります。理想的には、このドキュメントを参照するプロトコル仕様は、どの識別子がサーバーとクライアントによって包括的であるかを指定します。これは、証明書発行者によってサポートされるべきである識別子、およびアプリケーションサービスプロバイダーが要求する識別子を指定します。これらの要件はアプリケーション間で異なるため、普遍的なルールをカテゴリー的に規定することは不可能です（たとえば、すべてのアプリケーションプロトコルのすべてのソフトウェア実装、サービスプロバイダー、および認定当局が、相互運用性の目的のためのベースラインとしてDNS-IDを使用またはサポートする必要があること）。
However, it is preferable that each application protocol will at least define a baseline that applies to the community of software developers, application service providers, and CAs actively using or supporting that technology (one such community, the CA/Browser Forum, has codified such a baseline for "Extended Validation Certificates" in [EV-CERTS]).
ただし、各アプリケーションプロトコルは、ソフトウェア開発者、アプリケーションサービスプロバイダー、およびそのテクノロジーを積極的に使用またはサポートするCASのコミュニティに適用されるベースラインを少なくとも定義することが望ましいです（そのようなコミュニティ、CA/ブラウザフォーラムは、そのような成文化されました。[EV-Certs]の「拡張検証証明書」のベースライン。
For the purposes of this specification, the name of an application service is (or is based on) a DNS domain name that conforms to one of the following forms: 1. A "traditional domain name", i.e., a fully qualified DNS domain name or "FQDN" (see [DNS-CONCEPTS]) all of whose labels are "LDH labels" as described in [IDNA-DEFS]. Informally, such labels are constrained to [US-ASCII] letters, digits, and the hyphen, with the hyphen prohibited in the first character position. Additional qualifications apply (please refer to the above-referenced specifications for details), but they are not relevant to this specification.
この仕様の目的のために、アプリケーションサービスの名前は、次のフォームのいずれかに準拠するDNSドメイン名です（または基づいています）。1。「従来のドメイン名」、つまり完全に適格なDNSドメイン名ですまたは[fqdn "（[dnsconcepts]を参照）のすべてのラベルは、[idna-defs]に記載されているように「LDHラベル」です。非公式には、そのようなラベルは[us-ascii]文字、数字、およびハイフンに制約されており、ハイフンは最初のキャラクターの位置で禁止されています。追加の資格が適用されます（詳細については、上記の参照仕様を参照してください）が、この仕様には関係ありません。
2. An "internationalized domain name", i.e., a DNS domain name that conforms to the overall form of a domain name (informally, dot-separated letter-digit-hyphen labels) but includes at least one label containing appropriately encoded Unicode code points outside the traditional US-ASCII range. That is, it contains at least one U-label or A-label, but otherwise may contain any mixture of NR-LDH labels, A-labels, or U-labels, as described in [IDNA-DEFS] and the associated documents.
2. 「国際化されたドメイン名」、すなわち、ドメイン名の全体的な形式（非公式、ドット分離された文字桁Hyphenラベル）に準拠しているが、適切にエンコードされたユニコードコードポイントを含む少なくとも1つのラベルが含まれているDNSドメイン名は、DNSドメイン名です。従来の米国ASCII範囲。つまり、少なくとも1つのUラベルまたはAラベルが含まれていますが、それ以外の場合は、[IDNA-DEFS]と関連するドキュメントに記載されているように、NR-LDHラベル、Aラベル、またはUラベルの混合物を含む場合があります。
In theory, the Internet Public Key Infrastructure using X.509 [PKIX] employs the global directory service model defined in [X.500] and [X.501]. Under that model, information is held in a directory information base (DIB) and entries in the DIB are organized in a hierarchy called the directory information tree (DIT). An object or alias entry in that hierarchy consists of a set of attributes (each of which has a defined type and one or more values) and is uniquely identified by a Distinguished Name (DN). The DN of an entry is constructed by combining the Relative Distinguished Names of its superior entries in the tree (all the way down to the root of the DIT) with one or more specially nominated attributes of the entry itself (which together comprise the Relative Distinguished Name (RDN) of the entry, so-called because it is relative to the Distinguished Names of the superior entries in the tree). The entry closest to the root is sometimes referred to as the "most significant" entry, and the entry farthest from the root is sometimes referred to as the "least significant" entry. An RDN is a set (i.e., an unordered group) of attribute-type-and-value pairs (see also [LDAP-DN]), each of which asserts some attribute about the entry.
理論的には、X.509 [PKIX]を使用したインターネット公開キーインフラストラクチャは、[X.500]および[X.501]で定義されているグローバルディレクトリサービスモデルを採用しています。そのモデルでは、情報はディレクトリ情報ベース（DIB）に保持され、DIBのエントリはディレクトリ情報ツリー（DIT）と呼ばれる階層に編成されます。その階層のオブジェクトまたはエイリアスエントリは、一連の属性（それぞれが定義されたタイプと1つ以上の値を持つ）で構成され、著名な名前（DN）によって一意に識別されます。エントリのDNは、ツリー内の優れたエントリの相対的な識別名（DITのルートまで）を組み合わせて構築されます。エントリの名前（RDN）は、ツリー内の優れたエントリの際立った名前に関連しているため、いわゆるものです。ルートに最も近いエントリは、「最も重要な」エントリと呼ばれることがあり、ルートから最も遠いエントリは「最も重要でない」エントリと呼ばれることもあります。RDNは、属性タイプと価値のペアのセット（つまり、順序付けられていないグループ）です（[LDAP-DN]も参照）。それぞれがエントリに関する属性を主張しています。
In practice, the certificates used in [X.509] and [PKIX] borrow key concepts from X.500 and X.501 (e.g., DNs and RDNs) to identify entities, but such certificates are not necessarily part of a global directory information base. Specifically, the subject field of a PKIX certificate is an X.501 type Name that "identifies the entity associated with the public key stored in the subject public key field" (see Section 4.1.2.6 of [PKIX]). However, it is perfectly acceptable for the subject field to be empty, as long as the certificate contains a subject alternative name ("subjectAltName") extension that includes at least one subjectAltName entry, because the subjectAltName extension allows various identities to be bound to the subject (see Section 4.2.1.6 of [PKIX]). The subjectAltName extension itself is a sequence of typed entries, where each type is a distinct kind of identifier.
実際には、[X.509]および[PKIX]で使用されている証明書は、X.500およびX.501（DNSおよびRDNSなど）から重要な概念を借りてエンティティを識別しますが、そのような証明書は必ずしもグローバルディレクトリ情報の一部ではありませんベース。具体的には、PKIX証明書の主題フィールドは、「主題公開鍵フィールドに保存されている公開鍵に関連付けられているエンティティを識別する」X.501タイプ名です（[PKIX]のセクション4.1.2.6を参照）。ただし、SecumentAltNameのエントリを含む主題の代替名（ "subjectAltName"）拡張機能が含まれている限り、証明書に主題の代替名（「subjectAltName」）が含まれている限り、それは完全に受け入れられます。件名（[pkix]のセクション4.2.1.6を参照）。subjectAltName拡張機能自体は、各タイプが明確な種類の識別子であるタイプエントリのシーケンスです。
For our purposes, an application service can be identified by a name or names carried in the subject field (i.e., a CN-ID) and/or in one of the following identifier types within subjectAltName entries:
私たちの目的のために、アプリケーションサービスは、サブジェクトフィールド（すなわち、CN-ID）および/またはsumberaltaltNameエントリ内の次の識別子タイプのいずれかで伝達される名前または名前で識別できます。
o DNS-ID
o DNS-ID
o SRV-ID
o SRV-ID
o URI-ID
o uri-id
Existing certificates often use a CN-ID in the subject field to represent a fully qualified DNS domain name; for example, consider the following three subject names, where the attribute of type Common Name contains a string whose form matches that of a fully qualified DNS domain name ("im.example.org", "mail.example.net", and "www.example.com", respectively):
既存の証明書は、多くの場合、サブジェクトフィールドでCN-IDを使用して、完全に適格なDNSドメイン名を表します。たとえば、次の3つの主題名を考えてみましょう。タイプ共通名の属性には、完全に適格なDNSドメイン名の形式と一致する文字列が含まれています（ "im.example.org"、 "mail.example.net"、and "それぞれwww.example.com "、それぞれ）：
CN=im.example.org,O=Example Org,C=GB
C=CA,O=Example Internetworking,CN=mail.example.net
O=Examples-R-Us,CN=www.example.com,C=US
However, the Common Name is not strongly typed because a Common Name might contain a human-friendly string for the service, rather than a string whose form matches that of a fully qualified DNS domain name (a certificate with such a single Common Name will typically have at least one subjectAltName entry containing the fully qualified DNS domain name):
ただし、一般名は、完全に適格なDNSドメイン名のフォームと一致する文字列ではなく、サービスの人間に優しい文字列を含む可能性があるため、強く入力されていません（このような単一の共通名を持つ証明書は通常完全に適格なDNSドメイン名を含む少なくとも1つのsubjectAltNameエントリを持っています）：
CN=A Free Chat Service,O=Example Org,C=GB
Or, a certificate's subject might contain both a CN-ID as well as another common name attribute containing a human-friendly string:
または、証明書の件名には、CN-IDと、人間に優しい文字列を含む別の共通名属性の両方が含まれる場合があります。
CN=A Free Chat Service,CN=im.example.org,O=Example Org,C=GB
In general, this specification recommends and prefers use of subjectAltName entries (DNS-ID, SRV-ID, URI-ID, etc.) over use of the subject field (CN-ID) where possible, as more completely described in the following sections. However, specifications that reuse this one can legitimately encourage continued support for the CN-ID identifier type if they have good reasons to do so, such as backward compatibility with deployed infrastructure (see, for example, [EV-CERTS]).
一般に、この仕様は、次のセクションでより完全に説明されているように、可能であればサブジェクトフィールド（CN-ID）の使用よりも、subjectAltNameエントリ（DNS-ID、SRV-ID、URI-IDなど）の使用を推奨し、好みます。。ただし、これを再利用する仕様は、展開されたインフラストラクチャとの後方互換性など、それを行う正当な理由がある場合、CN-ID識別子タイプに対する継続的なサポートを合法的に促進できます（たとえば、[EV-Certs]を参照）。
Confusion sometimes arises from different renderings or encodings of the hierarchical information contained in a certificate.
混乱は、証明書に含まれる階層情報の異なるレンダリングまたはエンコーディングから発生することがあります。
Certificates are binary objects and are encoded using the Distinguished Encoding Rules (DER) specified in [X.690]. However, some implementations generate displayable (a.k.a. printable) renderings of the certificate issuer, subject field, and subjectAltName extension, and these renderings convert the DER-encoded sequences into a "string representation" before being displayed. Because a certificate subject field (of type Name [X.509], the same as for a Distinguished Name (DN) [X.501]) is an ordered sequence, order is typically preserved in subject string representations, although the two most prevalent subject (and DN) string representations differ in employing left-to-right vs. right-to-left ordering. However, because a Relative Distinguished Name (RDN) is an unordered group of attribute-type-and-value pairs, the string representation of an RDN can differ from the canonical DER encoding (and the order of attribute-type-and-value pairs can differ in the RDN string representations or display orders provided by various implementations). Furthermore, various specifications refer to the order of RDNs in DNs or certificate subject fields using terminology that is implicitly related to an information hierarchy (which may or may not actually exist), such as "most specific" vs. "least specific", "left-most" vs. "right-most", "first" vs. "last", or "most significant" vs. "least significant" (see, for example, [LDAP-DN]).
証明書はバイナリオブジェクトであり、[x.690]で指定された識別式エンコードルール（der）を使用してエンコードされます。ただし、一部の実装では、証明書発行者、サブジェクトフィールド、および件名拡張機能の表示可能な（別名）レンダリングを生成し、これらのレンダリングは表示される前にderエンコードされたシーケンスを「文字列表現」に変換します。証明書件名フィールド（タイプ名[x.509]のフィールドは、著名な名前（dn）[x.501]の場合と同じ）であるため、順序付けされたシーケンスであるため、順序は通常、被験者の文字列表現に保存されますが、2つの最も一般的ですが被験者（およびDN）の文字列表現は、左から右への右視線の順序の採用が異なります。ただし、相対的な識別名（RDN）は属性型型と価値のペアの順序付けられていないグループであるため、RDNの文字列表現は、標準的なderエンコード（および属性型型と価値のペアの順序とは異なる場合があります。さまざまな実装によって提供されるRDN文字列の表現または表示順序で異なる場合があります）。さらに、さまざまな仕様には、「最も具体的な」対「最小」、「最小」、「」などの情報階層（実際に存在する場合とはない場合がある場合もあります）に暗黙的に関連する用語を使用して、DNSまたは証明書の主題フィールドのRDNの順序を指します。左最大の "vs." right-most "、" first "vs." last "、または"最も重要な "vs.「最小重要」（たとえば、[ldap-dn]を参照）。
To reduce confusion, in this specification we avoid such terms and instead use the terms provided under Section 1.8; in particular, we do not use the term "(most specific) Common Name field in the subject field" from [HTTP-TLS] and instead state that a CN-ID is a Relative Distinguished Name (RDN) in the certificate subject containing one and only one attribute-type-and-value pair of type Common Name (thus removing the possibility that an RDN might contain multiple AVAs (Attribute Value Assertions) of type CN, one of which could be considered "most specific").
混乱を減らすために、この仕様ではそのような条件を回避し、代わりにセクション1.8に基づいて提供される条件を使用します。特に、[http-tls]から「（最も具体的な）サブジェクトフィールドの一般名フィールド」という用語を使用せず、代わりに、CN-idは1つを含む証明書科目の相対的な著名な名前（RDN）であると述べています。そして、タイプ共通名の属性タイプと値のペアは1つだけです（したがって、RDNがタイプCNの複数のAVA（属性値アサーション）を含む可能性を削除します。
Finally, although theoretically some consider the order of RDNs within a subject field to have meaning, in practice that rule is often not observed. An AVA of type CN is considered to be valid at any position within the subject field.
最後に、理論的には、主題分野内のRDNの順序が意味を持つと考えている人もいますが、実際にはそのルールはしばしば観察されません。タイプCNのAVAは、サブジェクトフィールド内の任意の位置で有効であると見なされます。
This section provides guidelines for designers of application protocols, in the form of a checklist to follow when reusing the recommendations provided in this document.
このセクションでは、このドキュメントで提供されている推奨事項を再利用する際に従うべきチェックリストの形で、アプリケーションプロトコルの設計者向けのガイドラインを提供します。
o Does your technology use DNS SRV records to resolve the DNS domain names of application services? If so, consider recommending or requiring support for the SRV-ID identifier type in PKIX certificates issued and used in your technology community. (Note that many existing application technologies use DNS SRV records to resolve the DNS domain names of application services, but do not rely on representations of those records in PKIX certificates by means of SRV-IDs as defined in [SRVNAME].)
o テクノロジーはDNS SRVレコードを使用して、アプリケーションサービスのDNSドメイン名を解決しますか？その場合は、テクノロジーコミュニティで発行および使用されているPKIX証明書のSRV-ID識別子タイプの推奨またはサポートを検討または要求することを検討してください。（多くの既存のアプリケーションテクノロジーは、DNS SRVレコードを使用してアプリケーションサービスのDNSドメイン名を解決しますが、[SRVNAME]で定義されているSRV-IDによってPKIX証明書のこれらのレコードの表現に依存しないことに注意してください。）
o Does your technology use URIs to identify application services? If so, consider recommending or requiring support for the URI-ID identifier type. (Note that many existing application technologies use URIs to identify application services, but do not rely on representation of those URIs in PKIX certificates by means of URI-IDs.)
o あなたのテクノロジーはURIを使用してアプリケーションサービスを特定していますか？その場合は、URI-ID識別子タイプを推奨またはサポートすることを検討してください。（既存のアプリケーションテクノロジーの多くは、URIを使用してアプリケーションサービスを特定しますが、URI-IDを使用してPKIX証明書のこれらのURIの表現に依存していないことに注意してください。）
o Does your technology need to use DNS domain names in the Common Name of certificates for the sake of backward compatibility? If so, consider recommending support for the CN-ID identifier type as a fallback.
o あなたのテクノロジーは、後方互換性のために証明書の共通名でDNSドメイン名を使用する必要がありますか？その場合は、CN-ID識別子タイプのサポートをフォールバックとして推奨することを検討してください。
o Does your technology need to allow the wildcard character in DNS domain names? If so, consider recommending support for wildcard certificates, and specify exactly where the wildcard character is allowed to occur (e.g., only the complete left-most label of a DNS domain name).
o あなたのテクノロジーは、DNSドメイン名でワイルドカード文字を許可する必要がありますか？その場合は、ワイルドカード証明書のサポートを推奨することを検討し、WildCard文字が発生する場所を正確に指定します（たとえば、DNSドメイン名の完全な左のラベルのみ）。
Sample text is provided under Appendix A.
サンプルテキストは付録Aに記載されています。
This section provides rules and guidelines for issuers of certificates.
このセクションでは、証明書の発行者のルールとガイドラインを提供します。
When a certification authority issues a certificate based on the fully qualified DNS domain name at which the application service provider will provide the relevant application, the following rules apply to the representation of application service identities. The reader needs to be aware that some of these rules are cumulative and can interact in important ways that are illustrated later in this document.
認定機関が、アプリケーションサービスプロバイダーが関連するアプリケーションを提供する完全に認定されたDNSドメイン名に基づいて証明書を発行する場合、以下のルールがアプリケーションサービスIDの表現に適用されます。読者は、これらのルールの一部が累積的であり、このドキュメントの後半に説明されている重要な方法で相互作用できることを認識する必要があります。
1. The certificate SHOULD include a "DNS-ID" if possible as a baseline for interoperability.
1. 証明書には、相互運用性のベースラインとして、可能であれば「DNS-ID」を含めるべきです (SHOULD)。
2. If the service using the certificate deploys a technology for which the relevant specification stipulates that certificates ought to include identifiers of type SRV-ID (e.g., this is true of [XMPP]), then the certificate SHOULD include an SRV-ID.
2. 証明書を使用するサービスが、関連仕様において証明書にSRV-IDタイプの識別子を含めるべきであると規定されている技術を展開している場合（例えば[XMPP]など）、証明書にはSRV-IDを含めるべきです (SHOULD)。
3. If the service using the certificate deploys a technology for which the relevant specification stipulates that certificates ought to include identifiers of type URI-ID (e.g., this is true of [SIP] as specified by [SIP-CERTS], but not true of [HTTP] since [HTTP-TLS] does not describe usage of a URI-ID for HTTP services), then the certificate SHOULD include a URI-ID. The scheme SHALL be that of the protocol associated with the application service type and the "host" component (or its equivalent) SHALL be the fully qualified DNS domain name of the service. A specification that reuses this one MUST specify which URI schemes are to be considered acceptable in URI-IDs contained in PKIX certificates used for the application protocol (e.g., "sip" but not "sips" or "tel" for SIP as described in [SIP-SIPS], or perhaps http and https for HTTP as might be described in a future specification).
3. 証明書を使用するサービスが、関連仕様において証明書にURI-IDタイプの識別子を含めるべきであると規定されている技術を展開している場合（例えば[SIP-CERTS]で規定されている[SIP]には当てはまりますが、HTTPサービスでのURI-IDの使用を規定していない[HTTP] [HTTP-TLS]には当てはまりません）、証明書にはURI-IDを含めるべきです (SHOULD)。ただし、後述のセクション7.3で論じるように、サービスがURIスキームだけでなくDNSドメイン名でも識別可能である場合は、URI-IDを唯一の識別子とすることはできず、代わりに証明書にはDNS-IDも含めなければなりません (SHALL)。関連仕様にそのような要件がない場合でも、証明書にはURI-IDを含めてもよいですが (MAY)、その場合でもDNS-IDも含めなければなりません (SHALL)（ただし、仕様でURI-IDが必須 (MUST) と定義されており、DNSドメイン名でのみ識別可能なクライアントとの相互運用性を明示的に放棄している場合は除きます）。
4. The certificate MAY include other application-specific identifiers for types that were defined before publication of [SRVNAME] (e.g., XmppAddr for [XMPP]) or for which service names or URI schemes do not exist; however, such application-specific identifiers are not applicable to all application technologies and therefore are out of scope for this specification.
4. 証明書には、[SRVNAME]の公開前に定義されたタイプ（例えば[XMPP]のXmppAddr）や、サービス名またはURIスキームが存在しない場合の他のアプリケーション固有の識別子を含めてもよいです (MAY)。ただし、このようなアプリケーション固有の識別子はすべてのアプリケーション技術に適用できるわけではないため、本仕様ではそれ以上のルールやガイドラインは提供しません。
5. Even though many deployed clients still check for the CN-ID within the certificate subject field, certification authorities are encouraged to migrate away from issuing certificates that represent the server's fully qualified DNS domain name in a CN-ID. Therefore, the certificate SHOULD NOT include a CN-ID unless the certification authority issues the certificate in accordance with a specification that reuses this one and that explicitly encourages continued support for the CN-ID identifier type in the context of a given application technology.
5. 運用中の多くのクライアントは依然として証明書のsubjectフィールド内のCN-IDをチェックしますが、認証機関（CA）は、CN-ID内にサーバーの完全修飾DNSドメイン名を表す証明書の発行から移行することが推奨されます。したがって、本仕様を再利用し特定のアプリケーション技術のために証明書発行をプロファイルする仕様で明確に許可されていない限り、提示される識別子にはCN-IDを含めるべきではありません (SHOULD NOT)（既存のアプリケーション技術に関する現在の実践状況の調査については付録Bを参照）。
6. The certificate MAY contain more than one DNS-ID, SRV-ID, or URI-ID but SHOULD NOT contain more than one CN-ID, as further explained under Section 7.4.
6. 証明書には、複数のDNS-ID、SRV-ID、またはURI-IDを含めてもよいですが (MAY)、セクション7.4でさらに説明するように、複数のCN-IDを含めるべきではありません (SHOULD NOT)。
7. Unless a specification that reuses this one allows continued support for the wildcard character '*', the DNS domain name portion of a presented identifier SHOULD NOT contain the wildcard character, whether as the complete left-most label within the identifier (following the description of labels and domain names in [DNS-CONCEPTS], e.g., "*.example.com") or as a fragment thereof (e.g., *oo.example.com, f*o.example.com, or fo*.example.com). A more detailed discussion of so-called "wildcard certificates" is provided under Section 7.2.
7. 本仕様を再利用する仕様でワイルドカード文字 '*' の継続的なサポートが許可されていない限り、提示される識別子のDNSドメイン名部分には、識別子内の完全な左端ラベルとしてワイルドカード文字を含めるべきではありません (SHOULD NOT)（[DNS-CONCEPTS]におけるラベルとドメイン名の説明に従い、例えば "*.example.com" など）。また、そのフラグメント（例えば "baz*.example.net" など）としても含めるべきではありません (SHOULD NOT)（詳細についてはセクション6.4.3を参照）。
Consider a simple website at "www.example.com", which is not discoverable via DNS SRV lookups. Because HTTP does not specify the use of URIs in server certificates, a certificate for this service might include only a DNS-ID of "www.example.com". It might also include a CN-ID of "www.example.com" for backward compatibility with deployed infrastructure.
「www.example.com」のシンプルなWebサイトを検討してください。これは、DNS SRV Lookupsで発見できません。HTTPはサーバー証明書でのURIの使用を指定していないため、このサービスの証明書には「www.example.com」のDNS-IDのみが含まれる場合があります。また、展開されたインフラストラクチャとの後方互換性のための「www.example.com」のCN-IDが含まれる場合があります。
Consider an IMAP-accessible email server at the host "mail.example.net" servicing email addresses of the form "user@example.net" and discoverable via DNS SRV lookups on the application service name of "example.net". A certificate for this service might include SRV-IDs of "_imap.example.net" and "_imaps.example.net" (see [EMAIL-SRV]) along with DNS-IDs of "example.net" and "mail.example.net". It might also include CN-IDs of "example.net" and "mail.example.net" for backward compatibility with deployed infrastructure.
フォーム「user@example.net」のフォームのメールアドレスを保守し、「example.net」のアプリケーションサービス名のDNS SRV lookupsを介して検出可能なメールアドレス「mail.example.net」のimap-accessableメールサーバーを検討してください。このサービスの証明書には、「_imap.example.net」および「_imaps.example.net」（[email-srv]を参照）と「embles.net」および「mail.exampleのdns-idsとともに、srv-idsが含まれる場合があります。。ネット"。また、展開されたインフラストラクチャとの後方互換性のための「embles.net」および「mail.example.net」のCN-IDが含まれる場合があります。
Consider a SIP-accessible voice-over-IP (VoIP) server at the host "voice.example.edu" servicing SIP addresses of the form "user@voice.example.edu" and identified by a URI of <sip: voice.example.edu>. A certificate for this service would include a URI-ID of "sip:voice.example.edu" (see [SIP-CERTS]) along with a DNS-ID of "voice.example.edu". It might also include a CN-ID of "voice.example.edu" for backward compatibility with deployed infrastructure.
ホスト「Voice.example.edu」のSip-Accessable Voice-Over-IP（VoIP）サーバーを検討してください。example.edu>。このサービスの証明書には、「sip：voice.example.edu」（[sip-certs]を参照）のuri-idと「voice.example.edu」のdns-idが含まれます。また、展開されたインフラストラクチャとの後方互換性のための「Voice.example.edu」のCN-IDが含まれる場合があります。
Consider an XMPP-compatible instant messaging (IM) server at the host "im.example.org" servicing IM addresses of the form "user@im.example.org" and discoverable via DNS SRV lookups on the "im.example.org" domain. A certificate for this service might include SRV-IDs of "_xmpp-client.im.example.org" and "_xmpp-server.im.example.org" (see [XMPP]), a DNS-ID of "im.example.org", and an XMPP-specific "XmppAddr" of "im.example.org" (see [XMPP]). It might also include a CN-ID of "im.example.org" for backward compatibility with deployed infrastructure.
ホストのXMPP互換インスタントメッセージング（IM）サーバー「im.example.org」のサーバー「user@im.example.org」のフォームのアドレスを保守し、 "im.example.orgのdns srv lookupsを介して発見可能「ドメイン。このサービスの証明書には、「_xmpp-client.im.example.org」のsrv-idsが含まれる場合があります。.org "、および「im.example.org」のxmpp固有の「xmppaddr」（[xmpp]を参照）。また、展開されたインフラストラクチャとの後方互換性のための「im.example.org」のCN-IDが含まれる場合があります。
This section provides rules and guidelines for service providers regarding the information to include in certificate signing requests (CSRs).
このセクションでは、証明書署名リクエスト（CSR）に含める情報に関するサービスプロバイダーのルールとガイドラインを提供します。
In general, service providers are encouraged to request certificates that include all of the identifier types that are required or recommended for the application service type that will be secured using the certificate to be issued.
一般に、サービスプロバイダーは、発行される証明書を使用して保護されるアプリケーションサービスタイプに必要または推奨されるすべての識別子タイプを含む証明書を要求することをお勧めします。
If the certificate might be used for any type of application service, then the service provider is encouraged to request a certificate that includes only a DNS-ID.
証明書があらゆるタイプのアプリケーションサービスに使用される場合は、サービスプロバイダーがDNS-IDのみを含む証明書を要求することをお勧めします。
If the certificate will be used for only a single type of application service, then the service provider is encouraged to request a certificate that includes a DNS-ID and, if appropriate for the application service type, an SRV-ID or URI-ID that limits the deployment scope of the certificate to only the defined application service type.
証明書が単一のタイプのアプリケーションサービスのみに使用される場合、サービスプロバイダーは、DNS-IDを含む証明書を要求することをお勧めします。証明書の展開範囲を定義されたアプリケーションサービスタイプのみに制限します。
If a service provider offering multiple application service types (e.g., a World Wide Web service, an email service, and an instant messaging service) wishes to limit the applicability of certificates using SRV-IDs or URI-IDs, then the service provider is encouraged to request multiple certificates, i.e., one certificate per application service type. Conversely, the service provider is discouraged from requesting a single certificate containing multiple SRV-IDs or URI-IDs identifying each different application service type. This guideline does not apply to application service type "bundles" that are used to identify manifold distinct access methods to the same underlying application (e.g., an email application with access methods denoted by the application service types of "imap", "imaps", "pop3", "pop3s", and "submission" as described in [EMAIL-SRV]).
複数のアプリケーションサービスタイプを提供するサービスプロバイダー（例：World Wide Webサービス、電子メールサービス、インスタントメッセージングサービス）がSRV-IDまたはURI-IDを使用して証明書の適用性を制限したい場合、サービスプロバイダーが推奨されます複数の証明書、つまり、アプリケーションサービスタイプごとに1つの証明書を要求します。逆に、サービスプロバイダーは、複数のSRV-IDまたはURI-IDがそれぞれの異なるアプリケーションサービスタイプを識別する1つの証明書を要求することを思いとどまらせます。このガイドラインは、同じ基礎となるアプリケーションへのマニホールド別個のアクセス方法を識別するために使用されるアプリケーションサービスタイプの「バンドル」には適用されません（たとえば、「IMAP」、「IMAP」のアプリケーションサービスタイプで示されるアクセスメソッドを含む電子メールアプリケーション。[email-srv]に記載されているように、「pop3」、「pop3s」、および「送信」。
This section provides rules and guidelines for implementers of application client software regarding algorithms for verification of application service identity.
このセクションでは、アプリケーションサービスIDの検証のためのアルゴリズムに関するアプリケーションクライアントソフトウェアの実装者向けのルールとガイドラインを提供します。
At a high level, the client verifies the application service's identity by performing the actions listed below (which are defined in the following subsections of this document): 1. The client constructs a list of acceptable reference identifiers based on the source domain and, optionally, the type of service to which the client is connecting.
高レベルでは、クライアントは、以下にリストされているアクション（このドキュメントの次のサブセクションで定義されている）を実行することにより、アプリケーションサービスのIDを検証します。1。クライアントは、ソースドメインに基づいて許容可能な参照識別子のリストを構築し、オプションでは、クライアントが接続しているサービスの種類。
2. The server provides its identifiers in the form of a PKIX certificate.
2. サーバーは、識別子をPKIX証明書の形式で提供します。
3. The client checks each of its reference identifiers against the presented identifiers for the purpose of finding a match.
3. クライアントは、一致を見つける目的で、提示された識別子に対して各参照識別子をチェックします。
4. When checking a reference identifier against a presented identifier, the client matches the source domain of the identifiers and, optionally, their application service type.
4. 提示された識別子に対して参照識別子をチェックするとき、クライアントは識別子のソースドメインと、オプションでアプリケーションサービスタイプと一致します。
Naturally, in addition to checking identifiers, a client might complete further checks to ensure that the server is authorized to provide the requested service. However, such checking is not a matter of verifying the application service identity presented in a certificate, and therefore methods for doing so (e.g., consulting local policy information) are out of scope for this document.
当然のことながら、識別子をチェックすることに加えて、クライアントはさらにチェックを完了し、サーバーが要求されたサービスを提供することを許可されていることを確認することができます。ただし、そのようなチェックは、証明書に提示されたアプリケーションサービスIDを確認することではないため、この文書の範囲外は範囲外です。
The client MUST construct a list of acceptable reference identifiers, and MUST do so independently of the identifiers presented by the service.
クライアントは許容可能な参照識別子のリストを構築しなければならず (MUST)、サービスによって提示される識別子とは独立してそれを行わなければなりません (MUST)。
The inputs used by the client to construct its list of reference identifiers might be a URI that a user has typed into an interface (e.g., an HTTPS URL for a website), configured account information (e.g., the domain name of a particular host or URI used for retrieving information or connecting to a network, which might be different from the DNS domain name portion of a username), a hyperlink in a web page that triggers a browser to retrieve a media object or script, or some other combination of information that can yield a source domain and an application service type.
クライアントが参照識別子のリストを作成するために使用される入力は、ユーザーがインターフェイス（たとえば、WebサイトのHTTPS URLなど）に入力したURI、構成されたアカウント情報（特定のホストのドメイン名、または情報の取得またはネットワークへの接続に使用されるURI（ユーザー名のDNSドメイン名部分とは異なる場合があります）、ブラウザをトリガーしてメディアオブジェクトまたはスクリプトを取得するためにトリガーするWebページのハイパーリンク、またはその他の情報の組み合わせこれにより、ソースドメインとアプリケーションサービスタイプが生成されます。
The client might need to extract the source domain and application service type from the input(s) it has received. The extracted data MUST include only information that can be securely parsed out of the inputs (e.g., parsing the fully qualified DNS domain name out of the "host" component (or its equivalent) of a URI or deriving the application service type from the scheme of a URI) or information that is derived in a manner not subject to subversion by network attackers (e.g., pulling the data from a delegated domain that is explicitly established via client or system configuration, resolving the data via [DNSSEC], or obtaining the data from a third-party domain mapping service in which a human user has explicitly placed trust and with which the client communicates over a connection or association that provides both mutual authentication and integrity checking). These considerations apply only to extraction of the source domain from the inputs; naturally, if the inputs themselves are invalid or corrupt (e.g., a user has clicked a link provided by a malicious entity in a phishing attack), then the client might end up communicating with an unexpected application service.
クライアントは、受信した入力からソースドメインおよびアプリケーションサービスタイプを抽出する必要がある場合があります。抽出されるデータには、入力から安全に解析できる情報のみを含めなければなりません (MUST)（例えば、URIの「host」コンポーネント（または同等のもの）から完全修飾DNSドメイン名を解析したり、スキームからアプリケーションサービスタイプを解析したりするなど）。
Example: Given an input URI of <sips:alice@example.net>, a client would derive the application service type "sip" from the "scheme" and parse the domain name "example.net" from the "host" component (or its equivalent).
例：<sips：alice@example.net>の入力uriが与えられた場合、クライアントは「スキーム」からアプリケーションサービスタイプ「SIP」を導き出し、「ホスト」コンポーネントからドメイン名「example.net」を解析します（または同等）。
Each reference identifier in the list SHOULD be based on the source domain and SHOULD NOT be based on a derived domain (e.g., a host name or domain name discovered through DNS resolution of the source domain). This rule is important because only a match between the user inputs and a presented identifier enables the client to be sure that the certificate can legitimately be used to secure the client's communication with the server. There is only one scenario in which it is acceptable for an interactive client to override the recommendation in this rule and therefore communicate with a domain name other than the source domain: because a human user has "pinned" the application service's certificate to the alternative domain name as further discussed under Section 6.6.4 and Section 7.1. In this case, the inputs used by the client to construct its list of reference identifiers might include more than one fully qualified DNS domain name, i.e., both (a) the source domain and (b) the alternative domain contained in the pinned certificate.
リスト内の各参照識別子はソースドメインに基づくべきであり (SHOULD)、派生ドメイン（例えば、ソースドメインのDNS解決によって発見されたホスト名やドメイン名など）に基づくべきではありません (SHOULD NOT)。ユーザー入力と提示された識別子の一致のみが、クライアントが意図したサーバーと通信していることをクライアント（ひいてはユーザー）に合理的な確信を与えることができます。
Using the combination of fully qualified DNS domain name(s) and application service type, the client constructs a list of reference identifiers in accordance with the following rules:
完全に適格なDNSドメイン名とアプリケーションサービスタイプの組み合わせを使用して、クライアントは次のルールに従って参照識別子のリストを作成します。
o The list SHOULD include a DNS-ID. A reference identifier of type DNS-ID can be directly constructed from a fully qualified DNS domain name that is (a) contained in or securely derived from the inputs (i.e., the source domain), or (b) explicitly associated with the source domain by means of user configuration (i.e., a derived domain).
o リストにはDNS-IDを含めるべきです (SHOULD)。DNS-IDタイプの参照識別子は、（a）入力に含まれるか安全に導出された（すなわちソースドメイン）、または（b）ユーザー設定によって明示的にソースドメインに関連付けられた（すなわち派生ドメイン）完全修飾DNSドメイン名から直接構築できます。
o If a server for the application service type is typically discovered by means of DNS SRV records, then the list SHOULD include an SRV-ID.
o アプリケーションサービスタイプのサーバーが通常DNS SRVレコードによって発見される場合、リストにはSRV-IDを含めるべきです (SHOULD)。
o If a server for the application service type is typically associated with a URI for security purposes (i.e., a formal protocol document specifies the use of URIs in server certificates), then the list SHOULD include a URI-ID.
o アプリケーションサービスタイプのサーバーが通常セキュリティ目的でURIに関連付けられている場合（すなわち、正式なプロトコル文書がサーバー証明書内でのURIの使用を指定している場合）、リストにはURI-IDを含めるべきです (SHOULD)。
o The list MAY include a CN-ID, mainly for the sake of backward compatibility with deployed infrastructure.
o 主に展開済みインフラストラクチャとの後方互換性のために、リストにはCN-IDを含めてもよいです (MAY)。
Which identifier types a client includes in its list of reference identifiers is a matter of local policy. For example, in certain deployment environments, a client that is built to connect only to a particular kind of service (e.g., only IM services) might be configured to accept as valid only certificates that include an SRV-ID for that application service type; in this case, the client would include only SRV-IDs matching the application service type in its list of reference identifiers (not, for example, DNS-IDs). By contrast, a more lenient client (even one built to connect only to a particular kind of service) might include both SRV-IDs and DNS-IDs in its list of reference identifiers.
クライアントが参照識別子のリストに含める識別子タイプは、ローカルポリシーの問題です。たとえば、特定の展開環境では、特定の種類のサービス（たとえば、IMサービスのみ）にのみ接続するように構築されたクライアントは、そのアプリケーションサービスタイプのSRV-IDを含む有効な証明書として受け入れるように構成される場合があります。この場合、クライアントには、参照識別子のリストにアプリケーションサービスタイプに一致するSRV-IDのみが含まれます（たとえば、DNS-IDではありません）。対照的に、より寛大なクライアント（特定の種類のサービスのみに接続するために構築されたものであっても）には、参照識別子のリストにSRV-IDとDNS-IDの両方が含まれる場合があります。
Implementation Note: It is highly likely that implementers of client software will need to support CN-IDs for the foreseeable future, because certificates containing CN-IDs are so widely deployed. Implementers are advised to monitor the state of the art with regard to certificate issuance policies and migrate away from support CN-IDs in the future if possible.
実装注：CN-IDを含む証明書が非常に広く展開されているため、クライアントソフトウェアの実装者は近い将来にCN-IDをサポートする必要がある可能性が高いです。実装者は、証明書発行ポリシーに関して最先端を監視し、可能であれば将来のサポートCN-IDから移行することをお勧めします。
Implementation Note: The client does not need to construct the foregoing identifiers in the actual formats found in a certificate (e.g., as ASN.1 types); it only needs to construct the functional equivalent of such identifiers for matching purposes.
実装注：クライアントは、証明書で見つかった実際の形式で前述の識別子を構築する必要はありません（例：ASN.1タイプなど）。一致する目的のために、そのような識別子との機能的な同等物を構築するだけです。
Security Warning: A client MUST NOT construct a reference identifier corresponding to Relative Distinguished Names (RDNs) other than those of type Common Name and MUST NOT check for RDNs other than those of type Common Name in the presented identifiers.
セキュリティ警告: クライアントは、Common NameタイプのRelative Distinguished Name (RDN) 以外のRDNに対応する参照識別子を構築してはならず (MUST NOT)、サブジェクトの識別名内の最も具体的（最後）のCommon Name以外のCommon Nameに対応する参照識別子を構築してはなりません (MUST NOT)（詳細についてはセクション7.4を参照）。
A web browser that is connecting via HTTPS to the website at "www.example.com" might have two reference identifiers: a DNS-ID of "www.example.com" and, as a fallback, a CN-ID of "www.example.com".
httpsを介して「www.example.com」のWebサイトに接続しているWebブラウザには、2つの参照識別子があります。.example.com "。
A mail user agent that is connecting via IMAPS to the email service at "example.net" (resolved as "mail.example.net") might have five reference identifiers: an SRV-ID of "_imaps.example.net" (see [EMAIL-SRV]), DNS-IDs of "example.net" and "mail.example.net", and, as a fallback, CN-IDs of "example.net" and "mail.example.net". (A legacy email user agent would not support [EMAIL-SRV] and therefore would probably be explicitly configured to connect to "mail.example.net", whereas an SRV-aware user agent would derive "example.net" from an email address of the form "user@example.net" but might also accept "mail.example.net" as the DNS domain name portion of reference identifiers for the service.)
imapsを介して "example.net"（ "mail.example.net"として解決された）で電子メールサービスに接続しているメールユーザーエージェントには、5つの参照識別子があります。[email-srv]）、 "example.net"および "mail.example.net"のdns-id、およびフォールバックとして、 "embles.net"および "mail.example.net"のcn-id。（レガシーメールユーザーエージェントは[電子メール-SRV]をサポートせず、したがって、おそらく「mail.example.net」に接続するように明示的に構成されますが、srvに適用されるユーザーエージェントは電子メールアドレスから「emple.net」を導き出します。「user@example.net」のフォームですが、サービスの参照識別子のDNSドメイン名部分として「mail.example.net」も受け入れるかもしれません。）
A voice-over-IP (VoIP) user agent that is connecting via SIP to the voice service at "voice.example.edu" might have only one reference identifier: a URI-ID of "sip:voice.example.edu" (see [SIP-CERTS]).
sipを介して「voice.example.edu」で音声サービスに接続しているボイスオーバーIP（VoIP）ユーザーエージェントには、参照識別子が1つしかない場合があります。[sip-certs]を参照してください。
An instant messaging (IM) client that is connecting via XMPP to the IM service at "im.example.org" might have three reference identifiers: an SRV-ID of "_xmpp-client.im.example.org" (see [XMPP]), a DNS-ID of "im.example.org", and an XMPP-specific "XmppAddr" of "im.example.org" (see [XMPP]).
XMPPを介して「IM.example.org」でIMサービスに接続しているインスタントメッセージング（IM）クライアントには、3つの参照識別子があります。]）、「im.example.org」のdns-id、および「im.example.org」のxmpp固有の「xmppaddr」（[xmpp]を参照）。
Once the client has constructed its list of reference identifiers and has received the server's presented identifiers in the form of a PKIX certificate, the client checks its reference identifiers against the presented identifiers for the purpose of finding a match. The search fails if the client exhausts its list of reference identifiers without finding a match. The search succeeds if any presented identifier matches one of the reference identifiers, at which point the client SHOULD stop the search.
クライアントが参照識別子のリストを構築し、PKIX証明書の形式でサーバーの提示された識別子を受信したら、クライアントは一致を見つける目的で提示された識別子に対して参照識別子をチェックすべきです (SHOULD)。クライアントが一致を見つけることなく参照識別子のリストを使い果たした場合、検索は失敗します。提示された識別子が参照識別子のいずれかと一致した場合、検索は成功します。
Implementation Note: A client might be configured to perform multiple searches, i.e., to match more than one reference identifier. Although such behavior is not forbidden by this specification, rules for matching multiple reference identifiers are a matter for implementation or future specification.
実装注：クライアントは、複数の検索を実行するように構成されている場合があります。つまり、複数の参照識別子に一致するように。このような動作はこの仕様では禁止されていませんが、複数の参照識別子を一致させるためのルールは、実装または将来の仕様の問題です。
Security Warning: A client MUST NOT seek a match for a reference identifier of CN-ID if the presented identifiers include a DNS-ID, SRV-ID, URI-ID, or any application-specific identifier types supported by the client.
セキュリティ警告: 提示された識別子にDNS-ID、SRV-ID、URI-ID、またはクライアントがサポートする任意のアプリケーション固有の識別子タイプが含まれている場合、クライアントはCN-IDの参照識別子の一致を求めてはなりません (MUST NOT)。
Before applying the comparison rules provided in the following sections, the client might need to split the reference identifier into its DNS domain name portion and its application service type portion, as follows:
次のセクションで提供される比較ルールを適用する前に、クライアントは、次のように、参照識別子をDNSドメイン名部分とアプリケーションサービスタイプ部分に分割する必要がある場合があります。
o A reference identifier of type DNS-ID does not include an application service type portion and thus can be used directly as the DNS domain name for comparison purposes. As an example, a DNS-ID of "www.example.com" would result in a DNS domain name portion of "www.example.com".
o タイプDNS-IDの参照識別子には、アプリケーションサービスタイプの部分が含まれていないため、比較目的でDNSドメイン名として直接使用できます。例として、「www.example.com」のDNS-IDは、「www.example.com」のDNSドメイン名部分になります。
o A reference identifier of type CN-ID also does not include an application service type portion and thus can be used directly as the DNS domain name for comparison purposes. As previously mentioned, this document specifies that a CN-ID always contains a string whose form matches that of a DNS domain name (thus differentiating a CN-ID from a Common Name containing a human-friendly name).
o タイプCN-IDの参照識別子には、アプリケーションサービスタイプの部分も含まれていないため、比較目的でDNSドメイン名として直接使用できます。前述のように、このドキュメントは、CN-IDには常にDNSドメイン名のフォームと一致する文字列が含まれていることを指定しています（したがって、CN-IDを人間に優しい名前を含む共通名から区別します）。
o For a reference identifier of type SRV-ID, the DNS domain name portion is the Name and the application service type portion is the Service. As an example, an SRV-ID of "_imaps.example.net" would be split into a DNS domain name portion of "example.net" and an application service type portion of "imaps" (mapping to an application protocol of IMAP as explained in [EMAIL-SRV]).
o タイプSRV-IDの参照識別子の場合、DNSドメイン名の部分は名前であり、アプリケーションサービスタイプの部分はサービスです。例として、「_imaps.example.net」のsrv-idは、「example.net」のdnsドメイン名部分に分割され、「imaps」のアプリケーションサービスタイプ部分に分割されます（imapのアプリケーションプロトコルへのマッピング[email-srv]で説明しました）。
o For a reference identifier of type URI-ID, the DNS domain name portion is the "reg-name" part of the "host" component (or its equivalent) and the application service type portion is the application service type associated with the scheme name matching the [ABNF] "scheme" rule from [URI] (not including the ':' separator). As previously mentioned, this document specifies that a URI-ID always contains a "host" component (or its equivalent) containing a "reg-name". (Matching only the "reg-name" rule from [URI] limits verification to DNS domain names, thereby differentiating a URI-ID from a uniformResourceIdentifier entry that contains an IP address or a mere host name, or that does not contain a "host" component at all.) Furthermore, note that extraction of the "reg-name" might necessitate normalization of the URI (as explained in [URI]). As an example, a URI-ID of "sip: voice.example.edu" would be split into a DNS domain name portion of "voice.example.edu" and an application service type of "sip" (associated with an application protocol of SIP as explained in [SIP-CERTS]).
o タイプURI-IDの参照識別子の場合、DNSドメイン名部分は「ホスト」コンポーネントの「reg-name」部分（または同等）であり、アプリケーションサービスタイプの部分はスキーム名に関連付けられたアプリケーションサービスタイプです[uri]の[abnf]「スキーム」ルールを一致させる（ '：'セパレーターを含めない）。前述のように、このドキュメントは、URI-IDには常に「regName」を含む「ホスト」コンポーネント（または同等）が含まれていることを指定しています。（[uri]の「reg-name」ルールのみをDNSドメイン名に制限し、URI-IDをIPアドレスまたは単なるホスト名を含む、または「ホストを含む」を含む均一なルイスアイデンティファイアエントリと区別することにより、「コンポーネント。）さらに、「reg-name」の抽出には、URIの正規化が必要になる可能性があることに注意してください（[uri]で説明されているように）。例として、「sip：voice.example.edu」のuri-idは、「voice.example.edu」のDNSドメイン名部分に分割され、「SIP」のアプリケーションサービスタイプに分割されます（アプリケーションプロトコルに関連付けられています[sip-certs]で説明されているSIPの）。
Detailed comparison rules for matching the DNS domain name portion and application service type portion of the reference identifier are provided in the following sections.
DNSドメイン名部分とリファレンス識別子のアプリケーションサービスタイプ部分を一致させるための詳細な比較ルールは、次のセクションで提供されています。
The client MUST match the DNS domain name portion of a reference identifier according to the following rules (and SHOULD also check the application service type as described under Section 6.5). The rules differ depending on whether the domain to be checked is a "traditional domain name" or an "internationalized domain name" (as defined under Section 2.2). Furthermore, to meet the needs of clients that support presented identifiers containing the wildcard character '*', we define a supplemental rule for so-called "wildcard certificates". Finally, we also specify the circumstances under which it is acceptable to check the "CN-ID" identifier type.
クライアントは、以下のルールに従って参照識別子のDNSドメイン名部分を照合しなければならず (MUST)（また、セクション6.5で説明されているようにアプリケーションサービスタイプも確認すべきです (SHOULD)）。ルールは、チェックされるドメインが「従来のドメイン名」か「国際化ドメイン名」かによって異なります（セクション1.4で定義）。
If the DNS domain name portion of a reference identifier is a "traditional domain name", then matching of the reference identifier against the presented identifier is performed by comparing the set of domain name labels using a case-insensitive ASCII comparison, as clarified by [DNS-CASE] (e.g., "WWW.Example.Com" would be lower-cased to "www.example.com" for comparison purposes). Each label MUST match in order for the names to be considered to match, except as supplemented by the rule about checking of wildcard labels (Section 6.4.3).
参照識別子のDNSドメイン名部分が「従来のドメイン名」である場合、提示された識別子に対する参照識別子の照合は、[DNS-CASE]に従って大文字小文字を区別しないASCII比較を使用してドメイン名ラベルのセットを比較することによって行われなければなりません (MUST)（例えば、比較の目的において "WWW.Example.Com" は "www.example.com" と等価です）。
If the DNS domain name portion of a reference identifier is an internationalized domain name, then an implementation MUST convert any U-labels [IDNA-DEFS] in the domain name to A-labels before checking the domain name. In accordance with [IDNA-PROTO], A-labels MUST be compared as case-insensitive ASCII. Each label MUST match in order for the domain names to be considered to match, except as supplemented by the rule about checking of wildcard labels (Section 6.4.3; but see also Section 7.2 regarding wildcards in internationalized domain names).
参照識別子のDNSドメイン名部分が国際化ドメイン名である場合、実装はドメイン名をチェックする前に、ドメイン名内のすべてのU-label [IDNA-DEFS] をA-labelに変換しなければなりません (MUST)。さらに、[IDNA-PROTO]に従って、A-labelは大文字小文字を区別しないASCIIとして比較されなければなりません (MUST)。各ラベルは独立して比較されなければならず (MUST)、ワイルドカードラベル（もしあれば）はセクション6.4.3で指定されたルールに従ってのみ検証されなければなりません (MUST)。
A client employing this specification's rules MAY match the reference identifier against a presented identifier whose DNS domain name portion contains the wildcard character '*' as part or all of a label (following the description of labels and domain names in [DNS-CONCEPTS]).
本仕様のルールを採用するクライアントは、DNSドメイン名部分にラベルの一部またはすべてとしてワイルドカード文字 '*' が含まれる提示された識別子と参照識別子を照合してもよいです (MAY)（[DNS-CONCEPTS]におけるラベルおよびドメイン名の説明に従います）。
For information regarding the security characteristics of wildcard certificates, see Section 7.2.
ワイルドカード証明書のセキュリティ特性に関する情報については、セクション7.2を参照してください。
If a client matches the reference identifier against a presented identifier whose DNS domain name portion contains the wildcard character '*', the following rules apply:
クライアントが、DNSドメイン名の部分にワイルドカード文字 '*'が含まれている提示された識別子に対して参照識別子を一致させる場合、次のルールが適用されます。
1. The client SHOULD NOT attempt to match a presented identifier in which the wildcard character comprises a label other than the left-most label (e.g., do not match bar.*.example.net).
1. クライアントは、ワイルドカード文字が左端のラベル以外のラベルを構成する提示された識別子を照合しようとすべきではありません (SHOULD NOT)（例えば、"bar.*.example.net" は照合しない）。
2. If the wildcard character is the only character of the left-most label in the presented identifier, the client SHOULD NOT compare against anything but the left-most label of the reference identifier (e.g., *.example.com would match foo.example.com but not bar.foo.example.com or example.com).
2. ワイルドカード文字が提示された識別子の左端のラベルの唯一の文字である場合、クライアントは参照識別子の左端のラベル以外のものと比較すべきではありません (SHOULD NOT)（例えば、"*.example.com" は "foo.example.com" に一致しますが、"bar.foo.example.com" や "example.com" には一致しません）。
3. The client MAY match a presented identifier in which the wildcard character is not the only character of the label (e.g., baz*.example.net and *baz.example.net and b*z.example.net would be taken to match baz1.example.net and foobaz.example.net and buzz.example.net, respectively). However, the client SHOULD NOT attempt to match a presented identifier where the wildcard character is embedded within an A-label or U-label [IDNA-DEFS] of an internationalized domain name [IDNA-PROTO].
3. クライアントは、ワイルドカード文字がラベルの唯一の文字ではない提示された識別子を照合してもよいですが (MAY)（例えば、"baz*.example.net" や "*baz.example.net"、"b*z.example.net" がそれぞれ "baz1.example.net"、"foobaz.example.net"、"buzz.example.net" に一致するとみなすなど）、クライアントはそのような識別子を照合しようとすべきではありません (SHOULD NOT)（付録Aで言及されているプロトコル仕様の調査から明らかなように、そのような部分的なワイルドカードのサポートに関する先行事例はほとんどないため）。
As noted, a client MUST NOT seek a match for a reference identifier of CN-ID if the presented identifiers include a DNS-ID, SRV-ID, URI-ID, or any application-specific identifier types supported by the client.
前述のとおり、提示された識別子にDNS-ID、SRV-ID、URI-ID、またはクライアントがサポートする任意のアプリケーション固有の識別子タイプが含まれている場合、クライアントはCN-IDの参照識別子の一致を求めてはなりません (MUST NOT)。
Therefore, if and only if the presented identifiers do not include a DNS-ID, SRV-ID, URI-ID, or any application-specific identifier types supported by the client, then the client MAY as a last resort check for a string whose form matches that of a fully qualified DNS domain name in a Common Name field of the subject field (i.e., a CN-ID). If the client chooses to compare a reference identifier of type CN-ID against that string, it MUST follow the comparison rules for the DNS domain name portion of an identifier of type DNS-ID, SRV-ID, or URI-ID, as described under Section 6.4.1, Section 6.4.2, and Section 6.4.3.
したがって、提示された識別子にDNS-ID、SRV-ID、URI-ID、またはクライアントがサポートする任意のアプリケーション固有の識別子タイプが含まれていない場合に限り、クライアントはSubjectフィールドのCommon Nameフィールド（すなわちCN-ID）内の完全修飾DNSドメイン名形式の文字列を参照識別子と照合してもよいです (MAY)。ただし、その場合でもクライアントはユーザーに警告すべきです (SHOULD)（セクション6.6.4を参照）。
When a client checks identifiers of type SRV-ID and URI-ID, it MUST check not only the DNS domain name portion of the identifier but also the application service type portion. The client does this by splitting the identifier into the DNS domain name portion and the application service type portion (as described under Section 6.3), then checking both the DNS domain name portion (as described under Section 6.4) and the application service type portion as described in the following subsections.
クライアントがSRV-IDおよびURI-IDタイプの識別子をチェックする場合、識別子のDNSドメイン名部分だけでなく、アプリケーションサービスタイプ部分もチェックしなければなりません (MUST)。識別子をDNSドメイン名部分とアプリケーションサービスタイプ部分（セクション6.3で説明）に分割し、DNSドメイン名部分を照合した後（セクション6.4で説明）、クライアントは以下のルールに従ってアプリケーションサービスタイプ部分を照合しなければなりません (MUST)。
Implementation Note: An identifier of type SRV-ID or URI-ID provides an application service type portion to be checked, but that portion is combined only with the DNS domain name portion of the SRV-ID or URI-ID itself. For example, if a client's list of reference identifiers includes an SRV-ID of "_xmpp-client.im.example.org" and a DNS-ID of "apps.example.net", the client would check (a) the combination of an application service type of "xmpp-client" and a DNS domain name of "im.example.org" and (b) a DNS domain name of "apps.example.net". However, the client would not check (c) the combination of an application service type of "xmpp-client" and a DNS domain name of "apps.example.net" because it does not have an SRV-ID of "_xmpp-client.apps.example.net" in its list of reference identifiers.
実装注：タイプSRV-IDまたはURI-IDの識別子は、チェックするアプリケーションサービスタイプの部分を提供しますが、その部分はSRV-IDまたはURI-ID自体のDNSドメイン名部分とのみ組み合わされます。たとえば、クライアントの参照識別子リストに「_xmpp-client.im.example.org」のSRV-IDが含まれている場合、「apps.example.net」のDNS-IDが含まれている場合、クライアントは（a）の組み合わせを確認します。「xmpp-client」のアプリケーションサービスタイプの「im.example.org」のDNSドメイン名と（b）「apps.example.net」のDNSドメイン名。ただし、クライアントは（c）「xmpp-client」のアプリケーションサービスタイプと「apps.example.net」のDNSドメイン名の組み合わせを確認しません。.apps.example.net "参照識別子のリストに。
The application service name portion of an SRV-ID (e.g., "imaps") MUST be matched in a case-insensitive manner, in accordance with [DNS-SRV]. Note that the "_" character is prepended to the service identifier in DNS SRV records and in SRV-IDs (per [SRVNAME]), and thus does not need to be included in any comparison.
SRV-IDのアプリケーションサービス名部分（例: "imaps"）は、[DNS-SRV]に従って大文字小文字を区別しない方法で照合しなければなりません (MUST)。DNS SRVレコードおよびSRV-ID（[SRVNAME]に従う）のサービス識別子には "_" 文字が先頭に付加されているため、比較に含める必要はないことに注意してください。
The scheme name portion of a URI-ID (e.g., "sip") MUST be matched in a case-insensitive manner, in accordance with [URI]. Note that the ":" character is a separator between the scheme name and the rest of the URI, and thus does not need to be included in any comparison.
URI-IDのスキーム名部分（例: "sip"）は、[URI]に従って大文字小文字を区別しない方法で照合しなければなりません (MUST)。":" 文字はスキーム名とURIの残りの部分の間の区切り文字であるため、比較に含める必要はないことに注意してください。
The outcome of the matching procedure is one of the following cases.
マッチング手順の結果は、次の場合の1つです。
If the client has found a presented identifier that matches a reference identifier, then the service identity check has succeeded. In this case, the client MUST use the matched reference identifier as the validated identity of the application service.
クライアントが参照識別子のいずれかに一致する提示された識別子を見つけた場合、サービスIDチェックは成功したとみなされます。その場合、クライアントは一致した参照識別子をアプリケーションサービスの検証済みIDとして使用しなければなりません (MUST)。
If the client does not find a presented identifier matching any of the reference identifiers but the client has previously pinned the application service's certificate to one of the reference identifiers in the list it constructed for this communication attempt (as "pinning" is explained under Section 1.8), and the presented certificate matches the pinned certificate (including the context as described under Section 7.1), then the service identity check has succeeded.
クライアントが参照識別子のいずれかを一致させる提示された識別子を見つけられないが、クライアントは以前にアプリケーションサービスの証明書をこの通信試行のために作成したリスト内の参照識別子のいずれかに固定したことがある場合（「ピン留め」はセクション1.8で説明されています。）、および提示された証明書は、ピン留め証明書（セクション7.1で説明されているコンテキストを含む）と一致し、サービスIDチェックが成功しました。
If the client does not find a presented identifier matching any of the reference identifiers and the client has not previously pinned the certificate to one of the reference identifiers in the list it constructed for this communication attempt, then the client MUST proceed as described under Section 6.6.4.
クライアントが参照識別子のいずれにも一致する提示された識別子を見つけられず、かつクライアントが今回の通信試行のために構築したリスト内の参照識別子のいずれにも証明書を以前に固定（ピン留め）していない場合、クライアントはセクション6.6.4で説明されているとおりに進めなければなりません (MUST)。
If the client is an interactive client that is directly controlled by a human user, then it SHOULD inform the user of the identity mismatch and automatically terminate the communication attempt with a bad certificate error; this behavior is preferable because it prevents users from inadvertently bypassing security protections in hostile situations.
クライアントが人間のユーザーによって直接制御される対話型クライアントである場合、ユーザーにIDの不一致を通知し、不正な証明書エラーで通信試行を自動的に終了すべきです (SHOULD)。この動作は、敵対的な状況においてユーザーが不注意でセキュリティ保護を回避することを防ぐため望ましいものです。
Security Warning: Some interactive clients give advanced users the option of proceeding with acceptance despite the identity mismatch, thereby "pinning" the certificate to one of the reference identifiers in the list constructed by the client for this communication attempt. Although this behavior can be appropriate in certain specialized circumstances, in general it ought to be exposed only to advanced users. Even then it needs to be handled with extreme caution, for example by first encouraging even an advanced user to terminate the communication attempt and, if the advanced user chooses to proceed anyway, by forcing the user to view the entire certification path and only then allowing the user to pin the certificate (on a temporary or permanent basis, at the user's option).
セキュリティ警告：一部のインタラクティブなクライアントには、アイデンティティの不一致にもかかわらず、高度なユーザーに受け入れを続けるオプションを提供し、それにより、この通信試行のためにクライアントが作成したリストの参照識別子の1つに証明書を「固定」します。この動作は特定の専門的な状況で適切である可能性がありますが、一般に、高度なユーザーにのみさらされるはずです。たとえば、最初に高度なユーザーでさえ通信試行を終了するように奨励することで、極端な注意を払って処理する必要があります。また、高度なユーザーがとにかく続行することを選択した場合、ユーザーに認証パス全体を表示し、その後のみを許可することによってのみ、ユーザーは証明書をピン留めします（ユーザーのオプションで一時的または永続的なベースで）。
Otherwise, if the client is an automated application not directly controlled by a human user, then it SHOULD terminate the communication attempt with a bad certificate error and log the error appropriately. An automated application MAY provide a configuration setting that disables this behavior, but MUST enable the behavior by default.
そうでない場合で、クライアントが人間のユーザーによって直接制御されていない自動化されたアプリケーションである場合、不正な証明書エラーで通信試行を終了し、エラーを適切にログに記録すべきです (SHOULD)。自動化されたアプリケーションは、この動作を無効にする設定オプションを提供してもよいですが (MAY)、デフォルトではその動作を有効にしなければなりません (MUST)。
As defined under Section 1.8, a certificate is said to be "pinned" to a DNS domain name when a user has explicitly chosen to associate a service's certificate with that DNS domain name despite the fact that the certificate contains some other DNS domain name (e.g., the user has explicitly approved "apps.example.net" as a domain associated with a source domain of "example.com"). The cached name association MUST take account of both the certificate presented and the context in which it was accepted or configured (where the "context" includes the chain of certificates from the presented certificate to the trust anchor, the source domain, the application service type, the service's derived domain and port number, and any other relevant information provided by the user or associated by the client).
セクション1.8で定義されているように、証明書に他のDNSドメイン名が含まれているという事実にもかかわらず、ユーザーがサービスの証明書をそのDNSドメイン名に関連付けることを明示的に選択した場合、証明書はそのDNSドメイン名に「固定（ピン留め）」されたと言われます（例えば、ユーザーが "example.com" のソースドメインに関連付けられたドメインとして "apps.example.net" を明示的に承認した場合など）。キャッシュされた名前の関連付けは、提示された証明書と、それが受け入れられたまたは設定されたコンテキストの両方を考慮しなければなりません (MUST)（ここで「コンテキスト」には、提示された証明書からトラストアンカーへの証明書チェーン、ソースドメイン、アプリケーションサービスタイプ、サービスの派生ドメインおよびポート番号、ならびにユーザーによって提供されたかクライアントによって関連付けられたその他の関連情報が含まれます）。
This document states that the wildcard character '*' SHOULD NOT be included in presented identifiers but MAY be checked by application clients (mainly for the sake of backward compatibility with deployed infrastructure). As a result, the rules provided in this document are more restrictive than the rules for many existing application technologies (such as those excerpted under Appendix B). Several security considerations justify tightening the rules:
本ドキュメントでは、ワイルドカード文字 '*' は提示される識別子に含まれるべきではないが (SHOULD NOT)、アプリケーションクライアントによってチェックされてもよい (MAY)（主に展開済みインフラストラクチャとの後方互換性のため）と述べています。その結果、本ドキュメントで提供されるルールは、多くの既存のアプリケーション技術のルール（付録Bで抜粋されているものなど）よりも厳格になっています。いくつかのセキュリティ上の考慮事項がルールの厳格化を正当化します:
o Wildcard certificates automatically vouch for any and all host names within their domain. This can be convenient for administrators but also poses the risk of vouching for rogue or buggy hosts. See for example [Defeating-SSL] (beginning at slide 91) and [HTTPSbytes] (slides 38-40).
o WildCard証明書は、ドメイン内のすべてのホスト名を自動的に保証します。これは管理者にとって便利ですが、不正なホストやバギーのホストを保証するリスクももたらします。たとえば、[SSLを倒す]（スライド91から始まる）および[httpsbytes]（スライド38-40）を参照してください。
o Specifications for existing application technologies are not clear or consistent about the allowable location of the wildcard character, such as whether it can be:
o 既存のアプリケーションテクノロジーの仕様は、WildCard文字の許容場所について明確または一貫していません。
* only the complete left-most label (e.g., *.example.com)
* 完全な左のラベルのみ（例： *.example.com）
* some fragment of the left-most label (e.g., fo*.example.com, f*o.example.com, or *oo.example.com)
* 左端のラベルのいくつかの断片（例：fo*.example.com、f*o.example.com、または*oo.example.com）
* all or part of a label other than the left-most label (e.g., www.*.example.com or www.foo*.example.com)
* 左端のラベル以外のラベルのすべてまたは一部（例：www。*。example.comまたはwww.foo*.example.com）
* all or part of a label that identifies a so-called "public suffix" (e.g., *.co.uk or *.com)
* いわゆる「パブリックサフィックス」を識別するラベルのすべてまたは一部（例： *.co.ukまたは *.com）
* included more than once in a given label (e.g., f*b*r.example.com
* 与えられたラベルに複数回含まれています（例：f*b*r.example.com
* included as all or part of more than one label (e.g., *.*.example.com)
* 複数のラベルのすべてまたは一部として含まれています（例えば、 *。 *。example.com）
These ambiguities might introduce exploitable differences in identity checking behavior among client implementations and necessitate overly complex and inefficient identity checking algorithms.
これらのあいまいさは、クライアントの実装間でアイデンティティチェック動作に悪用可能な違いをもたらし、過度に複雑で非効率的なアイデンティティチェックアルゴリズムを必要とする可能性があります。
o There is no specification that defines how the wildcard character may be embedded within the A-labels or U-labels [IDNA-DEFS] of an internationalized domain name [IDNA-PROTO]; as a result, implementations are strongly discouraged from including or attempting to check for the wildcard character embedded within the A-labels or U-labels of an internationalized domain name (e.g., "xn--kcry6tjko*.example.org"). Note, however, that a presented domain name identifier MAY contain the wildcard character as long as that character occupies the entire left-most label position, where all of the remaining labels are valid NR-LDH labels, A-labels, or U-labels (e.g., "*.xn--kcry6tjko.example.org").
o 国際化ドメイン名 [IDNA-PROTO] のA-labelまたはU-label [IDNA-DEFS] 内にワイルドカード文字をどのように埋め込むかを定義する仕様はありません。その結果、実装が国際化ドメイン名のA-labelまたはU-label内に埋め込まれたワイルドカード文字を含めたりチェックしようとしたりすることは強く非推奨とされます（例えば "xn--kcry6tjko*.example.org" など）。ただし、提示されたドメイン名識別子は、その文字が完全な左端のラベル位置を占め、残りのラベルがすべて有効なNR-LDHラベル、A-label、またはU-labelである限り、ワイルドカード文字を含めてもよいことに注意してください (MAY)（例えば "*.xn--kcry6tjko.example.org" など）。
Notwithstanding the foregoing security considerations, specifications that reuse this one can legitimately encourage continued support for the wildcard character if they have good reasons to do so, such as backward compatibility with deployed infrastructure (see, for example, [EV-CERTS]).
前述のセキュリティ上の考慮事項にもかかわらず、これを再利用する仕様は、展開されたインフラストラクチャとの後方互換性など、それを行う正当な理由がある場合、ワイルドカードキャラクターの継続的なサポートを合法的に促進できます（たとえば、[EVCerts]を参照）。
Allowing internationalized domain names can lead to the inclusion of visually similar (so-called "confusable") characters in certificates; for discussion, see for example [IDNA-DEFS].
国際化されたドメイン名を許可すると、証明書に視覚的に類似した（いわゆる「混乱できる」）文字を含めることができます。ディスカッションについては、たとえば[idna-defs]を参照してください。
A given application service might be addressed by multiple DNS domain names for a variety of reasons, and a given deployment might service multiple domains (e.g., in so-called "virtual hosting" environments). In the default TLS handshake exchange, the client is not able to indicate the DNS domain name with which it wants to communicate, and the TLS server returns only one certificate for itself. Absent an extension to TLS, a typical workaround used to facilitate mapping an application service to multiple DNS domain names is to embed all of the domain names into a single certificate.
特定のアプリケーションサービスは、さまざまな理由で複数のDNSドメイン名で対処される場合があり、特定の展開は複数のドメイン（いわゆる「仮想ホスティング」環境など）にサービスを提供する場合があります。デフォルトのTLSハンドシェイク交換では、クライアントは通信したいDNSドメイン名を示すことができず、TLSサーバーはそれ自体に対して1つの証明書のみを返します。TLSの拡張機能がなければ、アプリケーションサービスを複数のDNSドメイン名にマッピングするために使用される典型的な回避策は、すべてのドメイン名を単一の証明書に埋め込むことです。
A more recent approach, formally specified in [TLS-EXT], is for the client to use the TLS "Server Name Indication" (SNI) extension when sending the client_hello message, stipulating the DNS domain name it desires or expects of the service. The service can then return the appropriate certificate in its Certificate message, and that certificate can represent a single DNS domain name.
[TLS-Ext]で正式に指定されている最近のアプローチは、クライアント_Helloメッセージを送信するときにクライアントがTLS「サーバー名表示」（SNI）拡張機能を使用し、サービスに望むまたは期待するDNSドメイン名を規定することです。サービスは、証明書メッセージに適切な証明書を返すことができ、その証明書は単一のDNSドメイン名を表すことができます。
To accommodate the workaround that was needed before the development of the SNI extension, this specification allows multiple DNS-IDs, SRV-IDs, or URI-IDs in a certificate; however, it explicitly discourages multiple CN-IDs. Although it would be preferable to forbid multiple CN-IDs entirely, there are several reasons at this time why this specification states that they SHOULD NOT (instead of MUST NOT) be included:
SNI拡張の開発前に必要であった回避策に対応するため、本仕様は証明書内の複数のDNS-ID、SRV-ID、またはURI-IDを許可します。ただし、複数のCN-IDは明示的に非推奨とします。複数のCN-IDを完全に禁止することが望ましいですが、現時点で本仕様がそれらを含めるべきではない (SHOULD NOT)（含めてはならない (MUST NOT) ではなく）と述べている理由はいくつかあります:
o At least one significant technology community of interest explicitly allows multiple CN-IDs [EV-CERTS].
o 関心のある少なくとも1つの重要な技術コミュニティにより、複数のCN-IDが明示的に許可されています[EV-Certs]。
o At least one significant certification authority is known to issue certificates containing multiple CN-IDs.
o 少なくとも1つの重要な認証機関が、複数のCN-IDを含む証明書を発行することが知られています。
o Many service providers often deem inclusion of multiple CN-IDs necessary in virtual hosting environments because at least one widely deployed operating system does not yet support the SNI extension.
o 多くのサービスプロバイダーは、少なくとも1つの広く展開されているオペレーティングシステムがまだSNI拡張をサポートしていないため、仮想ホスティング環境に必要な複数のCN-IDを含めることが多いことがよくあります。
It is hoped that the recommendation regarding multiple CN-IDs can be further tightened in the future.
複数のCN-IDに関する推奨事項が将来さらに強化できることが期待されています。
The following individuals made important contributions to the text of this document: Shumon Huque, RL 'Bob' Morgan, and Kurt Zeilenga.
次の個人は、この文書のテキストに重要な貢献をしました：Shumon Huque、RL 'Bob' Morgan、およびKurt Zeilenga。
The editors and contributors wish to thank the following individuals for their feedback and suggestions: Bernard Aboba, Richard Barnes, Uri Blumenthal, Nelson Bolyard, Kaspar Brand, Anthony Bryan, Scott Cantor, Wan-Teh Chang, Bil Corry, Dave Cridland, Dave Crocker, Cyrus Daboo, Charles Gardiner, Philip Guenther, Phillip Hallam-Baker, Bruno Harbulot, Wes Hardaker, David Harrington, Paul Hoffman, Love Hornquist Astrand, Henry Hotz, Russ Housley, Jeffrey Hutzelman, Cullen Jennings, Simon Josefsson, Geoff Keating, John Klensin, Scott Lawrence, Matt McCutchen, Alexey Melnikov, Subramanian Moonesamy, Eddy Nigg, Ludwig Nussel, Joe Orton, Tom Petch, Yngve N. Pettersen, Tim Polk, Robert Relyea, Eric Rescorla, Pete Resnick, Martin Rex, Joe Salowey, Stefan Santesson, Jim Schaad, Rob Stradling, Michael Stroeder, Andrew Sullivan, Peter Sylvester, Martin Thomson, Paul Tiemann, Sean Turner, Nicolas Williams, Dan Wing, Dan Winship, and Stefan Winter.
編集者と貢献者は、ベルナード・アボバ、リチャード・バーンズ、ウリ・ブルーメンタル、ネルソン・ボリヤード、カスパー・ブランド、アンソニー・ブライアン、スコット・カンター、ワン・テー・チャン、ビル・コリー、デイブ・クリッドランド、デイブ・クロッカーランド、デイブ・クロッカーランド、デイブ・クロッカーランド、次の個人にフィードバックと提案に感謝したいと考えています。、Cyrus Daboo、Charles Gardiner、Philip Guenther、Phillip Hallam-Baker、Bruno Harbulot、Wes Hardaker、David Harrington、Paul Hoffman、Love Hornquist Astrand、Henry Hotz、Russ Housley、Jeffrey Hutzelman、Cullen Jonnings、Simon Josefssfs、Jeoff keating、Johofクレンシン、スコット・ローレンス、マット・マッカッチェン、アレクセイ・メルニコフ、スブラマニアン・ムーネミー、エディ・ニグ、ルートヴィヒ・ヌッセル、ジョー・オートン、トム・ペッチ、イヌヴェ・ペティターセン、ティム・ポーク、ロバート・レリエイ、エリック・レスカルサンテッソン、ジム・シャード、ロブ・ストラドリング、マイケル・ストロダー、アンドリュー・サリバン、ピーター・シルベスター、マーティン・トムソン、ポール・ティマン、ショーン・ターナー、ニコラス・ウィリアムズ、ダン・ウィング、ダン・ウィンシップ、ステファン・ウィンター。
Thanks also to Barry Leiba and Ben Campbell for their reviews on behalf of the Security Directorate and the General Area Review Team, respectively.
また、セキュリティ局と一般的なレビューチームに代わってレビューをしてくれたBarry LeibaとBen Campbellにも感謝します。
The responsible Area Director was Alexey Melnikov.
責任ある地域のディレクターはアレクセイ・メルニコフでした。
[DNS-CONCEPTS] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.
[DNS-CONCEPTS] Mockapetris, P.、「ドメイン名 - 概念と施設」、STD 13、RFC 1034、1987年11月。
[DNS-SRV] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000.
[DNS-SRV] Gulbrandsen, A., Vixie, P., and L. Esibov、「サービスの場所を指定するためのDNS RR（DNS SRV）」、RFC 2782、2000年2月。
[IDNA-DEFS] Klensin, J., "Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework", RFC 5890, August 2010.
[IDNA-DEFS] Klensin, J.、「アプリケーションの国際化ドメイン名（IDNA）：定義とドキュメントフレームワーク」、RFC 5890、2010年8月。
[IDNA-PROTO] Klensin, J., "Internationalized Domain Names in Applications (IDNA): Protocol", RFC 5891, August 2010.
[IDNA-PROTO] Klensin, J.、「アプリケーションの国際化ドメイン名（IDNA）：プロトコル」、RFC 5891、2010年8月。
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[KEYWORDS] Bradner, S.、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[LDAP-DN] Zeilenga, K., Ed., "Lightweight Directory Access Protocol (LDAP): String Representation of Distinguished Names", RFC 4514, June 2006.
[LDAP-DN] Zeilenga, K., Ed.、「Lightweight Directory Access Protocol（LDAP）：著名な名前の文字列表現」、RFC 4514、2006年6月。
[PKIX] 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.
[PKIX] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk、「Internet X.509公開キーインフラストラクチャ証明書および証明書取消リスト（CRL）プロファイル"、RFC 5280、2008年5月。
[SRVNAME] Santesson, S., "Internet X.509 Public Key Infrastructure Subject Alternative Name for Expression of Service Name", RFC 4985, August 2007.
[SRVNAME] Santesson, S.、「インターネットX.509公開キーインフラストラクチャの主題サービス名の表現の代替名」、RFC 4985、2007年8月。
[URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[URI] Berners-Lee, T., Fielding, R., and L. Masinter、「Uniform Resource Identifier（URI）：Generic Syntax」、Std 66、RFC 3986、2005年1月。
[ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[ABNF] Crocker, D., Ed. and P. Overell、「構文仕様のためのBNFの増強：ABNF」、STD 68、RFC 5234、2008年1月。
[DNS-CASE] Eastlake 3rd, D., "Domain Name System (DNS) Case Insensitivity Clarification", RFC 4343, January 2006.
[DNS-CASE] Eastlake 3rd, D.、「ドメイン名システム（DNS）ケースの無感覚の明確化」、RFC 4343、2006年1月。
[DNSSEC] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005.
[DNSSEC] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose、「DNSセキュリティの紹介と要件」、RFC 4033、2005年3月。
[DTLS] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security", RFC 4347, April 2006.
[DTLS] Rescorla, E. and N. Modadugu、「Datagram Transport Layer Security」、RFC 4347、2006年4月。
[Defeating-SSL] Marlinspike, M., "New Tricks for Defeating SSL in Practice", BlackHat DC, February 2009, <http://www.blackhat.com/presentations/ bh-dc-09/Marlinspike/ BlackHat-DC-09-Marlinspike-Defeating-SSL.pdf>.
[Defeating-SSL] Marlinspike, M.、「実際にSSLを倒すための新しいトリック」、ブラックハットDC、2009年2月、<http://www.blackhat.com/presentations/bh-dc-09/Marlinspike/BlackHat-DC-09-Marlinspike-Defeating-SSL.pdf>。
[EMAIL-SRV] Daboo, C., "Use of SRV Records for Locating Email Submission/Access Services", RFC 6186, March 2011.
[EMAIL-SRV] Daboo, C.、「電子メールの提出/アクセスサービスを見つけるためのSRVレコードの使用」、RFC 6186、2011年3月。
[EV-CERTS] CA/Browser Forum, "Guidelines For The Issuance And Management Of Extended Validation Certificates", October 2009, <http://www.cabforum.org/Guidelines_v1_2.pdf>.
[EV-CERTS] CA/Browser Forum、「拡張検証証明書の発行と管理のガイドライン」、2009年10月、<http://www.cabforum.org/Guidelines_v1_2.pdf>。
[GIST] Schulzrinne, H. and R. Hancock, "GIST: General Internet Signalling Transport", RFC 5971, October 2010.
[GIST] Schulzrinne, H. and R. Hancock、「Gist：General Internet Signaling Transport」、RFC 5971、2010年10月。
[HTTP] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[HTTP] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee、「HyperText Transfer Protocol-HTTP/1.1」、RFC 2616、1999年6月。
[HTTP-TLS] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[HTTP-TLS] Rescorla, E.、「TLS上のHTTP」、RFC 2818、2000年5月。
[HTTPSbytes] Sokol, J. and R. Hansen, "HTTPS Can Byte Me", BlackHat Abu Dhabi, November 2010, <https://media.blackhat.com/bh-ad-10/Hansen/ Blackhat-AD-2010-Hansen-Sokol-HTTPS-Can-Byte-Me-slides.pdf>.
[HTTPSbytes] Sokol, J. and R. Hansen, "HTTPS Can Byte Me", BlackHat Abu Dhabi, November 2010, <https://media.blackhat.com/bh-ad-10/Hansen/Blackhat-AD-2010-Hansen-Sokol-HTTPS-Can-Byte-Me-slides.pdf>.
[IDNA2003] Faltstrom, P., Hoffman, P., and A. Costello, "Internationalizing Domain Names in Applications (IDNA)", RFC 3490, March 2003.
[IDNA2003] Faltstrom, P., Hoffman, P., and A. Costello、「アプリケーションの国際化ドメイン名（IDNA）」、RFC 3490、2003年3月。
[IMAP] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, March 2003.
[IMAP] Crispin, M.、「インターネットメッセージアクセスプロトコル -バージョン4REV1」、RFC 3501、2003年3月。
[IP] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[IP] Postel, J.、「インターネットプロトコル」、STD 5、RFC 791、1981年9月。
[IPSEC] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[IPSEC] Kent, S. and K. Seo、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 4301、2005年12月。
[IPv6] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[IPv6] Deering, S. and R. Hinden、「Internet Protocol、バージョン6（IPv6）仕様」、RFC 2460、1998年12月。
[LDAP] Sermersheim, J., "Lightweight Directory Access Protocol (LDAP): The Protocol", RFC 4511, June 2006.
[LDAP] Sermersheim, J.、「Lightweight Directory Access Protocol（LDAP）：The Protocol」、RFC 4511、2006年6月。
[LDAP-AUTH] Harrison, R., "Lightweight Directory Access Protocol (LDAP): Authentication Methods and Security Mechanisms", RFC 4513, June 2006.
[LDAP-AUTH] Harrison, R.、「Lightweight Directory Access Protocol（LDAP）：認証方法とセキュリティメカニズム」、RFC 4513、2006年6月。
[LDAP-SCHEMA] Sciberras, A., Ed., "Lightweight Directory Access Protocol (LDAP): Schema for User Applications", RFC 4519, June 2006.
[LDAP-SCHEMA] Sciberras, A., Ed.、「Lightweight Directory Access Protocol（LDAP）：ユーザーアプリケーションのスキーマ」、RFC 4519、2006年6月。
[LDAP-TLS] Hodges, J., Morgan, R., and M. Wahl, "Lightweight Directory Access Protocol (v3): Extension for Transport Layer Security", RFC 2830, May 2000.
[LDAP-TLS] Hodges, J., Morgan, R., and M. Wahl、「Lightweight Directory Access Protocol（V3）：輸送層のセキュリティの拡張」、RFC 2830、2000年5月。
[NAPTR] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Three: The Domain Name System (DNS) Database", RFC 3403, October 2002.
[NAPTR] Mealling, M.、「動的委任発見システム（DDDS）パート3：ドメイン名システム（DNS）データベース」、RFC 3403、2002年10月。
[NETCONF] Enns, R., Ed., "NETCONF Configuration Protocol", RFC 4741, December 2006.
[NETCONF] Enns, R., Ed.、「NetConf Configuration Protocol」、RFC 4741、2006年12月。
[NETCONF-SSH] Wasserman, M. and T. Goddard, "Using the NETCONF Configuration Protocol over Secure SHell (SSH)", RFC 4742, December 2006.
[NETCONF-SSH] Wasserman, M. and T. Goddard、「Secure Shell（SSH）を介したNetConf構成プロトコルを使用」、RFC 4742、2006年12月。
[NETCONF-TLS] Badra, M., "NETCONF over Transport Layer Security (TLS)", RFC 5539, May 2009.
[NETCONF-TLS] Badra, M.、「NetConf Over Transport Layer Security（TLS）」、RFC 5539、2009年5月。
[NNTP] Feather, C., "Network News Transfer Protocol (NNTP)", RFC 3977, October 2006.
[NNTP] Feather, C.、「ネットワークニュース転送プロトコル（NNTP）」、RFC 3977、2006年10月。
[NNTP-TLS] Murchison, K., Vinocur, J., and C. Newman, "Using Transport Layer Security (TLS) with Network News Transfer Protocol (NNTP)", RFC 4642, October 2006.
[NNTP-TLS] Murchison, K., Vinocur, J., and C. Newman、「Network News Transfer Protocol（NNTP）を使用したTransport Layer Security（TLS）を使用」、RFC 4642、2006年10月。
[OCSP] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. Adams, "X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP", RFC 2560, June 1999.
[OCSP] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. Adams、「X.509インターネット公開キーインフラストラクチャオンライン証明書ステータスプロトコル」、RFC 2560、1999年6月。
[OPENPGP] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. Thayer, "OpenPGP Message Format", RFC 4880, November 2007.
[OPENPGP] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. Thayer、「OpenPGPメッセージ形式」、RFC 4880、2007年11月。
[PKIX-OLD] Housley, R., Ford, W., Polk, T., and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and CRL Profile", RFC 2459, January 1999.
[PKIX-OLD] Housley, R., Ford, W., Polk, T., and D. Solo、「インターネットX.509公開キーインフラストラクチャ証明書とCRLプロファイル」、RFC 2459、1999年1月。
[POP3] Myers, J. and M. Rose, "Post Office Protocol - Version 3", STD 53, RFC 1939, May 1996.
[POP3] Myers, J. and M. Rose、「郵便局プロトコル - バージョン3」、STD 53、RFC 1939、1996年5月。
[PRIVATE] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996.
[PRIVATE] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear、「Private Internetsのアドレス割り当て」、BCP 5、RFC 1918、1996年2月。
[S-NAPTR] Daigle, L. and A. Newton, "Domain-Based Application Service Location Using SRV RRs and the Dynamic Delegation Discovery Service (DDDS)", RFC 3958, January 2005.
[S-NAPTR] Daigle, L. and A. Newton、「SRV RRSおよびDynamic Derigation Discovery Service（DDDS）を使用したドメインベースのアプリケーションサービスの場所」、RFC 3958、2005年1月。
[SECTERMS] Shirey, R., "Internet Security Glossary, Version 2", RFC 4949, August 2007.
[SECTERMS] Shirey, R.、「インターネットセキュリティ用語集、バージョン2」、RFC 4949、2007年8月。
[SIP] 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.
[SIP] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler、「SIP：SESSION INTIATION Protocol」、RFC 3261、2002年6月。
[SIP-CERTS] Gurbani, V., Lawrence, S., and A. Jeffrey, "Domain Certificates in the Session Initiation Protocol (SIP)", RFC 5922, June 2010.
[SIP-CERTS] Gurbani, V., Lawrence, S., and A. Jeffrey、「セッション開始プロトコル（SIP）のドメイン証明書」、RFC 5922、2010年6月。
[SIP-SIPS] Audet, F., "The Use of the SIPS URI Scheme in the Session Initiation Protocol (SIP)", RFC 5630, October 2009.
[SIP-SIPS] Audet, F.、「セッション開始プロトコル（SIP）でのSIPS URIスキームの使用」、RFC 5630、2009年10月。
[SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, October 2008.
[SMTP] Klensin, J.、「Simple Mail Transfer Protocol」、RFC 5321、2008年10月。
[SMTP-AUTH] Siemborski, R., Ed. and A. Melnikov, Ed., "SMTP Service Extension for Authentication", RFC 4954, July 2007.
[SMTP-AUTH] Siemborski, R., Ed. and A. Melnikov, Ed.、「認証のためのSMTPサービス拡張」、RFC 4954、2007年7月。
[SMTP-TLS] Hoffman, P., "SMTP Service Extension for Secure SMTP over Transport Layer Security", RFC 3207, February 2002.
[SMTP-TLS] Hoffman, P.、「輸送層セキュリティ上の安全なSMTPのSMTPサービス拡張」、RFC 3207、2002年2月。
[SNMP] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, December 2002.
[SNMP] Harrington, D., Presuhn, R., and B. Wijnen、「単純なネットワーク管理プロトコル（SNMP）管理フレームワークを説明するためのアーキテクチャ」、STD 62、RFC 3411、2002年12月。
[SNMP-TLS] Hardaker, W., "Transport Layer Security (TLS) Transport Model for the Simple Network Management Protocol (SNMP)", RFC 5953, August 2010.
[SNMP-TLS] Hardaker, W.、「シンプルネットワーク管理プロトコル（SNMP）の輸送層セキュリティ（TLS）輸送モデル」、RFC 5953、2010年8月。
[SYSLOG] Gerhards, R., "The Syslog Protocol", RFC 5424, March 2009.
[SYSLOG] Gerhards, R.、「Syslog Protocol」、RFC 5424、2009年3月。
[SYSLOG-DTLS] Salowey, J., Petch, T., Gerhards, R., and H. Feng, "Datagram Transport Layer Security (DTLS) Transport Mapping for Syslog", RFC 6012, October 2010.
[SYSLOG-DTLS] Salowey, J., Petch, T., Gerhards, R., and H. Feng、「Syslog用のデータグラム輸送層セキュリティ（DTLS）輸送マッピング」、RFC 6012、2010年10月。
[SYSLOG-TLS] Miao, F., Ed., Ma, Y., Ed., and J. Salowey, Ed., "Transport Layer Security (TLS) Transport Mapping for Syslog", RFC 5425, March 2009.
[SYSLOG-TLS] Miao, F., Ed., Ma, Y., Ed., and J. Salowey, Ed.、「輸送層セキュリティ（TLS）Syslog用輸送マッピング」、RFC 5425、2009年3月。
[TLS] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[TLS] Dierks, T. and E. Rescorla、「The Transport Layer Security（TLS）Protocolバージョン1.2」、RFC 5246、2008年8月。
[TLS-EXT] Eastlake 3rd, D., "Transport Layer Security (TLS) Extensions: Extension Definitions", RFC 6066, January 2011.
[TLS-EXT] Eastlake 3rd, D.、「輸送層セキュリティ（TLS）拡張：拡張定義」、RFC 6066、2011年1月。
[US-ASCII] American National Standards Institute, "Coded Character Set - 7-bit American Standard Code for Information Interchange", ANSI X3.4, 1986.
[US-ASCII] American National Standards Institute、「コード化された文字セット-7ビットの情報インターチェンジのためのアメリカ標準コード」、ANSI X3.4、1986。
[USINGTLS] Newman, C., "Using TLS with IMAP, POP3 and ACAP", RFC 2595, June 1999.
[USINGTLS] Newman, C.、「IMAP、POP3およびACAPでTLSを使用」、RFC 2595、1999年6月。
[WSC-UI] Saldhana, A. and T. Roessler, "Web Security Context: User Interface Guidelines", World Wide Web Consortium LastCall WD-wsc-ui-20100309, March 2010, <http://www.w3.org/TR/2010/WD-wsc-ui-20100309>.
[WSC-UI] Saldhana, A. and T. Roessler、「Webセキュリティコンテキスト：ユーザーインターフェイスガイドライン」、World Wide Web Consortium LastCall WD-WSC-UI-20100309、2010年3月、<http://www.w3.org/TR/2010/WD-wsc-ui-20100309>。
[X.500] International Telecommunications Union, "Information Technology - Open Systems Interconnection - The Directory: Overview of concepts, models and services", ITU-T Recommendation X.500, ISO Standard 9594-1, August 2005.
[X.500] International Telecommunications Union、「情報技術 - オープンシステムの相互接続 - ディレクトリ：概念、モデル、サービスの概要」、ITU -T推奨X.500、ISO Standard 9594-1、2005年8月。
[X.501] International Telecommunications Union, "Information Technology - Open Systems Interconnection - The Directory: Models", ITU-T Recommendation X.501, ISO Standard 9594-2, August 2005.
[X.501] International Telecommunications Union、「情報技術 - オープンシステムの相互接続 - ディレクトリ：モデル」、ITU -T推奨X.501、ISO Standard 9594-2、2005年8月。
[X.509] 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, August 2005.
[X.509] International Telecommunications Union、「情報技術 - オープンシステムの相互接続 - ディレクトリ：パブリックキーおよび属性証明書フレームワーク」、ITU-T推奨X.509、ISO Standard 9594-8、2005年8月。
[X.520] International Telecommunications Union, "Information Technology - Open Systems Interconnection - The Directory: Selected attribute types", ITU-T Recommendation X.509, ISO Standard 9594-6, August 2005.
[X.520] International Telecommunications Union、「情報技術 - オープンシステムの相互接続 - ディレクトリ：選択された属性タイプ」、ITU -T推奨X.509、ISO Standard 9594-6、2005年8月。
[X.690] International Telecommunications Union, "Information Technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)", ITU-T Recommendation X.690, ISO Standard 8825-1, August 2008.
[X.690] International Telecommunications Union、「情報技術-ASN.1エンコーディングルール：基本エンコードルール（BER）、標準エンコードルール（CER）および識別済みエンコードルール（DER）の仕様」、ITU -T推奨X.690、ISO Standard 8825-1、2008年8月。
[XMPP] Saint-Andre, P., "Extensible Messaging and Presence Protocol (XMPP): Core", RFC 6120, March 2011.
[XMPP] Saint-Andre, P.、「拡張可能なメッセージと存在プロトコル（XMPP）：Core」、RFC 6120、2011年3月。
[XMPP-OLD] Saint-Andre, P., Ed., "Extensible Messaging and Presence Protocol (XMPP): Core", RFC 3920, October 2004.
[XMPP-OLD] Saint-Andre, P., Ed.、「Extensibleメッセージングとプレゼンスプロトコル（XMPP）：Core」、RFC 3920、2004年10月。
At the time of this writing, two application technologies reuse the recommendations in this specification: email [EMAIL-SRV] and XMPP [XMPP]. Here we include the text from [XMPP] to illustrate the thought process that might be followed by protocol designers for other application technologies. Specifically, because XMPP uses DNS SRV records for resolution of the DNS domain names for application services, the XMPP specification recommends the use of SRV-IDs.
この執筆時点では、2つのアプリケーションテクノロジーがこの仕様の推奨事項を再利用します：電子メール[電子メール-SRV]とXMPP [XMPP]。ここには、[XMPP]のテキストを含めて、他のアプリケーションテクノロジーのプロトコル設計者が従う可能性のある思考プロセスを説明します。具体的には、XMPPはアプリケーションサービスのDNSドメイン名の解決にDNS SRVレコードを使用するため、XMPP仕様はSRV-IDの使用を推奨します。
The text regarding certificate issuance is as follows:
証明書発行に関するテキストは次のとおりです。
######
In a PKIX certificate to be presented by an XMPP server (i.e., a "server certificate"), the certificate MUST include one or more XMPP addresses (i.e., domainparts) associated with XMPP services hosted at the server. The rules and guidelines defined in [this specification] apply to XMPP server certificates, with the following XMPP-specific considerations:
XMPPサーバーによって提示されるPKIX証明書（すなわち「サーバー証明書」）において、証明書には、サーバー上でホストされているXMPPサービスに関連付けられた1つ以上のXMPPアドレス（すなわちdomainpart）を含めなければなりません (MUST)。[本仕様]で定義されているルールとガイドラインがXMPPサーバー証明書に適用され、以下の例外と追加事項があります。
o Support for the DNS-ID identifier type [PKIX] is REQUIRED in XMPP client and server software implementations. Certification authorities that issue XMPP-specific certificates MUST support the DNS-ID identifier type. XMPP service providers SHOULD include the DNS-ID identifier type in certificate requests.
o DNS-ID識別子タイプ [PKIX] のサポートは、XMPPクライアントおよびサーバーソフトウェアの実装において要求されます (REQUIRED)。XMPP固有の証明書を発行する認証機関は、DNS-ID識別子タイプをサポートしなければなりません (MUST)。XMPPサービスプロバイダーは、証明書リクエストにDNS-ID識別子タイプを含めるべきです (SHOULD)。
o Support for the SRV-ID identifier type [SRVNAME] is REQUIRED for XMPP client and server software implementations (for verification purposes XMPP client implementations need to support only the "_xmpp-client" application service type, whereas XMPP server implementations need to support both the "_xmpp-client" and "_xmpp-server" application service types). Certification authorities that issue XMPP-specific certificates SHOULD support the SRV-ID identifier type. XMPP service providers SHOULD include the SRV-ID identifier type in certificate requests.
o SRV-ID識別子タイプ [SRVNAME] のサポートは、XMPPクライアントおよびサーバーソフトウェアの実装に要求されます (REQUIRED)（検証目的のため、XMPPクライアント実装は "_xmpp-client" アプリケーションサービスタイプのみをサポートすべきですが (SHOULD)、XMPPサーバー実装は "_xmpp-client" と "_xmpp-server" の両方のアプリケーションサービスタイプをサポートすべきです (SHOULD)）。認証機関は、XMPP固有の証明書を発行する際にSRV-ID識別子タイプをサポートすべきです (SHOULD)。XMPPサービスプロバイダーは、証明書リクエストにSRV-ID識別子タイプを含めるべきです (SHOULD)。
o Support for the XmppAddr identifier type is encouraged in XMPP client and server software implementations for the sake of backward-compatibility, but is no longer encouraged in certificates issued by certification authorities or requested by XMPP service providers.
o XmppAddr識別子タイプのサポートは、XMPPクライアントおよびサーバーソフトウェアの実装では、後方互換性のために推奨されますが、認証当局が発行した証明書ではXMPPサービスプロバイダーから要求された証明書では奨励されていません。
o DNS domain names in server certificates MAY contain the wildcard character '*' as the complete left-most label within the identifier.
o サーバー証明書内のDNSドメイン名には、識別子内の完全な左端ラベルとしてワイルドカード文字 '*' を含めてもよいです (MAY)。
###### The text regarding certificate verification is as follows:
######証明書の確認に関するテキストは次のとおりです。
######
For server certificates, the rules and guidelines defined in [this specification] apply, with the proviso that the XmppAddr identifier is allowed as a reference identifier.
サーバー証明書の場合、[この仕様]で定義されているルールとガイドラインが適用され、XmppAddr識別子が参照識別子として許可されるという条件が付いています。
The identities to be checked are set as follows:
チェックされるアイデンティティは次のように設定されています。
o The initiating entity sets its reference identifier to the 'to' address it communicates in the initial stream header; i.e., this is the identity it expects the receiving entity to provide in a PKIX certificate.
o 開始エンティティは、初期ストリームヘッダーで通信する「to」アドレスに基準識別子を設定します。つまり、これは受信エンティティがPKIX証明書で提供することを期待するアイデンティティです。
o The receiving entity sets its reference identifier to the 'from' address communicated by the initiating entity in the initial stream header; i.e., this is the identity that the initiating entity is trying to assert.
o 受信エンティティは、初期ストリームヘッダーの開始エンティティによって伝達された「From」アドレスに参照識別子を設定します。つまり、これは開始エンティティが主張しようとしているアイデンティティです。
######
(This section is non-normative.)
（このセクションは非規範的です。）
The recommendations in this document are an abstraction from recommendations in specifications for a wide range of application protocols. For the purpose of comparison and to delineate the history of thinking about application service identity verification within the IETF, this informative section gathers together prior art by including the exact text from various RFCs (the only modifications are changes to the names of several references to maintain coherence with the main body of this document, and the elision of irrelevant text as marked by the characters "[...]").
このドキュメントの推奨事項は、幅広いアプリケーションプロトコルの仕様の推奨事項からの抽象化です。比較の目的のために、IETF内のアプリケーションサービスのID検証に関する考え方の歴史を描写するために、この有益なセクションは、さまざまなRFCの正確なテキストを含めることにより、以前のアートを集めます（唯一の変更は、維持するためのいくつかの参照の名前の変更です。この文書の本体との一貫性、および文字「[...]」）によってマークされた無関係なテキストの排除。
In 1999, [USINGTLS] specified the following text regarding application service identity verification in IMAP, POP3, and ACAP:
1999年に、[使用型]は、IMAP、POP3、およびACAPのアプリケーションサービスIDの確認に関する次のテキストを指定しました。
######
2.4. Server Identity Check
2.4. サーバーIDチェック
During the TLS negotiation, the client MUST check its understanding of the server hostname against the server's identity as presented in the server Certificate message, in order to prevent man-in-the-middle attacks. Matching is performed according to these rules:
TLSネゴシエーション中、クライアントは、中間者攻撃を防ぐために、サーバーのCertificateメッセージに提示されたサーバーの身元に対して、サーバーホスト名に関する自身の認識をチェックしなければなりません (MUST)。照合は以下のルールに従って実行されます。
o The client MUST use the server hostname it used to open the connection as the value to compare against the server name as expressed in the server certificate. The client MUST NOT use any form of the server hostname derived from an insecure remote source (e.g., insecure DNS lookup). CNAME canonicalization is not done.
o クライアントは、サーバー証明書に表現されているサーバー名と比較する値として、接続を開くために使用したサーバーホスト名を使用しなければなりません (MUST)。クライアントは、安全でないリモートソースから派生したサーバーホスト名の形式（例: 安全でないDNSルックアップ）を使用してはなりません (MUST NOT)。CNAME正規化は行われません。
o If a subjectAltName extension of type dNSName is present in the certificate, it SHOULD be used as the source of the server's identity.
o dNSNameタイプのsubjectAltName拡張が証明書に存在する場合、それをサーバーの身元のソースとして使用すべきです (SHOULD)。
o Matching is case-insensitive.
o マッチングは症例感受性です。
o A "*" wildcard character MAY be used as the left-most name component in the certificate. For example, *.example.com would match a.example.com, foo.example.com, etc. but would not match example.com.
o 証明書の左端の名前コンポーネントとして "*" ワイルドカード文字を使用してもよいです (MAY)。例えば、*.example.comはa.example.com、foo.example.comなどに一致しますが、example.comには一致しません。
o If the certificate contains multiple names (e.g. more than one dNSName field), then a match with any one of the fields is considered acceptable.
o 証明書に複数の名前（たとえば、複数のDNSNAMEフィールドなど）が含まれている場合、フィールドのいずれかと一致すると、受け入れられると見なされます。
If the match fails, the client SHOULD either ask for explicit user confirmation, or terminate the connection and indicate the server's identity is suspect.
一致に失敗した場合、クライアントは明示的なユーザーの確認を求めるか、または接続を終了してサーバーの身元が疑わしいことを示すべきです (SHOULD)。
######
In 2000, [HTTP-TLS] specified the following text regarding application service identity verification in HTTP:
2000年に、[http-tls]は、HTTPでのアプリケーションサービスIDの確認に関する次のテキストを指定しました。
######
3.1. Server Identity
3.1. サーバーのアイデンティティ
In general, HTTP/TLS requests are generated by dereferencing a URI. As a consequence, the hostname for the server is known to the client. If the hostname is available, the client MUST check it against the server's identity as presented in the server's Certificate message, in order to prevent man-in-the-middle attacks.
一般に、HTTP/TLSリクエストはURIを逆参照することによって生成されます。結果として、サーバーのホスト名はクライアントに知られています。ホスト名が利用可能な場合、クライアントは中間者攻撃を防ぐために、サーバーのCertificateメッセージに提示されたサーバーの身元に対してそれをチェックしなければなりません (MUST)。
If the client has external information as to the expected identity of the server, the hostname check MAY be omitted. (For instance, a client may be connecting to a machine whose address and hostname are dynamic but the client knows the certificate that the server will present.) In such cases, it is important to narrow the scope of acceptable certificates as much as possible in order to prevent man in the middle attacks. In special cases, it may be appropriate for the client to simply ignore the server's identity, but it must be understood that this leaves the connection open to active attack.
クライアントがサーバーの期待される身元に関する外部情報を持っている場合、ホスト名チェックを省略してもよいです (MAY)。（例えば、クライアントはアドレスとホスト名が動的であるが、クライアントがサーバーが提示する証明書を知っているマシンに接続している可能性があります。）そのような場合、許容可能な証明書の範囲を可能な限り狭めるべきであり、またクライアントは接続を続行する前にユーザーに確認を求めることを強く考慮すべきです。
If a subjectAltName extension of type dNSName is present, that MUST be used as the identity. Otherwise, the (most specific) Common Name field in the Subject field of the certificate MUST be used. Although the use of the Common Name is existing practice, it is deprecated and Certification Authorities are encouraged to use the dNSName instead.
dNSNameタイプのsubjectAltName拡張が存在する場合、それを身元として使用しなければなりません (MUST)。そうでない場合は、証明書のSubjectフィールド内の（最も具体的な）Common Nameフィールドを使用しなければなりません (MUST)。Common Nameの使用は既存の実践ですが非推奨であり、認証機関は代わりにdNSNameを使用することが推奨されます。Common Nameと照合する際には、[RFC2459]の要件が適用されます。
Matching is performed using the matching rules specified by [PKIX-OLD]. If more than one identity of a given type is present in the certificate (e.g., more than one dNSName name, a match in any one of the set is considered acceptable.) Names may contain the wildcard character * which is considered to match any single domain name component or component fragment. E.g., *.a.com matches foo.a.com but not bar.foo.a.com. f*.com matches foo.com but not bar.com.
[PKIX-Old]で指定されたマッチングルールを使用して、マッチングが実行されます。特定のタイプの複数のIDが証明書に存在する場合（たとえば、複数のDNSNAME名の名前が多い場合、セットのいずれかの一致が許容できると見なされます。）名前には、ワイルドカード文字 *が含まれている場合があります。ドメイン名コンポーネントまたはコンポーネントフラグメント。たとえば、 *.a.comはfoo.a.comを一致させますが、bar.foo.a.comではありません。f*.comはfoo.comと一致しますが、bar.comではありません。
In some cases, the URI is specified as an IP address rather than a hostname. In this case, the iPAddress subjectAltName must be present in the certificate and must exactly match the IP in the URI.
場合によっては、URIはホスト名ではなくIPアドレスとして指定されます。この場合、iPaddressのsubjectAltNameが証明書に存在する必要があり、URIのIPと正確に一致する必要があります。
If the hostname does not match the identity in the certificate, user oriented clients MUST either notify the user (clients MAY give the user the opportunity to continue with the connection in any case) or terminate the connection with a bad certificate error. Automated clients MUST log the error to an appropriate audit log (if available) and SHOULD terminate the connection (with a bad certificate error). Automated clients MAY provide a configuration setting that disables this check, but MUST provide a setting which enables it.
ホスト名が証明書内の身元と一致しない場合、ユーザー指向のクライアントはユーザーに通知しなければならず (MUST)（クライアントは、いずれにしてもユーザーに接続を継続する機会を与えてもよいです (MAY)）、あるいは不正な証明書エラーで接続を終了しなければなりません (MUST)。自動化されたクライアントは、エラーを適切な監査ログに記録すべきであり (SHOULD)（利用可能な場合）、設定オプションを通じてこのチェックを無効にする機能を提供してもよいですが (MAY)、デフォルトでチェックを有効にする設定を提供しなければなりません (MUST)。
Note that in many cases the URI itself comes from an untrusted source. The above-described check provides no protection against attacks where this source is compromised. For example, if the URI was obtained by clicking on an HTML page which was itself obtained without using HTTP/TLS, a man in the middle could have replaced the URI. In order to prevent this form of attack, users should carefully examine the certificate presented by the server to determine if it meets their expectations.
多くの場合、URI自体は信頼されていないソースから来ていることに注意してください。上記の小切手は、このソースが侵害されている攻撃に対する保護を提供しません。たとえば、URIがHTTP/TLSを使用せずに取得されたHTMLページをクリックして取得した場合、中央の男性がURIを置き換えることができました。この形式の攻撃を防ぐために、ユーザーはサーバーが提示した証明書を慎重に調べて、期待を満たしているかどうかを判断する必要があります。
######
In 2000, [LDAP-TLS] specified the following text regarding application service identity verification in LDAP:
2000年、[LDAP-TLS]は、LDAPでのアプリケーションサービスIDの確認に関する次のテキストを指定しました。
######
3.6. Server Identity Check
3.6. サーバーIDチェック
The client MUST check its understanding of the server's hostname against the server's identity as presented in the server's Certificate message, in order to prevent man-in-the-middle attacks.
クライアントは、中間者攻撃を防ぐために、サーバーのCertificateメッセージに提示されたサーバーの身元に対してサーバーのホスト名に関する自身の認識をチェックしなければなりません (MUST)。
Matching is performed according to these rules:
一致は、これらのルールに従って実行されます。
o The client MUST use the server hostname it used to open the LDAP connection as the value to compare against the server name as expressed in the server's certificate. The client MUST NOT use the server's canonical DNS name or any other derived form of name.
o クライアントは、サーバーの証明書に表現されているサーバー名と比較する値として、LDAP接続を開くために使用したサーバーホスト名を使用しなければなりません (MUST)。クライアントは、サーバーの正規DNS名や他の派生形式の名前を使用してはなりません (MUST NOT)。
o If a subjectAltName extension of type dNSName is present in the certificate, it SHOULD be used as the source of the server's identity.
o dNSNameタイプのsubjectAltName拡張が証明書に存在する場合、それをサーバーの身元のソースとして使用すべきです (SHOULD)。
o Matching is case-insensitive.
o マッチングは症例感受性です。
o The "*" wildcard character is allowed. If present, it applies only to the left-most name component.
o 「*」ワイルドカード文字が許可されています。存在する場合、左端の名前コンポーネントにのみ適用されます。
E.g. *.bar.com would match a.bar.com, b.bar.com, etc. but not bar.com. If more than one identity of a given type is present in the certificate (e.g. more than one dNSName name), a match in any one of the set is considered acceptable.
例えば。*.bar.comは、bar.comではなく、a.bar.com、b.bar.comなどに一致します。特定のタイプの複数のIDが証明書に存在する場合（たとえば、複数のDNSNAME名）、セットのいずれかの一致が許容できると見なされます。
If the hostname does not match the dNSName-based identity in the certificate per the above check, user-oriented clients SHOULD either notify the user (clients MAY give the user the opportunity to continue with the connection in any case) or terminate the connection and indicate that the server's identity is suspect. Automated clients SHOULD close the connection, returning and/or logging an error indicating that the server's identity is suspect.
上記のチェックに従ってホスト名が証明書内のdNSNameベースの身元と一致しない場合、ユーザー指向のクライアントはユーザーに通知すべきであり (SHOULD)（クライアントはユーザーにLDAPセッションを継続する機会を与えてもよい (MAY)）、あるいはトランスポート接続を閉じてサーバーの身元が疑わしいことを示すべきです (SHOULD)。自動化されたクライアントは、トランスポート接続を閉じるべきであり、サーバーの身元が疑わしいことまたはその両方を示すべきです。自動化されたクライアントは、監査ログ（利用可能な場合）にエラーを記録すべきです。
Beyond the server identity checks described in this section, clients SHOULD be prepared to do further checking to ensure that the server is authorized to provide the service it is observed to provide. The client MAY need to make use of local policy information.
本セクションで説明するサーバー身元チェックを超えて、クライアントは、サーバーが提供しているのが観察されるサービスを提供することを許可されていることを確認するために、さらなるチェックを行う準備をすべきです (SHOULD)。クライアントは、ローカルポリシー情報を使用してもよいです (MAY)。（例えば、クライアントは、サーバーの証明書が特定の認証機関によって発行されたものであり、特定の名前空間内の名前に対して発行されたものであることをチェックしたい場合があります。）
######
In 2006, [LDAP-AUTH] specified the following text regarding application service identity verification in LDAP:
2006年、[LDAP-Auth]は、LDAPでのアプリケーションサービスIDの確認に関する次のテキストを指定しました。
######
3.1.3. Server Identity Check
3.1.3. サーバーIDチェック
In order to prevent man-in-the-middle attacks, the client MUST verify the server's identity (as presented in the server's Certificate message). In this section, the client's understanding of the server's identity (typically the identity used to establish the transport connection) is called the "reference identity".
中間者攻撃を防ぐために、クライアントはサーバーの身元（サーバーのCertificateメッセージに提示されたもの）を検証しなければなりません (MUST)。本セクションでは、サーバーの身元（通常はトランスポート接続の確立に使用された身元）に関するクライアントの認識を「参照身元」と呼びます。
The client determines the type (e.g., DNS name or IP address) of the reference identity and performs a comparison between the reference identity and each subjectAltName value of the corresponding type until a match is produced. Once a match is produced, the server's identity has been verified, and the server identity check is complete. Different subjectAltName types are matched in different ways. Sections 3.1.3.1 - 3.1.3.3 explain how to compare values of various subjectAltName types.
クライアントは、参照IDのタイプ（DNS名またはIPアドレスなど）を決定し、一致が生成されるまで参照IDと対応するタイプの各件名値との比較を実行します。一致が作成されると、サーバーのIDが検証され、サーバーIDのチェックが完了します。異なるsubmestaltnameタイプは、さまざまな方法で一致しています。セクション3.1.3.1-3.1.3.3さまざまなsubjectAltNameタイプの値を比較する方法を説明します。
The client may map the reference identity to a different type prior to performing a comparison. Mappings may be performed for all available subjectAltName types to which the reference identity can be mapped; however, the reference identity should only be mapped to types for which the mapping is either inherently secure (e.g., extracting the DNS name from a URI to compare with a subjectAltName of type dNSName) or for which the mapping is performed in a secure manner (e.g., using [DNSSEC], or using user- or admin-configured host-to-address/address-to-host lookup tables).
クライアントは、比較を実行する前に、参照IDを別のタイプにマッピングできます。マッピングは、参照IDをマッピングできるすべての利用可能なsubmicaltnameタイプに対して実行できます。ただし、参照IDは、マッピングが本質的に安全であるタイプにのみマッピングする必要があります（たとえば、DNS名をURIから抽出して、タイプDNSNAMEの対象者と比較）、またはマッピングが安全な方法で実行される（たとえば、[dnssec]を使用するか、ユーザーまたは管理者が構成されているホストからアドレスへ/アドレスからホストへのルックアップテーブルを使用します）。
The server's identity may also be verified by comparing the reference identity to the Common Name (CN) [LDAP-SCHEMA] value in the last Relative Distinguished Name (RDN) of the subject field of the server's certificate (where "last" refers to the DER-encoded order, not the order of presentation in a string representation of DER-encoded data). This comparison is performed using the rules for comparison of DNS names in Section 3.1.3.1, below, with the exception that no wildcard matching is allowed. Although the use of the Common Name value is existing practice, it is deprecated, and Certification Authorities are encouraged to provide subjectAltName values instead. Note that the TLS implementation may represent DNs in certificates according to X.500 or other conventions. For example, some X.500 implementations order the RDNs in a DN using a left-to-right (most significant to least significant) convention instead of LDAP's right-to-left convention.
また、サーバーの証明書の主題フィールドの最後の相対識別名（RDN）の共通名（CN）[LDAP-schema]値を参照アイデンティティと比較することにより、サーバーのIDを検証することもできます。derエンコードされた順序、derエンコードデータの文字列表現での表示の順序ではありません）。この比較は、WildCardマッチングが許可されていないことを除いて、以下のセクション3.1.3.1のDNS名を比較するためのルールを使用して実行されます。一般名値の使用は既存の慣行ですが、それは非推奨であり、認定当局は代わりにsubjectAltName値を提供することを奨励されています。TLS実装は、X.500またはその他の規則に従って証明書のDNSを表す場合があることに注意してください。たとえば、一部のX.500実装は、LDAPの左から左右の条約ではなく、左から右（最も重要なものから最も重要な）条約を使用してDNでRDNを注文します。
If the server identity check fails, user-oriented clients SHOULD either notify the user (clients may give the user the opportunity to continue with the LDAP session in this case) or close the transport connection and indicate that the server's identity is suspect. Automated clients SHOULD close the transport connection and then return or log an error indicating that the server's identity is suspect or both.
サーバー身元のチェックが失敗した場合、ユーザー指向のクライアントはユーザーに通知すべきであり (SHOULD)（クライアントはユーザーにLDAPセッションを継続する機会を与えてもよい）、あるいはトランスポート接続を閉じてサーバーの身元が疑わしいことを示すべきです (SHOULD)。自動化されたクライアントは、トランスポート接続を閉じるべきであり、サーバーの身元が疑わしいことまたはその両方を示すべきです。自動化されたクライアントは、監査ログ（利用可能な場合）にエラーを記録すべきです。
Beyond the server identity check described in this section, clients should be prepared to do further checking to ensure that the server is authorized to provide the service it is requested to provide. The client may need to make use of local policy information in making this determination.
このセクションで説明されているサーバーIDチェックを超えて、クライアントは、提供するように要求されるサービスを提供することをサーバーが許可されていることを確認するために、さらにチェックする準備をする必要があります。クライアントは、この決定を行う際にローカルポリシー情報を利用する必要がある場合があります。
3.1.3.1. Comparison of DNS Names
3.1.3.1. DNS名の比較
If the reference identity is an internationalized domain name, conforming implementations MUST convert it to the ASCII Compatible Encoding (ACE) format as specified in Section 4 of RFC 3490 [IDNA2003] before comparison with subjectAltName values of type dNSName. Specifically, conforming implementations MUST perform the conversion operation specified in Section 4 of RFC 3490 as follows:
参照身元が国際化ドメイン名である場合、適合実装は、dNSNameタイプのsubjectAltName値と比較する前に、RFC 3490 [IDNA2003]のセクション4で指定されているように、ASCII互換エンコーディング（ACE）形式に変換しなければなりません (MUST)。具体的には、適合実装は次のようにRFC 3490のセクション4に記載されている「ToASCII」操作を実行しなければなりません (MUST):
o in step 1, the domain name SHALL be considered a "stored string";
o ステップ1において、ドメイン名は「保存された文字列」とみなされなければなりません (SHALL)。
o in step 3, set the flag called "UseSTD3ASCIIRules";
o ステップ3では、「uesestd3asciirules」と呼ばれるフラグを設定します。
o in step 4, process each label with the "ToASCII" operation; and o in step 5, change all label separators to U+002E (full stop).
o ステップ4では、各ラベルを「ToASCII」操作で処理します。oステップ5では、すべてのラベルセパレータをu 002e（フルストップ）に変更します。
After performing the "to-ASCII" conversion, the DNS labels and names MUST be compared for equality according to the rules specified in Section 3 of RFC3490.
「ToASCII」変換を実行した後、RFC 3490のセクション3で指定されているルールに従って、DNSラベルと名前の一致を比較しなければなりません (MUST)。
The '*' (ASCII 42) wildcard character is allowed in subjectAltName values of type dNSName, and then only as the left-most (least significant) DNS label in that value. This wildcard matches any left-most DNS label in the server name. That is, the subject *.example.com matches the server names a.example.com and b.example.com, but does not match example.com or a.b.example.com.
'*'（ASCII 42）ワイルドカード文字は、タイプDNSNameのsubjectAltName値で許可され、次にその値の左端（最小重要な）DNSラベルとしてのみ許可されます。このワイルドカードは、サーバー名の左端のDNSラベルと一致します。つまり、件名 *.example.comはサーバー名A.example.comおよびB.Example.comと一致しますが、example.comまたはA.B.example.comと一致しません。
3.1.3.2. Comparison of IP Addresses
3.1.3.2. IPアドレスの比較
When the reference identity is an IP address, the identity MUST be converted to the "network byte order" octet string representation [IP] [IPv6]. For IP Version 4, as specified in RFC 791, the octet string will contain exactly four octets. For IP Version 6, as specified in RFC 2460, the octet string will contain exactly sixteen octets. This octet string is then compared against subjectAltName values of type iPAddress. A match occurs if the reference identity octet string and value octet strings are identical.
参照身元がIPアドレスである場合、身元は「ネットワークバイト順」のオクテット文字列表現 [IP] [IPv6] に変換されなければなりません (MUST)。IPバージョン4の場合、RFC 791で指定されているように、オクテット文字列には正確に4オクテットが含まれます。IPバージョン6の場合、RFC 2460で指定されているように、オクテット文字列には正確に16オクテットが含まれます。次に、このオクテット文字列がiPAddressタイプのsubjectAltName値と比較されます。参照身元のオクテット文字列と値のオクテット文字列が同一である場合に一致が発生します。
3.1.3.3. Comparison of Other subjectName Types
3.1.3.3. 他の件名タイプの比較
Client implementations MAY support matching against subjectAltName values of other types as described in other documents.
クライアント実装は、他の文書で説明されている他のタイプのsubjectAltName値との照合をサポートしてもよいです (MAY)。
######
In 2002, [SMTP-TLS] specified the following text regarding application service identity verification in SMTP:
2002年、[SMTP-TLS]は、SMTPでのアプリケーションサービスIDの確認に関する次のテキストを指定しました。
######
4.1 Processing After the STARTTLS Command
4.1 starttlsコマンド後の処理
[...]
[...]
The decision of whether or not to believe the authenticity of the other party in a TLS negotiation is a local matter. However, some general rules for the decisions are: o A SMTP client would probably only want to authenticate an SMTP server whose server certificate has a domain name that is the domain name that the client thought it was connecting to.
TLS交渉における相手の信ity性を信じるかどうかの決定は、地元の問題です。ただし、決定に関するいくつかの一般的なルールは次のとおりです。OSMTPクライアントは、おそらく、サーバー証明書にクライアントが接続していると思ったドメイン名であるドメイン名を持っているSMTPサーバーのみを認証することを望むでしょう。
[...]
[...]
######
In 2006, [SMTP-AUTH] specified the following text regarding application service identity verification in SMTP:
2006年、[SMTP-Auth]は、SMTPでのアプリケーションサービスIDの確認に関する次のテキストを指定しました。
######
14. Additional Requirements When Using SASL PLAIN over TLS
14. TLSでSASL平野を使用する場合の追加要件
[...]
[...]
After a successful [TLS] negotiation, the client MUST check its understanding of the server hostname against the server's identity as presented in the server Certificate message, in order to prevent man-in-the-middle attacks. If the match fails, the client MUST NOT attempt to authenticate using the SASL PLAIN mechanism. Matching is performed according to the following rules:
[TLS]ネゴシエーションが成功した後、クライアントは、中間者攻撃を防ぐために、サーバーのCertificateメッセージに提示されたサーバーの身元に対してサーバーホスト名に関する自身の認識をチェックしなければなりません (MUST)。一致が失敗した場合、クライアントはSASL PLAINメカニズムを使用して認証を試みてはなりません (MUST NOT)。照合は以下のルールに従って実行されます。
The client MUST use the server hostname it used to open the connection as the value to compare against the server name as expressed in the server certificate. The client MUST NOT use any form of the server hostname derived from an insecure remote source (e.g., insecure DNS lookup). CNAME canonicalization is not done.
クライアントは、サーバー証明書に表現されているサーバー名と比較する値として、接続を開くために使用したサーバーホスト名を使用しなければなりません (MUST)。クライアントは、安全でないリモートソースから派生したサーバーホスト名の形式（例: 安全でないDNSルックアップ）を使用してはなりません (MUST NOT)。CNAME正規化は行われません。
If a subjectAltName extension of type dNSName is present in the certificate, it SHOULD be used as the source of the server's identity.
dNSNameタイプのsubjectAltName拡張が証明書に存在する場合、それをサーバーの身元のソースとして使用すべきです (SHOULD)。
Matching is case-insensitive.
マッチングは症例感受性です。
A "*" wildcard character MAY be used as the leftmost name component in the certificate. For example, *.example.com would match a.example.com, foo.example.com, etc., but would not match example.com.
"*" ワイルドカード文字を証明書の左端の名前コンポーネントとして使用してもよいです (MAY)。例えば、*.example.comはa.example.com、foo.example.comなどに一致しますが、example.comには一致しません。
If the certificate contains multiple names (e.g., more than one dNSName field), then a match with any one of the fields is considered acceptable.
証明書に複数の名前（たとえば、複数のDNSNAMEフィールドなど）が含まれている場合、フィールドのいずれかと一致すると、受け入れられると見なされます。
######
In 2004, [XMPP-OLD] specified the following text regarding application service identity verification in XMPP:
2004年、[XMPP-Old]は、XMPPでのアプリケーションサービスIDの確認に関する次のテキストを指定しました。
######
14.2. Certificate Validation
14.2. 証明書の検証
When an XMPP peer communicates with another peer securely, it MUST validate the peer's certificate. There are three possible cases:
XMPPピアが別のピアと安全に通信する場合、ピアの証明書を検証しなければなりません (MUST)。可能なケースは3つあります:
Case #1: The peer contains an End Entity certificate which appears to be certified by a certification path terminating in a trust anchor (as described in Section 6.1 of [PKIX]).
ケース＃1：ピアには、[PKIX]のセクション6.1で説明されているように、信頼アンカーで終了する認定パスによって認定されていると思われるエンディティ証明書が含まれています。
Case #2: The peer certificate is certified by a Certificate Authority not known to the validating peer.
ケース＃2：ピア証明書は、有効なピアに知られていない証明書当局によって認定されます。
Case #3: The peer certificate is self-signed.
ケース＃3：ピア証明書は自己署名です。
In Case #1, the validating peer MUST do one of two things:
ケース#1では、検証するピアは以下の2つのうちいずれかを行わなければなりません (MUST):
1. Verify the peer certificate according to the rules of [PKIX]. The certificate SHOULD then be checked against the expected identity of the peer following the rules described in [HTTP-TLS], except that a subjectAltName extension of type "xmpp" MUST be used as the identity if present. If one of these checks fails, user-oriented clients MUST either notify the user (clients MAY give the user the opportunity to continue with the connection in any case) or terminate the connection with a bad certificate error. Automated clients SHOULD terminate the connection (with a bad certificate error) and log the error to an appropriate audit log. Automated clients MAY provide a configuration setting that disables this check, but MUST provide a setting that enables it.
1. [PKIX]のルールに従ってピア証明書を検証します。その後、[HTTP-TLS]で説明されているルールに従ってピアの期待される身元に対して証明書をチェックすべきですが (SHOULD)、"xmpp" タイプのsubjectAltName拡張が存在する場合はそれを身元として使用しなければなりません (MUST)。これらのチェックのいずれかが失敗した場合、ユーザー指向のクライアントはユーザーに通知しなければならず (MUST)（クライアントは、いずれにしてもユーザーに接続を継続する機会を与えてもよいです (MAY)）、あるいは不正な証明書エラーで接続を終了すべきです (SHOULD)。自動化されたクライアントは、（不正な証明書エラーで）接続を終了し、適切な監査ログにエラーを記録すべきです。自動化されたクライアントは、このチェックを無効にする設定オプションを提供してもよいですが (MAY)、それを有効にする設定を提供しなければなりません (MUST)。
2. The peer SHOULD show the certificate to a user for approval, including the entire certification path. The peer MUST cache the certificate (or some non-forgeable representation such as a hash). In future connections, the peer MUST verify that the same certificate was presented and MUST notify the user if it has changed.
2. ピアは、認証パス全体を含め、承認のために証明書をユーザーに提示すべきです (SHOULD)。ピアは証明書（またはハッシュなどの偽造不可能な表現）をキャッシュしなければなりません (MUST)。将来の接続において、ピアは同じ証明書が提示されたことを検証しなければならず (MUST)、変更された場合はユーザーに通知しなければなりません (MUST)。
In Case #2 and Case #3, implementations SHOULD act as in (2) above.
ケース#2およびケース#3では、実装は上記の (2) のように動作すべきです (SHOULD)。
###### Although [XMPP-OLD] defined its own rules, [XMPP] reuses the rules in this document regarding application service identity verification in XMPP.
###### [XMPP-Old]は独自のルールを定義しましたが、[XMPP]は、XMPPのアプリケーションサービスID検証に関するこのドキュメントのルールを再利用します。
In 2006, [NNTP-TLS] specified the following text regarding application service identity verification in NNTP:
2006年、[NNTP-TLS]は、NNTPでのアプリケーションサービスIDの確認に関する次のテキストを指定しました。
######
5. Security Considerations
5. セキュリティに関する考慮事項
[...]
[...]
During the TLS negotiation, the client MUST check its understanding of the server hostname against the server's identity as presented in the server Certificate message, in order to prevent man-in-the-middle attacks. Matching is performed according to these rules:
TLSネゴシエーション中、クライアントは、中間者攻撃を防ぐために、サーバーのCertificateメッセージに提示されたサーバーの身元に対してサーバーホスト名に関する自身の認識をチェックしなければなりません (MUST)。照合は以下のルールに従って実行されます。
o The client MUST use the server hostname it used to open the connection (or the hostname specified in TLS "server_name" extension [TLS]) as the value to compare against the server name as expressed in the server certificate. The client MUST NOT use any form of the server hostname derived from an insecure remote source (e.g., insecure DNS lookup). CNAME canonicalization is not done.
o クライアントは、サーバー証明書に表現されているサーバー名と比較する値として、接続を開くために使用したサーバーホスト名（またはTLSの "server_name" 拡張 [TLS] で指定されたホスト名）を使用しなければなりません (MUST)。クライアントは、安全でないリモートソースから派生したサーバーホスト名の形式（例: 安全でないDNSルックアップ）を使用してはなりません (MUST NOT)。CNAME正規化は行われません。
o If a subjectAltName extension of type dNSName is present in the certificate, it SHOULD be used as the source of the server's identity.
o dNSNameタイプのsubjectAltName拡張が証明書に存在する場合、それをサーバーの身元のソースとして使用すべきです (SHOULD)。
o Matching is case-insensitive.
o マッチングは症例感受性です。
o A "*" wildcard character MAY be used as the left-most name component in the certificate. For example, *.example.com would match a.example.com, foo.example.com, etc., but would not match example.com.
o 証明書の左端の名前コンポーネントとして "*" ワイルドカード文字を使用してもよいです (MAY)。例えば、*.example.comはa.example.com、foo.example.comなどに一致しますが、example.comには一致しません。
o If the certificate contains multiple names (e.g., more than one dNSName field), then a match with any one of the fields is considered acceptable.
o 証明書に複数の名前（たとえば、複数のDNSNAMEフィールドなど）が含まれている場合、フィールドのいずれかと一致すると、受け入れられると見なされます。
If the match fails, the client SHOULD either ask for explicit user confirmation or terminate the connection with a QUIT command and indicate the server's identity is suspect.
一致に失敗した場合、クライアントは明示的なユーザーの確認を求めるか、またはQUITコマンドで接続を終了してサーバーの身元が疑わしいことを示すべきです (SHOULD)。
Additionally, clients MUST verify the binding between the identity of the servers to which they connect and the public keys presented by those servers. Clients SHOULD implement the algorithm in Section 6 of [PKIX] for general certificate validation, but MAY supplement that algorithm with other validation methods that achieve equivalent levels of verification (such as comparing the server certificate against a local store of already-verified certificates and identity bindings).
さらに、クライアントは、接続先のサーバーの身元とそれらのサーバーが提示する公開鍵の間のバインディングを検証しなければなりません (MUST)。クライアントは、一般的な証明書検証のために[PKIX]のセクション6のアルゴリズムを実装すべきですが (SHOULD)、同等の検証レベルを達成する他の検証方法（すでに検証済みの証明書と身元バインディングのローカルストアに対してサーバー証明書を比較するなど）でそのアルゴリズムを補完してもよいです (MAY)。
######
In 2006, [NETCONF-SSH] specified the following text regarding application service identity verification in NETCONF:
2006年、[NetConf-SSH]は、NetConfのアプリケーションサービスIDの確認に関する次のテキストを指定しました。
######
6. Security Considerations
6. セキュリティに関する考慮事項
The identity of the server MUST be verified and authenticated by the client according to local policy before password-based authentication data or any configuration or state data is sent to or received from the server. The identity of the client MUST also be verified and authenticated by the server according to local policy to ensure that the incoming client request is legitimate before any configuration or state data is sent to or received from the client. Neither side should establish a NETCONF over SSH connection with an unknown, unexpected, or incorrect identity on the opposite side.
パスワードベースの認証データや構成または状態データがサーバーから送信または受信される前に、サーバーの身元はローカルポリシーに従ってクライアントによって検証および認証されなければなりません (MUST)。また、クライアントに適用可能な構成または状態データがサーバーから送信または受信される前に、クライアントの身元はローカルポリシーに従ってサーバーによって検証および認証されなければなりません (MUST)。
######
In 2009, [NETCONF-TLS] specified the following text regarding application service identity verification in NETCONF:
2009年、[NetConf-TLS]は、NetConfのアプリケーションサービスIDの確認に関する次のテキストを指定しました。
######
3.1. Server Identity
3.1. サーバーのアイデンティティ
During the TLS negotiation, the client MUST carefully examine the certificate presented by the server to determine if it meets the client's expectations. Particularly, the client MUST check its understanding of the server hostname against the server's identity as presented in the server Certificate message, in order to prevent man-in-the-middle attacks.
TLSネゴシエーション中、クライアントは、クライアントの期待を満たしているかどうかを判断するために、サーバーから提示された証明書を慎重に検査しなければなりません (MUST)。特に、クライアントは、中間者攻撃を防ぐために、サーバーのCertificateメッセージに提示されたサーバーの身元に対してサーバーホスト名に関する自身の認識をチェックしなければなりません (MUST)。
Matching is performed according to the rules below (following the example of [NNTP-TLS]):
マッチングは、以下のルールに従って実行されます（[NNTP-TLS]の例に従ってください）：
o The client MUST use the server hostname it used to open the connection (or the hostname specified in the TLS "server_name" extension [TLS]) as the value to compare against the server name as expressed in the server certificate. The client MUST NOT use any form of the server hostname derived from an insecure remote source (e.g., insecure DNS lookup). CNAME canonicalization is not done.
o クライアントは、サーバー証明書に表現されているサーバー名と比較する値として、接続を開くために使用したサーバーホスト名（またはTLSの "server_name" 拡張 [TLS] で指定されたホスト名）を使用しなければなりません (MUST)。クライアントは、安全でないリモートソースから派生したサーバーホスト名の形式（例: 安全でないDNSルックアップ）を使用してはなりません (MUST NOT)。CNAME正規化は行われません。
o If a subjectAltName extension of type dNSName is present in the certificate, it MUST be used as the source of the server's identity.
o dNSNameタイプのsubjectAltName拡張が証明書に存在する場合、それをサーバーの身元のソースとして使用しなければなりません (MUST)。
o Matching is case-insensitive.
o マッチングは症例感受性です。
o A "*" wildcard character MAY be used as the leftmost name component in the certificate. For example, *.example.com would match a.example.com, foo.example.com, etc., but would not match example.com.
o 証明書の左端の名前コンポーネントとして "*" ワイルドカード文字を使用してもよいです (MAY)。例えば、*.example.comはa.example.com、foo.example.comなどに一致しますが、example.comには一致しません。
o If the certificate contains multiple names (e.g., more than one dNSName field), then a match with any one of the fields is considered acceptable.
o 証明書に複数の名前（たとえば、複数のDNSNAMEフィールドなど）が含まれている場合、フィールドのいずれかと一致すると、受け入れられると見なされます。
If the match fails, the client MUST either ask for explicit user confirmation or terminate the connection and indicate the server's identity is suspect.
一致に失敗した場合、クライアントは明示的なユーザーの確認を求めるか、または接続を終了してサーバーの身元が疑わしいことを示さなければなりません (MUST)。
Additionally, clients MUST verify the binding between the identity of the servers to which they connect and the public keys presented by those servers. Clients SHOULD implement the algorithm in Section 6 of [PKIX] for general certificate validation, but MAY supplement that algorithm with other validation methods that achieve equivalent levels of verification (such as comparing the server certificate against a local store of already-verified certificates and identity bindings).
さらに、クライアントは、接続先のサーバーの身元とそれらのサーバーが提示する公開鍵の間のバインディングを検証しなければなりません (MUST)。クライアントは、一般的な証明書検証のために[PKIX]のセクション6のアルゴリズムを実装すべきですが (SHOULD)、同等の検証レベルを達成する他の検証方法（すでに検証済みの証明書と身元バインディングのローカルストアに対してサーバー証明書を比較するなど）でそのアルゴリズムを補完してもよいです (MAY)。
If the client has external information as to the expected identity of the server, the hostname check MAY be omitted.
クライアントがサーバーの期待される身元に関する外部情報を持っている場合、ホスト名チェックを省略してもよいです (MAY)。
######
In 2009, [SYSLOG-TLS] specified the following text regarding application service identity verification in Syslog:
2009年、[Syslog-TLS]は、SyslogのアプリケーションサービスIDの確認に関する次のテキストを指定しました。
######
5.2. Subject Name Authorization
5.2. 件名の認証
Implementations MUST support certification path validation [PKIX]. In addition, they MUST support specifying the authorized peers using locally configured host names and matching the name against the certificate as follows.
実装は認証パス検証 [PKIX] をサポートしなければなりません (MUST)。さらに、ローカルで設定されたホスト名を使用して認可されたピアを指定し、以下のように証明書に対して名前を照合することをサポートしなければなりません (MUST):
o Implementations MUST support matching the locally configured host name against a dNSName in the subjectAltName extension field and SHOULD support checking the name against the common name portion of the subject distinguished name.
o 実装は、subjectAltName拡張フィールドのdNSNameに対してローカルで設定されたホスト名を照合することをサポートしなければならず (MUST)、subjectの識別名（DN）のCommon Name部分に対して名前をチェックすることをサポートすべきです (SHOULD)。
o The '*' (ASCII 42) wildcard character is allowed in the dNSName of the subjectAltName extension (and in common name, if used to store the host name), but only as the left-most (least significant) DNS label in that value. This wildcard matches any left-most DNS label in the server name. That is, the subject *.example.com matches the server names a.example.com and b.example.com, but does not match example.com or a.b.example.com. Implementations MUST support wildcards in certificates as specified above, but MAY provide a configuration option to disable them.
o '*'（ASCII 42）ワイルドカード文字は、subjectAltName拡張のdNSNameにおいて（またホスト名を格納するために使用される場合はCommon Nameにおいて）許可されますが、その値の左端（最下位）のDNSラベルとしてのみ許可されます。このワイルドカードは、サーバー名内の任意の左端のDNSラベルと一致します。すなわち、subjectの *.example.com はサーバー名 a.example.com および b.example.com と一致しますが、example.com や a.b.example.com とは一致しません。実装は、上記で指定された証明書内のワイルドカードをサポートしなければなりませんが (MUST)、それらを無効にする設定オプションを提供してもよいです (MAY)。
o Locally configured names MAY contain the wildcard character to match a range of values. The types of wildcards supported MAY be more flexible than those allowed in subject names, making it possible to support various policies for different environments. For example, a policy could allow for a trust-root-based authorization where all credentials issued by a particular CA trust root are authorized.
o ローカルで設定された名前には、値の範囲に一致させるためにワイルドカード文字を含めてもよいです (MAY)。サポートされるワイルドカードのタイプは、subject名で許可されているものよりも柔軟であってもよく (MAY)、これにより異なる環境向けの異なるポリシーをサポートすることが可能になります。例えば、ポリシーにより、特定のCAトラストルートによって発行された証明書を提示する限り、*.example.comに一致する名前を持つ任意のリモートホストへの接続が許可される場合があります。
o If the locally configured name is an internationalized domain name, conforming implementations MUST convert it to the ASCII Compatible Encoding (ACE) format for performing comparisons, as specified in Section 7 of [PKIX].
o ローカルで設定された名前が国際化ドメイン名である場合、適合実装は、[PKIX]のセクション7で指定されているように、比較を実行するためにそれをASCII互換エンコーディング（ACE）形式に変換しなければなりません (MUST)。
o Implementations MAY support matching a locally configured IP address against an iPAddress stored in the subjectAltName extension. In this case, the locally configured IP address is converted to an octet string as specified in [PKIX], Section 4.2.1.6. A match occurs if this octet string is equal to the value of iPAddress in the subjectAltName extension.
o 実装は、subjectAltName拡張に格納されているiPAddressに対してローカルで設定されたIPアドレスを照合することをサポートしてもよいです (MAY)。この場合、[PKIX]のセクション4.2.1.6で指定されているように、ローカルで設定されたIPアドレスはオクテット文字列に変換されます。このオクテット文字列がsubjectAltNameのiPAddressと正確に一致する場合に一致が発生します。
######
In 2010, [SIP-CERTS] specified the following text regarding application service identity verification in SIP:
2010年、[SIP-Certs]は、SIPのアプリケーションサービスIDの確認に関する次のテキストを指定しました。
######
7.2. Comparing SIP Identities
7.2. SIP IDの比較
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名コンポーネントのみを比較しなければなりません (MUST)。実装は比較においていかなるスキームやパラメータも使用してはなりません (MUST NOT)。
Implementations MUST compare the values as DNS names, which means that the comparison is case insensitive as specified by [DNS-CASE]. Implementations MUST handle Internationalized Domain Names (IDNs) in accordance with Section 7.2 of [PKIX].
実装は、値をDNS名として比較しなければならず (MUST)、これは[DNS-CASE]で指定されているように比較が大文字小文字を区別しないことを意味します。実装は、[PKIX]のセクション7.2に従って国際化ドメイン名（IDN）を処理しなければなりません (MUST)。
Implementations MUST match the values in their entirety:
実装は値全体を照合しなければなりません (MUST):
Implementations MUST NOT match suffixes. For example, "foo.example.com" does not match "example.com".
実装はサフィックスを照合してはなりません (MUST NOT)。例えば、"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ラベルやラベルシーケンスと照合してはなりません (MUST NOT)。例えば、"*.example.com" は "*.example.com" のみに一致し、"foo.example.com" とは一致しません。同様に、".example.com" は ".example.com" のみに一致し、"foo.example.com" とは一致しません。
[HTTP-TLS] allows the dNSName component to contain a wildcard; e.g., "DNS:*.example.com". [PKIX], while not disallowing this explicitly, leaves the interpretation of wildcards to the individual specification. [SIP] 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.
[HTTP-TLS]により、DNSNAMEコンポーネントがワイルドカードを含めることができます。たとえば、「dns：*。example.com」。[pkix]は、これを明示的に許可していませんが、ワイルドカードの解釈を個々の仕様に残します。[SIP]は、証明書にワイルドカードの存在に関するガイドラインを提供していません。上記のルールを通じて、この文書は、SIPドメインの証明書のこのようなワイルドカードを禁止しています。
######
In 2010, [SNMP-TLS] specified the following text regarding application service identity verification in SNMP:
2010年、[SNMP-TLS]は、SNMPのアプリケーションサービスIDの確認に関する次のテキストを指定しました。
######
If the server's presented certificate has passed certification path validation [PKIX] to a configured trust anchor, and an active row exists with a zero-length snmpTlstmAddrServerFingerprint value, then the snmpTlstmAddrServerIdentity column contains the expected host name. This expected host name is then compared against the server's certificate as follows:
サーバーの提示された証明書が認定パス検証[PKIX]を構成されたトラストアンカーに合格し、ゼロの長さのsnmpTlstmAddrServerFingerprint値を備えたアクティブな行が存在する場合、SNMPTLSTMADDRSERVERIDETY列には予想されるホスト名が含まれています。この予想ホスト名は、次のようにサーバーの証明書に対して比較されます。
o Implementations MUST support matching the expected host name against a dNSName in the subjectAltName extension field and MAY support checking the name against the CommonName portion of the subject distinguished name.
o 実装は、subjectAltName拡張フィールドのdNSNameに対して期待されるホスト名を照合することをサポートしなければならず (MUST)、subjectの識別名のCommon Name部分に対して名前をチェックすることをサポートしてもよいです (MAY)。
o The '*' (ASCII 0x2a) wildcard character is allowed in the dNSName of the subjectAltName extension (and in common name, if used to store the host name), but only as the left-most (least significant) DNS label in that value. This wildcard matches any left-most DNS label in the server name. That is, the subject *.example.com matches the server names a.example.com and b.example.com, but does not match example.com or a.b.example.com. Implementations MUST support wildcards in certificates as specified above, but MAY provide a configuration option to disable them.
o '*'（ASCII 0x2a）ワイルドカード文字は、subjectAltName拡張のdNSNameにおいて（またホスト名を格納するために使用される場合はCommon Nameにおいて）許可されますが、その値の左端（最下位）のDNSラベルとしてのみ許可されます。このワイルドカードは、サーバー名内の任意の左端のDNSラベルと一致します。すなわち、subjectの *.example.com はサーバー名 a.example.com および b.example.com と一致しますが、example.com や a.b.example.com とは一致しません。実装は、上記で指定された証明書内のワイルドカードをサポートしなければなりませんが (MUST)、それらを無効にする設定オプションを提供してもよいです (MAY)。
o If the locally configured name is an internationalized domain name, conforming implementations MUST convert it to the ASCII Compatible Encoding (ACE) format for performing comparisons, as specified in Section 7 of [PKIX].
o ローカルで設定された名前が国際化ドメイン名である場合、適合実装は、[PKIX]のセクション7で指定されているように、比較を実行するためにそれをASCII互換エンコーディング（ACE）形式に変換しなければなりません (MUST)。
If the expected host name fails these conditions then the connection MUST be closed.
期待されるホスト名がこれらの条件を満たさない場合、接続を閉じなければなりません (MUST)。
######
In 2010, [GIST] specified the following text regarding application service identity verification in the General Internet Signalling Transport:
2010年、[GIST]は、一般的なインターネットシグナル伝達輸送におけるアプリケーションサービスのID検証に関する次のテキストを指定しました。
######
5.7.3.1. Identity Checking in TLS
5.7.3.1. TLSでのIDチェック
After TLS authentication, a node MUST check the identity presented by the peer in order to avoid man-in-the-middle attacks, and verify that the peer is authorised to take part in signalling at the GIST layer. The authorisation check is carried out by comparing the presented identity with each Authorised Peer Database (APD) entry in turn, as discussed in Section 4.4.2. This section defines the identity comparison algorithm for a single APD entry.
TLS認証の後、ノードは中間者攻撃を回避するためにピアから提示された身元をチェックしなければならず (MUST)、ピアがGIST層でのシグナリングに参加することを認可されていることを検証しなければなりません (MUST)。認可チェックは、セクション4.4.2で説明されているように、提示された身元を各認可ピアデータベース（APD）エントリと順番に比較することによって実行されます。本セクションでは、単一のAPDエントリに対する身元比較アルゴリズムを定義します。
For TLS authentication with X.509 certificates, an identity from the DNS namespace MUST be checked against each subjectAltName extension of type dNSName present in the certificate. If no such extension is present, then the identity MUST be compared to the (most specific) Common Name in the Subject field of the certificate. When matching DNS names against dNSName or Common Name fields, matching is case-insensitive. Also, a "*" wildcard character MAY be used as the left-most name component in the certificate or identity in the APD. For example, *.example.com in the APD would match certificates for a.example.com, foo.example.com, *.example.com, etc., but would not match example.com. Similarly, a certificate for *.example.com would be valid for APD identities of a.example.com, foo.example.com, *.example.com, etc., but not example.com.
X.509証明書を使用したTLS認証の場合、DNS名前空間からの身元は、証明書に存在するタイプdNSNameの各subjectAltName拡張に対してチェックされなければなりません (MUST)。そのような拡張が存在しない場合、身元は証明書のSubjectフィールド内の（最も具体的な）Common Nameと比較されなければなりません (MUST)。DNS名をdNSNameまたはCommon Nameフィールドに対して照合する場合、照合は大文字小文字を区別しません。また、証明書またはAPD内の身元の左端の名前コンポーネントとして "*" ワイルドカード文字を使用してもよいです (MAY)。例えば、APD内の *.example.com は a.example.com、foo.example.com、*.example.com などの証明書と一致しますが、example.com には一致しません。同様に、*.example.com の証明書は APD身元の a.example.com、foo.example.com、*.example.com などに対して有効ですが、example.com には有効ではありません。
Additionally, a node MUST verify the binding between the identity of the peer to which it connects and the public key presented by that peer. Nodes SHOULD implement the algorithm in Section 6 of [PKIX] for general certificate validation, but MAY supplement that algorithm with other validation methods that achieve equivalent levels of verification (such as comparing the server certificate against a local store of already-verified certificates and identity bindings).
さらに、ノードは、接続先のピアの身元と、そのピアが提示した公開鍵の間のバインディングを検証しなければなりません (MUST)。ノードは、一般的な証明書検証のために[PKIX]のセクション6のアルゴリズムを実装すべきですが (SHOULD)、同等の検証レベルを達成する他の検証方法（すでに検証済みの証明書と身元バインディングのローカルストアに対してサーバー証明書を比較するなど）でそのアルゴリズムを補完してもよいです (MAY)。
For TLS authentication with pre-shared keys, the identity in the psk_identity_hint (for the server identity, i.e. the Responding node) or psk_identity (for the client identity, i.e. the Querying node) MUST be compared to the identities in the APD.
事前共有鍵を使用したTLS認証の場合、psk_identity_hint（サーバー身元、すなわち応答側ノード用）またはpsk_identity（クライアント身元、すなわちクエリ側ノード用）内の身元は、APD内の身元と比較されなければなりません (MUST)。
######
Authors' Addresses
著者のアドレス
Peter Saint-Andre Cisco 1899 Wyknoop Street, Suite 600 Denver, CO 80202 USA
ピーターセントアンドレシスコ1899 Wyknoop Street、Suite 600 Denver、Co 80202 USA
Phone: +1-303-308-3282
EMail: psaintan@cisco.com
Jeff Hodges PayPal 2211 North First Street San Jose, California 95131 US
ジェフホッジスペイパル2211ノースファーストストリートサンノゼ、カリフォルニア95131米国
EMail: Jeff.Hodges@PayPal.com