Internet Engineering Task Force (IETF) P. Saint-Andre
Request for Comments: 6125 Cisco
Category: Standards Track J. Hodges
ISSN: 2070-1721 PayPal
March 2011
Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)
トランスポート層セキュリティ（TLS）のコンテキストでX.509（PKIX）証明書を使用したインターネット公開鍵インフラストラクチャ内のドメインベースのアプリケーションサービスのアイデンティティの表現と検証
Abstract
抽象
Many application technologies enable secure communication between two entities by means of Internet Public Key Infrastructure Using X.509 (PKIX) certificates in the context of Transport Layer Security (TLS). This document specifies procedures for representing and verifying the identity of application services in such interactions.
多くのアプリケーション技術は、トランスポート層セキュリティ（TLS）の文脈でX.509（PKIX）証明書を使用して、インターネット公開鍵インフラストラクチャによって、2つのエンティティ間の安全な通信を可能にします。この文書では、このような相互作用におけるアプリケーションサービスのアイデンティティを表現し、検証するための手順を指定します。
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.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報が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.
著作権（C）2011 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明4.eおよび簡体BSDライセンスで説明したように、保証なしで提供されているよう簡体BSDライセンスのテキストを含める必要があり、この文書から抽出されました。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
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（例えば、「example.comのウェブサイト」）のいくつかの概念を参照します。同様に、TLSネゴシエーション中に、サーバーは、X.509を使用して、インターネット公開鍵インフラストラクチャのコンテキストで認証局（CA）によって発行された公開鍵証明書の形でサービスのアイデンティティのその概念を提示し、[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.
多くのアプリケーション技術がちょうど概説パターンに準拠しています。このようなプロトコルは、伝統的に表現すると、アプリケーションサービスの身元を確認するための独自のルールを指定しています。残念ながら、アプローチのこの乖離は、証明機関、アプリケーション開発者、およびプロトコル設計者の間でいくつかの混乱を引き起こしました。
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を使用するアプリケーションプロトコルでの使用を意図した証明書でアプリケーションサービスのアイデンティティを表現し、検証するための推奨手順を指定します。
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].
この文書アドレスは、リーフ「エンドエンティティ」サーバー証明書ではなく、サーバ証明書を検証するために使用される証明書のチェーンに任意の名前のフォームのフォームに名前を付けます。したがって、適切な認証を保証するために、アプリケーション・クライアントは、[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証明書内のアプリケーション・サービス・アイデンティティの表現と検証のための推奨手順を提供します。
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.
dNSName：Oを含むとその目的のために設計さSubjectAlternativeNameの延長を経てDNSドメイン名を確認するに向かって移動します。
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を含むプロトコルを使用するための適切な一層特定SubjectAlternativeNameの拡張機能を確認向かって移動（例えば、uniformResourceIdentifierで及び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]
インターネットメッセージアクセスプロトコル[IMAP]およびポストオフィスプロトコル[POP3] O; [USINGTLS]も参照
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-TLS]と[SYSLOG-DTLS]も参照
o The Session Initiation Protocol [SIP]; see also [SIP-CERTS]
セッション開始プロトコル[SIP] O。 [SIP-CERTS]も参照
o The Simple Network Management Protocol [SNMP]; see also [SNMP-TLS]
簡易ネットワーク管理プロトコル[SNMP] O;参照[SNMP-TLS]
o The General Internet Signalling Transport [GIST]
一般的なインターネットシグナリング交通[GIST] O
However, as noted, this document does not supersede the rules for verifying service identity provided in specifications for those application protocols.
しかし、述べたように、このドキュメントはこれらのアプリケーションプロトコルの仕様で提供されるサービスの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).
この文書は、とだけPKIXベースのシステムにのみTLSとDTLS（または古いのSecure Sockets Layer（SSL）技術）に、完全修飾DNSドメイン名に関連するサービスのIDに適用されます。 （それらは将来の仕様によって対処されるかもしれないが）その結果、次のセクションで説明したシナリオは、本明細書の範囲外です。
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.
クライアントまたはエンドユーザのアイデンティティ（例えば、rfc822Nameで識別子）を表す証明書は、このように強力なクライアント・サーバ・セキュリティやエンドツーエンドのセキュリティを可能にする、クライアントとサーバとの間または2つのクライアント間の相互認証のために使用することができます。しかし、認証機関、アプリケーション開発者、およびサービス事業者は、このように私たちに一般化するこれからの少数のモデルとベストプラクティスを定義するための少ない強固な基盤を与えて、サーバ証明書を持つよりも、クライアント証明書と少ない経験を持っています。
o Identifiers other than fully qualified DNS domain names.
完全修飾DNSドメイン名以外のO識別子。
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アドレスのための異なる位置からのホストの異なるアドレスで得プライベート[PRIVATE]のインターネット、ホストモビリティ、特定のホスト上の複数のインタフェース、ネットワークアドレス変換の有無器（NAT）のアプリケーション・サービスのための信頼性の識別子は、必ずしもではありませんネットワーク等、単一のIPアドレスの後ろに一緒に多くのホストをグループ化の実践は、ほとんどの基本的に、ほとんどのユーザーは、ドメイン名システムが最初に設計された理由であるIPアドレスを、よりで作業する方がはるかに簡単DNSドメイン名を見つけます。私たちは、はるかに一般的なユースケースのためのベストプラクティスを定義するには、この仕様でルールを複雑にしないことを好みます。
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).
さらに、我々は、アプリケーション・サービス・アイデンティティではなく、そのようなサービスにある特定のリソースにここに焦点を当てます。したがって、この文書は[URI]のみ（URI「ホスト」コンポーネントまたはその等価物を介して）DNSドメイン名を通信するための手段としてではなく、そのような特定のリソース（のようなサービスの他の側面を通信するための方法として、ユニフォームリソース識別子を議論します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.
[TLS]、[DTLS]、または古いのSecure Sockets Layer（SSL）技術以外のセキュリティ・プロトコルO。
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の]、または（自己署名証明書を使用するか、直接証明書失効リストに依存することはできませんので、公共のインターネットに接続されていないネットワーク上に展開されているに似てCRL）またはオンライン証明書状態プロトコル[OCSP] CAが発行した証明書をチェックします。しかし、OpenPGPの中で識別子に公開鍵を結合させる方法は、X.509のメソッドから、本質的に異なり、自己署名証明書のデータはどのような方法で第三者によって認定され、CA-発行された証明書のチェックされていませんCRLのか、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.
DNSドメイン名のO決議。
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ベースの構築のための口語名称。 [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）では、代表団の一例は、情報を取得するか、ユーザーのアカウント名のサーバ部分と異なる場合がありますネットワークに接続するために使用される特定のホストのドメイン名を指定したアカウントのセットアップです（例： 、juliet@example.comの電子メールアドレスをホストしているIMAPサーバ）に接続するためのmailhost.example.comのサーバ。ケース（b）において、委譲の一例は、管理者が設定したホストからアドレス/アドレス・ツー・ホストルックアップテーブルです。
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値は、ドメイン名の全体的な形状と一致するものとタイプ共通名（CN）の唯一の属性タイプと値のペアが含まれている証明書のサブジェクトフィールドに相対識別名（RDN）を= （非公式に、ドットで区切られた文字、数字、ハイフンのラベル）。また、[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あるタイプのotherNameの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は、（ここで引用された用語の「REG-名」ルールと一致する値（I）A「スキーム」及び（ii）「ホスト」コンポーネント（またはその等価物）の両方を含むタイプuniformResourceIdentifierでののsubjectAltNameエントリ= [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つとの間にキャッシュされた名前の関連付けを確立する行為。ピニングは、人間のユーザが積極的にアプリケーションサービスと通信しようとする時に不一致を受け入れるようにすることによって達成されます。キャッシュされた名前の関連付けが確立されると、証明書は、参照識別子にし、将来の通信に固定されると言わクライアントは単に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は、X.509v3証明書の仕様のプロファイルとX.509v2証明書失効リストで使用するため（CRL）の仕様を含む、[PKIX] RFC 5280で定義されたX.509を使用して、インターネット公開鍵インフラストラクチャのための短い名前です。インターネット。
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証明書内のサーバからクライアントに提示された識別子。証明書は、異なるタイプの一つ以上の提示された識別子を含むことができ、そして、サーバが複数のドメインをホストする場合、証明書は、ドメインごとに個別の識別子を提示するかもしれません。
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.
ソースドメイン：クライアントは、アプリケーションサービス（例えば、「www.example.com」）証明書に提示する予定の完全修飾DNSドメイン名は、人間のユーザによって一般的に入力が、クライアントに構成、またはそのような参照が提供しますハイパーリンクのように。ソースドメインの組み合わせと、必要に応じて、アプリケーションサービスタイプは、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]参照します）。より具体的には、この用語は、しばしば（[PKIX]のセクション4.1.2.6を参照）X.501タイプ名としてエンコードされ、証明書のサブジェクトフィールドで搬送、PKIX証明書のサブジェクト名を指します。
TLS client: An entity that assumes the role of a client in a Transport Layer Security [TLS] negotiation. In this specification we generally assume that the TLS client is an (interactive or automated) application client; however, in application protocols that enable server-to-server communication, the TLS client could be a peer application service.
TLSクライアント：トランスポート層セキュリティ[TLS]交渉におけるクライアントの役割を担っているエンティティ。この仕様では、一般的にTLSクライアントが（対話型または自動化された）アプリケーションクライアントであることを前提としています。ただし、サーバー間通信を可能にするアプリケーションプロトコルで、TLSクライアントは、ピアアプリケーションサービスである可能性があります。
TLS server: An entity that assumes the role of a server in a Transport Layer Security [TLS] negotiation; in this specification we assume that the TLS server is an application service.
TLSサーバ：トランスポート層セキュリティ[TLS]交渉中のサーバーの役割を前提としたエンティティ。この仕様では、我々は、TLSサーバは、アプリケーション・サービスであることを前提としています。
Most security-related terms in this document are to be understood in the sense defined in [SECTERMS]; such terms include, but are not limited to, "attack", "authentication", "authorization", "certification authority", "certification path", "certificate", "credential", "identity", "self-signed certificate", "trust", "trust anchor", "trust chain", "validate", and "verify".
この文書に記載されているほとんどのセキュリティ関連の用語は[SECTERMS]で定義された意味で理解されるべきです。このような用語には、それだけ、「攻撃」、「認証」、「認証」、「認証局」、「証明書パス」、「証明書」、「資格」、「アイデンティティ」に限定されるものではなく、「自己署名証明書」 、「信頼」、「トラストアンカー」、「信頼の連鎖」、「検証」、および「検証」。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [KEYWORDS].
キーワード "MUST"、 "MUST NOT"、 "REQUIRED"、 "SHALL"、 "SHOULD"、 "ないもの"、 "推奨" "ない（SHOULD NOT）"、 "MAY"、 "推奨NOT"、および「OPTIONAL RFC 2119に記載されているように「この文書の[KEYWORDS]解釈されるべきです。
This section discusses naming of application services on the Internet, followed by a brief tutorial about subject naming in PKIX.
このセクションでは、PKIXの被写体の命名についての簡単なチュートリアルが続き、インターネット上のアプリケーションサービスの命名について説明します。
This specification assumes that the name of an application service is based on a DNS domain name (e.g., "example.com") -- supplemented in some circumstances by an application service type (e.g., "the IMAP server at example.com").
この仕様では、アプリケーション・サービスの名前がDNSドメイン名に基づいていることを前提とし（例えば、「example.com」） - アプリケーションサービスの種類によっていくつかの状況で補足し（例えば、「example.comでIMAPサーバ」） 。
From the perspective of the application client or user, some names are direct because they are provided directly by a human user (e.g., via runtime input, prior configuration, or explicit acceptance of a client communication attempt), whereas other names are indirect because they are automatically resolved by the client based on user input (e.g., a target name resolved from a source name using DNS SRV or NAPTR records). This dimension matters most for certificate consumption, specifically verification as discussed in this document.
彼らは人間のユーザによって直接提供されるため、他の名前が間接ているのに対し、アプリケーションクライアントやユーザーの視点からは、いくつかの名前は、（例えば、実行時の入力、以前の設定、またはクライアントの通信の試行の明示的な承諾を経て、）直接のある彼ら理由自動的にユーザの入力に基づいてクライアントによって解決されている（例えば、ターゲット名は、DNS SRVやNAPTRレコードを使用して、ソース名から解決します）。この寸法は、証明書の消費量は、この文書で説明したように、具体的検証のために最も重要。
From the perspective of the application service, some names are unrestricted because they can be used in any type of service (e.g., a certificate might be reused for both the HTTP service and the IMAP service at example.com), whereas other names are restricted because they can be used in only one type of service (e.g., a special-purpose certificate that can be used only for an IMAP service). This dimension matters most for certificate issuance.
他の名前が制限されているのに対し、彼らは、（例えば、証明書がexample.comで、HTTPサービスおよびIMAPサービスの両方のために再利用される可能性があります）サービスのいずれかのタイプに使用することができるため、アプリケーションサービスの観点から、いくつかの名前は無制限です彼らはサービスの一種類のみで使用することができるので（例えば、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]).
しかし、それは、それぞれのアプリケーションプロトコルは、少なくとも積極的に使用したり、その技術（そのようなコミュニティ、CA /ブラウザフォーラムをサポートするソフトウェア開発者、アプリケーションサービスプロバイダ、および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:
本明細書の目的のために、アプリケーション・サービスの名前（またはに基づいている）は、以下のいずれかの形式に準拠するDNSドメイン名：
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.
1.「伝統的なドメイン名」は、すなわち、完全修飾DNSドメイン名または「FQDN」は、そのラベル[IDNA-DEFS]に記載されているように、「LDHラベル」でのすべてが（[DNS-CONCEPTS]を参照します）。非公式に、そのような標識は、最初の文字位置に禁止ハイフンで、[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.「国際化ドメイン名」、すなわち、ドメイン名（非公式に、ドットで区切られた文字、数字、ハイフンラベル）の全体的な形状に適合しなく適切にエンコードされたUnicodeコードポイントを含む少なくとも1つの標識を含むDNSドメイン名伝統的なUS-ASCIIの範囲外。すなわち、それは、少なくとも1つのUラベル又はラベルが含まれ、それ以外は[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.501]と[X.500]で定義されたグローバルディレクトリサービスモデルを採用しています。そのモデルでは、情報は、ディレクトリ情報ベース（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、およびRDNの）からの重要な概念を借りて、そのような証明書は必ずしもグローバルディレクトリ情報の一部ではありませんベース。具体的には、PKIX証明書のサブジェクトフィールドはX.501タイプ名が「サブジェクト公開鍵フィールドに格納された公開鍵に関連付けられたエンティティを識別する」ことである（[PKIX]のセクション4.1.2.6を参照）。しかし、対象フィールドがあれば証明書がsubjectAltName拡張は、様々なアイデンティティがバインドされることを可能にするため、少なくとも一つの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）及び/又はのsubjectAltNameエントリ内の次の識別子タイプのいずれかで運ば名前または名前によって識別することができます。
o DNS-ID
OのDNS-ID
o SRV-ID
OのSRV-ID
o URI-ID
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):
既存の証明書は、多くの場合、完全修飾DNSドメイン名を表すために、件名フィールドにCN-IDを使用します。例えば、タイプ共通名の属性は "フォーム（「im.example.org」、「mail.example.net」完全修飾DNSドメイン名のそれと一致する文字列が含まれ、以下の3つのサブジェクト名を検討www.example.com」、それぞれ）：
CN=im.example.org,O=Example Org,C=GB
CN = im.example.org、O =実施例組織、C = GB
C=CA,O=Example Internetworking,CN=mail.example.net
C = CA、O =実施例インターネットワーキング、CN = mail.example.net
O=Examples-R-Us,CN=www.example.com,C=US
O =例-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
CNは、無料チャットサービスを=、O =例組織、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
CNは、無料チャットサービスを=、CN = im.example.org、O =例組織、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）を用いて符号化されます。しかし、いくつかの実装では、証明書発行者、件名フィールド、およびsubjectAltName拡張の表示（別名印刷可能な）レンダリングを生成し、これらのレンダリングが表示される前に「文字列表現」にDER符号化された配列を変換します。 （タイプ名の[X.509]、識別名（DN）[X.501]と同じ）、証明書のサブジェクトフィールドは、順序付けられたシーケンスであるため、順序は、典型的には、対象文字列表現に保存されている二つの最も普及しているものの被験者（およびDN）文字列表現右から左への順序対左から右への採用が異なります。相対識別名（RDN）は、属性タイプと値のペアの順序付けられていないグループがあるためしかし、RDNの文字列表現は正規DER符号化（及び属性タイプと値のペアの順序は異なることができますさまざまな実装によって提供されるRDNの文字列表現又は表示注文）が異なることができます。さらに、様々な仕様は、「少なくとも特異的」対「最も具体的な」として、暗黙的に（又は実際に存在してもしなくてもよい）情報の階層に関連するDNSまたは用語を使用して、証明書のサブジェクトフィールドでのRDNの順序を指し、「左端の一番右の」対 『』、 『最初最後『または 『『最下位』対』最も重要な』対』（[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]から「件名欄に（最も特定の）Common Nameフィールドを」という用語を使用して、代わりにCN-IDが1を含む証明書のサブジェクトに相対識別名（RDN）された状態はありませんタイプ共通名の、唯一の属性タイプと値のペア（タイプCNのため、RDNは、複数の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ドメイン名を解決するために、あなたの技術を使用したDNS SRVレコードをしていますか？もしそうなら、あなたの技術コミュニティで発行され、使用さPKIX証明書にSRV-IDの識別子タイプのサポートを推薦するか、必要と考えます。 （多くの既存のアプリケーション技術がアプリケーションサービスのDNSドメイン名を解決するためのDNS SRVレコードを使用しますが、[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ドメイン名にワイルドカード文字を許可する必要がありますか？その場合は、ワイルドカード証明書のサポートを推薦考慮し、ワイルドカード文字が発生することが許可されている場所を正確に指定します（たとえば、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ドメイン名に基づいて証明書を発行すると、次のルールは、アプリケーション・サービス・アイデンティティの表現に適用されます。読者は、これらの規則のいくつかは累積され、この文書の後半で説明される重要な方法で相互作用することができることを認識する必要があります。
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.証明書を利用したサービスは、関連する仕様（例えば、これは[XMPP]についても同様である）、次いで、証明書はSRV-IDを含むべきである証明書は、タイプ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).
証明書を利用したサービスは、関連する仕様は、証明書がタイプURI-IDの識別子を含むべきことを規定した技術を展開した場合3.（例えば、これは、[SIP-CERTS]で指定された[SIP]の真のですが、真実ではありません[HTTP]以来[HTTP-TLS] HTTPサービスのURI-IDの使用を記載していない）、その後、証明書はURI-IDを含むべきです。スキームは、アプリケーションサービスタイプと「ホスト」コンポーネント（またはその等価物）に関連するプロトコルのものでなければならないサービスの完全修飾DNSドメイン名でなければなりません。これを再利用する仕様は、[URIスキームはで説明したようにアプリケーションプロトコル（例えば、「SIP」ではなくSIPのための「一口」または「TEL」に使用PKIX証明書に含まれるURI-IDの中で許容されるとみなされるべきであるかを指定しなければなりませんSIP-SIPS]、またはおそらくHTTPおよびHTTPS HTTPの将来明細書に記載されるかもしれないように）。
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]の出版前に定義されたタイプの他のアプリケーション固有の識別子を含む（例えば、XmppAddr [XMPP]）またはそのためのサービス名または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.
多く展開されたクライアントはまだ証明書のサブジェクトフィールド内CN-IDの確認5.にもかかわらず、証明機関は、CN-IDに、サーバの完全修飾DNSドメイン名を表す証明書を発行することから離れて移行することをお勧めします。認証機関はこの1つを再利用し、それが明示的に指定したアプリケーション技術の文脈で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.証明書は、複数のDNS-ID、SRV-ID、またはURI-IDを含んでいてもよいが、さらなるセクション7.4の下で説明し、複数の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.
この1つはワイルドカード文字「*」のための継続的な支援を可能にする、提示された識別子のDNSドメイン名部分には、次の識別子内で完全一番左のラベル（のようにするかどうか、ワイルドカード文字を含めることはできません再利用して仕様がない限り7.例えば、[DNS-CONCEPTS]のラベルとドメイン名の説明において、 "* .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.
DNSのSRVルックアップを経て発見されていない、「www.example.com」で簡単なウェブサイトを考えてみましょう。 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.
「example.net」のアプリケーション・サービス名のDNS SRVルックアップを介した形「user@example.net」と発見の電子メールアドレスをサービスするホスト「mail.example.net」でIMAPアクセス可能な電子メールサーバを考えてみましょう。このサービスの証明書は、「example.net」および「mail.exampleのDNS-IDが一緒に「_imap.example.net」および「_imaps.example.net」のSRV-IDを（[EMAIL-SRV]を参照）が含まれる場合があります。ネット"。また、「example.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.
SIPアクセス可能なボイスオーバーIP（VoIP）のサーバーのホストで「voice.example.edu」形式のSIPアドレスをサービスする「user@voice.example.edu」を検討し、<SIPのURIで識別：声。 example.edu>。このサービスの証明書は、 "SIP：voice.example.edu" のURI-IDを含むであろう（参照[SIP-CERTS]） "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.
「im.example.org上のDNS SRVルックアップを介したXMPP互換のインスタントメッセージング（IM）「user@im.example.org」形式のIMアドレスをサービスする「im.example.org」ホストのサーバーや発見を考えてみましょう"ドメイン。このサービスのための証明書は、 "_xmpp-client.im.example.org" と "_xmpp-server.im.example.org" のSRV-IDを（[XMPP]参照）、DNS-ID im.example」のが含まれる場合があります.ORG」、およびXMPP特異的 " "im.example.org" の" 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を含み、証明書を要求することが奨励されているアプリケーションサービスタイプ、SRV-ID又はURI-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を使用して証明書の適用を制限したい場合は、サービスプロバイダが奨励されています複数の証明書、つまり、アプリケーションサービスの種類ごとに証明書を要求します。逆に、サービスプロバイダは、それぞれ異なるアプリケーションサービスタイプを識別する複数SRV-IDまたはURI-IDを含む単一の証明書を要求してからお勧めします。このガイドラインは、同じ基本アプリケーション（例えば、「IMAP」のアプリケーションサービスの種類によって示されるアクセス方法が電子メールアプリケーション、「IMAPS」にマニホールドの異なるアクセス方法を識別するために使用されているアプリケーションサービスタイプ「バンドル」には適用されません、 "POP3"、 "POP3S"、および "提出" [EMAIL-SRV]に記載されているように）。
This section provides rules and guidelines for implementers of application client software regarding algorithms for verification of application service identity.
このセクションでは、アプリケーション・サービス・アイデンティティの検証のためのアルゴリズムに関するアプリケーション・クライアント・ソフトウェアの実装のためのルールやガイドラインを提供します。
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):
ハイレベルでは、クライアントが（このドキュメントの以下のサブセクションで定義されている）、下記のアクションを実行することにより、アプリケーションサービスのIDを検証します。
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.
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.
当然のことながら、識別子のチェックに加えて、クライアントは、サーバが要求されたサービスを提供するために許可されていることを確認するためにさらにチェックを完了することがあります。しかし、そのようなチェックは、証明書に示されたアプリケーションサービスの身元を確認する問題ではなく、そのため（例えば、ローカルポリシー情報をコンサルティング）そのようにするための方法は、この文書の範囲外です。
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.
参照識別子のリストを構築するために、クライアントによって使用される入力は、ユーザがインターフェース（例えば、ウェブサイトのHTTPS URL）に入力されたことをURIであるかもしれない、設定されたアカウント情報（例えば、特定のホストのドメイン名またはURIは、メディアオブジェクトやスクリプト、または情報の他のいくつかの組み合わせを取得するには、ブラウザをトリガーするWebページでは、）ハイパーリンクを情報の取得またはユーザ名のDNSドメイン名の部分と異なる場合がありますネットワークに接続するために使用されますそれは、ソースドメインおよびアプリケーションサービスの種類を得ることができます。
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.
クライアントは、それが受信した入力（S）からソースドメインおよびアプリケーションサービスタイプを抽出する必要があります。抽出されたデータを確実にURIの入力（例えば、「ホスト」コンポーネント（またはその等価物のうち完全修飾DNSドメイン名を解析する）のうち解析またはスキームからアプリケーション・サービス・タイプを導出することができるだけの情報を含まなければなりません明示[DNSSEC]を介してデータを解決し、クライアントまたはシステムの構成を介して確立され、または取得された委任のドメインからデータを引っ張って、ネットワークの攻撃者（例えばによる転覆を受けないようにして導出されるURI）または情報のサードパーティ製のドメインマッピングサービスからのデータとは、人間のユーザが明示的に信頼を置いているし、これでクライアントは、相互認証と整合性チェック）の両方を提供して接続または関連付けを介して通信します。これらの考慮事項は、入力のみから元ドメインの抽出に適用されます。入力自体が無効であるか、または破損している場合には、当然、（例えば、ユーザーがフィッシング攻撃では、悪意のあるエンティティによって提供されたリンクをクリックした）、その後、クライアントは、アプリケーションが予期せずサービスとの通信に終わるかもしれません。
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).
例：<一口：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解決を介して発見された）に基づいてされるべきではありません。ユーザ入力と提示された識別子の間の唯一の試合は、クライアント証明書が合法的にサーバとクライアントの通信を保護するために使用できることを確認することができますので、このルールは重要です。それは、このルールに勧告をオーバーライドするため、元のドメイン以外のドメイン名と通信する対話型のクライアントのために許容される唯一のシナリオがあります：人間のユーザは、代替ドメインへのアプリケーションサービスの証明書を「固定」しているので、さらに、セクション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）に含まれるか、安全入力（すなわち、ソースドメイン）に由来する完全修飾DNSドメイン名から構成され、または（b）明示的にソースドメインに関連付けることができます（すなわち、派生ドメイン）ユーザ設定による。
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.
アプリケーションサービスの種類のサーバは、通常のDNS SRVレコードによって発見された場合、O、そしてリストは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.
アプリケーションサービスタイプのサーバは、典型的に（すなわち、正式なプロトコル文書は、サーバ証明書内のURIの使用を指定）セキュリティ目的のためにURIに関連付けられている場合、O、リストは、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.
どの識別子のタイプのクライアントが参照識別子のリストに含まれるローカルポリシーの問題です。例えば、特定の配備環境で、内蔵されているクライアントは、アプリケーション・サービス・タイプにSRV-IDを含む有効な証明書のみを受け入れるように設定されるかもしれない唯一のサービス（例えば、唯一のIMサービス）の特定の種類に接続します。この場合、クライアントは、参照識別子のリスト（ない、例えば、DNS-ID）をアプリケーションサービスタイプに一致のみSRV-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の）に対応する参照識別子を構築してはならないと発表識別子でタイプ共通名以外の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".
2つの参照識別子を持っているかもしれない「www.example.com」のウェブサイトにHTTPS経由で接続されたWebブラウザ：のDNS-ID「www.example.com」と、フォールバック、「WWWのCN-IDとして.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.)
「example.net」で電子メールサービスにIMAPS経由で接続されたメールユーザエージェントは、5つの参照識別子を持っているかもしれません（「mail.example.net」として解決）：「_imaps.example.net」のSRV-ID（参照[EMAIL-SRV]）、 "example.net" および "mail.example.net" のDNS-ID、および、 "example.net" および "mail.example.net" の代替、CN-IDなど。 （従来の電子メールユーザエージェントは[EMAIL-SRV]をサポートしていませんので、SRV-意識し、ユーザーエージェントがメールアドレスから「example.net」を導き出すだろう一方で、おそらく、明示的に、「mail.example.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」のURI-ID（「voice.example.edu」における音声サービスにSIPを介して接続されるボイスオーバーIP（VoIP）のユーザエージェントは、唯一の参照識別子を有するかもしれません[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]).
「im.example.org」でIMサービスへのXMPP経由で接続しているインスタントメッセージング（IM）クライアントは、3つの参照識別子を持っているかもしれません：SRV-ID「_xmpp-client.im.example.org」のを（[XMPPを参照してください"im.example.org" の "im.example.org" の]）、DNS-ID、および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証明書の形式で、サーバーの提示した識別子を受信すると、クライアントが一致を見つけるために、提示された識別子に対するその参照識別子をチェックします。クライアントが一致を検出することなく、参照識別子のリストを使い果たした場合、検索は失敗します。いずれかの提示された識別子は、クライアントが検索を停止する必要があり、その時点で参照識別子のいずれかを、一致した場合、検索は成功します。
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
O型DNS-IDの参照識別子は、アプリケーションサービスタイプ部分を含んでいないので、比較の目的のためにDNSドメイン名として直接使用することができます。一例として、A
DNS-ID of "www.example.com" would result in a DNS domain name portion of "www.example.com".
「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).
タイプCN-IDの参照識別子oを、アプリケーションサービスタイプ部分を含んでいないので、比較の目的のために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-名」「ホスト」コンポーネント（またはその等価物）の一部とアプリケーションサービスタイプ部分は、スキームに関連付けられているアプリケーションサービスタイプであります（「：」セパレータを含まない）[URI]から[ABNF]「スキーム」ルールと一致する名前。前述したように、この文書は、URI-IDは、常に「REG-name」を含む「ホスト」コンポーネント（またはそれに相当）が含まれていることを指定します。 （これにより、IPアドレス、または単なるホスト名が含まれているuniformResourceIdentifierでエントリからURI-IDを区別する、DNSドメイン名の制限の検証[URI]からのみ、「REG-名」ルールと一致、またはそれは「ホストが含まれていません[URI]で説明したようにREG-名」成分は全く。）また、の抽出を注意 『』（URIの正規化が必要かもしれません）。一例として、「SIP：voice.example.edu」のURI-ID「はvoice.example.edu」のDNSドメイン名部分と「SIP」のアプリケーションサービスタイプに分割されることになる（アプリケーションプロトコルに関連付けられていますSIPのように、[SIP-CERTS]で説明）。
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]を変換しなければなりません。 [IDNA-PROTO]に従って、A-ラベルは、大文字と小文字を区別しないASCIIとして比較されなければなりません。各ラベルは、ワイルドカードラベルのチェックについてのルールによって補完される場合を除き、一致すると見なされるドメイン名の順序に一致する必要があります（;しかし、国際化ドメイン名でのワイルドカードについても、7.2節を参照してください6.4.3項）。
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-CONCEPTS]のラベルとドメイン名の説明の後）のラベルのすべてのようにワイルドカード文字「*」が含まれ提示された識別子に対する参照識別子にマッチします。
For information regarding the security characteristics of wildcard certificates, see Section 7.2.
ワイルドカード証明書のセキュリティ特性に関する情報については、7.2節を参照してください。
If a client matches the reference identifier against a presented identifier whose DNS domain name portion contains the wildcard character '*', the following rules apply:
クライアントは、DNSドメイン名部分はワイルドカード文字「*」が含まれ提示された識別子に対する参照識別子と一致した場合、次の規則が適用されます。
1. The client SHOULD NOT attempt to match a presented identifier in which the wildcard character comprises a label other than the left-most label (e.g., do not match bar.*.example.net).
1.クライアントは、ワイルドカード文字は、一番左のラベル以外のラベルを含む、提示された識別子と一致するように試みるべきではありません（例えば、バーと一致していません。*。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.ワイルドカード文字が提示された識別子で一番左のラベルの文字のみである場合は、クライアントが参照識別子の一番左のラベル以外のものに対して比較を行うべきではない（例えば、* .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.クライアントは、ワイルドカード文字は、ラベルのみの文字（例えば、バズ* .example.netと* baz.example.net、およびb *のz.example.netがに取られるだろうされていないで提示された識別子と一致するかもしれませんマッチbaz1.example.netとfoobaz.example.netとbuzz.example.net、それぞれ）。ただし、クライアントは、ワイルドカード文字は、A-ラベルまたはU-ラベル国際化ドメイン名の[IDNA-DEFS] [IDNA-PROTO]内に埋め込まれ提示された識別子と一致するように試みるべきではありません。
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、またはクライアントがサポートする任意のアプリケーション固有の識別子の種類、文字列の最後のチェックとして、クライアントMAYが含まれていない場合に限り、フォームは、サブジェクトフィールド（すなわち、CN-ID）のCommon Nameフィールドに、完全修飾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.4で説明したように）、アプリケーションサービスタイプ部分の両方をチェックし、（セクション6.3で説明したように）、DNSドメイン名部分及びアプリケーションサービスタイプの部分に識別子を分割することによってこれを行います以下のサブセクションで説明します。
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クライアント」および「apps.example.net」の「im.example.org」と（b）のDNSドメイン名のDNSドメイン名のアプリケーションサービスタイプの。それは「_xmppクライアントのSRV-IDを持っていないので、しかし、クライアントは、（c）は、「XMPPクライアント」および「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レコードでのサービス識別子にして（[SRVNAME]あたり）SRV-IDの中で先頭に追加されるので、任意の比較に含める必要はないことに注意してください。
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.
マッチング手順の結果は、次のような場合のいずれかです。
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チェックが成功しました。この場合、クライアントは、アプリケーション・サービスの検証アイデンティティとしてマッチした参照識別子を使用しなければなりません。
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で説明したように、コンテキストを含む固定証明書と一致します。
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で説明したように、クライアントは続行しなければなりません0.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.
クライアントが直接人間のユーザによって制御され、対話型クライアントである場合、それはアイデンティティの不一致をユーザに通知する必要があり、自動的に悪い証明書エラーとの通信の試行を終了します。それは不注意敵対状況でセキュリティ保護をバイパスからユーザーを防止するため、この現象が好ましいです。
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).
セキュリティ警告：一部の対話型のクライアントは、これにより、この通信の試みのためにクライアントによって構築され、リスト内の参照識別子のいずれかに証明書を「ピン留め」、上級ユーザーに身元の不一致にもかかわらず、受け入れを進めるのオプションを与えます。この動作は、特定の特殊な状況で適切なことができますが、一般的には上級ユーザーにのみ公開されるべきです。高度なユーザーは全体の認証パスを表示するようにユーザに強制のみ次いでせることにより、とにかく続行することを選択した場合でも、それは、最初の通信の試行を終了するためにも高度なユーザを促すことによって、例えば、細心の注意を払って処理する必要があると（ユーザーの選択により、一時的または永続的に、）証明書を固定するためのユーザー。
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
セクション1.8の下で定義されているように、証明書は、（ユーザーが明示的に証明書が他のDNSドメイン名が含まれているという事実にもかかわらず、そのDNSドメイン名を持つサービスの証明書を関連付けるために選択したDNSドメイン名に「固定」されると言われている例、ユーザーが明示的に）「example.com」のソースドメインに関連付けられているドメインとして「apps.example.net」を承認しました。キャッシュされた名前協会
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).
証明書が提示され、それが受け入れられるかに構成されたコンテキスト（「文脈」はトラストアンカー、ソースドメイン、アプリケーションサービスの種類に提示した証明書から証明書のチェーンが含まれ、サービスの派生の両方を考慮しなければなりませんドメインとポート番号、およびその他の関連情報のクライアントによってユーザによって提供されるか、または関連します）。
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:
この文書では、ワイルドカード文字「*」を提示した識別子に含まれるべきではありませんが、（主に展開インフラストラクチャとの下位互換性のために）、アプリケーションクライアントによって確認することができることを述べています。結果として、本書で提供されるルールは、（付録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ワイルドカード証明書は自動的に自分のドメイン内の任意のおよびすべてのホスト名を保証します。これにより、管理者のための便利なことだけでなく、不正やバグのホストのバウチングのリスクをもたらすことができます。例えば[倒す-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既存のアプリケーション技術の仕様は、このようなことができるかどうかなど、ワイルドカード文字の許容場所について明確か、一貫性がありません。
* 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)
一番左のラベルの*いくつかの断片（例えば、* .example.comのFOは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-ラベルまたは国際化ドメイン名（例えば、「 - kcry6tjko * .example.org XN」）のU-ラベル内に埋め込まれたワイルドカード文字を確認しようとしてから、推奨されています。提示したドメイン名識別子がいる限り、その文字が残っているラベルの全てが有効なNR-LDHラベル、-ラベル、またはU-ラベルで全体の一番左のラベルの位置を占めるようにワイルドカード文字を含むことができること、しかし、注意してください（例えば、 "* .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]).
彼らは（[EV-CERTS]、例えば、参照）、このような展開インフラストラクチャとの下位互換性を保つように行うには十分な理由を持っている場合は、上記のセキュリティの考慮事項にもかかわらず、これを再利用する仕様は、合法的にワイルドカード文字のための継続的な支援を奨励することができます。
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]で指定されたより最近のアプローチは、それが望むまたはサービスに期待するDNSドメイン名を規定、CLIENT_HELLOメッセージを送信するときにTLS「サーバ名の表示」（SNI）拡張子を使用するクライアントのためです。サービスは、その証明書のメッセージに適切な証明書を返すことができ、かつその証明書は、単一の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を禁止するのが好ましいだろうが、この仕様は、彼らが（代わりにはならない（MUST NOT））に含まれるべきではないと述べている理由は、この時点でいくつかの理由があります。
o At least one significant technology community of interest explicitly allows multiple CN-IDs [EV-CERTS].
O関心の少なくとも一つの重要な技術コミュニティは、明示的に複数のCN-IDが[EV-CERTS]ことができます。
o At least one significant certification authority is known to issue certificates containing multiple CN-IDs.
O少なくとも一つの重要な認証局は、複数の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.
少なくとも一つの広く展開されているオペレーティングシステムがまだSNI拡張をサポートしていないため、O、多くのサービスプロバイダーは、多くの場合、仮想ホスティング環境で必要な複数の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「ボブ・モーガン、およびクルト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.
バーナードAboba、リチャード・バーンズ、ウリブルーメンソール、ネルソンBolyard、カスパー・ブランド、アンソニー・ブライアン、スコット・カントール、ワン・テー・チャン、ビリルビンコリー、デイブCridland、デイヴ・クロッカー：編集者と貢献者は、彼らのフィードバックと提案のために以下の個人に感謝したいです、サイラスDaboo、チャールズ・ガーディナー、フィリップ・ギュンター、フィリップハラム - ベイカー、ブルーノHarbulot、ウェスHardaker、デヴィッド・ハリントン、ポール・ホフマン、愛Hornquist Astrand、ヘンリー・ホッツ、ラスHousley、ジェフリーHutzelman、カレン・ジェニングス、サイモンJosefsson氏、ジェフ・キーティング、ジョンKlensin、スコット・ローレンス、マット・McCutchen、アレクセイ・メルニコフ、サブラマニアンMoonesamy、エディNigg、ルートヴィヒNussel、ジョー・オートン、トム・ペッチ、Yngve N. Pettersenの、ティムポーク、ロバートRelyea、エリックレスコラ、ピート・レズニック、マーティン・レックス、ジョーSalowey、ステファンSantesson、ジムSchaad、ロブStradling、マイケルStroeder、アンドリュー・サリバン、ピーター・シルベスター、マーティン・トムソン、ポール・ティーマン、ショーン・ターナー、ニコラス・ウィリアムズ、ダン・ウィング、ダン・ウィンシップ、そしてステファン・ウィンター。
Thanks also to Barry Leiba and Ben Campbell for their reviews on behalf of the Security Directorate and the General Area Review Team, respectively.
それぞれのセキュリティ総局と一般エリアレビューチームに代わって彼らのレビューのためにも、バリー・レイバとベン・キャンベルに感謝します。
The responsible Area Director was Alexey Melnikov.
責任エリアディレクターはアレクセイ・メルニコフました。
[DNS-CONCEPTS] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.
[DNS-CONCEPTS] Mockapetris、P.、 "ドメイン名 - 概念と施設"、STD 13、RFC 1034、1987年11月。
[DNS-SRV] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000.
[DNS-SRV] Gulbrandsenの、A.、いるVixie、P.、およびL. Esibov、 "（DNSのSRV）サービスの位置を特定するためのDNS RR"、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.
[キーワード]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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.、エド、 "ライトウェイトディレクトリアクセスプロトコル（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]クーパー、D.、Santesson、S.、ファレル、S.、Boeyen、S.、Housley氏、R.、およびW.ポーク、「インターネット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]バーナーズ - リー、T.、フィールディング、R.、およびL. Masinter、 "ユニフォームリソース識別子（URI）：汎用構文"、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]クロッカー、D.、エド。そして、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]イーストレイク3日、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]アレンズ、R.、Austeinと、R.、ラーソン、M.、マッシー、D.、およびS.ローズ、 "DNSセキュリティ序論と要件"、RFC 4033、2005年3月。
[DTLS] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security", RFC 4347, April 2006.
[DTLS]レスコラ、E.およびN. Modadugu、 "データグラムトランスポート層セキュリティ"、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氏/ブラックハット-DC -09-Marlinspike氏-破っ-SSL.pdf>。
[EMAIL-SRV] Daboo, C., "Use of SRV Records for Locating Email Submission/Access Services", RFC 6186, March 2011.
[EMAIL-SRV] Daboo、C.、RFC 6186、2011年3月、 "電子メールの提出/アクセスサービスの検索のためのSRVレコードの使用"。
[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>.
2009年10月、<http://www.cabforum.org/Guidelines_v1_2.pdf> [EV-CERTS] CA /ブラウザフォーラム、 "発行および拡張検証証明書の管理のためのガイドライン"。
[GIST] Schulzrinne, H. and R. Hancock, "GIST: General Internet Signalling Transport", RFC 5971, October 2010.
[GIST] Schulzrinneと、H.とR.ハンコック、 "GIST：一般的なインターネットシグナリング交通"、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]フィールディング、R.、ゲティス、J.、モーグル、J.、Frystyk、H.、Masinter、L.、リーチ、P.、およびT.バーナーズ - リー、 "ハイパーテキスト転送プロトコル - HTTP / 1.1" 、RFC 2616、1999年6月。
[HTTP-TLS] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[HTTP-TLS]レスコラ、E.、 "HTTPオーバーTLS"、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ミーバイトできる"、ブラックハットアブダビ、2010年11月、<https://media.blackhat.com/bh-ad-10/Hansen/ブラックハット-AD-2010 -Hansen-ソコル-HTTPS-CAN-バイト・ミー・slides.pdf>。
[IDNA2003] Faltstrom, P., Hoffman, P., and A. Costello, "Internationalizing Domain Names in Applications (IDNA)", RFC 3490, March 2003.
[IDNA2003] Faltstrom、P.、ホフマン、P.、およびA.コステロ、 "アプリケーションにおける国際化ドメイン名（IDNA）"、RFC 3490、2003年3月。
[IMAP] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, March 2003.
[IMAP]クリスピン、M.、 "インターネットメッセージアクセスプロトコル - バージョン4rev1"、RFC 3501、2003年3月。
[IP] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[IP]ポステル、J.、 "インターネットプロトコル"、STD 5、RFC 791、1981年9月。
[IPSEC] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[IPSEC]ケント、S.とK. Seo、 "インターネットプロトコルのためのセキュリティアーキテクチャ"、RFC 4301、2005年12月。
[IPv6] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[IPv6の]デアリング、S.とR. Hindenと、 "インターネットプロトコルバージョン6（IPv6）の仕様"、RFC 2460、1998年12月。
[LDAP] Sermersheim, J., "Lightweight Directory Access Protocol (LDAP): The Protocol", RFC 4511, June 2006.
[LDAP] Sermersheim、J.、 "ライトウェイトディレクトリアクセスプロトコル（LDAP）：プロトコル"、RFC 4511、2006年6月。
[LDAP-AUTH] Harrison, R., "Lightweight Directory Access Protocol (LDAP): Authentication Methods and Security Mechanisms", RFC 4513, June 2006.
[LDAP-AUTH]ハリソン、R.、 "ライトウェイトディレクトリアクセスプロトコル（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.、エド、 "ライトウェイトディレクトリアクセスプロトコル（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]ホッジス、J.、モルガン、R.、およびM.ワール、 "ライトウェイトディレクトリアクセスプロトコル（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]エンス、R.、エド。、 "NETCONF構成プロトコル"、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]ワッサーマン、M.とT.ゴダード、 "セキュアシェル上でNETCONF構成プロトコルを使用して（SSH）"、RFC 4742、2006年12月。
[NETCONF-TLS] Badra, M., "NETCONF over Transport Layer Security (TLS)", RFC 5539, May 2009.
[NETCONF-TLS] Badra、M.、RFC 5539、2009年5月、 "トランスポート層セキュリティ（TLS）の上にNETCONF"。
[NNTP] Feather, C., "Network News Transfer Protocol (NNTP)", RFC 3977, October 2006.
[NNTP]フェザー、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]マーチソン、K.、Vinocur、J.、およびC.ニューマン、RFC 4642、2006年10月 "ネットワークニュース転送プロトコル（NNTP）とトランスポート層セキュリティ（TLS）を使用します"。
[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]マイヤーズ、M.、Ankney、R.、Malpani、A.、Galperin、S.、およびC.アダムス、 "X.509のインターネット公開鍵暗号基盤のオンライン証明書状態プロトコル - OCSP"、RFC 2560、1999年6月。
[OPENPGP] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. Thayer, "OpenPGP Message Format", RFC 4880, November 2007.
[OpenPGPの]カラス、J.、Donnerhacke、L.、フィニー、H.、ショー、D.、およびR.セイヤー、 "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.、フォード、W.、ポーク、T.、およびD.ソロ、 "インターネット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]マイヤーズ、J.とM.ローズ、 "ポストオフィスプロトコル - バージョン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.、モスコウィッツ、R.、Karrenberg、D.、グルート、G.、およびE.リア、 "個人的なインターネットのための配分"、BCP 5、RFC 1918、1996年2月[PRIVATE]。
[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.ニュートン、 "SRVのRRを使用したドメインベースのアプリケーションサービスロケーションとダイナミックな委譲発見サービス（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]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "SIP：セッション開始プロトコル" 、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.、ローレンス、S.、およびA.ジェフリー、 "セッション開始プロトコル（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.、RFC 5630、2009年10月 "セッション開始プロトコル（SIP）におけるSIPS URIスキームの使用"。
[SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, October 2008.
[SMTP] Klensin、J.、 "簡易メール転送プロトコル"、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.、エド。そして、A.メルニコフ、エド。、 "認証のための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]ホフマン、P.、RFC 3207、2002年2月 "トランスポート層セキュリティの安全なSMTPのためのSMTPサービス拡張子"。
[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]ハリントン、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.、 "トランスポート層セキュリティ（TLS）簡易ネットワーク管理プロトコル（SNMP）のための輸送モデル"、RFC 5953、2010年8月。
[SYSLOG] Gerhards, R., "The Syslog Protocol", RFC 5424, March 2009.
[SYSLOG] Gerhards氏、R.、 "Syslogのプロトコル"、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.、ペッチ、T. Gerhards氏、R.、およびH.風水、 "データグラムトランスポート層セキュリティ（DTLS）Syslogのための交通のマッピング"、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]ミャオ族、F.、エド。、馬、Y.、エド。、およびJ. Salowey、エド。、 "トランスポート層セキュリティ（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]ダークス、T.およびE.レスコラ、 "トランスポート層セキュリティ（TLS）プロトコルバージョン1.2"、RFC 5246、2008年8月。
[TLS-EXT] Eastlake 3rd, D., "Transport Layer Security (TLS) Extensions: Extension Definitions", RFC 6066, January 2011.
[TLS-EXT]イーストレイク3日、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]米国規格協会、 "コード化文字セット - 情報交換のための7ビットの米国標準コード"、ANSI X3.4、1986。
[USINGTLS] Newman, C., "Using TLS with IMAP, POP3 and ACAP", RFC 2595, June 1999.
[USINGTLS]ニューマン、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.およびT.レスラー、 "Webセキュリティコンテキスト：ユーザーインターフェイスガイドライン"、ワールド・ワイド・ウェブ・コンソーシアム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]国際電気通信連合、「情報技術 - 開放型システム間相互接続 - ディレクトリ：概念、モデルとサービスの概要」、ITU-T勧告X.500、ISO規格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]国際電気通信連合、 "情報技術 - 開放型システム間相互接続 - ディレクトリ：モデル"、ITU-T勧告X.501、ISO規格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]国際電気通信連合、「情報技術 - 開放型システム間相互接続 - ディレクトリ：公開鍵と属性証明書の枠組み」、ITU-T勧告X.509、ISO規格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]国際電気通信連合、「情報技術 - 開放型システム間相互接続 - ディレクトリ：選択した属性の型」、ITU-T勧告X.509、ISO規格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）、Canonicalの符号化規則（CER）、および顕著な符号化規則（DER）の仕様"、ITU-T勧告X.690 、ISO規格8825から1、2008年8月。
[XMPP] Saint-Andre, P., "Extensible Messaging and Presence Protocol (XMPP): Core", RFC 6120, March 2011.
[XMPP]サンアンドレ、P.、 "拡張メッセージングおよびプレゼンスプロトコル（XMPP）：コア"、RFC 6120、2011年3月。
[XMPP-OLD] Saint-Andre, P., Ed., "Extensible Messaging and Presence Protocol (XMPP): Core", RFC 3920, October 2004.
[XMPP-OLD]サンアンドレ、P.、エドは、 "拡張メッセージングおよびプレゼンスプロトコル（XMPP）：コア"。、RFC 3920、2004年10月。
Appendix A. Sample Text
付録A.サンプルテキスト
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.
電子メール[EMAIL-SRV]およびXMPP [XMPP]：この記事の執筆時点では、2つのアプリケーションの技術は、本明細書の勧告を再利用します。ここでは、他のアプリケーション技術のためのプロトコルデザイナーが続くかもしれない思考プロセスを説明する[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:
PKIX証明書内のXMPPサーバ（すなわち、「サーバ証明書」）によって提示されるように、証明書がサーバでホストされているXMPPサービスに関連する1つまたは複数のXMPPアドレス（すなわち、domainparts）を含まなければなりません。 [この仕様]で定義されたルールやガイドラインは以下の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 DNS-IDの識別子タイプのサポート[PKIX]は、XMPPクライアントとサーバソフトウェアの実装で必要とされます。問題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.
XMPPサーバの実装の両方をサポートする必要があるのに対し、SRV-IDの識別子タイプ[SRVNAME] XMPPクライアントとサーバのソフトウェア実装のために必要とされるためOサポート（検証目的のためにXMPPクライアントの実装では、唯一の「_xmppクライアント」アプリケーション・サービス・タイプをサポートする必要があります「_xmpp・クライアント」および「_xmppサーバ」アプリケーション・サービス・タイプ）。問題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開始エンティティは、初期ストリームヘッダに通信アドレス「に」への参照識別子を設定します。すなわち、これは受信エンティティは、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であり;すなわち、これは、開始エンティティが主張しようとしているアイデンティティがあります。
######
＃＃＃＃＃＃
Appendix B. Prior Art
付録B.先行技術
(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内のアプリケーションサービスの身元確認について考えるの歴史を描写するために、この有益なセクションでは、さまざまなRFCからの正確なテキストを含めることによって一緒に先行技術を収集し（唯一の変更は、維持するために、いくつかの参照の名前に変更されていますこの文書の本体との一貫性、および文字でマークされたとして無関係なテキストのエリジオン「[...]」）。
B.1. IMAP, POP3, and ACAP (1999)
B.1。 IMAP、POP3、およびACAP（1999）
In 1999, [USINGTLS] specified the following text regarding application service identity verification in IMAP, POP3, and ACAP:
1999年には、[USINGTLS] IMAP、POP3、およびACAPでアプリケーションサービス身元確認に関する以下のテキストを指定：
######
＃＃＃＃＃＃
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:
man-in-the-middle攻撃を防ぐために、サーバ証明書メッセージに提示される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の正規化が行われていません。
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.
型のdNSNameのsubjectAltName拡張が証明書に存在している場合は、O、それはサーバのアイデンティティの源として使用する必要があります。
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.
証明書が複数の名前（例えば、複数のdNSNameフィールド）が含まれている場合、Oは、フィールドのいずれかとの一致が許容されると考えられます。
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.
マッチが失敗した場合、クライアントは、明示的なユーザの確認を求める、または接続を終了し、サーバのアイデンティティが疑わしいであることを示すべきです。
######
＃＃＃＃＃＃
B.2. HTTP (2000)
B.2。 HTTP（2000）
In 2000, [HTTP-TLS] specified the following text regarding application service identity verification in HTTP:
2000年には、[HTTP-TLS]はHTTPでのアプリケーション・サービス・身元確認に関する以下のテキストを指定しました：
######
＃＃＃＃＃＃
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を逆参照によって生成されます。その結果、サーバのホスト名がクライアントに知られています。ホスト名が使用可能な場合はman-in-the-middle攻撃を防ぐために、サーバーの証明書メッセージに提示され、クライアントはサーバのアイデンティティに対してそれをチェックしなければなりません。
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.
クライアントがサーバの予想身元のような外部の情報を持っている場合は、ホスト名のチェックは省略されるかもしれません。 （例えば、クライアントは、そのアドレスとホスト名動的であるが、クライアントは、サーバが存在することの証明書を認識しているマシンに接続してもよい。）このような場合に、中に可能な限り許容される証明書の範囲を狭くすることが重要ですmiddle攻撃で男を防ぐため。特殊なケースでは、クライアントは、単にサーバーの身元を無視することが適切かもしれませんが、これは積極的な攻撃への接続を開いたままにすることを理解しなければなりません。
If a subjectAltName extension of type dNSName is present, that MUST be used as the identity. Otherwise, the (most specific) Common Name field in the Subject field of the certificate MUST be used. Although the use of the Common Name is existing practice, it is deprecated and Certification Authorities are encouraged to use the dNSName instead.
型のdNSNameのsubjectAltName拡張が存在する場合、それはIDとして使用しなければなりません。それ以外の場合は、証明書のSubjectフィールドで（最も特定の）Common Nameフィールドを使用しなければなりません。共通名の使用は練習を既存しているが、それが廃止されており、認証機関は、代わりの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]によって指定されたマッチングルールを使用して実行されます。与えられたタイプの複数のアイデンティティが証明書に存在している場合（例えば、複数の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アドレスではなくホスト名として指定されています。この場合、IPアドレスの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.
ホスト名が証明書で身元と一致しない場合は、ユーザー指向のクライアントは、ユーザーに通知しなければなりませんいずれか、または不正な証明書エラーとの接続を終了する（クライアントは、ユーザーが任意の場合の接続を継続する機会を与える場合があります）。自動化されたクライアントは、適切な監査ログにエラーを記録しなければならない（可能な場合）と（悪い証明書エラーで）接続を終了すべきです。自動化されたクライアントは、このチェックを無効にしますが、それを可能に設定を提供しなければならない構成設定を提供することができます。
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を交換した可能性があります。この形式の攻撃を防ぐために、ユーザーは慎重に、それは彼らの期待を満たしているかどうかを判断するために、サーバーが提示した証明書を調べる必要があります。
######
＃＃＃＃＃＃
B.3. LDAP (2000/2006)
B.3。 LDAP（2000/2006）
In 2000, [LDAP-TLS] specified the following text regarding application service identity verification in LDAP:
2000年には、[LDAP-TLS]はLDAPでのアプリケーション・サービス・身元確認に関する以下のテキストを指定しました：
######
＃＃＃＃＃＃
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.
man-in-the-middle攻撃を防ぐために、サーバーの証明書メッセージに提示されたクライアントは、サーバーの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.
型のdNSNameのsubjectAltName拡張が証明書に存在している場合は、O、それはサーバのアイデンティティの源として使用する必要があります。
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 a.bar.com、b.bar.comなどにマッチしなくbar.com。与えられたタイプの複数のアイデンティティ証明書（例えば、複数の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と一致しない場合、ユーザー指向のクライアントは、ユーザーに通知する（クライアントは、ユーザーが任意の場合の接続を継続する機会を与えるかもしれない）、または接続を終了すべきでどちらかとサーバのアイデンティティが疑わしいであることを示しています。自動化されたクライアントは、返却および/またはサーバのアイデンティティが疑わしいことを示すエラーをログに記録する、接続を閉じる必要があります。
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.
このセクションで説明するサーバーの身元確認を越えて、クライアントはさらに、サーバは、提供することが観察されたサービスを提供することを許可されていることを確認するチェックを行うために準備する必要があります。クライアントは、ローカルポリシー情報を利用するために必要があるかもしれません。
######
＃＃＃＃＃＃
In 2006, [LDAP-AUTH] specified the following text regarding application service identity verification in LDAP:
2006年には、[LDAP-AUTH]はLDAPでのアプリケーション・サービス・身元確認に関する以下のテキストを指定しました：
######
＃＃＃＃＃＃
In order to prevent man-in-the-middle attacks, the client MUST verify the server's identity (as presented in the server's Certificate message). In this section, the client's understanding of the server's identity (typically the identity used to establish the transport connection) is called the "reference identity".
（サーバのCertificateメッセージに提示される）man-in-the-middle攻撃を防ぐために、クライアントはサーバーの身元を確かめなければなりません。このセクションでは、サーバーの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.
クライアントは、基準同一のタイプ（例えば、DNS名またはIPアドレス）を決定し、基準アイデンティティとマッチが生成されるまで、対応するタイプのそれぞれのsubjectAltName値との比較を行います。試合が生成されると、サーバの身元が確認された、およびサーバのIDチェックが完了しています。異なるのsubjectAltNameタイプが異なる方法で一致しています。セクション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をマッピングすることができます。マッピングは、リファレンスアイデンティティをマッピングすることができるに利用可能なすべてのsubjectAltNameタイプに対して実行されてもよいです。しかし、基準IDは唯一のマッピングがされているタイプのいずれか、本質的に安全な（例えば、型のdNSNameののsubjectAltNameと比較するURIからDNS名を抽出する）、またはそのためのマッピングは、安全な方法で行われる（にマッピングされなければなりません例えば、[DNSSEC]を使用して、またはUSER-または管理者が設定したホストからアドレス/アドレスからホストルックアップテーブル）を使用。
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]の値を参照の同一性を比較することによって確認することができる（ここで、「最後」とはDER符号化された順序ではなく、DER符号化されたデータの文字列表現で提示の順序）。この比較は、ワイルドカードマッチングが許可されないことを除いて、以下のセクション3.1.3.1でDNS名の比較のための規則を使用して行われます。共通名の値の使用は練習を既存しているが、これは廃止され、および認証機関が代わりのsubjectAltName値を提供することが奨励されています。 TLS実装がX.500または他の規則に従って証明書にDNを表してもよいことに留意されたいです。例えば、いくつかの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セッションを継続する機会を与える場合があります）またはトランスポート接続を閉じ、サーバのアイデンティティが疑わしいであることを示しています。自動化されたクライアントは、トランスポート接続をクローズして、サーバのアイデンティティが疑わしいかまたは両方であることを示すエラーを返すか、ログインする必要があります。
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チェックを越えて、クライアントはさらに、サーバは、提供するように要求されたサービスを提供することを許可されていることを確認するチェックを行うために準備する必要があります。クライアントは、この決意を行う際に、ローカルポリシー情報を利用するために必要があるかもしれません。
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は国際化ドメイン名である場合は、RFC 3490のセクション4で指定されるように、適合実装は、型のdNSNameののsubjectAltName値と比較する前に、[IDNA2003] 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で、「UseSTD3ASCIIRules」と呼ばれるフラグを設定します。
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).
ステップ4、工程「もしToASCII」操作で各ラベルにOであり;ステップ5において、O、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.
「へ-ASCII」変換を行った後、DNSラベルと名前がRFC3490のセクション3で指定された規則に従って等しいかどうかを比較しなければなりません。
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と一致していないです。
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アドレスである場合、同一性「とは、ネットワークバイト順」オクテットストリング表現[IP] [IPv6の]に変換されなければなりません。 IPバージョン4の場合、RFC 791で指定されているように、オクテット文字列は正確に4オクテットを含んでいます。 IPバージョン6の場合は、RFC 2460で指定されているように、オクテット文字列は、正確に16オクテットを含んでいます。このオクテット文字列は、その後のタイプIPアドレスののsubjectAltName値と比較されます。参照アイデンティティオクテット文字列と値のオクテット文字列が同一である場合、一致が発生します。
Client implementations MAY support matching against subjectAltName values of other types as described in other documents.
他の文書に記載されているように、クライアントの実装は、他のタイプののsubjectAltName値に対するマッチングをサポートするかもしれません。
######
＃＃＃＃＃＃
B.4. SMTP (2002/2007)
B.4。 SMTP（2002/2007）
In 2002, [SMTP-TLS] specified the following text regarding application service identity verification in SMTP:
2002年には、[SMTP-TLS]はSMTPでのアプリケーション・サービス・身元確認に関する以下のテキストを指定しました：
######
＃＃＃＃＃＃
[...]
「。。。」
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交渉で相手方の信憑性を信じるべきか否かの決定はローカルの問題です。ただし、意思決定のためのいくつかの一般的なルールは以下のとおりです。SMTPクライアントはおそらく唯一のそのサーバー証明書をクライアントがに接続していたと思ったことをドメイン名であるドメイン名を持っているSMTPサーバを認証したいと思うoを。
[...]
「。。。」
######
＃＃＃＃＃＃
In 2006, [SMTP-AUTH] specified the following text regarding application service identity verification in SMTP:
2006年には、[SMTP-AUTH]はSMTPでのアプリケーション・サービス・身元確認に関する以下のテキストを指定しました：
######
＃＃＃＃＃＃
[...]
「。。。」
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:
man-in-the-middle攻撃を防ぐために、サーバ証明書メッセージに提示されるように成功[TLS]交渉の後、クライアントはサーバーのIDに対するサーバーのホスト名のその理解をチェックしなければなりません。マッチが失敗した場合、クライアントはSASL PLAINメカニズムを使用して認証を試みてはいけません。マッチングは次の規則に従って行われます。
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の正規化が行われていません。
If a subjectAltName extension of type dNSName is present in the certificate, it SHOULD be used as the source of the server's identity.
型のdNSNameのsubjectAltName拡張が証明書に存在している場合、それはサーバのアイデンティティの源として使用する必要があります。
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フィールドが）、その後のフィールドのいずれかとの一致が許容されると考えられます。
######
＃＃＃＃＃＃
B.5. XMPP (2004)
B.5。 XMPP（2004）
In 2004, [XMPP-OLD] specified the following text regarding application service identity verification in XMPP:
2004年には、[XMPP-OLD]はXMPPのアプリケーションサービス身元確認に関する以下のテキストを指定しました：
######
＃＃＃＃＃＃
When an XMPP peer communicates with another peer securely, it MUST validate the peer's certificate. There are three possible cases:
XMPPピアがしっかりと他のピアと通信するとき、それはピアの証明書を検証する必要があります。三つの可能なケースがあります。
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]の規則に従ってピア証明書を確認します。証明書は、次に、タイプ「XMPP」のsubjectAltName拡張が存在する場合にはIDとして使用する必要があることを除いて、[HTTP-TLS]に記載の規則に従ってピアの期待アイデンティティと照合されるべきです。これらのチェックのいずれかが失敗した場合、ユーザー指向のクライアントは、ユーザーに通知しなければなりませんいずれか、または不正な証明書エラーとの接続を終了する（クライアントは、ユーザーが任意の場合の接続を継続する機会を与える場合があります）。自動化されたクライアントは、（悪い証明書エラーで）接続を終了し、適切な監査ログにエラーを記録すべきです。自動化されたクライアントは、このチェックを無効にしますが、それを可能に設定を提供しなければならない構成設定を提供することができます。
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でのアプリケーション・サービス・本人確認についてこの文書のルールを再利用します。
B.6. NNTP (2006)
B.6。 NNTP（2006）
In 2006, [NNTP-TLS] specified the following text regarding application service identity verification in NNTP:
2006年には、[NNTP-TLS]はNNTPにおけるアプリケーション・サービス・身元確認に関する以下のテキストを指定しました：
######
＃＃＃＃＃＃
[...]
「。。。」
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:
man-in-the-middle攻撃を防ぐために、サーバ証明書メッセージに提示される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で指定またはホスト名「サーバ名」拡張子[TLS]）接続を開くために使用されるサーバのホスト名を使用しなければなりません。クライアントは、安全でないリモートソース（例えば、安全でないDNSルックアップ）に由来するサーバのホスト名のいずれかの形式を使用してはなりません。 CNAMEの正規化が行われていません。
o If a subjectAltName extension of type dNSName is present in the certificate, it SHOULD be used as the source of the server's identity.
型のdNSNameのsubjectAltName拡張が証明書に存在している場合は、O、それはサーバのアイデンティティの源として使用する必要があります。
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コマンドとの接続を終了し、サーバのアイデンティティが疑わしいであることを示すべきです。
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).
さらに、クライアントは接続先のサーバとそれらのサーバが提示する公開鍵のアイデンティティ間の結合を確かめなければなりません。クライアントは、一般的な証明書の検証のために[PKIX]のセクション6でアルゴリズムを実装する必要がありますが、このような検査済みの証明書及び身元のローカルストアに対してサーバ証明書を比較するなど、検証の同等のレベルを（達成するため、他の検証方法とそのアルゴリズムを補完するかもしれバインディング）。
######
＃＃＃＃＃＃
B.7. NETCONF (2006/2009)
B.7。 NETCONF（2006/2009）
In 2006, [NETCONF-SSH] specified the following text regarding application service identity verification in NETCONF:
2006年には、[NETCONF-SSH]はNETCONFにおけるアプリケーション・サービス・身元確認に関する以下のテキストを指定しました：
######
＃＃＃＃＃＃
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.
パスワードベースの認証データまたは任意の構成や状態データが送られたり、サーバから受信される前に、サーバーの身元は、ローカルポリシーに従ってクライアントによって検証し、認証される必要があります。クライアントのアイデンティティはまた、任意の構成または状態データが送信またはクライアントから受信する前に着信クライアント要求が正当であることを確認するために、ローカルポリシーに従ってサーバによって検証及び認証されなければなりません。どちらの側が反対側に、未知の予期しない、または不正なアイデンティティとのSSH接続経由でNETCONFを確立すべきです。
######
＃＃＃＃＃＃
In 2009, [NETCONF-TLS] specified the following text regarding application service identity verification in NETCONF:
2009年には、[NETCONF-TLS]はNETCONFにおけるアプリケーション・サービス・身元確認に関する以下のテキストを指定しました：
######
＃＃＃＃＃＃
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ネゴシエーション中に、クライアントは慎重に、それは、クライアントの期待を満たしているかどうかを判断するために、サーバーが提示した証明書を調べる必要があります。 man-in-the-middle攻撃を防ぐために、サーバ証明書メッセージに提示される。特に、クライアントはサーバーの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「サーバ名」拡張子[TLS]で指定されたホスト名）サーバ証明書で表されるサーバ名と比較する値としてを開くために使用されるサーバのホスト名を使用しなければなりません。クライアントは、安全でないリモートソース（例えば、安全でないDNSルックアップ）に由来するサーバのホスト名のいずれかの形式を使用してはなりません。 CNAMEの正規化が行われていません。
o If a subjectAltName extension of type dNSName is present in the certificate, it MUST be used as the source of the server's identity.
型のdNSNameのsubjectAltName拡張が証明書に存在している場合は、O、それはサーバのアイデンティティの源として使用しなければなりません。
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.
マッチが失敗した場合、クライアントは、明示的なユーザー確認を求めるか、接続を終了し、サーバのアイデンティティが疑わしいであることを示す必要があります。
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).
さらに、クライアントは接続先のサーバとそれらのサーバが提示する公開鍵のアイデンティティ間の結合を確かめなければなりません。クライアントは、一般的な証明書の検証のために[PKIX]のセクション6でアルゴリズムを実装する必要がありますが、このような検査済みの証明書及び身元のローカルストアに対してサーバ証明書を比較するなど、検証の同等のレベルを（達成するため、他の検証方法とそのアルゴリズムを補完するかもしれバインディング）。
If the client has external information as to the expected identity of the server, the hostname check MAY be omitted.
クライアントがサーバの予想身元のような外部の情報を持っている場合は、ホスト名のチェックは省略されるかもしれません。
######
＃＃＃＃＃＃
B.8. Syslog (2009)
B.8。シスログ（2009）
In 2009, [SYSLOG-TLS] specified the following text regarding application service identity verification in Syslog:
2009年には、[SYSLOG-TLS]はsyslogにアプリケーション・サービス・身元確認に関する以下のテキストを指定しました：
######
＃＃＃＃＃＃
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実装はsubjectAltName拡張に格納されたIPアドレスに対してローカルに設定されたIPアドレスに一致するサポートすることができます。セクション4.2.1.6、[PKIX]で指定されるように、この場合には、ローカルに設定されたIPアドレスは、オクテットストリングに変換されます。このオクテットストリングがsubjectAltName拡張におけるIPアドレスの値と等しい場合にマッチが起こります。
######
＃＃＃＃＃＃
B.9. SIP (2010)
B.9。 SIP（2010）
In 2010, [SIP-CERTS] specified the following text regarding application service identity verification in SIP:
2010年には、[SIP-CERTS]はSIPでのアプリケーション・サービス・身元確認に関する以下のテキストを指定しました：
######
＃＃＃＃＃＃
When an implementation (either client or server) compares two values as SIP domain identities:
実装（クライアントまたはサーバ）は、SIPドメインのIDとして2つの値を比較した場合：
Implementations MUST compare only the DNS name component of each SIP domain identifier; an implementation MUST NOT use any scheme or parameters in the comparison.
実装は、各SIPドメイン識別子のみDNS名コンポーネントを比較しなければなりません。実装は、比較のいずれかの方式やパラメータを使用してはなりません。
Implementations MUST compare the values as DNS names, which means that the comparison is case insensitive as specified by [DNS-CASE]. Implementations MUST handle Internationalized Domain Names (IDNs) in accordance with Section 7.2 of [PKIX].
実装は、[DNS-CASE]によって指定されるように、比較は大文字小文字を区別しないことを意味する、DNS名として値を比較しなければなりません。実装は、[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ドメインの証明書では、このようなワイルドカードを禁止しています。
######
＃＃＃＃＃＃
B.10. SNMP (2010)
B.10。 SNMP（2010）
In 2010, [SNMP-TLS] specified the following text regarding application service identity verification in SNMP:
2010年には、[SNMP-TLS]はSNMPでのアプリケーション・サービス・身元確認に関する以下のテキストを指定しました：
######
＃＃＃＃＃＃
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値で存在する場合、snmpTlstmAddrServerIdentity列は予想ホスト名を含みます。これは、次のようにホスト名は、サーバの証明書と比較されると予想しました。
o Implementations MUST support matching the expected host name against a dNSName in the subjectAltName extension field and MAY support checking the name against the CommonName portion of the subject distinguished name.
O実装はsubjectAltName拡張フィールド内のdNSNameに対して予期されているホスト名と一致するサポートしなければならないと被写体識別名のCommonName部に対して名前をチェックサポートするかもしれません。
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「*」（アスキー0x2a）ワイルドカード文字は、その中にsubjectAltName拡張（および一般名で、ホスト名を格納するために使用される場合）が、唯一のように、一番左の（最下位）DNSラベルののdNSNameで許可されています値。このワイルドカードは、サーバー名に任意の一番左の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.
予想されるホスト名は、これらの条件を失敗した場合、接続は閉じられなければなりません。
######
＃＃＃＃＃＃
B.11. GIST (2010)
B.11。 GIST（2010）
In 2010, [GIST] specified the following text regarding application service identity verification in the General Internet Signalling Transport:
2010年には、[GIST]は、一般的なインターネットシグナリング交通におけるアプリケーションサービスの身元確認に関する以下のテキストを指定しました：
######
＃＃＃＃＃＃
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認証した後、ノードは、man-in-the-middle攻撃を避けるために、ピアによって提示されたアイデンティティをチェックし、ピアはGIST層でのシグナル伝達に参加することを許可されていることを確かめなければなりません。 4.4.2項で述べたように、認可チェックは、順番に各認定ピアデータベース（APD）のエントリで提示アイデンティティを比較することで行われます。このセクションでは、単一のAPDエントリの同一性比較アルゴリズムを定義します。
For TLS authentication with X.509 certificates, an identity from the DNS namespace MUST be checked against each subjectAltName extension of type dNSName present in the certificate. If no such extension is present, then the identity MUST be compared to the (most specific) Common Name in the Subject field of the certificate. When matching DNS names against dNSName or Common Name fields, matching is case-insensitive. Also, a "*" wildcard character MAY be used as the left-most name component in the certificate or identity in the APD. For example, *.example.com in the APD would match certificates for a.example.com, foo.example.com, *.example.com, etc., but would not match example.com. Similarly, a certificate for *.example.com would be valid for APD identities of a.example.com, foo.example.com, *.example.com, etc., but not example.com.
X.509証明書とTLS認証の場合は、DNS名前空間のアイデンティティが証明書に存在するタイプのdNSNameの各subjectAltName拡張に対してチェックしなければなりません。そのような拡張機能が存在しない場合、アイデンティティは、証明書のSubjectフィールドで（最も特定の）一般名と比較されなければなりません。 dNSNameまたは共通名フィールドに対してDNS名を照合すると、マッチングは大文字と小文字を区別しません。また、「*」ワイルドカード文字は、APDで証明書またはアイデンティティで一番左の名前の成分として使用することができます。たとえば、* .example.comとAPDではa.example.com、foo.example.com、* .example.comと、などの証明書と一致しますが、example.comが一致しません。同様に、* .example.comのための証明書がa.example.com、foo.example.com、* .example.comと、などのAPDのアイデンティティのために有効ではなく、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にアルゴリズムを実装する必要があり、そのような検査済みの証明書と同一のローカルストアに対してサーバ証明書を比較するよう検証の等価レベルを（達成する他の検証方法とそのアルゴリズムを補うMAYバインディング）。
For TLS authentication with pre-shared keys, the identity in the psk_identity_hint (for the server identity, i.e. the Responding node) or psk_identity (for the client identity, i.e. the Querying node) MUST be compared to the identities in the APD.
事前共有キーを使用してTLS認証のために、（クライアントIDのために、すなわち、照会ノード）（サーバ・アイデンティティのために、すなわち、応答ノード）psk_identity_hint又はpsk_identityのIDは、APDにおけるアイデンティティと比較されなければなりません。
######
＃＃＃＃＃＃
Authors' Addresses
著者のアドレス
Peter Saint-Andre Cisco 1899 Wyknoop Street, Suite 600 Denver, CO 80202 USA
ピーターサンアンドレのCisco 1899 Wyknoopストリート、スイート600デンバー、CO 80202 USA
Phone: +1-303-308-3282 EMail: psaintan@cisco.com
電話：+ 1-303-308-3282 Eメール：psaintan@cisco.com
Jeff Hodges PayPal 2211 North First Street San Jose, California 95131 US
ジェフ・ホッジスペイパル2211北まずストリートサンノゼ、カリフォルニア州95131米国
EMail: Jeff.Hodges@PayPal.com
メールアドレス：Jeff.Hodges@PayPal.com