Internet Engineering Task Force (IETF) P. Saint-Andre
Request for Comments: 9525 Independent
Obsoletes: 6125 R. Salz
Category: Standards Track Akamai Technologies
ISSN: 2070-1721 November 2023
Many application technologies enable secure communication between two entities by means of Transport Layer Security (TLS) with Internet Public Key Infrastructure using X.509 (PKIX) certificates. This document specifies procedures for representing and verifying the identity of application services in such interactions.
多くのアプリケーションテクノロジーにより、X.509（PKIX）証明書を使用したインターネット公開キーインフラストラクチャを使用して、輸送層のセキュリティ（TLS）を使用して、2つのエンティティ間の安全な通信を可能にします。このドキュメントは、このような相互作用におけるアプリケーションサービスのIDを表現および検証するための手順を指定します。
This document obsoletes RFC 6125.
このドキュメントは、RFC 6125を廃止します。
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 7841.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。インターネット標準の詳細については、RFC 7841のセクション2で入手できます。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9525.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https：//www.rfc-editor.org/info/rfc9525で取得できます。
Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2023 IETF Trustおよび文書著者として特定された人。無断転載を禁じます。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、改訂されたBSDライセンスで説明されている保証なしで提供されるように、改訂されたBSDライセンステキストを含める必要があります。
1. Introduction
1.1. Motivation
1.2. Applicability
1.3. Overview of Recommendations
1.4. Scope
1.4.1. In Scope
1.4.2. Out of Scope
1.5. Terminology
2. Identifying Application Services
3. Designing Application Protocols
4. Representing Server Identity
4.1. Rules
4.2. Examples
5. Requesting Server Certificates
6. Verifying Service Identity
6.1. Constructing a List of Reference Identifiers
6.1.1. Rules
6.1.2. Examples
6.2. Preparing to Seek a Match
6.3. Matching the DNS Domain Name Portion
6.4. Matching an IP Address Portion
6.5. Matching the Application Service Type Portion
6.6. Outcome
7. Security Considerations
7.1. Wildcard Certificates
7.2. Uniform Resource Identifiers
7.3. Internationalized Domain Names
7.4. IP Addresses
7.5. Multiple Presented Identifiers
7.6. Multiple Reference Identifiers
7.7. Certificate Trust
8. IANA Considerations
9. References
9.1. Normative References
9.2. Informative References
Appendix A. Changes from RFC 6125
Acknowledgements
Contributors
Authors' Addresses
The visible face of the Internet largely consists of services that employ a client-server architecture in which a client communicates with an application service. When a client communicates with an application service using [TLS], [DTLS], or a protocol built on those ([QUIC] being a notable example), it has some notion of the server's identity (e.g., "the website at bigcompany.example") 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"; more formal definitions are given later. A client needs to verify that the server's presented identity matches its reference identity so it can deterministically and automatically authenticate the communication.
インターネットの目に見える顔は、主にクライアントがアプリケーションサービスと通信するクライアントサーバーアーキテクチャを採用するサービスで構成されています。クライアントが[TLS]、[DTLS]、またはそれらに基づいて構築されたプロトコルを使用してアプリケーションサービスと通信すると、サーバーのアイデンティティ（例えば、BigCompanyのWebサイト）の概念があります。例 "）安全なコミュニケーションを確立しようとしている間。同様に、TLS交渉中に、サーバーは、X.509 [PKIX]を使用してインターネット公開キーインフラストラクチャのコンテキストで認証機関（CA）によって発行された公開キー証明書の形でサービスのIDの概念を提示します。非公式には、これらのアイデンティティをクライアントの「参照アイデンティティ」およびサーバーの「提示されたアイデンティティ」と考えることができます。より正式な定義は後で説明されます。クライアントは、サーバーが提示されたIDがその参照IDと一致することを確認する必要があるため、通信を決定的かつ自動的に認証できるようにする必要があります。
This document defines procedures for how clients perform this verification. It therefore defines requirements on other parties, such as the certification authorities that issue certificates, the service administrators requesting them, and the protocol designers defining interactions between clients and servers.
このドキュメントでは、クライアントがこの検証を実行する方法の手順を定義しています。したがって、証明書を発行する認定当局、それらを要求するサービス管理者、およびクライアントとサーバー間の相互作用を定義するプロトコル設計者など、他の関係者の要件を定義します。
This document obsoletes RFC 6125 [VERIFY]. Changes from RFC 6125 [VERIFY] are described under Appendix A.
このドキュメントは、RFC 6125を廃止します[検証]。RFC 6125 [検証]からの変更については、付録Aで説明します。
This document does not supersede the rules for certificate issuance or validation specified by [PKIX]. That document also governs any certificate-related topic on which this document is silent. This includes certificate syntax, extensions such as name constraints or extended key usage, and handling of certification paths.
このドキュメントは、[PKIX]によって指定された証明書発行または検証の規則に取って代わるものではありません。このドキュメントは、このドキュメントが沈黙している証明書関連のトピックも管理しています。これには、証明書の構文、名前の制約や拡張キー使用量などの拡張機能、認証パスの処理が含まれます。
This document addresses only name forms in the leaf "end entity" server certificate. It does not address the name forms in the chain of certificates used to validate a certificate, nor does it create or check the validity of such a chain. In order to ensure proper authentication, applications need to verify the entire certification path.
このドキュメントは、Leaf "End Entity"サーバー証明書の名前のみを扱います。証明書の検証に使用される証明書のチェーン内の名前フォームには対処されず、そのようなチェーンの有効性を作成または確認しません。適切な認証を確保するために、アプリケーションは認証パス全体を検証する必要があります。
The previous version of this specification, [VERIFY], surveyed the then-current practice from many IETF standards and tried to generalize best practices (see Appendix A of [VERIFY] for details).
この仕様の以前のバージョン[Verify]は、多くのIETF標準からの当時の通貨プラクティスを調査し、ベストプラクティスを一般化しようとしました（詳細については[確認]の付録Aを参照）。
This document takes the lessons learned since then and codifies them. The following is a summary of the rules, which are described at greater length in the remainder of this document:
このドキュメントは、それ以来学んだ教訓を取り、それらを成文化します。以下は、このドキュメントの残りの部分でより長く説明されている規則の概要です。
* Only check DNS domain names via the subjectAltName extension designed for that purpose: dNSName.
* その目的のために設計されたsubjectaltname拡張機能を介してDNSドメイン名のみを確認します：dnsname。
* Allow use of even more specific subjectAltName extensions where appropriate such as uniformResourceIdentifier, iPAddress, and the otherName form SRVName.
* 必要に応じて、より具体的なsubjectaltname拡張機能を使用して、cionderresourceidentifier、iPaddress、othernameフォームsrvnameなどの使用を許可します。
* Wildcard support is now the default in certificates. Constrain wildcard certificates so that the wildcard can only be the complete left-most label of a domain name.
* WildCardサポートは、証明書のデフォルトになりました。ワイルドカードがドメイン名の完全な左のラベルにしかできないように、ワイルドカード証明書を制約します。
* Do not include or check strings that look like domain names in the subject's Common Name.
* 被験者の共通名にドメイン名のように見える文字列を含めたりチェックしたりしないでください。
This document applies only to service identities that are used in TLS or DTLS and that are included in PKIX certificates.
このドキュメントは、TLSまたはDTLSで使用され、PKIX証明書に含まれるサービスIDにのみ適用されます。
With regard to TLS and DTLS, these security protocols are used to protect data exchanged over a wide variety of application protocols, which use both the TLS or DTLS handshake protocol and the TLS or DTLS record layer, either directly or through a profile as in Network Time Security [NTS]. The TLS handshake protocol can also be used with different record layers to define secure transport protocols; at present, the most prominent example is QUIC [RFC9000]. The rules specified here are intended to apply to all protocols in this extended TLS "family".
TLSおよびDTLに関して、これらのセキュリティプロトコルは、TLSまたはDTLSハンドシェイクプロトコルとTLSまたはDTLSレコードレイヤーの両方を使用して、さまざまなアプリケーションプロトコルで交換されるデータを保護するために使用されます。時間セキュリティ[NTS]。TLSハンドシェイクプロトコルは、さまざまなレコードレイヤーで使用して、安全な輸送プロトコルを定義することもできます。現在、最も顕著な例はQUIC [RFC9000]です。ここで指定されているルールは、この拡張されたTLS「ファミリー」のすべてのプロトコルに適用することを目的としています。
With regard to PKIX certificates, the primary usage is in the context of the public key infrastructure described in [PKIX]. In addition, technologies such as DNS-Based Authentication of Named Entities (DANE) [DANE] sometimes use certificates based on PKIX (more precisely, certificates structured via [X.509] or specific encodings thereof such as [X.690]), at least in certain modes. Alternatively, a TLS peer could issue delegated credentials that are based on a CA-issued certificate, as in [TLS-SUBCERTS]. In both cases, a TLS client could learn of a service identity through its inclusion in the relevant certificate. The rules specified here are intended to apply whenever service identities are included in X.509 certificates or credentials that are derived from such certificates.
PKIX証明書に関しては、主な使用法は[PKIX]で説明されている公開キーインフラストラクチャのコンテキストにあります。さらに、DNSベースの名前付きエンティティの認証（Dane）[Dane]などのテクノロジーは、PKIX（より正確には、[X.509]を介して構造化された証明書または[X.690]などの特定のエンコーディング）に基づく証明書を使用することがあります。少なくとも特定のモードで。あるいは、TLSピアは、[TLS-Subcerts]のように、CA発行証明書に基づいた委任された資格情報を発行する可能性があります。どちらの場合も、TLSクライアントは、関連する証明書に含めることにより、サービスアイデンティティを学習できます。ここで指定されているルールは、サービスのアイデンティティがX.509証明書またはそのような証明書から派生した資格情報に含まれる場合はいつでも適用することを目的としています。
The following topics are out of scope for this specification:
次のトピックは、この仕様の範囲外です。
* Security protocols other than those described above.
* 上記のセキュリティプロトコル以外のセキュリティプロトコル。
* Keys or certificates employed outside the context of PKIX-based systems.
* PKIXベースのシステムのコンテキスト外で採用されているキーまたは証明書。
* Client or end-user identities. Other than as described above, certificates representing client identities (e.g., rfc822Name) are beyond the scope of this document.
* クライアントまたはエンドユーザーのアイデンティティ。上記のように、クライアントのアイデンティティ（rfc822nameなど）を表す証明書は、このドキュメントの範囲を超えています。
* Identification of servers using other than a domain name, an IP address, or an SRV service name. This document discusses Uniform Resource Identifiers [URI] only to the extent that they are expressed in certificates. Other aspects of a service such as a specific resource (the URI "path" component) or parameters (the URI "query" component) are the responsibility of specific protocols or URI schemes.
* ドメイン名、IPアドレス、またはSRVサービス名以外のサーバーの識別。このドキュメントでは、均一なリソース識別子[URI]が証明書で表される範囲でのみ説明します。特定のリソース（URI「パス」コンポーネント）やパラメーター（URI「クエリ」コンポーネント）などのサービスの他の側面は、特定のプロトコルまたはURIスキームの責任です。
* Certification authority policies. This includes items such as the following:
* 認定機関のポリシー。これには、次のようなアイテムが含まれます。
- How to certify or validate fully qualified domain names (FQDNs) and application service types (see [ACME]).
- 完全に適格なドメイン名（FQDNS）およびアプリケーションサービスタイプを証明または検証する方法（[ACME]を参照）。
- What types or "classes" of certificates to issue and whether to apply different policies for them.
- 発行する証明書のタイプまたは「クラス」、およびそれらに異なるポリシーを適用するかどうか。
- How to certify or validate other kinds of information that might be included in a certificate (e.g., organization name).
- 証明書に含まれる可能性のある他の種類の情報を証明または検証する方法（組織名など）。
* Resolution of DNS domain names. Although the process whereby a client resolves the DNS domain name of an application service can involve several steps, for the purposes of this specification, the only relevant consideration is that the client needs to verify the identity of the entity with which it will communicate once the resolution process is complete. Thus, the resolution process itself is out of scope for this specification.
* DNSドメイン名の解像度。クライアントがアプリケーションサービスのDNSドメイン名を解決するプロセスには、この仕様の目的のためにいくつかのステップが含まれる可能性がありますが、唯一の関連する考慮事項は、クライアントがそれが通信するエンティティのIDを確認する必要があることです。解像度プロセスが完了しました。したがって、解像度プロセス自体は、この仕様の範囲外です。
* User interface issues. In general, such issues are properly the responsibility of client software developers and standards development organizations dedicated to particular application technologies (for example, see [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 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 entity 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. This often appears as a URI scheme [URI], a DNS SRV Service [DNS-SRV], or an Application-Layer Protocol Negotiation (ALPN) [ALPN] identifier.
ドメインで特定の種類のアプリケーションサービスを提供するために使用されるアプリケーションプロトコルの正式な識別子。これは、多くの場合、URIスキーム[URI]、DNS SRVサービス[DNS-SRV]、またはアプリケーション層プロトコル交渉（ALPN）[ALPN]識別子として表示されます。
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 be used for matching purposes. For conciseness and convenience, we define the following identifier types of interest:
証明書に含めることができる、したがって照合目的に使用できる、正式に定義された識別子のカテゴリ。 簡潔さと便宜のために、対象となる次の識別子の種類を定義します。
DNS-ID:
DNS-ID：
A subjectAltName entry of type dNSName as defined in [PKIX].
[pkix]で定義されているタイプdnsnameのsubjectaltnameエントリ。
IP-ID:
IP-ID：
A subjectAltName entry of type iPAddress as defined in [PKIX].
[pkix]で定義されているタイプiPaddressのsubjectaltnameエントリ。
SRV-ID:
SRV-ID：
A subjectAltName entry of type otherName whose name form is SRVName as defined in [SRVNAME].
[srvname]で定義されているように、名前フォームがsrvnameであるタイプの他の名前のsubjectaltnameエントリ。
URI-ID:
uri-id：
A subjectAltName entry of type uniformResourceIdentifier as defined in [PKIX]. See further discussion in Section 7.2.
[pkix]で定義されているタイプのuniredresourceidentifierのsumberaltaltnameエントリ。セクション7.2の詳細については、詳細を参照してください。
A formally defined category of identifier that can be included in a certificate and therefore be used for matching purposes. For conciseness and convenience, we define the following identifier types of interest: DNS-ID: A subjectAltName entry of type dNSName as defined in [PKIX]. IP-ID: A subjectAltName entry of type iPAddress as defined in [PKIX]. SRV-ID: A subjectAltName entry of type otherName whose name form is SRVName as defined in [SRVNAME]. URI-ID: A subjectAltName entry of type uniformResourceIdentifier as defined in [PKIX]. See further discussion in Section 7.2.
証明書に含めることができる正式に定義された識別子のカテゴリ。したがって、一致する目的で使用できます。簡潔さと利便性のために、次の識別子タイプの関心を定義します。DNS-ID：[PKIX]で定義されているタイプDNSNAMEの主題エントリ。IP-ID：[pkix]で定義されているタイプiPaddressのsubjectaltnameエントリ。srv-id：[srvname]で定義されているように、名前フォームがsrvnameであるタイプの他の名前のsubjectaltnameエントリ。uri-id：[pkix]で定義されているタイプのuniredresourceidentidifierのsubjectaltnameエントリ。セクション7.2の詳細については、詳細を参照してください。
PKIX:
pkix：
The short name for the Internet Public Key Infrastructure using X.509 defined in [PKIX]. That document provides a profile of the X.509v3 certificate specifications and X.509v2 certificate revocation list (CRL) specifications for use on the Internet.
[pkix]で定義されたx.509を使用したインターネット公開キーインフラストラクチャの短い名前。このドキュメントは、インターネットで使用するためのX.509V3証明書仕様とX.509v2証明書取消リスト（CRL）仕様のプロファイルを提供します。
presented identifier:
提示された識別子：
An identifier presented by a server to a client within a PKIX certificate when the client attempts to establish secure communication with the server. The certificate can include one or more presented identifiers of different types, and if the server hosts more than one domain, then the certificate might present distinct identifiers for each domain.
クライアントがサーバーとの安全な通信を確立しようとしたときに、PKIX証明書内のクライアントにサーバーによって提示された識別子。証明書には、異なるタイプの1つ以上の提示された識別子を含めることができ、サーバーが複数のドメインをホストする場合、証明書は各ドメインの個別の識別子を提示する場合があります。
reference identifier:
参照識別子：
An identifier expected by the client when examining presented identifiers. It is constructed from the source domain and, optionally, an application service type.
提示された識別子を調べるときにクライアントが期待する識別子。ソースドメインと、オプションでアプリケーションサービスタイプから構築されています。
Relative Distinguished Name (RDN):
相対的な著名な名前（RDN）：
An ASN.1-based construction that is itself a building-block component of Distinguished Names. See [LDAP-DN], Section 2.
それ自体が著名な名前の建物ブロックコンポーネントであるASN.1ベースの構造。[LDAP-DN]、セクション2を参照してください。
source domain:
ソースドメイン：
The FQDN that a client expects an application service to present in the certificate. This is typically input by a human user, configured into a client, or provided by reference such as a URL. The combination of a source domain and, optionally, an application service type enables a client to construct one or more reference identifiers. This specification covers FQDNs. Use of any names that are not fully qualified is out of scope and may result in unexpected or undefined behavior.
クライアントがアプリケーションサービスが証明書に提示することを期待するFQDN。これは通常、クライアントに構成された、またはURLなどの参照によって提供される人間のユーザーによる入力です。ソースドメインと、オプションでは、アプリケーションサービスタイプの組み合わせにより、クライアントは1つ以上の参照識別子を構築できます。この仕様はFQDNSをカバーしています。完全に資格のない名前の使用は範囲外であり、予期しないまたは未定義の動作をもたらす可能性があります。
subjectAltName entry:
subjectaltnameエントリ：
An identifier placed in a subjectAltName extension.
subjectaltname拡張子に配置された識別子。
subjectAltName extension:
subjectaltname拡張機能：
A standard PKIX extension enabling identifiers of various types to be bound to the certificate subject.
さまざまなタイプの識別子が証明書の主題にバインドされることを可能にする標準のPKIX拡張機能。
subjectName:
件名：
The name of a PKIX certificate's subject, encoded in a certificate's subject field (see [PKIX], Section 4.1.2.6).
証明書の件名フィールドにエンコードされたPKIX証明書の件名の名前（[PKIX]、セクション4.1.2.6を参照）。
TLS uses the words "client" and "server", where the client is the entity that initiates the connection. In many cases, this is consistent with common practice, such as a browser connecting to a web origin. For the sake of clarity, and to follow the usage in [TLS] and related specifications, we will continue to use the terms client and server in this document. However, these are TLS-layer roles, and the application protocol could support the TLS server making requests to the TLS client after the TLS handshake; there is no requirement that the roles at the application layer match the TLS layer.
TLSは、「クライアント」と「サーバー」という単語を使用します。クライアントは、接続を開始するエンティティです。多くの場合、これは、Web Originに接続するブラウザなど、一般的な実践と一致しています。明確にし、[TLS]および関連する仕様の使用法に従うために、このドキュメントのクライアントとサーバーという用語を引き続き使用します。ただし、これらはTLSレイヤーの役割であり、アプリケーションプロトコルは、TLSハンドシェイク後にTLSサーバーのリクエストをTLSクライアントにリクエストすることをサポートできます。アプリケーションレイヤーの役割がTLSレイヤーと一致するという要件はありません。
Security-related terms used in this document, but not defined here or in [PKIX], should be understood in the sense defined in [SECTERMS]. Such terms include "attack", "authentication", "identity", "trust", "validate", and "verify".
このドキュメントで使用されるセキュリティ関連の用語は、ここまたは[pkix]で定義されていませんが、[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 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はBCP 14 [RFC2119] [RFC8174]で説明されているように、すべて大文字の場合にのみ解釈されます。
This document assumes that an application service is identified by a DNS domain name (e.g., bigcompany.example), an IP address (IPv4 or IPv6), or an identifier that contains additional supplementary information. Supplementary information is limited to the application service type as expressed in a DNS SRV record (e.g., "the IMAP server at isp.example" for "_imap.isp.example") or a URI.
このドキュメントは、アプリケーションサービスがDNSドメイン名（例：BigCompany.example）、IPアドレス（IPv4またはIPv6）、または追加の補足情報を含む識別子によって識別されることを前提としています。補足情報は、DNS SRVレコードで表現されているアプリケーションサービスタイプに限定されています（例：「_imap.isp.example」の「isp.example」の「IMAPサーバー」）またはURI。
In a DNS-ID -- and in the DNS domain name portion of an SRV-ID or URI-ID -- any characters outside the range described in [US-ASCII] are prohibited, and internationalized domain labels are represented as A-labels [IDNA-DEFS].
DNS-ID-およびSRV-IDまたはURI-IDのDNSドメイン名部分 - [US-ASCII]で説明されている範囲外の文字は禁止されており、国際化ドメインラベルはA-Labelsとして表されます[idna-defs]。
An IP address is either a 4-octet IPv4 address [IPv4] or a 16-octet IPv6 address [IPv6]. The identifier might need to be converted from a textual representation to obtain this value.
IPアドレスは、4-OCTET IPv4アドレス[IPv4]または16-OCTET IPv6アドレス[IPv6]のいずれかです。識別子は、この値を取得するためにテキスト表現から変換する必要がある場合があります。
From the perspective of the application client or user, some identifiers are _direct_ because they are provided directly by a human user. This includes runtime input, prior configuration, or explicit acceptance of a client communication attempt. Other names are _indirect_ because they are automatically resolved by the application based on user input, such as a target name resolved from a source name using DNS SRV or the records described in [NAPTR]. The distinction matters most for certificate consumption, specifically verification as discussed in this document.
アプリケーションクライアントまたはユーザーの観点から見ると、一部の識別子は、人間のユーザーが直接提供されるため_Direct_です。これには、ランタイム入力、以前の構成、またはクライアント通信の試みの明示的な受け入れが含まれます。他の名前は、DNS SRVを使用してソース名から解決されたターゲット名や[NAPTR]で説明されているレコードなど、ユーザー入力に基づいてアプリケーションによって自動的に解決されるため、_indirect_です。区別は、証明書の消費、特にこのドキュメントで説明されている検証で最も重要です。
From the perspective of the application service, some identifiers are _unrestricted_ because they can be used in any type of service, such as a single certificate being used for both the HTTP and IMAP services at the host "bigcompany.example". Other identifiers are _restricted_ because they can only be used for one type of service, such as a special-purpose certificate that can only be used for an IMAP service. This distinction matters most for certificate issuance.
アプリケーションサービスの観点から見ると、一部の識別子は、ホスト「BigCompany.example」のHTTPサービスとIMAPサービスの両方に使用される単一の証明書など、あらゆる種類のサービスで使用できるため、_Unrestricted_です。他の識別子は、IMAPサービスにのみ使用できる特別な目的証明書など、1つのタイプのサービスにのみ使用できるため、_Restricted_です。この区別は、証明書発行にとって最も重要です。
The four identifier types can be categorized as follows:
4つの識別子タイプは、次のように分類できます。
* A DNS-ID is direct and unrestricted.
* DNS-IDは直接的で無制限です。
* An IP-ID is direct and unrestricted.
* IP-IDは直接的で無制限です。
* An SRV-ID is typically indirect but can be direct, and it is restricted.
* SRV-IDは通常間接的ですが、直接的であり、制限されています。
* A URI-ID is direct and restricted.
* URI-IDは直接的で制限されています。
It is important to keep these distinctions in mind because best practices for the deployment and use of the identifiers differ. Note that cross-protocol attacks such as those described in [ALPACA] are possible when two different protocol services use the same certificate. This can be addressed by using restricted identifiers or deploying services so that they do not share certificates. Protocol specifications MUST specify which identifiers are mandatory to implement and SHOULD provide operational guidance when necessary.
識別子の展開と使用のベストプラクティスが異なるため、これらの区別を念頭に置くことが重要です。2つの異なるプロトコルサービスが同じ証明書を使用している場合、[ALPACA]に記載されているようなクロスプロトコル攻撃が可能であることに注意してください。これは、制限された識別子を使用して、または証明書を共有しないようにサービスを展開することで対処できます。プロトコル仕様は、どの識別子が実装することに必須であるかを指定する必要があり、必要に応じて運用ガイダンスを提供する必要があります。
The Common Name RDN MUST NOT be used to identify a service because it is not strongly typed (it is essentially free-form text) and therefore suffers from ambiguities in interpretation.
共通名RDNは、強く入力されていない（本質的に自由形式のテキスト）、したがって解釈のあいまいさに苦しんでいるため、サービスを識別するために使用してはなりません。
For similar reasons, other RDNs within the subjectName MUST NOT be used to identify a service.
同様の理由で、件名内の他のRDNを使用してサービスを特定してはなりません。
An IP address that is the result of a DNS query is indirect. Use of IP-IDs that are indirect is out of scope for this document.
DNSクエリの結果であるIPアドレスは間接的です。間接的なIP-IDの使用は、このドキュメントの範囲外です。
The IETF continues to define methods for looking up information needed to make connections to network services. One recent example is service binding via the "SVCB" and "HTTPS" DNS resource record (RR) types. This document does not define any identity representation or verification procedures that are specific to SVCB-compatible records, because the use of such records during connection establishment does not currently alter any of the PKIX validation requirements specified herein or in any other relevant specification. For example, the PKIX validation rules for [HTTP] and [DNS-OVER-TLS] do not change when the client uses the DNS resource records defined in [SVCB-FOR-HTTPS] or [SVCB-FOR-DNS] to look up connection information. However, it is possible that future SVCB mapping documents could specify altered PKIX rules for new use cases.
IETFは、ネットワークサービスに接続するために必要な情報を検索する方法を定義し続けています。最近の例の1つは、「SVCB」および「HTTPS」DNSリソースレコード（RR）タイプを介したサービスバインディングです。このドキュメントは、SVCB互換レコードに固有のID表現または検証手順を定義しません。これは、接続確立中のそのようなレコードの使用が現在、本明細書またはその他の関連する仕様で指定されているPKIX検証要件を変更しないためです。たとえば、[http]および[dns-over-tls]のpkix検証ルールは、クライアントが[svcb-for-https]または[svcb-for-dns]で定義されているDNSリソースレコードを使用して検索する場合に変更されません。接続情報。ただし、将来のSVCBマッピングドキュメントが、新しいユースケースの変更されたPKIXルールを指定できる可能性があります。
This section defines how protocol designers should reference this document, which would typically be a normative reference in their specification.
このセクションでは、プロトコル設計者がこのドキュメントを参照する方法を定義します。これは通常、仕様の規範的な参照です。
A specification MAY choose to allow only one of the identifier types defined here.
仕様は、ここに定義されている識別子タイプの1つのみを許可することを選択できます。
If the technology does not use DNS SRV records to resolve the DNS domain names of application services, then the specification MUST state that SRV-ID as defined in this document is not supported. Note that many existing application technologies use DNS SRV records to resolve the DNS domain names of application services, but they do not rely on representations of those records in PKIX certificates by means of SRV-IDs as defined in [SRVNAME].
テクノロジーがDNS SRVレコードを使用してアプリケーションサービスのDNSドメイン名を解決しない場合、このドキュメントで定義されているSRV-IDがサポートされていないことを指定する必要があります。多くの既存のアプリケーションテクノロジーは、DNS SRVレコードを使用してアプリケーションサービスのDNSドメイン名を解決しますが、[SRVNAME]で定義されているSRV-IDによってPKIX証明書のこれらのレコードの表現に依存していないことに注意してください。
If the technology does not use URIs to identify application services, then the specification MUST state that URI-ID as defined in this document is not supported. Note that many existing application technologies use URIs to identify application services, but they do not rely on representation of those URIs in PKIX certificates by means of URI-IDs.
テクノロジーがURIを使用してアプリケーションサービスを特定しない場合、このドキュメントで定義されているURI-IDがサポートされていないことを指定する必要があります。多くの既存のアプリケーションテクノロジーは、URIを使用してアプリケーションサービスを特定していますが、URI-IDを使用してPKIX証明書のこれらのURIの表現に依存していないことに注意してください。
A technology MAY disallow the use of the wildcard character in presented identifiers. If it does so, then the specification MUST state that wildcard certificates as defined in this document are not supported.
テクノロジーは、提示された識別子でワイルドカード文字の使用を許可する場合があります。そうする場合、このドキュメントで定義されているワイルドカード証明書はサポートされていないことを指定する必要があります。
A protocol can allow the use of an IP address in place of a DNS name. This might use the same field without distinguishing the type of identifier as, for example, in the "host" components of a URI. In this case, applications need to be aware that the textual representation of an IPv4 address is a valid DNS name. The two types can be distinguished by first testing if the identifier is a valid IPv4 address, as is done by the "first-match-wins" algorithm in Section 3.2.2 of [URI].
プロトコルでは、DNS名の代わりにIPアドレスを使用できます。これは、たとえば、URIの「ホスト」コンポーネントのように識別子のタイプを区別せずに同じフィールドを使用する場合があります。この場合、アプリケーションは、IPv4アドレスのテキスト表現が有効なDNS名であることに注意する必要があります。[URI]のセクション3.2.2の「最初の試合ウィン」アルゴリズムによって行われるように、識別子が有効なIPv4アドレスであるかどうかを最初にテストすることで2つのタイプを区別できます。
This section provides instructions for issuers of certificates.
このセクションでは、証明書の発行者に関する指示を提供します。
When a certification authority issues a certificate based on the FQDN at which the application service provider will provide the relevant application, the following rules apply to the representation of application service identities. Note that some of these rules are cumulative and can interact in important ways that are illustrated later in this document.
認定機関が、アプリケーションサービスプロバイダーが関連するアプリケーションを提供するFQDNに基づいて証明書を発行する場合、以下のルールがアプリケーションサービスIDの表現に適用されます。これらのルールのいくつかは累積的であり、このドキュメントの後半で説明されている重要な方法で相互作用できることに注意してください。
1. The certificate MUST include at least one identifier.
1. 証明書には、少なくとも1つの識別子を含める必要があります。
2. The certificate SHOULD include a DNS-ID as a baseline for interoperability. This is not mandatory because it is legitimate for a certificate to include only an SRV-ID or URI-ID so as to scope its use to a particular application type.
2. 証明書には、相互運用性のベースラインとしてDNS-IDを含める必要があります。証明書がSRV-IDまたはURI-IDのみを特定のアプリケーションタイプに範囲するためにSRV-IDまたはURI-IDのみを含めることが合法であるため、これは必須ではありません。
3. If the service using the certificate deploys a technology for which the relevant specification stipulates that certificates should include identifiers of type SRV-ID (e.g., this is true of the Extensible Messaging and Presence Protocol (XMPP) as described in [XMPP]), then the certificate SHOULD include an SRV-ID. This identifier type could supplement the DNS-ID, unless the certificate is meant to be scoped to only the protocol in question.
3. 証明書を使用したサービスが、関連する仕様が証明書にSRV-IDのタイプの識別子を含める必要があることを規定するテクノロジーを展開する場合（例えば、これは[XMPP]に記載されている拡張可能なメッセージングおよび存在プロトコル（XMPP）に当てはまります）。証明書には、SRV-IDを含める必要があります。証明書が問題のプロトコルのみにスコープされることを意図していない限り、この識別子タイプはDNS-IDを補完する可能性があります。
4. If the service using the certificate deploys a technology for which the relevant specification stipulates that certificates should include identifiers of type URI-ID (e.g., this is true of the Session Initiation Protocol [SIP] as specified by [SIP-CERTS]), then the certificate SHOULD include a URI-ID. The scheme MUST be that of the protocol associated with the application service type, and the "host" component MUST be the FQDN of the service. The application protocol specification MUST specify which URI schemes are 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]). Typically, this identifier type would supplement the DNS-ID, unless the certificate is meant to be scoped to only the protocol in question.
4. 証明書を使用したサービスが、関連する仕様が証明書にタイプURI-IDの識別子を含める必要があることを規定するテクノロジーを展開する場合（例えば、これは[SIP-Certs]で指定されているセッション開始プロトコル[SIP]に当てはまります）。証明書にはURI-IDを含める必要があります。スキームは、アプリケーションサービスタイプに関連付けられたプロトコルのスキームでなければならず、「ホスト」コンポーネントはサービスのFQDNでなければなりません。アプリケーションプロトコル仕様は、アプリケーションプロトコルに使用されるPKIX証明書に含まれるURI-IDで許容されるURIスキームを指定する必要があります（例：[SIP-SIP]]に記載されているSIP用のSIPまたはTELではありません）。通常、証明書が問題のプロトコルのみにスコープされることを意図していない限り、この識別子タイプはDNS-IDを補完します。
5. The certificate MAY contain more than one DNS-ID, SRV-ID, URI-ID, or IP-ID as further explained in Section 7.5.
5. 証明書には、セクション7.5でさらに説明されているように、複数のDNS-ID、SRV-ID、URI-ID、またはIP-IDが含まれる場合があります。
6. The certificate MAY include other application-specific identifiers for compatibility with a deployed base, especially identifiers for types that were defined before publication of [SRVNAME] or for which SRV service names or URI schemes do not exist. Such identifiers are out of scope for this specification.
6. 証明書には、展開されたベースとの互換性、特に[srvname]の公開前に定義されたタイプの識別子、またはSRVサービス名またはURIスキームが存在しない他のアプリケーション固有の識別子が含まれる場合があります。このような識別子は、この仕様の範囲外です。
Consider a simple website at <www.bigcompany.example>, 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.bigcompany.example>.
<www.bigcompany.example> <www.bigcompany.example>のシンプルなWebサイトを検討してください。HTTPはサーバー証明書でのURIの使用を指定していないため、このサービスの証明書には<www.bigcompany.example>のDNS-IDのみが含まれる場合があります。
Consider another website, which is reachable by a fixed IP address of 2001:db8::5c. If the two sites refer to the same web service, then the certificate might also include this value in an IP-ID to allow clients to use the fixed IP address as a reference identity.
別のウェブサイトを検討してください。これは、2001年の固定IPアドレスで到達可能です：db8 :: 5c。2つのサイトが同じWebサービスを参照している場合、証明書にはIP-IDにこの値を含めることができ、クライアントが固定IPアドレスを参照IDとして使用できるようにします。
Consider an IMAP-accessible email server at the host mail.isp.example servicing email addresses of the form user@isp.example and discoverable via DNS SRV lookups on the application service name of isp.example. A certificate for this service might include SRV-IDs of _imap.isp.example and _imaps.isp.example (see [EMAIL-SRV]) along with DNS-IDs of isp.example and mail.isp.example.
host mail.isp.exampleフォームのメールアドレスを保守し、usp.exampleのdns srv lookupsを介して発見可能なメールアドレスのimap-accessableメールサーバーを考えてみましょう。このサービスの証明書には、_imap.isp.exampleおよび_imaps.isp.exampleのsrv-idsが含まれる場合があります。
Consider a SIP-accessible voice-over-IP (VoIP) server at the host voice.college.example servicing SIP addresses of the form user@voice.college.example and identified by a URI of <sip:voice.college.example>. A certificate for this service would include a URI-ID of <sip:voice.college.example> (see [SIP-CERTS]) along with a DNS-ID of voice.college.example.
ホストVoice.College.College.exampleのSIPアドレスのSIP-Accessable Voice-Over-IP（VoIP）サーバーを考えてみてくださいuser@voice.college.exampleのSIPアドレス。。このサービスの証明書には、<sip：voice.college.example>（[sip-certs]を参照）のuri-id of <sip：voice.college.example>（[sip-certs]を参照）が含まれます。
Consider an XMPP-compatible instant messaging (IM) server at the host messenger.example that services IM addresses of the form user@messenger.example and that is discoverable via DNS SRV lookups on the messenger.example domain. A certificate for this service might include SRV-IDs of _xmpp-client.messenger.example and _xmpp-server.messenger.example (see [XMPP]), as well as a DNS-ID of messenger.example.
ホストメッセンジャーでXMPP互換のインスタントメッセージング（IM）サーバーを検討してください。このサービスの証明書には、_xmpp-client.messenger.exampleおよび_xmpp-server.messenger.example（[xmpp]を参照）のsrv-idsと、messenger.exampleのDNS-idが含まれる場合があります。
This section provides instructions for service providers regarding the information to include in certificate signing requests (CSRs). In general, service providers SHOULD request certificates that include all the identifier types that are required or recommended for the application service type that will be secured using the certificate to be issued.
このセクションでは、証明書署名リクエスト（CSR）に含める情報に関するサービスプロバイダーに指示を提供します。一般に、サービスプロバイダーは、発行される証明書を使用して保護されるアプリケーションサービスタイプに必要または推奨されるすべての識別子タイプを含む証明書を要求する必要があります。
A service provider SHOULD request certificates with as few identifiers as necessary to identify a single service; see Section 7.5.
サービスプロバイダーは、単一のサービスを識別するために必要な識別子が少ない証明書を要求する必要があります。セクション7.5を参照してください。
If the certificate will be used for only a single type of application service, the service provider SHOULD request a certificate that includes DNS-ID or IP-ID values that identify that service or, if appropriate for the application service type, SRV-ID or URI-ID values that limit the deployment scope of the certificate to only the defined application service type.
証明書が単一のタイプのアプリケーションサービスのみに使用される場合、サービスプロバイダーは、そのサービスを識別するDNS-IDまたはIP-ID値を含む証明書を要求する必要があります。証明書の展開スコープを定義されたアプリケーションサービスタイプのみに制限するURI-ID値。
If the certificate might be used for any type of application service, the service provider SHOULD request a certificate that includes only DNS-IDs or IP-IDs. Again, because of multiprotocol attacks, this practice is discouraged; it can be mitigated by deploying only one service on a host.
証明書があらゆるタイプのアプリケーションサービスに使用される場合、サービスプロバイダーはDNS-IDまたはIP-IDのみを含む証明書を要求する必要があります。繰り返しますが、マルチプロトコル攻撃のため、この慣行は落胆しています。ホストに1つのサービスのみを展開することで軽減できます。
If a service provider offers multiple application service types and wishes to limit the applicability of certificates using SRV-IDs or URI-IDs, it SHOULD request that multiple certificates rather than a single certificate containing multiple SRV-IDs or URI-IDs each identify a different application service type. This rule does not apply to application service type "bundles" that identify distinct access methods to the same underlying application such as an email application with access methods denoted by the application service types of imap, imaps, pop3, pop3s, and submission as described in [EMAIL-SRV].
サービスプロバイダーが複数のアプリケーションサービスタイプを提供し、SRV-IDまたはURI-IDを使用して証明書の適用性を制限することを希望する場合、複数のSRV-IDまたはURI-IDを含む単一の証明書ではなく、複数の証明書がそれぞれ異なるものを識別することを要求する必要がありますアプリケーションサービスタイプ。このルールは、アプリケーションサービスのタイプ、IMAPS、POP3、POP3S、および提出によって示されるアクセス方法を備えた同じ基礎となるアプリケーションへの異なるアクセスメソッドを識別するアプリケーションサービスタイプの「バンドル」には適用されません。[電子メール-SRV]。
At a high level, the client verifies the application service's identity by performing the following actions:
高レベルでは、クライアントは次のアクションを実行することにより、アプリケーションサービスのIDを検証します。
1. The client constructs a list of reference identifiers it would find acceptable based on the source domain and, if applicable, the type of service to which the client is connecting.
1. クライアントは、ソースドメインに基づいて受け入れられる参照識別子のリストを構築し、該当する場合はクライアントが接続しているサービスのタイプを構築します。
2. The server provides its presented identifiers in the form of a PKIX certificate.
2. サーバーは、PKIX証明書の形式で提示された識別子を提供します。
3. The client checks each of its reference identifiers against the server's presented identifiers for the purpose of finding a match. When checking a reference identifier against a presented identifier, the client matches the source domain of the identifiers and, optionally, their application service type.
3. クライアントは、一致を見つける目的で、サーバーの提示された識別子に対して各参照識別子をチェックします。提示された識別子に対して参照識別子をチェックする場合、クライアントは識別子のソースドメインと、オプションでアプリケーションサービスタイプと一致します。
Naturally, in addition to checking identifiers, a client should perform further checks, such as expiration and revocation, to ensure that the server is authorized to provide the requested service. Because such checking is not a matter of verifying the application service identity presented in a certificate, methods for doing so are out of scope for this document.
当然のことながら、識別子をチェックすることに加えて、クライアントは、有効期限や取り消しなどのさらにチェックを実行して、サーバーが要求されたサービスを提供することを許可されていることを確認する必要があります。このようなチェックは、証明書に表示されるアプリケーションサービスIDを確認することではないため、このドキュメントの範囲外です。
The client MUST construct a list of acceptable reference identifiers and MUST do so independently of the identifiers presented by the server.
クライアントは、許容可能な参照識別子のリストを作成する必要があり、サーバーによって提示された識別子とは無関係にそうする必要があります。
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 host for retrieving email, which might be different from the DNS domain name portion of a username), a hyperlink in a web page that triggers a browser to retrieve a media object or script, or some other combination of information that can yield a source domain and an application service type.
クライアントが参照識別子のリストを作成するために使用される入力は、ユーザーがインターフェイス（たとえば、WebサイトのHTTPS URLなど）に入力したURIである可能性があります。ユーザー名のDNSドメイン名部分とは異なる場合があるメール、ブラウザをトリガーしてメディアオブジェクトまたはスクリプトを取得するWebページのハイパーリンク、またはソースドメインとアプリケーションを生成できる他の情報の組み合わせサービスの種類。
This document does not precisely define how reference identifiers are generated. Defining reference identifiers is the responsibility of applications or protocols that use this document. Because the security of a system that uses this document will depend on how reference identifiers are generated, great care should be taken in this process. For example, a protocol or application could specify that the application service type is obtained through a one-to-one mapping of URI schemes to service types or that the protocol or application supports only a restricted set of URI schemes. Similarly, it could specify that a domain name or an IP address taken as input to the reference identifier must be obtained in a secure context such as a hyperlink embedded in a web page that was delivered over an authenticated and encrypted channel (for instance, see [SECURE-CONTEXTS] with regard to the web platform).
このドキュメントでは、参照識別子の生成方法を正確に定義しません。参照識別子の定義は、このドキュメントを使用するアプリケーションまたはプロトコルの責任です。このドキュメントを使用するシステムのセキュリティは、参照識別子の生成方法に依存するため、このプロセスでは細心の注意を払う必要があります。たとえば、プロトコルまたはアプリケーションは、アプリケーションサービスタイプをサービスタイプに1対1のマッピングを介して取得されること、またはプロトコルまたはアプリケーションが制限付きのURIスキームのみをサポートすることを指定できます。同様に、参照識別子への入力として採取されたドメイン名またはIPアドレスが、認証された暗号化されたチャネルに届くWebページに埋め込まれたハイパーリンクなどの安全なコンテキストで取得する必要があることを指定できます（たとえば、例えば、参照してください。[Secure-Contexts] Webプラットフォームに関して）。
Naturally, if the inputs themselves are invalid or corrupt (e.g., a user has clicked a hyperlink provided by a malicious entity in a phishing attack), then the client might end up communicating with an unexpected application service.
当然のことながら、入力自体が無効または破損している場合（たとえば、ユーザーがフィッシング攻撃で悪意のあるエンティティが提供するハイパーリンクをクリックした場合）、クライアントは予期しないアプリケーションサービスと通信することになります。
During the course of processing, a client might be exposed to identifiers that look like, but are not, reference identifiers. For example, DNS resolution that starts at a DNS-ID reference identifier might produce intermediate domain names that need to be further resolved. Unless an application defines a process for authenticating intermediate identifiers in a way that then allows them to be used as a reference identifier (for example, see [SMTP-TLS]), any intermediate values are not reference identifiers and MUST NOT be treated as such. In the DNS case, not treating intermediate domain names as reference identifiers removes DNS and DNS resolution from the attack surface.
処理中に、クライアントは、参照識別子のように見えるがそうではない識別子にさらされる可能性があります。たとえば、DNS-ID参照識別子から始まるDNS解像度は、さらに解決する必要がある中間ドメイン名を生成する可能性があります。アプリケーションが中間識別子を認証するプロセスを定義している場合を除いて、それらを参照識別子として使用できるようにしない限り（たとえば、[smtp-tls]を参照）、中間値は参照識別子ではなく、そのように扱われてはなりません。。DNSの場合、参照識別子として中間ドメイン名を扱わないと、攻撃面からDNSとDNS解像度が削除されます。
As one example of the process of generating a reference identifier, from the user input of the URI <sip:alice@voice.college.example>, a client could derive the application service type sip from the URI scheme and parse the domain name college.example from the "host" component.
uri <sip：alice@voice.college.example>のユーザー入力から、参照識別子を生成するプロセスの1つの例として、クライアントはURIスキームからアプリケーションサービスタイプのSIPを導き出し、ドメイン名カレッジを解析することができます「ホスト」コンポーネントからの例。
Using the combination of one or more FQDNs or IP addresses, plus optionally an application service type, the client MUST construct its list of reference identifiers in accordance with the following rules:
1つ以上のFQDNまたはIPアドレスの組み合わせと、オプションでアプリケーションサービスタイプを使用すると、クライアントは次のルールに従って参照識別子のリストを作成する必要があります。
* 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), the reference identifier SHOULD be a URI-ID.
* アプリケーションサービスタイプのサーバーが通常、セキュリティ目的でURIに関連付けられている場合（つまり、正式なプロトコルドキュメントがサーバー証明書でのURIの使用を指定します）、参照識別子はURI-IDでなければなりません。
* If a server for the application service type is typically discovered by means of DNS SRV records, the reference identifier SHOULD be an SRV-ID.
* アプリケーションサービスタイプのサーバーが通常、DNS SRVレコードによって発見される場合、参照識別子はSRV-IDである必要があります。
* If the reference identifier is an IP address, the reference identifier is an IP-ID.
* 参照識別子がIPアドレスである場合、参照識別子はIP-IDです。
* In the absence of more specific identifiers, the reference identifier is a DNS-ID. A reference identifier of type DNS-ID can be directly constructed from an FQDN that is (a) contained in or securely derived from the inputs or (b) explicitly associated with the source domain by means of user configuration.
* より特定の識別子がない場合、参照識別子はDNS-IDです。タイプDNS-IDの参照識別子は、（a）入力または（b）に含まれるまたは安全に導出される（a）、またはユーザー構成によってソースドメインに明示的に関連付けられているFQDNから直接構築できます。
Which identifier types a client includes in its list of reference identifiers, and their priority, is a matter of local policy. For example, a client that is built to connect only to a particular kind of service might be configured to accept as valid only certificates that include an SRV-ID for that application service type. By contrast, a more lenient client, even if built to connect only to a particular kind of service, might include SRV-IDs, DNS-IDs, and IP-IDs in its list of reference identifiers.
クライアントが参照識別子のリストに含める識別子タイプとその優先事項は、ローカルポリシーの問題です。たとえば、特定の種類のサービスにのみ接続するように構築されたクライアントは、そのアプリケーションサービスタイプのSRV-IDを含む有効な証明書として受け入れるように構成される場合があります。対照的に、特定の種類のサービスのみに接続するように構築されたとしても、より寛大なクライアントは、参照識別子のリストにSRV-ID、DNS-ID、およびIP-IDが含まれる場合があります。
The following examples are for illustrative purposes only and are not intended to be comprehensive.
次の例は、説明のみを目的としており、包括的であることを意図していません。
1. A web browser that is connecting via HTTPS to the website at <https://www.bigcompany.example/> would have a single reference identifier: a DNS-ID of www.bigcompany.example.
1. httpsを介して<https：//www.bigcompany.example/>のWebサイトに接続しているWebブラウザには、単一の参照識別子があります：www.bigcompany.exampleのdns-id。
2. A web browser connecting to <https://192.0.2.107/> would have a single IP-ID reference identifier of 192.0.2.107. Likewise, if connecting to <https://[2001:db8::abcd]>, it would have a single IP-ID reference identifier of 2001:db8::abcd.
2. <https://192.0.2.107/>に接続するWebブラウザには、192.0.2.107の単一のIP-IDリファレンス識別子があります。同様に、<https：// [2001：db8 :: abcd]>に接続すると、2001：db8 :: abcdの単一のIP-ID参照識別子があります。
3. A mail user agent that is connecting via IMAPS to the email service at isp.example (resolved as mail.isp.example) might have three reference identifiers: an SRV-ID of _imaps.isp.example (see [EMAIL-SRV]) and DNS-IDs of isp.example and mail.isp.example. An email user agent that does not support [EMAIL-SRV] would probably be explicitly configured to connect to mail.isp.example, whereas an SRV-aware user agent would derive isp.example from an email address of the form user@isp.example but might also accept mail.isp.example as the DNS domain name portion of reference identifiers for the service.
3. isp.example（mail.isp.exampleとして解決された）の電子メールサービスにimapsを介して接続しているメールユーザーエージェントには、_imaps.isp.exampleのsrv-id（[email-srv]を参照）の3つの参照識別子があります。およびISP.exampleとmail.isp.exampleのDNS-ID。[電子メール-SRV]をサポートしていない電子メールユーザーエージェントは、おそらくmail.isp.exampleに接続するように明示的に構成されますが、SRVに対応するユーザーエージェントは、form user@ispの電子メールアドレスからisp.exampleを導き出します。例ですが、サービスの参照識別子のDNSドメイン名部分としてmail.isp.exampleも受け入れる場合があります。
4. A VoIP user agent that is connecting via SIP to the voice service at voice.college.example might have only one reference identifier: a URI-ID of sip:voice.college.example (see [SIP-CERTS]).
4. sipを介してvoice.college.exampleで音声サービスに接続しているVoIPユーザーエージェントには、1つの参照識別子のみがあります：sip：voice.college.example（[sip-certs]を参照）のuri-id。
5. An IM client that is connecting via XMPP to the IM service at messenger.example might have three reference identifiers: an SRV-ID of _xmpp-client.messenger.example (see [XMPP]), a DNS-ID of messenger.example, and an XMPP-specific XmppAddr of messenger.example (see [XMPP]).
5. XMPPを介してMessenger.exampleでIMサービスに接続しているIMクライアントには、_xmpp-client.messenger.exampleのsrv-id（[xmpp]を参照）、messenger.exampleのdns-idの3つの参照識別子がある場合があります。Messenger.exampleのXMPP固有のXMPPADDR（[XMPP]を参照）。
In all these cases, presented identifiers that do not match the reference identifier(s) would be rejected; for instance:
これらすべての場合、参照識別子と一致しない提示された識別子が拒否されます。例えば：
* With regard to the first example, a DNS-ID of web.bigcompany.example would be rejected because the DNS domain name portion does not match www.bigcompany.example.
* 最初の例に関しては、DNSドメイン名の部分がwww.bigcompany.exampleと一致しないため、web.bigcompany.exampleのDNS-idが拒否されます。
* With regard to the third example, a URI-ID of <sip:www.college.example> would be rejected because the DNS domain name portion does not match "voice.college.example", and a DNS-ID of "voice.college.example" would be rejected because it lacks the appropriate application service type portion (i.e., it does not specify a "sip:" URI).
* 3番目の例に関しては、<sip：www.college.example>のuri-idは、dnsドメイン名の部分が「voice.college.example」と「VoiceのDNS-ID」と一致しないため拒否されます。college.example "適切なアプリケーションサービスタイプの部分がないため、拒否されます（つまり、「sip：" uri）を指定しません。
Once the client has constructed its list of reference identifiers and has received the server's presented identifiers, 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.
クライアントが参照識別子のリストを作成し、サーバーの提示された識別子を受信すると、クライアントは一致を見つける目的で提示された識別子に対して参照識別子をチェックします。クライアントが一致を見つけることなく参照識別子のリストを使い果たした場合、検索は失敗します。提示された識別子が参照識別子の1つと一致する場合、検索は成功します。その時点で、クライアントは検索を停止する必要があります。
Before applying the comparison rules provided in the following sections, the client might need to split the reference identifier into components. Each reference identifier produces either a domain name or an IP address and optionally an application service type as follows:
次のセクションで提供される比較ルールを適用する前に、クライアントは参照識別子をコンポーネントに分割する必要がある場合があります。各参照識別子は、ドメイン名またはIPアドレスのいずれかを生成します。
* A DNS-ID reference identifier MUST be used directly as the DNS domain name, and there is no application service type.
* DNS-ID参照識別子は、DNSドメイン名として直接使用する必要があり、アプリケーションサービスタイプはありません。
* An IP-ID reference identifier MUST exactly match the value of an iPAddress entry in subjectAltName, with no partial (e.g., network-level) matching. There is no application service type.
* IP-IDリファレンス識別子は、件名のiPaddressエントリの値と正確に一致する必要があり、部分的な（ネットワークレベルなど）マッチングはありません。アプリケーションサービスタイプはありません。
* For an SRV-ID reference identifier, the DNS domain name portion is the Name and the application service type portion is the Service. For example, an SRV-ID of _imaps.isp.example has a DNS domain name portion of isp.example and an application service type portion of imaps, which maps to the IMAP application protocol as explained in [EMAIL-SRV].
* SRV-IDリファレンス識別子の場合、DNSドメイン名の部分は名前であり、アプリケーションサービスタイプの部分はサービスです。たとえば、_imaps.isp.exampleのSRV-IDには、[電子メール-SRV]で説明されているように、ISP.exampleのDNSドメイン名部分とIMAPSのアプリケーションサービスタイプ部分がiMAPSの部分をマップします。
* For a reference identifier of type URI-ID, the DNS domain name portion is the "reg-name" part of the "host" component and the application service type portion is the scheme, as defined above. Matching only the "reg-name" rule from [URI] limits the additional domain name validation (Section 6.3) to DNS domain names or non-IP hostnames. A URI that contains an IP address might be matched against an IP-ID in place of a URI-ID by some lenient clients. This document does not describe how a URI that contains no "host" component can be matched. Note that extraction of the "reg-name" might necessitate normalization of the URI (as explained in Section 6 of [URI]). For example, a URI-ID of <sip:voice.college.example> would be split into a DNS domain name portion of voice.college.example and an application service type of sip (associated with an application protocol of SIP as explained in [SIP-CERTS]).
* タイプURI-IDの参照識別子の場合、DNSドメイン名部分は「ホスト」コンポーネントの「regName」部分であり、上記のようにアプリケーションサービスタイプの部分がスキームです。[uri]の「reg-name」ルールのみを一致させると、追加のドメイン名の検証（セクション6.3）がDNSドメイン名または非IPホスト名に制限されます。IPアドレスを含むURIは、一部の寛大なクライアントによってURI-IDの代わりにIP-IDと一致する場合があります。このドキュメントでは、「ホスト」コンポーネントを含むURIがどのように一致しないかについては説明していません。「reg-name」の抽出には、URIの正規化が必要になる可能性があることに注意してください（[URI]のセクション6で説明されているように）。たとえば、<sip：voice.college.example>のuri-idは、voice.college.exampleのDNSドメイン名部分に分割されます。[sip-certs]）。
If the reference identifier produces a domain name, the client MUST match the DNS name; see Section 6.3. If the reference identifier produces an IP address, the client MUST match the IP address; see Section 6.4. If an application service type is present, it MUST also match the service type; see Section 6.5.
参照識別子がドメイン名を生成する場合、クライアントはDNS名と一致する必要があります。セクション6.3を参照してください。参照識別子がIPアドレスを生成する場合、クライアントはIPアドレスと一致する必要があります。セクション6.4を参照してください。アプリケーションサービスタイプが存在する場合は、サービスタイプも一致する必要があります。セクション6.5を参照してください。
This section describes how the client must determine if the presented DNS name matches the reference DNS name. The rules differ depending on whether the domain to be checked is an internationalized domain name, as defined in Section 2, or not. For clients that support presented identifiers containing the wildcard character "*", this section also specifies a supplemental rule for such "wildcard certificates". This section uses the description of labels and domain names in [DNS-CONCEPTS].
このセクションでは、提示されたDNS名が参照DNS名と一致するかどうかをクライアントがどのように判断する必要があるかについて説明します。ルールは、セクション2で定義されているように、チェックされるドメインが国際化されたドメイン名であるかどうかによって異なります。WildCard文字「*」を含む提示された識別子をサポートするクライアントの場合、このセクションは、そのような「ワイルドカード証明書」の補足ルールも指定しています。このセクションでは、[DNSコンセプト]でラベル名とドメイン名の説明を使用します。
If the DNS domain name portion of a reference identifier is not an internationalized domain name (i.e., an FQDN that conforms to "preferred name syntax" as described in Section 3.5 of [DNS-CONCEPTS]), then the matching of the reference identifier against the presented identifier MUST be performed by comparing the set of domain name labels using a case-insensitive ASCII comparison, as clarified by [DNS-CASE]. For example, WWW.BigCompany.Example would be lower-cased to www.bigcompany.example for comparison purposes. Each label MUST match in order for the names to be considered a match, except as supplemented by the rule about checking wildcard labels in presented identifiers given below.
参照識別子のDNSドメイン名部分が国際化ドメイン名ではない場合（つまり、[DNS概念]セクション3.5で説明されているように「優先名の構文」に準拠するFQDN）、次の参照識別子の一致する提示された識別子は、[DNS-Case]によって明確にされたように、ケースに依存しないASCII比較を使用してドメイン名ラベルのセットを比較することにより実行する必要があります。たとえば、www.bigcompany.exampleは、比較目的でwww.bigcompany.exampleに低いケースを測定します。以下に示す提示された識別子のワイルドカードラベルをチェックすることについてのルールで補足されている場合を除き、各ラベルは一致するためには一致する必要があります。
If the DNS domain name portion of a reference identifier is an internationalized domain name, then the client MUST convert any U-labels [IDNA-DEFS] in the domain name to A-labels before checking the domain name or comparing it with others. 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 wildcard labels in presented identifiers given below.
参照識別子のDNSドメイン名部分が国際化されたドメイン名である場合、クライアントはドメイン名をチェックするか、他の人と比較する前に、ドメイン名のuラベル[idna-defs]をドメイン名に変換する必要があります。[idna-proto]に従って、a-labelsを症例感受性ASCIIとして比較する必要があります。各ラベルは、以下に示す提示された識別子のワイルドカードラベルのチェックに関するルールで補足されている場合を除き、ドメイン名を一致すると見なすために一致する必要があります。
If the technology specification supports wildcards in presented identifiers, then the client MUST match the reference identifier against a presented identifier whose DNS domain name portion contains the wildcard character "*" in a label, provided these requirements are met:
テクノロジー仕様が提示された識別子のワイルドカードをサポートする場合、クライアントは、これらの要件が満たされている場合、ラベルにDNSドメイン名部分がラベルにワイルドカード文字「*」を含む提示された識別子と参照識別子と一致する必要があります。
1. There is only one wildcard character.
1. ワイルドカードの文字は1つだけです。
2. The wildcard character appears only as the complete content of the left-most label.
2. ワイルドカードの文字は、左端のラベルの完全なコンテンツとしてのみ表示されます。
If the requirements are not met, the presented identifier is invalid and MUST be ignored.
要件が満たされていない場合、提示された識別子は無効であり、無視する必要があります。
A wildcard in a presented identifier can only match one label in a reference identifier. This specification covers only wildcard characters in presented identifiers, not wildcard characters in reference identifiers or in DNS domain names more generally. Therefore, the use of wildcard characters as described herein is not to be confused with DNS wildcard matching, where the "*" label always matches at least one whole label and sometimes more; see [DNS-CONCEPTS], Section 4.3.3 and [DNS-WILDCARDS]. In particular, it also deviates from [DNS-WILDCARDS], Section 2.1.3.
提示された識別子のワイルドカードは、参照識別子の1つのラベルのみを一致させることができます。この仕様は、参照識別子またはDNSドメイン名のワイルドカード文字ではなく、提示された識別子のワイルドカード文字のみをカバーします。したがって、本明細書に記載されているワイルドカード文字の使用は、「*」ラベルが常に少なくとも1つのラベル全体に一致するDNSワイルドカードマッチングと混同しないでください。[DNSConcepts]、セクション4.3.3および[DNS-WildCards]を参照してください。特に、[DNS-WildCards]、セクション2.1.3からも逸脱しています。
For information regarding the security characteristics of wildcard certificates, see Section 7.1.
ワイルドカード証明書のセキュリティ特性に関する情報については、セクション7.1を参照してください。
Matching of an IP-ID is based on an octet-for-octet comparison of the bytes of the reference identity with the bytes contained in the iPAddress subjectAltName.
IP-IDの一致は、iPaddressのsubjectaltnameに含まれるバイトとの参照アイデンティティのバイトのオクテットの比較に基づいています。
For an IP address that appears in a URI-ID, the "host" component of both the reference identity and the presented identifier must match. These are parsed as either an "IPv6address" (following [URI], Section 3.2.2) or an "IPv4address" (following [IPv4]). If the resulting octets are equal, the IP address matches.
URI-IDに表示されるIPアドレスの場合、参照IDと提示された識別子の両方の「ホスト」コンポーネントが一致する必要があります。これらは、「IPv6Address」（[URI]、セクション3.2.2に続く）または「IPv4Address」（[IPv4]に続く）として解析されます。結果のオクテットが等しい場合、IPアドレスは一致します。
This document does not specify how an SRV-ID reference identity can include an IP address, as [SRVNAME] only defines string names, not octet identifiers such as an IP address.
このドキュメントでは、[SRVNAME]はIPアドレスなどのオクテット識別子ではなく、文字列名のみを定義するため、SRV-ID参照IDにIPアドレスをどのように含めるかを指定しません。
The rules for matching the application service type depend on whether the identifier is an SRV-ID or a URI-ID.
アプリケーションサービスタイプを一致させるためのルールは、識別子がSRV-IDかURI-IDであるかによって異なります。
These identifiers provide 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. Consider the example of a messaging client that has two reference identifiers: (1) an SRV-ID of _xmpp-client.messenger.example and (2) a DNS-ID of app.example. The client MUST check (1) the combination of (a) an application service type of xmpp-client and (b) a DNS domain name of messenger.example as well as (2) a DNS domain name of app.example. However, the client MUST NOT check the combination of an application service type of xmpp-client and a DNS domain name of app.example because it does not have an SRV-ID of _xmpp-client.app.example in its list of reference identifiers.
これらの識別子は、チェックするアプリケーションサービスタイプの部分を提供しますが、その部分はSRV-IDまたはURI-ID自体のDNSドメイン名部分とのみ組み合わされます。2つの参照識別子を持つメッセージングクライアントの例を考えてみましょう。（1）_xmpp-client.messenger.exampleのsrv-idおよび（2）app.exampleのdns-id。クライアントは、（1）（a）XMPP-Clientのアプリケーションサービスタイプと（b）Messenger.exampleのDNSドメイン名の組み合わせと（2）App.exampleのDNSドメイン名を確認する必要があります。ただし、クライアントは、XMPP-ClientのアプリケーションサービスタイプとDNSドメイン名の組み合わせを確認してはなりません。。
If the identifier is an SRV-ID, then the application service name MUST be matched in a case-insensitive manner, in accordance with [DNS-SRV]. Note that per [SRVNAME], the underscore "_" is part of the service name in DNS SRV records and in SRV-IDs.
識別子がSRV-IDである場合、[DNS-SRV]に従って、アプリケーションサービス名をケースに依存しない方法で一致させる必要があります。[SRVNAME]ごとに、アンダースコア「_」はDNS SRVレコードおよびSRV-IDのサービス名の一部であることに注意してください。
If the identifier is a URI-ID, then the scheme name portion MUST be matched in a case-insensitive manner, in accordance with [URI]. Note that the colon ":" 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である場合、[URI]に従って、スキーム名の部分をケースに依存しない方法で一致させる必要があります。コロン "："はスキーム名とURIの残りの部分の間のセパレーターであるため、比較に含める必要はないことに注意してください。
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, then the client MUST proceed as follows.
クライアントが参照識別子のいずれかを一致させる提示された識別子が見つからない場合、クライアントは次のように続行する必要があります。
If the client is an automated application, then it SHOULD terminate the communication attempt with a bad certificate error and log the error appropriately. The application MAY provide a configuration setting to disable this behavior, but it MUST NOT disable this security control by default.
クライアントが自動化されたアプリケーションである場合、悪い証明書エラーで通信試行を終了し、エラーを適切にログに記録する必要があります。アプリケーションは、この動作を無効にする構成設定を提供する場合がありますが、デフォルトでこのセキュリティ制御を無効にしてはなりません。
If the client is one 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 in order to prevent users from inadvertently bypassing security protections in hostile situations. Such clients MAY give advanced users the option of proceeding with acceptance despite the identity mismatch. Although this behavior can be appropriate in certain specialized circumstances, it needs to be handled with extreme caution, for example by first encouraging even an advanced user to terminate the communication attempt and, if they choose to proceed anyway, by forcing the user to view the entire certification path before proceeding.
クライアントが人間のユーザーによって直接制御されている場合、ユーザーにIDの不一致を通知し、ユーザーが敵対的な状況でのセキュリティ保護を不注意にバイパスするのを防ぐために、悪い証明書エラーで通信試行を自動的に終了する必要があります。このようなクライアントは、アイデンティティの不一致にもかかわらず、上級ユーザーに受け入れを続けるオプションを提供する場合があります。この動作は特定の専門的な状況では適切ですが、たとえば、上級ユーザーでさえ通信試行を終了するように奨励し、とにかく続行することを選択した場合、ユーザーにユーザーに表示するように強制することにより、極端に注意して処理する必要があります。進む前の認定パス全体。
The application MAY also present the user with the ability to accept the presented certificate as valid for subsequent connections. Such ad hoc "pinning" SHOULD NOT restrict future connections to just the pinned certificate. Local policy that statically enforces a given certificate for a given peer SHOULD be made available only as prior configuration rather than a just-in-time override for a failed connection.
また、アプリケーションは、後続の接続に対して有効として提示された証明書を受け入れる機能をユーザーに提示する場合があります。このようなアドホックな「ピン留め」は、将来の接続を固定された証明書のみに制限するものではありません。特定のピアの特定の証明書を静的に実施するローカルポリシーは、接続に失敗したジャストインタイムオーバーライドではなく、以前の構成としてのみ利用可能にする必要があります。
Wildcard certificates automatically vouch for any single-label hostnames within their domain, but not multiple levels of domains. This can be convenient for administrators but also poses the risk of vouching for rogue or buggy hosts. For example, see [Defeating-SSL] (beginning at slide 91) and [HTTPSbytes] (slides 38-40).
ワイルドカード証明書は、ドメイン内の単一ラベルホスト名を自動的に保証しますが、複数のレベルのドメインではありません。これは管理者にとって便利ですが、不正なホストやバギーのホストを保証するリスクももたらします。たとえば、[敗北SSL]（Slide 91から始まる）および[httpsbytes]（スライド38-40）を参照してください。
As specified in Section 6.3, restricting the presented identifiers in certificates to only one wildcard character (e.g., "*.bigcompany.example" but not "*.*.bigcompany.example") and restricting the use of wildcards to only the left-most domain label can help to mitigate certain aspects of the attack described in [Defeating-SSL].
セクション6.3で指定されているように、証明書の提示された識別子を1つのワイルドカード文字（ "*.bigcompany.example"ではないが、「*。*。bigcompany.example "）に制限し、ワイルドカードの使用を左だけに制限する - ほとんどのドメインラベルは、[SSLを倒す]に記載されている攻撃の特定の側面を軽減するのに役立ちます。
That same attack also relies on the initial use of a cleartext HTTP connection, which is hijacked by an active on-path attacker and subsequently upgraded to HTTPS. In order to mitigate such an attack, administrators and software developers are advised to follow the strict TLS guidelines provided in [TLS-REC], Section 3.2.
同じ攻撃は、アクティブなオンパス攻撃者によってハイジャックされ、その後HTTPSにアップグレードされるClearText HTTP接続の初期使用にも依存しています。このような攻撃を緩和するために、管理者とソフトウェア開発者は、[TLS-REC]、セクション3.2で提供される厳密なTLSガイドラインに従うことをお勧めします。
Because the attack described in [HTTPSbytes] relies on an underlying cross-site scripting (XSS) attack, web browsers and applications are advised to follow best practices to prevent XSS attacks; for example, see [XSS], which was published by the Open Web Application Security Project (OWASP).
[httpsbytes]に記載されている攻撃は、基礎となるクロスサイトスクリプト（XSS）攻撃に依存しているため、XSS攻撃を防ぐためにベストプラクティスに従うことをお勧めします。たとえば、Open Web Application Security Project（OWASP）によって公開された[XSS]を参照してください。
Protection against a wildcard that identifies a public suffix [Public-Suffix], such as *.co.uk or *.com, is beyond the scope of this document.
*.co.ukや *.comなどのパブリックサフィックス[public-suffix]を識別するワイルドカードに対する保護は、このドキュメントの範囲を超えています。
As noted in Section 3, application protocols can disallow the use of wildcard certificates entirely as a more foolproof mitigation.
セクション3で述べたように、アプリケーションプロトコルは、より完全な緩和策としてワイルドカード証明書の使用を完全に禁止できます。
The URI-ID type is a subjectAltName entry of type uniformResourceIdentifier as defined in [PKIX]. For the purposes of this specification, the URI-ID MUST include both a "scheme" and a "host" component that matches the "reg-name" rule; if the entry does not include both, it is not a valid URI-ID and MUST be ignored. Any other components are ignored because only the "scheme" and "host" components are used for certificate matching as specified under Section 6.
URI-IDタイプは、[pkix]で定義されている統一ResourceIdentidifierの科目エントリです。この仕様の目的のために、URI-IDには、「スキーム」と「登録名」ルールに一致する「ホスト」コンポーネントの両方を含める必要があります。エントリに両方が含まれていない場合、それは有効なURI-IDではなく、無視する必要があります。セクション6で指定されているように、「スキーム」と「ホスト」コンポーネントのみが証明書マッチングに使用されるため、他のコンポーネントは無視されます。
The quoted component names in the previous paragraph represent the associated [ABNF] productions from the IETF Proposed Standard for Uniform Resource Identifiers [URI]. Although the reader should be aware that some applications (e.g., web browsers) might instead conform to the Uniform Resource Locator (URL) specification maintained by the WHATWG [URL], it is not expected that differences between the URI and URL specifications would manifest themselves in certificate matching.
前の段落の引用されたコンポーネント名は、均一なリソース識別子[URI]のIETF提案標準からの関連する[ABNF]プロダクションを表しています。読者は、一部のアプリケーション（たとえば、Webブラウザー）がwhatwg [url]によって維持されているユニフォームリソースロケーター（URL）仕様に適合する可能性があることに注意する必要がありますが、URIとURL仕様の違いが自分自身を明らかにすることは予想されません。証明書マッチングで。
This document specifies only matching between reference identifiers and presented identifiers, not the visual presentation of domain names. Specifically, the matching of internationalized domain names is performed on A-labels only (Section 6.3). The limited scope of this specification likely mitigates potential confusion caused by the use of visually similar characters in domain names (for example, as described in Section 4.4 of [IDNA-DEFS], [UTS-36], and [UTS-39]); in any case, such concerns are a matter for application-level protocols and user interfaces, not the matching of certificates.
このドキュメントは、ドメイン名の視覚的な表示ではなく、参照識別子と提示された識別子間の一致のみを指定します。具体的には、国際化されたドメイン名の一致は、Aラベルでのみ実行されます（セクション6.3）。この仕様の限られた範囲は、ドメイン名で視覚的に類似した文字を使用することによって引き起こされる潜在的な混乱を軽減する可能性があります（たとえば、[IDNA-DEFS]、[UTS-36]、および[UTS-39]のセクション4.4で説明されています）;いずれにせよ、そのような懸念は、証明書の一致ではなく、アプリケーションレベルのプロトコルとユーザーインターフェイスの問題です。
The TLS Server Name Indication (SNI) extension only conveys domain names. Therefore, a client with an IP-ID reference identity cannot present any information about its reference identity when connecting to a server. Servers that wish to present an IP-ID therefore need to present this identity when a connection is made without SNI.
TLSサーバー名表示（SNI）拡張機能は、ドメイン名のみを伝えます。したがって、IP-ID参照IDを持つクライアントは、サーバーに接続するときに参照IDに関する情報を提示することはできません。したがって、IP-IDを提示したいサーバーは、SNIなしで接続が行われたときにこのIDを提示する必要があります。
The textual representation of an IPv4 address might be misinterpreted as a valid FQDN in some contexts. This can result in different security treatment that might cause different components of a system to classify the value differently, which might lead to vulnerabilities. Consider a system in which one component enforces a security rule that is conditional on the type of identifier but misclassifies an IP address as an FQDN, whereas a second component correctly classifies the identifier but incorrectly assumes that rules regarding IP addresses have been enforced by the first component. As a result, the system as a whole might behave in an insecure manner. Consistent classification of identifiers avoids this problem.
IPv4アドレスのテキスト表現は、一部のコンテキストで有効なFQDNと誤解される可能性があります。これにより、システムのさまざまなコンポーネントがバリューを異なる方法で分類する可能性があるさまざまなセキュリティ処理につながる可能性があり、脆弱性につながる可能性があります。1つのコンポーネントが識別子のタイプを条件としているがIPアドレスをFQDNとして誤って分類するセキュリティルールを強制するシステムを考えてみましょう。成分。その結果、システム全体が不安定な方法で動作する可能性があります。識別子の一貫した分類は、この問題を回避します。
See also Section 3, particularly the last paragraph.
セクション3、特に最後の段落も参照してください。
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 or protocols. TLS extensions such as the Server Name Indication (SNI), as discussed in [TLS-EXT], Section 3, and ALPN, as discussed in [ALPN], provide a way for the application to indicate the desired identifier and protocol to the server, which it can then use to select the most appropriate certificate.
特定のアプリケーションサービスは、さまざまな理由で複数のDNSドメイン名によって対処される場合があり、特定の展開は複数のドメインまたはプロトコルにサービスを提供する場合があります。[TLS-EXT]、セクション3、およびALPNで説明されているサーバー名表示（SNI）などのTLS拡張機能は、[ALPN]で説明されているように、アプリケーションがサーバーへの望ましい識別子とプロトコルを示す方法を提供します。、それを使用して、最も適切な証明書を選択できます。
This specification allows multiple DNS-IDs, IP-IDs, SRV-IDs, or URI-IDs in a certificate. As a result, an application service can use the same certificate for multiple hostnames, such as when a client does not support the TLS SNI extension, or for multiple protocols, such as SMTP and HTTP, on a single hostname. Note that the set of names in a certificate is the set of names that could be affected by a compromise of any other server named in the set: the strength of any server in the set of names is determined by the weakest of those servers that offer the names.
この仕様により、証明書に複数のDNS-ID、IP-ID、SRV-ID、またはURI-IDが許可されます。その結果、アプリケーションサービスは、クライアントがTLS SNI拡張機能をサポートしていない場合、または単一のホスト名でSMTPやHTTPなどの複数のプロトコルなど、複数のホスト名で同じ証明書を使用できます。証明書内の名前のセットは、セットに指定された他のサーバーの妥協によって影響を受ける可能性のある名前のセットであることに注意してください。名前のセット内のサーバーの強度は、提供するサーバーの最も弱いサーバーによって決定されます。名。
The way to mitigate this risk is to limit the number of names that any server can speak for and to ensure that all servers in the set have a strong minimum configuration as described in [TLS-REC], Section 3.9.
このリスクを軽減する方法は、どのサーバーが話すことができる名前の数を制限し、[TLS-REC]、セクション3.9で説明されているように、セット内のすべてのサーバーが強力な最小構成を確保することです。
This specification describes how a client may construct multiple acceptable reference identifiers and may match any of those reference identifiers with the set of presented identifiers. [PKIX], Section 4.2.1.10 describes a mechanism to allow CA certificates to be constrained in the set of presented identifiers that they may include within server certificates. However, these constraints only apply to the explicitly enumerated name forms. For example, a CA that is only name-constrained for DNS-IDs is not constrained for SRV-IDs and URI-IDs, unless those name forms are also explicitly included within the name constraints extension.
この仕様では、クライアントが複数の許容可能な参照識別子を構築する方法を説明し、それらの参照識別子のいずれかを提示された識別子のセットと一致させることができます。[PKIX]、セクション4.2.1.10では、サーバー証明書に含まれる可能性のある提示された識別子のセットにCA証明書を制約できるようにするメカニズムについて説明しています。ただし、これらの制約は、明示的に列挙された名前フォームにのみ適用されます。たとえば、DNS-IDの名前のみが制約されるCAは、SRV-IDとURI-IDに制約されません。これらの名前フォームが名前の制約拡張機能に明示的に含まれている場合を除きます。
A client that constructs multiple reference identifiers of different types, such as both DNS-IDs and SRV-IDs as described in Section 6.1.1, SHOULD take care to ensure that CAs issuing such certificates are appropriately constrained. This MAY take the form of local policy through agreement with the issuing CA or MAY be enforced by the client requiring that if one form of presented identifier is constrained, such as a dNSName name constraint for DNS-IDs, then all other forms of acceptable reference identities are also constrained, such as requiring a uniformResourceIndicator name constraint for URI-IDs.
セクション6.1.1で説明されているように、DNS-IDとSRV-IDの両方など、さまざまなタイプの複数の参照識別子を構築するクライアントは、そのような証明書を発行するCASが適切に制約されるように注意する必要があります。これは、発行CAとの契約を通じてローカルポリシーの形をとるか、DNS-IDのDNSName名制約など、提示された識別子の1つの形式が制約される場合、その後のすべての許容可能な参照の形式が制約されることを要求するクライアントによって施行される場合があります。uri-idsの均一resourceindicator名の制約が必要ななど、アイデンティティも制約されています。
This document assumes that if a client trusts a given CA, it trusts all certificates issued by that CA. The certificate checking process does not include additional checks for bad behavior by the hosts identified with such certificates, for instance, rogue servers or buggy applications. Any additional checks (e.g., checking the server name against trusted block lists) are the responsibility of the application protocol or the client itself.
このドキュメントは、クライアントが特定のCAを信頼している場合、そのCAによって発行されたすべての証明書を信頼することを前提としています。証明書チェックプロセスには、そのような証明書で識別されたホストによる悪い動作の追加チェックは含まれていません。たとえば、Rogueサーバーやバギーアプリケーションです。追加のチェック（たとえば、信頼できるブロックリストに対するサーバー名のチェック）は、アプリケーションプロトコルまたはクライアント自体の責任です。
This document has no IANA actions.
このドキュメントにはIANAアクションがありません。
[DNS-CONCEPTS]
Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
<https://www.rfc-editor.org/info/rfc1034>.
[DNS-SRV] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
specifying the location of services (DNS SRV)", RFC 2782,
DOI 10.17487/RFC2782, February 2000,
<https://www.rfc-editor.org/info/rfc2782>.
[DNS-WILDCARDS]
Lewis, E., "The Role of Wildcards in the Domain Name
System", RFC 4592, DOI 10.17487/RFC4592, July 2006,
<https://www.rfc-editor.org/info/rfc4592>.
[IDNA-DEFS]
Klensin, J., "Internationalized Domain Names for
Applications (IDNA): Definitions and Document Framework",
RFC 5890, DOI 10.17487/RFC5890, August 2010,
<https://www.rfc-editor.org/info/rfc5890>.
[IDNA-PROTO]
Klensin, J., "Internationalized Domain Names in
Applications (IDNA): Protocol", RFC 5891,
DOI 10.17487/RFC5891, August 2010,
<https://www.rfc-editor.org/info/rfc5891>.
[IPv4] Postel, J., "Internet Protocol", STD 5, RFC 791,
DOI 10.17487/RFC0791, September 1981,
<https://www.rfc-editor.org/info/rfc791>.
[IPv6] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, DOI 10.17487/RFC4291, February
2006, <https://www.rfc-editor.org/info/rfc4291>.
[LDAP-DN] Zeilenga, K., Ed., "Lightweight Directory Access Protocol
(LDAP): String Representation of Distinguished Names",
RFC 4514, DOI 10.17487/RFC4514, June 2006,
<https://www.rfc-editor.org/info/rfc4514>.
[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, DOI 10.17487/RFC5280, May 2008,
<https://www.rfc-editor.org/info/rfc5280>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[SRVNAME] Santesson, S., "Internet X.509 Public Key Infrastructure
Subject Alternative Name for Expression of Service Name",
RFC 4985, DOI 10.17487/RFC4985, August 2007,
<https://www.rfc-editor.org/info/rfc4985>.
[TLS-REC] Sheffer, Y., Saint-Andre, P., and T. Fossati,
"Recommendations for Secure Use of Transport Layer
Security (TLS) and Datagram Transport Layer Security
(DTLS)", BCP 195, RFC 9325, DOI 10.17487/RFC9325, November
2022, <https://www.rfc-editor.org/info/rfc9325>.
[URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, DOI 10.17487/RFC3986, January 2005,
<https://www.rfc-editor.org/info/rfc3986>.
[ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234,
DOI 10.17487/RFC5234, January 2008,
<https://www.rfc-editor.org/info/rfc5234>.
[ACME] Barnes, R., Hoffman-Andrews, J., McCarney, D., and J.
Kasten, "Automatic Certificate Management Environment
(ACME)", RFC 8555, DOI 10.17487/RFC8555, March 2019,
<https://www.rfc-editor.org/info/rfc8555>.
[ALPACA] Brinkmann, M., Dresen, C., Merget, R., Poddebniak, D.,
Müller, J., Somorovsky, J., Schwenk, J., and S. Schinzel,
"ALPACA: Application Layer Protocol Confusion - Analyzing
and Mitigating Cracks in TLS Authentication", 30th USENIX
Security Symposium (USENIX Security 21), September 2021,
<https://alpaca-attack.com/ALPACA.pdf>.
[ALPN] Friedl, S., Popov, A., Langley, A., and E. Stephan,
"Transport Layer Security (TLS) Application-Layer Protocol
Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301,
July 2014, <https://www.rfc-editor.org/info/rfc7301>.
[DANE] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication
of Named Entities (DANE) Transport Layer Security (TLS)
Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August
2012, <https://www.rfc-editor.org/info/rfc6698>.
[Defeating-SSL]
Marlinspike, M., "New Tricks for Defeating SSL in
Practice", Black Hat DC, February 2009,
<https://www.blackhat.com/presentations/bh-dc-
09/Marlinspike/BlackHat-DC-09-Marlinspike-Defeating-
SSL.pdf>.
[DNS-CASE] Eastlake 3rd, D., "Domain Name System (DNS) Case
Insensitivity Clarification", RFC 4343,
DOI 10.17487/RFC4343, January 2006,
<https://www.rfc-editor.org/info/rfc4343>.
[DNS-OVER-TLS]
Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D.,
and P. Hoffman, "Specification for DNS over Transport
Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May
2016, <https://www.rfc-editor.org/info/rfc7858>.
[DTLS] Rescorla, E., Tschofenig, H., and N. Modadugu, "The
Datagram Transport Layer Security (DTLS) Protocol Version
1.3", RFC 9147, DOI 10.17487/RFC9147, April 2022,
<https://www.rfc-editor.org/info/rfc9147>.
[EMAIL-SRV]
Daboo, C., "Use of SRV Records for Locating Email
Submission/Access Services", RFC 6186,
DOI 10.17487/RFC6186, March 2011,
<https://www.rfc-editor.org/info/rfc6186>.
[HTTP] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "HTTP Semantics", STD 97, RFC 9110,
DOI 10.17487/RFC9110, June 2022,
<https://www.rfc-editor.org/info/rfc9110>.
[HTTPSbytes]
Sokol, J. and R. Hansen, "HTTPS Can Byte Me", Black Hat
Briefings, November 2010, <https://media.blackhat.com/bh-
ad-10/Hansen/Blackhat-AD-2010-Hansen-Sokol-HTTPS-Can-Byte-
Me-slides.pdf>.
[NAPTR] Mealling, M., "Dynamic Delegation Discovery System (DDDS)
Part Three: The Domain Name System (DNS) Database",
RFC 3403, DOI 10.17487/RFC3403, October 2002,
<https://www.rfc-editor.org/info/rfc3403>.
[NTS] Franke, D., Sibold, D., Teichel, K., Dansarie, M., and R.
Sundblad, "Network Time Security for the Network Time
Protocol", RFC 8915, DOI 10.17487/RFC8915, September 2020,
<https://www.rfc-editor.org/info/rfc8915>.
[Public-Suffix]
Mozilla Foundation, "Public Suffix List",
<https://publicsuffix.org>.
[QUIC] Thomson, M., Ed. and S. Turner, Ed., "Using TLS to Secure
QUIC", RFC 9001, DOI 10.17487/RFC9001, May 2021,
<https://www.rfc-editor.org/info/rfc9001>.
[RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
Multiplexed and Secure Transport", RFC 9000,
DOI 10.17487/RFC9000, May 2021,
<https://www.rfc-editor.org/info/rfc9000>.
[SECTERMS] Shirey, R., "Internet Security Glossary, Version 2",
FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007,
<https://www.rfc-editor.org/info/rfc4949>.
[SECURE-CONTEXTS]
West, M., "Secure Contexts", W3C Candidate Recommendation
Draft, September 2021,
<https://www.w3.org/TR/secure-contexts/>.
[SIP] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
DOI 10.17487/RFC3261, June 2002,
<https://www.rfc-editor.org/info/rfc3261>.
[SIP-CERTS]
Gurbani, V., Lawrence, S., and A. Jeffrey, "Domain
Certificates in the Session Initiation Protocol (SIP)",
RFC 5922, DOI 10.17487/RFC5922, June 2010,
<https://www.rfc-editor.org/info/rfc5922>.
[SIP-SIPS] Audet, F., "The Use of the SIPS URI Scheme in the Session
Initiation Protocol (SIP)", RFC 5630,
DOI 10.17487/RFC5630, October 2009,
<https://www.rfc-editor.org/info/rfc5630>.
[SMTP-TLS] Fenton, J., "SMTP Require TLS Option", RFC 8689,
DOI 10.17487/RFC8689, November 2019,
<https://www.rfc-editor.org/info/rfc8689>.
[SVCB-FOR-DNS]
Schwartz, B., "Service Binding Mapping for DNS Servers",
RFC 9461, DOI 10.17487/RFC9461, November 2023,
<https://www.rfc-editor.org/info/rfc9461>.
[SVCB-FOR-HTTPS]
Schwartz, B., Bishop, M., and E. Nygren, "Service Binding
and Parameter Specification via the DNS (SVCB and HTTPS
Resource Records)", RFC 9460, DOI 10.17487/RFC9460,
November 2023, <https://www.rfc-editor.org/info/rfc9460>.
[TLS] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>.
[TLS-EXT] Eastlake 3rd, D., "Transport Layer Security (TLS)
Extensions: Extension Definitions", RFC 6066,
DOI 10.17487/RFC6066, January 2011,
<https://www.rfc-editor.org/info/rfc6066>.
[TLS-SUBCERTS]
Barnes, R., Iyengar, S., Sullivan, N., and E. Rescorla,
"Delegated Credentials for TLS and DTLS", RFC 9345,
DOI 10.17487/RFC9345, July 2023,
<https://www.rfc-editor.org/info/rfc9345>.
[URL] van Kesteren, A., "URL", WHATWG Living Standard, September
2023, <https://url.spec.whatwg.org/>.
[US-ASCII] American National Standards Institute, "Coded Character
Sets - 7-bit American Standard Code for Information
Interchange (7-Bit ASCII)", ANSI INCITS 4-1986 (R2007),
June 2007.
[UTS-36] Davis, M. and M. Suignard, "Unicode Security
Considerations", Revision 15, Unicode Technical
Report #36, September 2014,
<https://unicode.org/reports/tr36/>.
[UTS-39] Davis, M. and M. Suignard, "Unicode Security Mechanisms",
Version 15.1.0, Revision 28, Unicode Technical
Standard #39, September 2023,
<https://unicode.org/reports/tr39/>.
[VERIFY] Saint-Andre, P. and J. Hodges, "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)", RFC 6125, DOI 10.17487/RFC6125, March
2011, <https://www.rfc-editor.org/info/rfc6125>.
[WSC-UI] Saldhana, A. and T. Roessler, "Web Security Context: User
Interface Guidelines", W3C Recommendation REC-wsc-ui-
20100812, August 2010,
<https://www.w3.org/TR/2010/REC-wsc-ui-20100812/>.
[X.509] ITU-T, "Information Technology - Open Systems
Interconnection - The Directory: Public-key and attribute
certificate frameworks", ISO/IEC 9594-8, ITU-T
Recommendation X.509, October 2019.
[X.690] ITU-T, "Information Technology - ASN.1 encoding rules:
Specification of Basic Encoding Rules (BER), Canonical
Encoding Rules (CER) and Distinguished Encoding Rules
(DER)", ISO/IEC 8825-1:2021 (E), ITU-T
Recommendation X.690, February 2021.
[XMPP] Saint-Andre, P., "Extensible Messaging and Presence
Protocol (XMPP): Core", RFC 6120, DOI 10.17487/RFC6120,
March 2011, <https://www.rfc-editor.org/info/rfc6120>.
[XSS] Kirsten, S., et al., "Cross Site Scripting (XSS)", OWASP
Foundation, 2020,
<https://owasp.org/www-community/attacks/xss/>.
This document revises and obsoletes [VERIFY] based on the decade of experience and changes since it was published. The major changes, in no particular order, include:
このドキュメントは、公開されてからの経験と変化の10年に基づいて、[確認]を修正および廃止します。主要な変更には、順番には含まれていません。
* The only legal place for a certificate wildcard is as the complete left-most label in a domain name.
* 証明書のワイルドカードの唯一の合法的な場所は、ドメイン名の完全な左のラベルとしてです。
* The server identity can only be expressed in the subjectAltNames extension; it is no longer valid to use the commonName RDN, known as CN-ID in [VERIFY].
* サーバーのアイデンティティは、subjectaltnames拡張機能でのみ表現できます。[検証]でCN-IDとして知られるCommonName RDNを使用することはもはや有効です。
* Detailed discussion of pinning (configuring use of a certificate that doesn't match the criteria in this document) has been removed and replaced with two paragraphs in Section 6.6.
* ピン留め（このドキュメントの基準と一致しない証明書の使用の構成）の詳細な説明は削除され、セクション6.6の2つの段落に置き換えられました。
* The sections detailing different target audiences and which sections to read (first) have been removed.
* さまざまなターゲットオーディエンスと読むべきセクション（最初）を詳述したセクションが削除されました。
* References to the X.500 directory, the survey of prior art, and the sample text in Appendix A have been removed.
* X.500ディレクトリへの参照、以前のアートの調査、および付録Aのサンプルテキストは削除されました。
* All references have been updated to the latest versions.
* すべての参照は最新のバージョンに更新されました。
* The TLS SNI extension is no longer new; it is commonplace.
* TLS SNI拡張はもはや新しいものではありません。それは一般的です。
* Additional text on multiple identifiers, and their security considerations, has been added.
* 複数の識別子に関する追加のテキストとそのセキュリティ上の考慮事項が追加されました。
* IP-ID reference identifiers have been added. This builds on the definition in [HTTP], Section 4.3.5.
* IP-ID参照識別子が追加されました。これは、[HTTP]、セクション4.3.5の定義に基づいています。
* The document title has been shortened because the previous title was difficult to cite.
* 前のタイトルを引用するのが困難だったため、ドキュメントタイトルが短縮されました。
We gratefully acknowledge everyone who contributed to the previous version of this specification [VERIFY]. Thanks also to Carsten Bormann for converting the previous version of this specification to Markdown so that we could more easily use Martin Thomson's i-d-template software.
この仕様の以前のバージョンに貢献したすべての人に感謝します[Verify]。この仕様の以前のバージョンをMarkdownに変換して、Martin ThomsonのI-D-Templateソフトウェアをより簡単に使用できるように、Carsten Bormannにも感謝します。
In addition to discussions within the UTA Working Group, the following people provided official reviews or especially significant feedback: Corey Bonnell, Roman Danyliw, Viktor Dukhovni, Lars Eggert, Patrik Fältström, Jim Fenton, Olle Johansson, John Klensin, Murray Kucherawy, Warren Kumari, John Mattson, Alexey Melnikov, Derrell Piper, Maria Ines Robles, Rob Sayre, Yaron Sheffer, Ryan Sleevi, Brian Smith, Petr Špaček, Orie Steele, Martin Thomson, Joe Touch, Éric Vyncke, Paul Wouters, and Qin Wu.
UTAワーキンググループ内での議論に加えて、次の人々は公式のレビューまたは特に重要なフィードバックを提供しました：Corey Bonnell、Roman Danyliw、Viktor Dukhovni、Lars Eggert、PatrikFältström、Jim Fenton、Olle Johansson、John Klensin、Murray Kumariy、Warren Kumari、ジョン・マットソン、アレクセイ・メルニコフ、デレル・パイパー、マリア・イネス・ロブレス、ロブ・セイヤー、ヤロン・シェファー、ライアン・スリーヴィ、ブライアン・スミス、ペトルシュパチェク、オリー・スティール、マーティン・トムソン、ジョー・タッチ、エリック・ヴィンチケ、ポール・ワウター、キン・ワウ。
A few descriptive sentences were borrowed from [TLS-REC].
[TLS-REC]からいくつかの記述文が借りられました。
Jeff Hodges coauthored the previous version of this specification [VERIFY]. The authors gratefully acknowledge his essential contributions to this work.
Jeff Hodgesは、この仕様の以前のバージョンを共著しました[Verify]。著者は、この作業に対する彼の本質的な貢献に感謝しています。
Martin Thomson contributed the text on the handling of IP-IDs.
Martin Thomsonは、IP-IDの取り扱いに関するテキストに貢献しました。
Peter Saint-Andre
Independent
United States of America
Email: stpeter@stpeter.im
Rich Salz
Akamai Technologies
United States of America
Email: rsalz@akamai.com