1. はじめに (Introduction)

1.1. 動機 (Motivation)

インターネットの目に見える顔の大部分は、対話的または自動化されたクライアントが、情報の取得やアップロード、他のエンティティとの通信、またはより広範なサービスネットワークへのアクセスのためにアプリケーションサービス (application service) と通信するクライアントサーバーアーキテクチャを採用しているサービスで構成されています。クライアントが Transport Layer Security [TLS] または Datagram Transport Layer Security [DTLS] を使用してアプリケーションサービスと通信する場合、安全な通信を確立しようとする間、サーバーのアイデンティティ (identity) の何らかの概念（たとえば、「example.com のウェブサイト」）を参照します。同様に、TLS ネゴシエーション中、サーバーは、X.509 [PKIX] を使用するインターネット公開鍵インフラストラクチャのコンテキストにおいて認証局 (CA) によって発行された公開鍵証明書の形式で、サービスアイデンティティの概念を提示します。非公式には、これらのアイデンティティをクライアントの「参照アイデンティティ (reference identity)」およびサーバーの「提示アイデンティティ (presented identity)」と考えることができます（これらの大まかなアイデアは、特定の識別子の概念を通じて、このドキュメントの後半でより正確に定義されます）。一般に、クライアントは、通信を認証できるように、サーバーの提示アイデンティティが参照アイデンティティと一致することを確認する必要があります。

多くのアプリケーション技術は、概説したパターンに従っています。そのようなプロトコルは伝統的に、アプリケーションサービスアイデンティティを表現および検証するための独自のルールを規定してきました。残念ながら、アプローチのこの相違は、認証局、アプリケーション開発者、およびプロトコル設計者の間でいくらかの混乱を引き起こしました。

たとえば、さまざまなアプリケーションプロトコルがさまざまな方法でサービスアイデンティティを表し（たとえば、DNS ドメイン名を汎用公開鍵インフラストラクチャ (PKI) 識別子として使用するものもあれば、アプリケーション固有の識別子を定義するものもあります）、多くのプロトコルは、国際化ドメイン名、ワイルドカードドメイン名、または証明書ごとの複数のアイデンティティを処理するための明確なルールを提供していません。これにより、認証局にとって幅広いアプリケーションで一貫して機能する証明書を発行することが困難になり、ソフトウェア開発者にとって一貫したアドレス検証コードを作成することが困難になり、プロトコル設計者にとってプロトコル定義で ID 検証を処理する方法を決定することが困難になります。

アプリケーションサービスアイデンティティを表現および検証するための単一の統一されたルールセットが存在する場合、さまざまな参加者の混乱を減らすだけでなく、各アプリケーションがアドホックな方法で検証ロジックを再実装することを要求するのではなく、実装が認証のための共通コードを共有できるようにすることで、ソフトウェアの品質を向上させることもできます。

1.2. 対象読者 (Audience)

このドキュメントの対象読者は次のとおりです。

TLS 上で実行されるプロトコルを指定するアプリケーションプロトコル設計者。
そのようなプロトコルを実装するアプリケーションソフトウェア開発者。
そのようなサービスを展開するサービスプロバイダー。
そのようなサービスで使用するための証明書を発行する認証局。

1.3. このドキュメントの読み方 (How to Read This Document)

このドキュメントは主に、アプリケーションプロトコル設計者によって再利用されることを意図して書かれています。したがって、ほとんどの「要件 (Requirements)」の文言は、「このドキュメントを再利用するアプリケーションプロトコル仕様は、次の要件を含めるか参照しなければならない」と解釈できます。

アプリケーションソフトウェア開発者向けには、サーバーアイデンティティの検証（セクション 6）および関連するセキュリティ上の考慮事項（セクション 7）をカバーする個別のセクションを提供しています。

サービスプロバイダーおよび認証局向けには、サーバーアイデンティティの表現（セクション 4）およびサーバー証明書の要求（セクション 5）をカバーする個別のセクションを提供しています。

1.4. 適用可能性 (Applicability)

このドキュメントは、あらゆる PKIX 証明書の一般的な使用ポリシーを定義することを意図したものではありません。代わりに、その範囲は、X.509 (PKIX) 証明書を使用してサーバーを認証する TLS クライアントに限定されています。S/MIME、IPsec、またはその他のプロトコルの一部としての認証は管理しません（このドキュメントを再利用するそのようなプロトコルの仕様で明示的に記載されている場合を除く）。このドキュメントで定義されている概念は他のコンテキストで有用である可能性がありますが、そのような拡張はこのドキュメントの範囲外です。

このドキュメントは主に新しいアプリケーションプロトコルによって採用されることを目的としていますが、既存のアプリケーションプロトコル（付録 B に記載されているものなど）が徐々にこのドキュメントの使用に移行することも期待されています。

1.5. 推奨事項の概要 (Overview of Recommendations)

次の表は、このドキュメントの推奨事項をまとめたものです。詳細は以下のセクションで提供されます。

エンティティ	役割	推奨事項
プロトコル設計者	仕様の作成	可能な限りこのドキュメントを参照する; 特定の識別子タイプを定義する。
アプリソフト開発者	検証の実装	セクション 6 のアルゴリズムに従う; ワイルドカードを慎重に処理する; ユーザーオーバーライド ("pinning") をサポートする。
サービス提供者	サービスの展開	DNS-ID を含む証明書を取得する; 必要な場合、SRV-ID または URI-ID も含める。
認証局	証明書の発行	subjectAltName に DNS-ID を含める; 後方互換性のためだけの場合のみ Subject に Common Name を含める。

1.6. 現在の技術からの一般化 (Generalization from Current Technologies)

このドキュメントで指定されている推奨事項は、さまざまなアプリケーションプロトコル仕様に含まれる ID 検証ルールから一般化されています（付録 B に記載されているものを含む）。私たちの一般的なアプローチは、そうしない説得力のある理由（たとえば、以前の仕様で特定されたセキュリティホールを閉じるため）がない限り、既存の慣行に従うべきであるというものです。現在の慣行の詳細な分析と、アプリケーションプロトコル開発コミュニティとの広範な協議の後、著者は、このドキュメントで指定されているルールが、展開されている現在の使用法の大部分と実質的に一致していると信じています。サーバーアイデンティティを表現する際の X.509 "Common Name" の使用など、現在の使用法との互換性を最大化しようと努めましたが、セキュリティ上の理由から（たとえば、ワイルドカード証明書に関連する攻撃から保護するため）、既存の制限を厳しくすることを推奨する場合もあります。

1.7. 範囲 (Scope)

1.7.1. 範囲内 (In Scope)

この仕様は、次の条件のすべてを満たすソフトウェア実装および展開に適用されます。

クライアントは、DNS ドメイン名によって識別されるサービスと通信することを目的としています。
クライアントは、DNS を使用してドメイン名をネットワークアドレス（たとえば、IPv4 または IPv6 アドレス）に解決します。
クライアントは、Transport Layer Security [TLS] または Datagram Transport Layer Security [DTLS] およびそれらの拡張機能（たとえば、[TLS-EXT] の Server Name Indication 拡張機能）を使用してサーバーと通信します。
サーバーは、X.509 ベースの公開鍵証明書 [PKIX] の形式でクライアントにそのアイデンティティを提示します。
クライアントは、サーバーのアイデンティティを検証する過程で、サーバーによって提示された証明書を使用します。

1.7.2. 範囲外 (Out of Scope)

次のトピックは、このドキュメントの範囲外です。

アプリケーションサービス認証以外のクライアントまたはサーバー認証（たとえば、クライアント認証、またはピアがクライアントまたはサーバーとして機能できる XML ベースのプロトコルでの認証）。
PKIX 以外の PKI プロファイル（たとえば、OpenPGP [OPENPGP]）のコンテキストでの証明書。
DNS ドメイン名によって識別されないサービスの認証（たとえば、[IP] または [IPv6] アドレスなどの IP アドレスによって識別されるサービス、または [NAPTR] で使用されるような他のタイプの識別子によって識別されるサービス）。
DNS ドメイン名の IP アドレスへの解決（ただし、これはドキュメントの操作に必要な前提条件です）。
証明書の有効性をチェックするためのメカニズム（たとえば、証明書失効リスト [PKIX] に対して、または Online Certificate Status Protocol [OCSP] を介して）。
認可決定（たとえば、クライアントが特定の認証局を信頼すべきかどうか、または特定のサーバーに接続すべきかどうか）。
証明書に既知のタイプの識別子が含まれていない場合（たとえば、クライアントが理解できない独自の識別子タイプのみが含まれている場合）にアイデンティティを検証する方法。
ユーザーインターフェースの詳細（たとえば、[WSC-UI]）。

1.8. 用語 (Terminology)

「アイデンティティ」に関連する多くの概念は、アプリケーションプロトコルで実行可能にするには曖昧すぎることが多いため、この仕様で使用するためのより具体的な用語のセットを定義します。

アプリケーションサービス (application service): インターネット上のサービスであり、対話的および自動化されたクライアントが接続して、情報の取得やアップロード、他のエンティティとの通信、またはより広範なサービスネットワークへの接続を可能にします。

アプリケーションサービスプロバイダー (application service provider): 特定のアプリケーションサービスをホストおよび管理するエンティティ。

アプリケーションサービスタイプ (application service type): さまざまなアプリケーションサービスを区別する特定のアプリケーションプロトコルまたはプロトコル構成を定義する識別子。可能な値には、DNS SRV サービス名（たとえば、"ldap"、"imap"、"xmpp-client"）または URI スキーム名（たとえば、"http"、"sip"、"acap"）が含まれます。

属性タイプ (attribute type): X.500 [X.500] 属性に保持される情報の種類のオブジェクト識別子。このドキュメントのコンテキストでは、属性値アサーション [X.501] で使用される特定のオブジェクト識別子（たとえば、CN）を指します。

属性値アサーション (Attribute Value Assertion, AVA): 属性タイプとそれに対応する値のアサーション [X.501]。

認証局 (certification authority, CA): 証明書を発行するエンティティ（たとえば、"Example CA"）。

CN-ID: 証明書 [PKIX] の Subject フィールド内の Common Name 属性（つまり、タイプ 2.5.4.3 の属性 [X.520]）であり、DNS ドメイン名の構文と一致する文字列を含みます。

Common Name: 証明書 [PKIX] の Subject フィールド内の属性（つまり、タイプ 2.5.4.3 の属性 [X.520]）。歴史的な理由から、識別子として Common Name を確認する必要があることがよくありますが、認証局が DNS ドメイン名だけでなく、他の文字列（たとえば、"John Doe" や "Simple Authority"）をそこに配置することは一般的な慣行です。したがって、識別子としての Common Name（CN-ID を参照）と他の形式の Common Name を区別する必要があります。

DNS-ID: subjectAltName 拡張内の dNSName タイプの識別子（[PKIX] で定義）。

識別子 (identifier): 特定のアプリケーションエンティティを識別するためにクライアントまたはサーバーによって使用される文字列。

識別子タイプ (identifier type): 特定のクラスの識別子（たとえば、DNS-ID、CN-ID、SRV-ID、または URI-ID）。

PKIX: X.509 を使用するインターネット公開鍵インフラストラクチャ (Public Key Infrastructure using X.509)、[PKIX] で定義。

提示アイデンティティ (presented identity): サーバーによって PKIX 証明書でクライアントに提示される識別子。

参照アイデンティティ (reference identity): クライアントがサーバーに証明書で提示することを期待する識別子。

ソースドメイン (source domain): クライアントが受信した入力（ユーザー入力、構成など）から抽出した完全修飾 DNS ドメイン名 [DNS-CONCEPTS]。ソースドメインは、安全な接続が確立される主要な識別子です。

SRV-ID: subjectAltName 拡張内の otherName タイプの識別子であり、SRVName の形式（[SRVNAME] で定義）。

URI-ID: subjectAltName 拡張内の uniformResourceIdentifier タイプの識別子（[PKIX] で定義）。

ワイルドカード証明書 (wildcard certificate): ワイルドカード文字 ('*') を含む少なくとも 1 つの識別子を含む証明書。

ピニング (pinning): ユーザーが、通常は最初の接続時に、または証明書検証の失敗後にユーザーが手動で確認することにより、特定の証明書を特定のサービスに関連付ける、または「ピン留めする」アクション。

このドキュメントのキーワード "MUST" (必須), "MUST NOT" (禁止), "REQUIRED" (要求), "SHALL" (すべき), "SHALL NOT" (すべきでない), "SHOULD" (推奨), "SHOULD NOT" (非推奨), "RECOMMENDED" (推奨), "MAY" (可能), および "OPTIONAL" (任意) は、[KEYWORDS] の記述に従って解釈されるものです。