メインコンテンツまでスキップ

6. サービス ID の検証 (Verifying Service Identity)

6. サービス ID の検証 (Verifying Service Identity)​

このセクションでは、アプリケーションクライアントソフトウェアの実装者向けに、アプリケーションサービスアイデンティティを検証するためのアルゴリズムに関するルールとガイダンスを提供します。

6.1. 概要 (Overview)​

高レベルでは、クライアントは、以下にリストされている操作を実行することによって、アプリケーションサービスのアイデンティティを検証します（これらの操作は、このドキュメントの後続のサブセクションで定義されています）。

  1. クライアントは、ソースドメイン (source domain) と、クライアントが接続しているサービスのタイプ（オプション）に基づいて、受け入れ可能な参照識別子 (reference identifiers) のリストを構築します。

  2. サーバーは、PKIX 証明書の形式でその識別子を提示します。

  3. クライアントは、参照識別子のそれぞれを提示識別子 (presented identifiers) と照合して、一致するものを見つけます。

  4. 参照識別子と提示識別子の照合を確認する際、クライアントは識別子のソースドメインと、それらのアプリケーションサービスタイプ（オプション）を照合します。

もちろん、識別子のチェックに加えて、クライアントは、サーバーが要求されたサービスを提供することを許可されていることを確認するために、さらなるチェックを完了することができます。ただし、そのようなチェックは、証明書に示されているアプリケーションサービスアイデンティティを確認する問題ではないため、それを行うための方法（たとえば、ローカルポリシー情報の参照）はこのドキュメントの範囲外です。

6.2. 参照識別子のリストの構築 (Constructing a List of Reference Identifiers)​

6.2.1. ルール (Rules)​

クライアントは、受け入れ可能な参照識別子のリストを構築しなければならず (MUST)、サービスによって提示された識別子とは独立してそれを行わなければなりません (MUST)。

クライアントが参照識別子のリストを構築するために使用する入力は、インターフェイスでユーザーによって入力された URI（たとえば、ウェブサイトの HTTPS URL）、構成されたアカウント情報（たとえば、情報の取得やネットワークへの接続に使用する特定のホストまたは URI のドメイン名。これはユーザー名の DNS ドメイン名部分とは異なる場合があります）、ブラウザがメディアオブジェクトやスクリプトを取得するトリガーとなるウェブページ内のハイパーリンク、またはソースドメインとアプリケーションサービスタイプを生成できるその他の情報の組み合わせである可能性があります。

クライアントは、受信した入力からソースドメインとアプリケーションサービスタイプを抽出する必要がある場合があります。抽出されたデータには、入力から安全に解析できる情報（たとえば、URI の「ホスト」コンポーネント（またはその同等物）から解析された完全修飾 DNS ドメイン名、または URI のスキームから派生したアプリケーションサービスタイプ）のみを含めるか (MUST)、ネットワーク攻撃者による破損の影響を受けない方法で派生した情報（たとえば、クライアントまたはシステム構成を介して明示的に確立された委任ドメインから抽出されたデータ、[DNSSEC] を介して解決されたデータ、または人間のユーザーが明示的に信頼し、クライアントが相互認証と整合性チェックを提供する接続または関連付けを介して通信するサードパーティのドメインマッピングサービスから取得されたデータ）のみを含めなければなりません。これらの考慮事項は、入力からのソースドメインの抽出にのみ適用されます。もちろん、入力自体が無効または破損している場合（たとえば、ユーザーがフィッシング攻撃で悪意のあるエンティティによって提供されたリンクをクリックした場合）、クライアントは意図しないアプリケーションサービスと通信することになる可能性があります。

例: 入力 URI <sips:[email protected]> が与えられた場合、クライアントは「スキーム」からアプリケーションサービスタイプ "sip" を導出し、「ホスト」コンポーネント（またはその同等物）からドメイン名 "example.net" を解析します。

リスト内の各参照識別子は、ソースドメインに基づいているべきであり (SHOULD)、派生ドメイン（たとえば、ソースドメインの DNS 解決の結果として発見されたホスト名またはドメイン名）に基づいているべきではありません (SHOULD NOT)。ユーザー入力と提示識別子の一致のみが、証明書がクライアントとサーバー間の通信を保護するために正当に使用できることをクライアントに確信させることができるため、このルールは重要です。インタラクティブクライアントがこのルールの推奨事項を上書きし、ソースドメイン以外のドメイン名と通信できるケースは 1 つだけあります。それは、人間のユーザーがアプリケーションサービスの証明書を代替ドメイン名に「ピン留め (pinned)」した場合です。これについては、セクション 6.6.4 および 7.1 でさらに説明します。この場合、クライアントが参照識別子のリストを構築するために使用する入力には、(a) ソースドメインと (b) ピン留めされた証明書に含まれる代替ドメインという複数の完全修飾 DNS ドメイン名が含まれる可能性があります。

完全修飾 DNS ドメイン名とアプリケーションサービスタイプの組み合わせを使用して、クライアントは次のルールに従って参照識別子のリストを構築します。

  • リストには、(a) 入力に含まれるか、入力から安全に派生した完全修飾 DNS ドメイン名（つまり、ソースドメイン）、または (b) ユーザー構成を介してソースドメインに明示的に関連付けられた完全修飾 DNS ドメイン名（つまり、派生ドメイン）から直接構築された DNS-ID を含めるべきである (SHOULD)。

  • アプリケーションサービスタイプのサーバーが通常 DNS SRV レコードを介して検出される場合、リストには SRV-ID を含めるべきである (SHOULD)。

  • アプリケーションサービスタイプのサーバーが通常、セキュリティ目的で URI に関連付けられている場合（つまり、正式なプロトコルドキュメントがサーバー証明書での URI の使用を指定している場合）、リストには URI-ID を含めるべきである (SHOULD)。

  • リストには、主にデプロイされたインフラストラクチャとの後方互換性のために、CN-ID を含めることができる (MAY)。

クライアントがその参照識別子リストにどの識別子タイプを含めるかは、ローカルポリシーの問題です。たとえば、特定のタイプのサービス（たとえば IM サービスのみ）に接続するように構築されたクライアントが、そのアプリケーションサービスタイプの SRV-ID を含む証明書のみを有効として受け入れるように構成されるデプロイメント環境があるかもしれません。その場合、クライアントは、参照識別子リストに、一致するアプリケーションサービスタイプの SRV-ID のみを含めます（DNS-ID などは含めません）。対照的に、より寛容なクライアント（特定のタイプのサービスにのみ接続するように構築されたクライアントであっても）は、参照識別子リストに SRV-ID と DNS-ID の両方を含める可能性があります。

実装上の注意: CN-ID を含む証明書が広く展開されているため、クライアントソフトウェアの実装者は、予見可能な将来において CN-ID をサポートする必要がある可能性が非常に高いです。実装者は、証明書発行ポリシーの最新技術を監視し、将来的に可能であれば CN-ID のサポートを段階的に廃止することが推奨されます。

実装上の注意: クライアントは、上記の識別子を証明書の実際の形式（たとえば、ASN.1 タイプとして）で構築する必要はありません。マッチング目的のために、そのような識別子の機能的に同等のものを構築するだけで十分です。

セキュリティ警告: クライアントは、Common Name タイプ以外の相対識別名 (RDN) に対応する参照識別子を構築してはならず (MUST NOT)、提示識別子内の Common Name タイプ以外の RDN をチェックしてはなりません (MUST NOT)。

6.2.2. 例 (Examples)​

HTTPS 経由で "www.example.com" ウェブサイトに接続するウェブブラウザは、2 つの参照識別子を持つ可能性があります。"www.example.com" の DNS-ID と、フォールバックとしての "www.example.com" の CN-ID です。

IMAPS 経由で "example.net" メールサービス（"mail.example.net" に解決される）に接続するメールユーザーエージェントは、5 つの参照識別子を持つ可能性があります。"_imaps.example.net" の SRV-ID（[EMAIL-SRV] を参照）、"example.net" および "mail.example.net" の DNS-ID、そしてフォールバックとしての "example.net" および "mail.example.net" の CN-ID です。（古いメールユーザーエージェントは [EMAIL-SRV] をサポートしていないため、"mail.example.net" に接続するように明示的に構成されている可能性がありますが、SRV 対応のユーザーエージェントは "[email protected]" 形式の電子メールアドレスから "example.net" を導出しますが、サービスの参照識別子の DNS ドメイン名部分として "mail.example.net" も受け入れる可能性があります。）

SIP 経由で "voice.example.edu" 音声サービスに接続する Voice over IP (VoIP) ユーザーエージェントは、1 つの参照識別子のみを持つ可能性があります。"sip:voice.example.edu" の URI-ID（[SIP-CERTS] を参照）です。

XMPP 経由で "im.example.org" IM サービスに接続するインスタントメッセージング (IM) クライアントは、3 つの参照識別子を持つ可能性があります。"_xmpp-client.im.example.org" の SRV-ID（[XMPP] を参照）、"im.example.org" の DNS-ID、および "im.example.org" の XMPP 固有の "XmppAddr"（[XMPP] を参照）です。

6.3. 一致の検索の準備 (Preparing to Seek a Match)​

クライアントが参照識別子のリストを構築し、サーバーの識別子を PKIX 証明書の形式で受け取ると、クライアントは、一致するものを見つけるために、提示識別子と参照識別子を照合します。クライアントが参照識別子のリストを使い果たしても一致するものが見つからない場合、検索は失敗します。いずれかの提示識別子が参照識別子の 1 つと一致する場合、検索は成功し、その時点でクライアントは検索を停止すべきです (SHOULD)。

実装上の注意: クライアントは、複数の検索を実行するように構成される場合があります。つまり、複数の参照識別子と一致させることです。この仕様ではそのような動作を禁止していませんが、複数の参照識別子と一致させるためのルールは、実装または将来の仕様の問題です。

セキュリティ警告: 提示識別子に、DNS-ID、SRV-ID、URI-ID、またはクライアントがサポートするアプリケーション固有の識別子タイプが含まれている場合、クライアントは CN-ID 参照識別子との一致を求めてはなりません (MUST NOT)。

以下のセクションで提供される比較ルールを適用する前に、クライアントは参照識別子を次のように DNS ドメイン名部分とアプリケーションサービスタイプ部分に分割する必要がある場合があります。

  • DNS-ID タイプの参照識別子にはアプリケーションサービスタイプ部分は含まれないため、直接 DNS ドメイン名として比較に使用できます。たとえば、"www.example.com" の DNS-ID は、"www.example.com" の DNS ドメイン名部分になります。

  • CN-ID タイプの参照識別子にもアプリケーションサービスタイプ部分は含まれないため、直接 DNS ドメイン名として比較に使用できます。前述のように、このドキュメントは、CN-ID には常に DNS ドメイン名の形式と一致する文字列が含まれると規定しています（これにより、CN-ID と、ユーザーフレンドリーな名前を含む Common Name が区別されます）。

  • SRV-ID タイプの参照識別子の場合、DNS ドメイン名部分は Name であり、アプリケーションサービスタイプ部分は Service です。たとえば、"_imaps.example.net" の SRV-ID は、"example.net" の DNS ドメイン名部分と "imaps" のアプリケーションサービスタイプ部分（[EMAIL-SRV] で説明されているように、IMAP のアプリケーションプロトコルにマップされる）に分割されます。

  • URI-ID タイプの参照識別子の場合、DNS ドメイン名部分は「ホスト」コンポーネント（またはその同等物）の "reg-name" 部分であり、アプリケーションサービスタイプ部分は、[URI] の [ABNF] "scheme" ルールと一致するスキーム名に関連付けられたアプリケーションサービスタイプ（':' 区切り文字を除く）です。前述のように、このドキュメントは、URI-ID には常に "reg-name" を含む「ホスト」コンポーネント（またはその同等物）を含む URI が含まれると規定しています。（[URI] の "reg-name" ルールのみを照合することで、検証が DNS ドメイン名に制限され、URI-ID と、IP アドレスを含むか単にホスト名を含む uniformResourceIdentifier エントリとの区別、または「ホスト」コンポーネントをまったく含まないエントリとの区別が可能になります。）さらに、"reg-name" の抽出には、URI の正規化が必要になる場合があることに注意してください（[URI] で説明されているとおり）。たとえば、"sip:voice.example.edu" の URI-ID は、"voice.example.edu" の DNS ドメイン名部分と "sip" のアプリケーションサービスタイプ（[SIP-CERTS] で説明されているように、SIP のアプリケーションプロトコルに関連付けられている）に分割されます。

以下のセクションでは、参照識別子の DNS ドメイン名部分とアプリケーションサービスタイプ部分を照合するための詳細な比較ルールを提供します。

6.4. DNS ドメイン名部分の照合 (Matching the DNS Domain Name Portion)​

クライアントは、以下のルールに従って参照識別子の DNS ドメイン名部分を照合しなければならず (MUST)、セクション 6.5 で説明するように、同時にアプリケーションサービスタイプもチェックすべきです (SHOULD)。ルールは、チェックされるドメインが「従来のドメイン名」か「国際化ドメイン名」か（セクション 2.2 で定義）によって異なります。さらに、ワイルドカード文字 '*' を含む提示識別子をサポートするクライアントのニーズを満たすために、いわゆる「ワイルドカード証明書」の補足ルールを定義しています。最後に、"CN-ID" 識別子タイプのチェックが許容される状況も規定しています。

6.4.1. 従来のドメイン名の確認 (Checking of Traditional Domain Names)​

参照識別子の DNS ドメイン名部分が「従来のドメイン名」である場合、[DNS-CASE] で明らかにされているように、大文字と小文字を区別しない ASCII 比較を使用してドメイン名ラベルのセットを比較することにより、参照識別子と提示識別子の照合が実行されます（たとえば、"WWW.Example.Com" は、比較のために小文字の "www.example.com" になります）。一致していると見なされるには、ワイルドカードラベルのチェックに関するルール（セクション 6.4.3）によって補足されない限り、各ラベルが一致しなければなりません (MUST)。

6.4.2. 国際化ドメイン名の確認 (Checking of Internationalized Domain Names)​

参照識別子の DNS ドメイン名部分が国際化ドメイン名である場合、実装は、ドメイン名をチェックする前に、ドメイン名内の U-ラベル [IDNA-DEFS] を A-ラベルに変換しなければなりません (MUST)。[IDNA-PROTO] に従って、A-ラベルは大文字と小文字を区別しない ASCII として比較されなければなりません (MUST)。一致していると見なされるには、ワイルドカードラベルのチェックに関するルール（セクション 6.4.3。ただし、国際化ドメイン名でのワイルドカードに関してはセクション 7.2 も参照）によって補足されない限り、各ラベルが一致しなければなりません (MUST)。

6.4.3. ワイルドカード証明書の確認 (Checking of Wildcard Certificates)​

この仕様のルールを採用するクライアントは、ラベルの一部または全部としてワイルドカード文字 '*' を含む DNS ドメイン名部分を持つ提示識別子と参照識別子を照合することができます (MAY)（[DNS-CONCEPTS] のラベルとドメイン名の説明に従います）。

ワイルドカード証明書のセキュリティ特性については、セクション 7.2 を参照してください。

クライアントが参照識別子を、DNS ドメイン名部分にワイルドカード文字 '*' を含む提示識別子と照合する場合、次のルールが適用されます。

  1. クライアントは、ワイルドカード文字が左端以外のラベルを構成する提示識別子と照合しようとすべきではありません (SHOULD NOT)（たとえば、bar.*.example.net と照合しないでください）。

  2. ワイルドカード文字が提示識別子の左端のラベルの唯一の文字である場合、クライアントは、参照識別子の左端のラベル以外と照合すべきではありません (SHOULD NOT)（たとえば、*.example.com は foo.example.com と一致しますが、bar.foo.example.com や example.com とは一致しません）。

  3. クライアントは、ワイルドカード文字がラベルの唯一の文字ではない提示識別子と照合することができます (MAY)（たとえば、baz*.example.net および baz.example.net および bz.example.net は、それぞれ baz1.example.net、foobaz.example.net、および buzz.example.net と一致すると見なされます）。ただし、クライアントは、ワイルドカード文字が国際化ドメイン名 [IDNA-PROTO] の A-ラベルまたは U-ラベル [IDNA-DEFS] に埋め込まれている提示識別子と照合しようとすべきではありません (SHOULD NOT)。

6.4.4. Common Name の確認 (Checking of Common Names)​

前述のように、提示識別子に DNS-ID、SRV-ID、URI-ID、またはクライアントがサポートするアプリケーション固有の識別子タイプが含まれる場合、クライアントは CN-ID 参照識別子との一致を求めてはなりません (MUST NOT)。

したがって、提示識別子に DNS-ID、SRV-ID、URI-ID、またはクライアントがサポートするアプリケーション固有の識別子タイプが含まれない場合に限り、クライアントは、サブジェクトフィールドの Common Name フィールドにある、完全修飾 DNS ドメイン名の形式と一致する文字列（つまり、CN-ID）を最後の手段としてチェックすることができます (MAY)。クライアントが CN-ID タイプの参照識別子をその文字列と比較することを選択した場合、セクション 6.4.1、6.4.2、および 6.4.3 で説明されているように、DNS-ID、SRV-ID、または URI-ID タイプの識別子の DNS ドメイン名部分の比較ルールに従わなければなりません (MUST)。

6.5. アプリケーションサービスタイプ部分の照合 (Matching the Application Service Type Portion)​

クライアントが SRV-ID および URI-ID タイプの識別子をチェックする場合、識別子の DNS ドメイン名部分だけでなく、アプリケーションサービスタイプ部分もチェックしなければなりません (MUST)。クライアントは、識別子を DNS ドメイン名部分とアプリケーションサービスタイプ部分に分割し（セクション 6.3 で推奨されているように）、DNS ドメイン名部分（セクション 6.4 で説明されているように）とアプリケーションサービスタイプ部分（以下のサブセクションで説明するように）をチェックすることによってこれを行います。

実装上の注意: SRV-ID または URI-ID タイプの識別子は、チェックするアプリケーションサービスタイプ部分を提供しますが、その部分は SRV-ID または URI-ID 自体の DNS ドメイン名部分とのみ組み合わされます。たとえば、クライアントの参照識別子リストに "_xmpp-client.im.example.org" の SRV-ID と "apps.example.net" の DNS-ID が含まれている場合、クライアントは (a) "xmpp-client" のアプリケーションサービスタイプと "im.example.org" の DNS ドメイン名の組み合わせ、および (b) "apps.example.net" の DNS ドメイン名の組み合わせをチェックします。ただし、クライアントは (c) "xmpp-client" のアプリケーションサービスタイプと "apps.example.net" の DNS ドメイン名の組み合わせについては、参照識別子リストに "_xmpp-client.apps.example.net" の SRV-ID がないため、チェックしません。

6.5.1. SRV-ID​

SRV-ID のアプリケーションサービス名部分（たとえば、"imaps"）は、[DNS-SRV] に従って、大文字と小文字を区別しないで照合しなければなりません (MUST) 。"_" 文字は DNS SRV レコードおよび SRV-ID のサービス識別子の先頭に追加されているため（[SRVNAME] に従う）、比較に含める必要はないことに注意してください。

6.5.2. URI-ID​

URI-ID のスキーム名部分（たとえば、"sip"）は、[URI] に従って、大文字と小文字を区別しないで照合しなければなりません (MUST)。":" 文字はスキーム名と URI の残りの部分の間の区切り文字であるため、比較に含める必要はないことに注意してください。

6.6. 結果 (Outcome)​

マッチングプロセスの結果は、次のいずれかの場合になります。

6.6.1. ケース #1: 一致が見つかった (Case #1: Match Found)​

クライアントが参照識別子と一致する提示識別子を見つけた場合、サービスアイデンティティチェックは成功しました。この場合、クライアントは、一致する参照識別子を、アプリケーションサービスの認証されたアイデンティティとして使用しなければなりません (MUST)。

6.6.2. ケース #2: 一致が見つからない、固定された証明書 (Case #2: No Match Found, Pinned Certificate)​

クライアントがいずれの参照識別子とも一致する提示識別子を見つけられなかったが、クライアントが以前にアプリケーションサービスの証明書を、この通信試行のために構築されたリスト内の参照識別子の 1 つにピン留めしており（「ピン留め」はセクション 1.8 で説明）、提示された証明書がピン留めされた証明書と一致する場合（セクション 7.1 で説明されているコンテキストを含む）、サービスアイデンティティチェックは成功しました。

6.6.3. ケース #3: 一致が見つからない、固定された証明書なし (Case #3: No Match Found, No Pinned Certificate)​

クライアントがいずれの参照識別子とも一致する提示識別子を見つけられず、クライアントが以前に証明書をこの通信試行のために構築されたリスト内の参照識別子の 1 つにピン留めしていない場合、クライアントはセクション 6.6.4 の説明に従って続行しなければなりません (MUST)。

6.6.4. フォールバック (Fallback)​

クライアントが人間のユーザーによって直接制御されるインタラクティブクライアントである場合、アイデンティティの不一致をユーザーに通知し、自動的に不正な証明書エラーで通信試行を終了すべきです (SHOULD)。敵対的な状況でユーザーが誤ってセキュリティ保護をバイパスするのを防ぐことができるため、この動作が望ましいです。

セキュリティ警告: 一部のインタラクティブクライアントは、アイデンティティが一致しないにもかかわらず受け入れを続行するオプションを上級ユーザーに提供し、それによってクライアントがこの通信試行のために構築したリスト内の参照識別子の 1 つに証明書を効果的に「ピン留め」します。このような動作は特定の特殊な状況では適切な場合がありますが、一般に上級ユーザーにのみ公開されるべきです。その場合でも、たとえば、上級ユーザーにも通信試行を終了することを最初に推奨し、上級ユーザーがとにかく続行することを選択した場合は、ユーザーに完全な認証パスを表示するように強制し、その時点で初めてユーザーが証明書をピン留めできるようにする（ユーザーの選択により、一時的または永続的に）など、細心の注意を払って処理する必要があります。

それ以外の場合、クライアントが人間のユーザーによって直接制御されていない自動化アプリケーションである場合、不正な証明書エラーで通信試行を終了し、エラーを適切にログに記録すべきです (SHOULD)。自動化アプリケーションは、この動作を無効にする構成設定を提供することができます (MAY) が、デフォルトでこの動作を有効にしなければなりません (MUST)。

に最終更新