[要約] RFC 6125は、インターネット公開鍵基盤（PKIX）を使用したドメインベースのアプリケーションサービスの識別子の表現と検証に関する規定を定めています。この文書の主な目的は、Transport Layer Security (TLS) などのセキュリティプロトコルを使用する際に、X.509証明書を通じてサービスの身元を確認するための一貫した方法を提供することです。これは、Webサーバー、メールサーバーなど、さまざまなインターネットサービスにおいて、安全な通信を確立するために重要です。関連するRFCには、RFC 5280（X.509証明書とCRLのプロファイル）やRFC 5246（TLSのバージョン1.2の仕様）などがあります。
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）証明書を使用したインターネット公開キーインフラストラクチャ内のドメインベースのアプリケーションサービスIDの表現と検証
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].
キーワードは「必須」、「必要」、「必須」、「shall」、「shall "、" bood "、" low "not"、 "becommended"、 "bodement"、 ""、 "、" optional「このドキュメントでは、RFC 2119 [キーワード]で説明されているように解釈されます。
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」を含める必要があります。
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を含める必要があります。
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] [HTTP-TLS]はHTTPサービスのURI-IDの使用法を説明していないため、証明書にはURI-IDを含める必要があります。スキームは、アプリケーションサービスタイプに関連付けられたプロトコルのスキームであり、「ホスト」コンポーネント（または同等）は、サービスの完全な資格のあるDNSドメイン名でなければなりません。これを再利用する仕様は、アプリケーションプロトコルに使用されるPKIX証明書に含まれるURI-IDで受け入れられると見なされるURIスキームを指定する必要があります（例えば、「SIP」または「SIP」または「TEL」はSIPで説明されています。sip-sips]、または将来の仕様で説明されている可能性のあるHTTPのHTTPおよびHTTPS）。
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スキームが存在しない場合が含まれます。ただし、このようなアプリケーション固有の識別子は、すべてのアプリケーションテクノロジーに適用できないため、この仕様の範囲外です。
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. 多くの展開されたクライアントは、証明書サブジェクトフィールド内のCN-IDをまだチェックしていますが、認定当局は、CN-IDのサーバーの完全資格のDNSドメイン名を表す証明書の発行から離れて移行することを奨励されています。したがって、証明書は、これを再利用する仕様に従って証明書を発行し、特定のアプリケーションテクノロジーのコンテキストでCN-ID識別子タイプの継続的なサポートを明示的に奨励する場合を除き、CN-IDをCN-IDを含めるべきではありません。
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. 証明書には、セクション7.4でさらに説明されているように、複数のDNS-ID、SRV-ID、またはURI-IDを含むことができますが、複数のCN-IDを含めることはできません。
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ドメイン名部分には、識別子内の完全な左のラベルとしてのワイルドカード文字を含めるべきではありません（[DNSコンセプト]のラベルとドメイン名、例えば、 "*.example.com"）またはそのフラグメントとして（例：*oo.example.com、f*o.example.com、またはfo*.example。com）。いわゆる「ワイルドカード証明書」のより詳細な議論は、セクション7.2に基づいて提供されています。
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.
クライアントは、許容可能な参照識別子のリストを作成する必要があり、サービスによって提示された識別子とは無関係にそうする必要があります。
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.
クライアントは、受信した入力からソースドメインとアプリケーションサービスタイプを抽出する必要がある場合があります。抽出されたデータには、入力から安全に解析できる情報のみを含める必要があります（たとえば、URIの「ホスト」コンポーネント（または同等）から完全に適格なDNSドメイン名を解析するか、スキームからアプリケーションサービスタイプを導出するURIの）またはネットワーク攻撃者による転覆の対象ではない方法で派生した情報（たとえば、クライアントまたはシステム構成を介して明示的に確立された委任ドメインからデータを引き出し、[DNSSEC]を介してデータを解決するか、または取得します。人間のユーザーが明示的に信頼を置いており、クライアントが相互認証と整合性チェックの両方を提供する接続または関連性を介して通信したサードパーティドメインマッピングサービスからのデータ。これらの考慮事項は、入力からソースドメインの抽出にのみ適用されます。当然のことながら、入力自体が無効または破損している場合（たとえば、ユーザーがフィッシング攻撃で悪意のあるエンティティが提供するリンクをクリックした場合）、クライアントは予期しないアプリケーションサービスと通信することになります。
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.
リスト内の各参照識別子は、ソースドメインに基づいている必要があり、派生ドメイン（たとえば、ソースドメインのDNS解像度で発見されたホスト名またはドメイン名）に基づいてはなりません。ユーザー入力と提示された識別子の一致のみが、クライアントがクライアントのサーバーとの通信を確保するために正当に使用できることをクライアントが確認できるようにすることができるため、このルールは重要です。インタラクティブなクライアントがこのルールの推奨事項をオーバーライドし、ソースドメイン以外のドメイン名と通信することが許容できるシナリオは1つだけです。人間のユーザーがアプリケーションサービスの証明書を代替ドメインに「ピン留め」したためセクション6.6.4およびセクション7.1でさらに説明する名前。この場合、クライアントが参照識別子のリストを作成するために使用する入力には、複数の完全に適格なDNSドメイン名、つまり（a）ソースドメインと（b）ピン留め証明書に含まれる代替ドメインの両方が含まれる場合があります。
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を含める必要があります。タイプDNS-IDの参照識別子は、（a）入力（すなわち、ソースドメイン）に含まれる、または安全に導出された（a）、または（b）ソースドメインに明示的に関連付けられている（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を含める必要があります。
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を含める必要があります。
o The list MAY include a CN-ID, mainly for the sake of backward compatibility with deployed infrastructure.
o リストには、主に展開されたインフラストラクチャとの後方互換性のために、CN-IDが含まれる場合があります。
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.
セキュリティ警告：クライアントは、タイプの共通名のもの以外の相対的な識別名（RDN）に対応する参照識別子を構築してはなりません。
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証明書の形でサーバーの提示された識別子を受信すると、クライアントは一致を見つける目的で提示された識別子に対して参照識別子をチェックします。クライアントが一致を見つけることなく参照識別子のリストを排出すると、検索に失敗します。提示された識別子が参照識別子の1つと一致する場合、検索は成功します。その時点で、クライアントは検索を停止する必要があります。
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の参照識別子の一致を求めてはなりません。
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ドメイン名部分と一致する必要があります（また、セクション6.5で説明されているようにアプリケーションサービスタイプも確認する必要があります）。ルールは、チェックされるドメインが「従来のドメイン名」または「国際化されたドメイン名」であるかどうかによって異なります（セクション2.2で定義されています）。さらに、ワイルドカード文字「*」を含む提示された識別子をサポートするクライアントのニーズを満たすために、いわゆる「ワイルドカード証明書」の補足ルールを定義します。最後に、「CN-ID」識別子タイプを確認することが許容される状況も指定します。
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ドメイン名部分が「従来のドメイン名」である場合、[参照識別子と提示された識別子と一致する場合、[ケース]無意識のASCII比較を使用してドメイン名ラベルのセットを比較することにより実行されます。dns-case]（例：「www.example.com」は、比較目的で「www.example.com」に低くなります）。各ラベルは、ワイルドカードラベルのチェックに関するルールで補足されている場合を除き、名前を一致させるために一致する必要があります（セクション6.4.3）。
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ラベル[idna-defs]をA-labelsに変換する必要があります。[idna-proto]に従って、a-labelsは症例感受性ASCIIとして比較する必要があります。各ラベルは、ワイルドカードラベルのチェックに関するルールで補足されている場合を除き、ドメイン名を一致させるために一致する必要があります（セクション6.4.3;ただし、国際化されたドメイン名のワイルドカードに関するセクション7.2も参照してください）。
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ドメイン名部分にワイルドカード文字「*」がラベルの一部またはすべてとして含まれる提示された識別子と一致する場合があります（[DNSコンセプト]のラベルとドメイン名の説明に従って）。
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. クライアントは、ワイルドカード文字が左端のラベル以外のラベルを構成する提示された識別子と一致させようとしないでください（例：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. WildCard文字が提示された識別子の左概算ラベルの唯一の文字である場合、クライアントは参照識別子の左概念ラベル以外のものと比較してはなりません（たとえば、 *.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. クライアントは、ワイルドカード文字がラベルの唯一の文字ではない提示された識別子と一致させることができます（例：baz*.example.netおよび*baz.example.netおよびb*z.example.netがBaz1に一致すると見なされます.example.netおよびfoobaz.example.netとbuzz.example.net、それぞれ）。ただし、クライアントは、国際化ドメイン名[IDNA-Proto]のAラベルまたはUラベル[IDNA-DEFS]にワイルドカード文字が埋め込まれている提示された識別子と一致させようとしてはなりません。
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の参照識別子の一致を求めてはなりません。
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、またはクライアントがサポートするアプリケーション固有の識別子タイプを含まない場合にのみ、クライアントは、その文字列の最後の手段としてクライアントとして、フォームは、サブジェクトフィールドの一般名フィールド（つまり、CN-ID）の完全に適格なDNSドメイン名のそれと一致します。クライアントがその文字列に対してタイプCN-IDの参照識別子を比較することを選択した場合、説明されているように、dns-id、srv-id、またはuri-idのタイプの識別子のDNSドメイン名部分の比較ルールに従う必要があります。セクション6.4.1、セクション6.4.2、およびセクション6.4.3に基づきます。
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ドメイン名部分だけでなく、アプリケーションサービスタイプの部分も確認する必要があります。識別子をDNSドメイン名部分とアプリケーションサービスタイプ部分（セクション6.3で説明）に分割し、DNSドメイン名部分（セクション6.4で説明）とアプリケーションサービスタイプ部分の両方を確認することにより、これを行います。以下のサブセクションで説明されています。
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]に従って、ケースに依存しない方法で一致する必要があります。「_」文字は、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]に従って、ケース非感受性の方法で一致する必要があります。「：」文字はスキーム名と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として一致した参照識別子を使用する必要があります。
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。
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の不一致を通知し、悪い証明書エラーで通信試行を自動的に終了する必要があります。この動作は、ユーザーが敵対的な状況でセキュリティ保護を不注意にバイパスすることを妨げるため、好ましいです。
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.
それ以外の場合、クライアントが人間のユーザーによって直接制御されていない自動化されたアプリケーションである場合、悪い証明書エラーを使用して通信試行を終了し、エラーを適切に記録する必要があります。自動化されたアプリケーションは、この動作を無効にする構成設定を提供する場合がありますが、デフォルトで動作を有効にする必要があります。
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ドメイン名に「ピン留め」されると言われています（例えば、ユーザーは、「emple.com」のソースドメインに関連付けられたドメインとして「apps.example.net」を明示的に承認しました。Cached Name Associationは、提示された証明書と、それが受け入れられた、または構成されたコンテキストの両方を考慮する必要があります（「コンテキスト」には、提示された証明書から信託アンカー、ソースドメイン、アプリケーションサービスタイプへの証明書のチェーンが含まれています。、サービスの派生ドメインとポート番号、およびユーザーが提供する、またはクライアントが関連付けたその他の関連情報。
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:
このドキュメントでは、WildCard文字「*」は提示された識別子に含めるべきではなく、アプリケーションクライアントがチェックすることができると述べています（主に展開されたインフラストラクチャとの後方互換性のため）。その結果、このドキュメントで提供される規則は、多くの既存のアプリケーションテクノロジー（付録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ラベルまたはuラベル[idna-defs]にワイルドカード文字をどのように埋め込むかを定義する仕様はありません。その結果、実装は、国際化されたドメイン名のAラベルまたはUラベル内に埋め込まれたワイルドカードのキャラクターを含める、またはチェックしようとすることを強く妨げています（例： "xn-kcry6tjko*.example.org"）。ただし、提示されたドメイン名識別子には、その文字が左端のラベルポジション全体を占める限り、ワイルドカード文字を含むことができることに注意してください。（例えば、 "*.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を完全に禁止することは望ましいことですが、現時点では、この仕様が含まれるべきではないと述べている理由がいくつかあります。
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.
[DNSConcepts] 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。、および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.
[キーワード] 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.、および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。、および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。および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.、およびS. Rose、「DNSセキュリティの紹介と要件」、RFC 4033、2005年3月。
[DTLS] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security", RFC 4347, April 2006.
[DTLS] Rescorla、E。および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>.
[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/ブラウザフォーラム、「拡張検証証明書の発行と管理のガイドライン」、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。および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。、および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]ソコル、J。およびR.ハンセン、「https can byte me」、ブラックハットアブダビ、2010年11月、<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。、および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。および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。、および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。および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。、および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.、および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。、および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。、および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.
[プライベート] Rekhter、Y.、Moskowitz、R.、Karrenberg、D.、Groot、G。、および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。および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。、および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。、および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編、「認証のための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。、および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。、および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。、および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。および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.
[使用]ニューマン、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]国際電気通信同盟、「情報技術-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アドレス（つまり、ドメインパート）を含める必要があります。[この仕様]で定義されているルールとガイドラインは、XMPPサーバー証明書に適用され、次の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 XMPPクライアントおよびサーバーソフトウェアの実装では、DNS-ID識別子タイプ[PKIX]のサポートが必要です。XMPP固有の証明書を発行する認定当局は、DNS-ID識別子タイプをサポートする必要があります。XMPPサービスプロバイダーには、証明書リクエストにDNS-ID識別子タイプを含める必要があります。
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クライアントおよびサーバーソフトウェアの実装に必要です（検証のためにXMPPクライアントの実装は「_XMPP-Client」アプリケーションサービスタイプのみをサポートする必要がありますが、XMPPサーバーの実装は両方をサポートする必要があります。「_xmpp-client」および「_xmpp-server」アプリケーションサービスタイプ）。XMPP固有の証明書を発行する認定当局は、SRV-ID識別子タイプをサポートする必要があります。XMPPサービスプロバイダーには、証明書リクエストにSRV-ID識別子タイプを含める必要があります。
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ドメイン名には、識別子内の完全な左のラベルとしてワイルドカード文字 '*'が含まれている場合があります。
###### 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交渉中、クライアントは、中間の攻撃を防ぐために、サーバー証明書メッセージに表示されるサーバーのIDに対してサーバーのホスト名の理解を確認する必要があります。一致は、これらのルールに従って実行されます。
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 クライアントは、接続を開くために使用されるサーバーホスト名を使用して、サーバー証明書で表現されているサーバー名と比較する値として値として使用する必要があります。クライアントは、安全でないリモートソースから派生したサーバーホスト名の形式（例：安全でないDNSルックアップ）を使用してはなりません。CName Canonicalizationは行われていません。
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のsubmestaltname拡張機能が証明書に存在する場合、サーバーのIDのソースとして使用する必要があります。
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 「*」ワイルドカード文字は、証明書の左端の名前コンポーネントとして使用できます。たとえば、 *.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.
一致が失敗した場合、クライアントは明示的なユーザーの確認を要求するか、接続を終了し、サーバーのIDが疑わしいことを示す必要があります。
######
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を繰り返すことにより生成されます。結果として、サーバーのホスト名はクライアントに知られています。ホスト名が利用可能な場合、クライアントは、中間の攻撃を防ぐために、サーバーの証明書メッセージに表示されているようにサーバーのIDに対してそれを確認する必要があります。
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.
クライアントがサーバーの予想されるIDに関する外部情報を持っている場合、ホスト名チェックは省略される場合があります。（たとえば、クライアントはアドレスとホスト名が動的であるが、クライアントがサーバーが提示する証明書を知っているマシンに接続している可能性があります。）そのような場合、許容可能な証明書の範囲を可能な限り狭めることが重要です。中央の攻撃で人間を防ぐために。特別な場合、クライアントがサーバーのIDを単純に無視することは適切かもしれませんが、これにより接続がアクティブな攻撃に開かれたままになることを理解する必要があります。
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のsumbercaltname拡張が存在する場合、それはIDとして使用する必要があります。それ以外の場合、証明書の件名フィールドの（最も具体的な）一般名フィールドを使用する必要があります。一般名の使用は既存の慣行ですが、それは非推奨であり、認証当局は代わりにDNSNameを使用することを奨励されています。
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.
ホスト名が証明書のIDと一致しない場合、ユーザー指向のクライアントは、ユーザーに通知する必要があります（クライアントは、いずれにしてもユーザーに接続を継続する機会を与えます）か、悪い証明書エラーで接続を終了する必要があります。自動化されたクライアントは、エラーを適切な監査ログ（利用可能な場合）にログに記録する必要があり、接続を終了する必要があります（悪い証明書エラーを使用）。自動化されたクライアントは、このチェックを無効にする構成設定を提供する場合がありますが、それを有効にする設定を提供する必要があります。
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.
クライアントは、中間の攻撃を防ぐために、サーバーの証明書メッセージに表示されるサーバーのIDに対してサーバーのホスト名の理解を確認する必要があります。
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接続を開くために使用されるサーバーホスト名を使用して、サーバーの証明書で表現されているサーバー名と比較する値として値として使用する必要があります。クライアントは、サーバーの標準的なDNS名またはその他の派生形式の名前を使用してはなりません。
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のsubmestaltname拡張機能が証明書に存在する場合、サーバーのIDのソースとして使用する必要があります。
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ベースのIDと一致しない場合、ユーザー指向のクライアントはユーザーに通知する必要があります（クライアントはユーザーに接続を継続する機会を与えるか、接続を終了し、接続を終了し、サーバーのIDが疑わしいことを示します。自動化されたクライアントは、接続を閉じて、サーバーのIDが疑わしいことを示すエラーを返したり記録したりする必要があります。
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.
このセクションで説明されているサーバーのIDチェックを超えて、クライアントは、提供することが観察されるサービスを提供することをサーバーが許可されていることを確認するために、さらにチェックする準備をする必要があります。クライアントは、ローカルポリシー情報を使用する必要がある場合があります。
######
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".
中間の攻撃を防ぐために、クライアントはサーバーのIDを確認する必要があります（サーバーの証明書メッセージに示されているように）。このセクションでは、サーバーのID（通常、輸送接続の確立に使用されるID）に対するクライアントの理解は、「参照ID」と呼ばれます。
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.
サーバーIDのチェックが失敗した場合、ユーザー指向のクライアントはユーザー（クライアントにユーザーにLDAPセッションを継続する機会を与えることができます）か、トランスポート接続を閉じて、サーバーのIDが疑わしいことを示します。自動化されたクライアントは、トランスポート接続を閉じてから、サーバーのIDが疑わしいかその両方であることを示すエラーを返したりログにしたりする必要があります。
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:
参照IDが国際化されたドメイン名である場合、適合実装は、タイプDNSNAMEのsubjectAltName値と比較する前に、RFC 3490 [IDNA2003]のセクション4で指定されているように、ASCII互換エンコード（ACE）形式に変換する必要があります。具体的には、適合実装は、次のようにRFC 3490のセクション4で指定された変換操作を実行する必要があります。
o in step 1, the domain name SHALL be considered a "stored string";
o ステップ1では、ドメイン名は「保存された文字列」と見なされます。
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.
「to-ascii」変換を実行した後、RFC3490のセクション3で指定されたルールに従って、DNSラベルと名前を平等と比較する必要があります。
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.
参照IDがIPアドレスである場合、IDは「ネットワークバイトの順序」Octet String表現[IP] [IPv6]に変換する必要があります。IPバージョン4の場合、RFC 791で指定されているように、オクテット文字列には正確に4オクテットが含まれます。IPバージョン6の場合、RFC 2460で指定されているように、オクテット文字列には正確に16のオクテットが含まれます。次に、このOctet文字列は、iPaddressのタイプのsumbutaltname値と比較されます。参照IDオクテット文字列と値のオクテット文字列が同一である場合、一致が発生します。
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.
クライアントの実装は、他のドキュメントで説明されているように、他のタイプのsumberaltaltname値との一致をサポートする場合があります。
######
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]交渉が成功した後、クライアントは、中間の攻撃を防ぐために、サーバー証明書メッセージに表示されるサーバーのIDに対してサーバーのホスト名の理解を確認する必要があります。一致が失敗した場合、クライアントはSASLプレーンメカニズムを使用して認証を試みてはなりません。マッチングは、次のルールに従って実行されます。
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.
クライアントは、接続を開くために使用されるサーバーホスト名を使用して、サーバー証明書で表現されているサーバー名と比較する値として値として使用する必要があります。クライアントは、安全でないリモートソースから派生したサーバーホスト名の形式（例：安全でないDNSルックアップ）を使用してはなりません。CName Canonicalizationは行われていません。
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のsubmestaltname拡張機能が証明書に存在する場合、サーバーのIDのソースとして使用する必要があります。
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.
「*」ワイルドカード文字は、証明書の左端の名前コンポーネントとして使用できます。たとえば、 *.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ピアが別のピアと安全に通信する場合、ピアの証明書を検証する必要があります。可能な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つのことのいずれかを行う必要があります。
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]で説明されているルールに従って、ピアの予想される身元に対して証明書を確認する必要があります。ただし、タイプ「XMPP」の件名拡張は、存在する場合はIDとして使用する必要があります。これらのチェックのいずれかが失敗した場合、ユーザー指向のクライアントは、ユーザーに通知する必要があります（クライアントは、いずれにしてもユーザーに接続を継続する機会を与えます）か、悪い証明書エラーで接続を終了する必要があります。自動化されたクライアントは、接続を終了し（悪い証明書エラーを使用して）、エラーを適切な監査ログにログに記録する必要があります。自動化されたクライアントは、このチェックを無効にする構成設定を提供する場合がありますが、それを有効にする設定を提供する必要があります。
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. ピアは、認定パス全体を含め、承認のために証明書をユーザーに表示する必要があります。ピアは証明書（またはハッシュなどの忘れられない表現）をキャッシュする必要があります。将来の接続では、ピアは同じ証明書が提示されたことを確認し、ユーザーが変更された場合にユーザーに通知する必要があります。
In Case #2 and Case #3, implementations SHOULD act as in (2) above.
ケース＃2およびケース＃3では、上記の（2）のように実装が機能する必要があります。
###### 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交渉中、クライアントは、中間の攻撃を防ぐために、サーバー証明書メッセージに表示されるサーバーのIDに対してサーバーのホスト名の理解を確認する必要があります。一致は、これらのルールに従って実行されます。
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]）で指定されたホスト名）を使用する必要があります。クライアントは、安全でないリモートソースから派生したサーバーホスト名の形式（例：安全でないDNSルックアップ）を使用してはなりません。CName Canonicalizationは行われていません。
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のsubmestaltname拡張機能が証明書に存在する場合、サーバーのIDのソースとして使用する必要があります。
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 「*」ワイルドカード文字は、証明書の左端の名前コンポーネントとして使用できます。たとえば、 *.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コマンドとの接続を終了し、サーバーのIDが疑わしいことを示す必要があります。
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).
さらに、クライアントは、接続するサーバーのIDとそれらのサーバーが提示するパブリックキーの間のバインディングを検証する必要があります。クライアントは、一般証明書の検証のために[PKIX]のセクション6にアルゴリズムを実装する必要がありますが、そのアルゴリズムは、同等のレベルの検証を実現する他の検証方法で補完する場合があります（既に検証された証明書とIDのローカルストアとサーバー証明書を比較するなど、バインディング）。
######
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.
サーバーのIDは、パスワードベースの認証データまたは構成または状態データがサーバーから送信または受信される前に、ローカルポリシーに従ってクライアントによって検証および認証される必要があります。また、クライアントの識別は、ローカルポリシーに従ってサーバーによって検証および認証されなければなりません。これは、クライアントに送信またはクライアントから受信される前に、着信クライアント要求が合法であることを確認する必要があります。どちらの側も、反対側に未知の、予期しない、または誤ったアイデンティティを持つSSH接続を介してネットコンを確立する必要はありません。
######
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交渉中、クライアントは、サーバーが提示した証明書を慎重に調べて、クライアントの期待を満たしているかどうかを判断する必要があります。特に、クライアントは、中間の攻撃を防ぐために、サーバー証明書メッセージに表示されるサーバーのIDに対してサーバーのホスト名の理解を確認する必要があります。
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]）で指定されたホスト名）を使用して、サーバー証明書で表現されているサーバー名と比較する値として使用する必要があります。クライアントは、安全でないリモートソースから派生したサーバーホスト名の形式（例：安全でないDNSルックアップ）を使用してはなりません。CName Canonicalizationは行われていません。
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のsumbestaltname拡張機能が証明書に存在する場合、サーバーのIDのソースとして使用する必要があります。
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 「*」ワイルドカード文字は、証明書の左端の名前コンポーネントとして使用できます。たとえば、 *.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.
一致が失敗した場合、クライアントは明示的なユーザーの確認を要求するか、接続を終了し、サーバーのIDが疑わしいことを示す必要があります。
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).
さらに、クライアントは、接続するサーバーのIDとそれらのサーバーが提示するパブリックキーの間のバインディングを検証する必要があります。クライアントは、一般証明書の検証のために[PKIX]のセクション6にアルゴリズムを実装する必要がありますが、そのアルゴリズムは、同等のレベルの検証を実現する他の検証方法で補完する場合があります（既に検証された証明書とIDのローカルストアとサーバー証明書を比較するなど、バインディング）。
If the client has external information as to the expected identity of the server, the hostname check MAY be omitted.
クライアントがサーバーの予想されるIDに関する外部情報を持っている場合、ホスト名チェックは省略される場合があります。
######
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]をサポートする必要があります。さらに、ローカルで構成されたホスト名を使用して認定ピアを指定し、次のように証明書に対して名前を一致させることをサポートする必要があります。
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に対してローカルに構成されたホスト名と一致することをサポートする必要があり、サブジェクトの識別名の共通名部分に対して名前をチェックすることをサポートする必要があります。
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で許可されています（およびホスト名の保存に使用する場合は、共通名で）が、その値の左端（最も重要ではない）dnsラベルとしてのみです。このワイルドカードは、サーバー名の左端のDNSラベルと一致します。つまり、件名 *.example.comはサーバー名A.example.comおよびB.Example.comと一致しますが、example.comまたはA.B.example.comと一致しません。実装は、上記で指定されているように証明書のワイルドカードをサポートする必要がありますが、それらを無効にする構成オプションを提供する場合があります。
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 ローカルで構成された名前には、値の範囲に合わせてワイルドカード文字が含まれる場合があります。サポートされているワイルドカードの種類は、主題名で許可されているものよりも柔軟性があり、さまざまな環境のさまざまなポリシーをサポートすることが可能になります。たとえば、ポリシーでは、特定のCAトラストルートによって発行されたすべての資格情報が承認されるトラストルートベースの承認を可能にする可能性があります。
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）形式に変換する必要があります。
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 実装は、件名拡張機能に保存されているiPaddressに対してローカルで構成されたIPアドレスと一致することをサポートする場合があります。この場合、[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名コンポーネントのみを比較する必要があります。実装は、比較でスキームやパラメーターを使用してはなりません。
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名として比較する必要があります。つまり、比較は[DNS-Case]で指定されているとおり、症例が鈍感であることを意味します。実装は、[PKIX]のセクション7.2に従って、国際化ドメイン名（IDN）を処理する必要があります。
Implementations MUST match the values in their entirety:
実装は、値全体と一致する必要があります。
Implementations MUST NOT match suffixes. For example, "foo.example.com" does not match "example.com".
実装はサフィックスと一致してはなりません。たとえば、「foo.example.com」は「Example.com」と一致しません。
Implementations MUST NOT match any form of wildcard, such as a leading "." or "*." with any other DNS label or sequence of labels. For example, "*.example.com" matches only "*.example.com" but not "foo.example.com". Similarly, ".example.com" matches only ".example.com", and does not match "foo.example.com."
実装は、主要な「」などのワイルドカードと一致してはなりません。また "*。"他のDNSラベルまたはラベルのシーケンス。たとえば、「*.example.com」は「*.example.com」のみに一致しますが、「foo.example.com」ではありません。同様に、「.example.com」は「.example.com」のみに一致し、「foo.example.com」と一致しません。
[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 実装は、件名の拡張機能フィールドのDNSNameとの予想ホスト名の一致をサポートする必要があり、サブジェクトの著名な名前の共通名部分に対して名前をチェックすることをサポートする場合があります。
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で許可されています（およびホスト名を保存するために使用される場合は共通名で）が、その値の左端（最も重要ではない）dnsラベルとしてのみです。このワイルドカードは、サーバー名の左端のDNSラベルと一致します。つまり、件名 *.example.comはサーバー名A.example.comおよびB.Example.comと一致しますが、example.comまたはA.B.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）形式に変換する必要があります。
If the expected host name fails these conditions then the connection MUST be closed.
予想されるホスト名がこれらの条件に失敗した場合、接続を閉じる必要があります。
######
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認証の後、ノードは、中間の攻撃を避けるためにピアが提示した身元を確認し、ピアがGIST層でのシグナリングに参加することが許可されていることを確認する必要があります。承認チェックは、セクション4.4.2で説明されているように、提示されたアイデンティティを各認定ピアデータベース（APD）エントリと比較することにより実行されます。このセクションでは、単一のAPDエントリのID比較アルゴリズムを定義します。
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認証の場合、証明書に存在するタイプDNSNAMEの各subjectAltName拡張に対してDNS名前空間からのIDを確認する必要があります。そのような拡張機能が存在しない場合、証明書の件名フィールドの（最も具体的な）一般名と同一性を比較する必要があります。DNS名をDNSNAMEまたは共通名フィールドに対して一致させる場合、マッチングはケース非感受性です。また、「*」ワイルドカード文字は、APDの証明書またはIDの左端の名前コンポーネントとして使用できます。たとえば、APDの *.example.comは、a.example.com、foo.example.com、 *.example.comなどの証明書と一致しますが、example.comと一致しません。同様に、 *.example.comの証明書は、a.example.com、foo.example.com、 *.example.comなどのAPD IDに対して有効ですが、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).
さらに、ノードは、接続するピアのアイデンティティと、そのピアが提示した公開鍵の間のバインディングを検証する必要があります。ノードは、一般証明書の検証のために[PKIX]のセクション6にアルゴリズムを実装する必要がありますが、そのアルゴリズムは、同等のレベルの検証を実現する他の検証方法で補完する場合があります（既に検証された証明書とアイデンティティのローカルストアとサーバー証明書を比較するなど。バインディング）。
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（サーバーID、つまり応答ノード）またはPSK_IDENTITY（クライアントID、つまりクエリノード）のIDは、APDのIDと比較する必要があります。
######
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