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

付録 B. 先行技術 (Prior Art)

付録 B. 先行技術 (Prior Art)​

(このセクションは規範的ではありません。)

このドキュメントの推奨事項は、幅広いアプリケーションプロトコルの仕様の推奨事項を抽象化したものです。比較の目的で、また IETF 内でのアプリケーションサービスアイデンティティ検証に関する考え方の歴史を概説するために、この有益なセクションでは、さまざまな RFC からの正確なテキストを含めることによって先行技術を収集します（唯一の変更は、このドキュメントの本文との一貫性を維持するためのいくつかの参照名の変更と、"[...]" という文字でマークされた無関係なテキストの省略です）。

B.1. IMAP, POP3, and ACAP (1999)​

1999 年、[USINGTLS] は、IMAP、POP3、および ACAP でのアプリケーションサービス ID 検証に関して次のテキストを指定しました。

2.4. サーバー ID チェック (Server Identity Check)

TLS ネゴシエーション中に、クライアントは、中間者攻撃を防ぐために、サーバーの Certificate メッセージで提示されたサーバーの ID に対して、サーバーホスト名についての理解を確認しなければなりません (MUST)。照合は、次のルールに従って実行されます。

  • クライアントは、接続を開くために使用したサーバーホスト名を、サーバー証明書で表現されたサーバー名と比較する値として使用しなければなりません (MUST)。クライアントは、安全でないリモートソース（たとえば、安全でない DNS ルックアップ）から派生したサーバーホスト名のいかなる形式も使用してはなりません (MUST NOT)。CNAME の正規化は行われません。

  • 証明書にタイプ dNSName の subjectAltName 拡張が存在する場合、それをサーバーの ID のソースとして使用すべきです (SHOULD)。

  • 照合は大文字と小文字を区別しません。

  • "" ワイルドカード文字は、証明書の左端の名前コンポーネントとして使用できます (MAY)。たとえば、.example.com は a.example.com、foo.example.com などと一致しますが、example.com とは一致しません。

  • 証明書に複数の名前（たとえば、複数の dNSName フィールド）が含まれている場合、いずれかのフィールドとの一致が許容されると見なされます。

一致が失敗した場合、クライアントは、明示的なユーザー確認を求めるか、接続を終了してサーバーの ID が疑わしいことを示すべきです (SHOULD)。

B.2. HTTP (2000)​

2000 年、[HTTP-TLS] は、HTTP でのアプリケーションサービス ID 検証に関して次のテキストを指定しました。

3.1. サーバー ID (Server Identity)

一般に、HTTP/TLS 要求は URI を逆参照することによって生成されます。結果として、サーバーのホスト名はクライアントに知られています。ホスト名が利用可能な場合、クライアントは、中間者攻撃を防ぐために、サーバーの Certificate メッセージで提示されたサーバーの ID に対してそれをチェックしなければなりません (MUST)。

クライアントがサーバーの予想される ID に関する外部情報を持っている場合、ホスト名チェックを省略できます (MAY)。（たとえば、クライアントはアドレスとホスト名が動的なマシンに接続している可能性がありますが、クライアントはサーバーが提示する証明書を知っています。）そのような場合、中間者攻撃を防ぐために、許容される証明書の範囲を可能な限り狭めることが重要です。特別な場合、クライアントが単にサーバーの ID を無視することが適切な場合もありますが、これにより接続がアクティブな攻撃に対して開かれたままになることを理解しておく必要があります。

タイプ dNSName の subjectAltName 拡張が存在する場合、それを ID として使用しなければなりません (MUST)。それ以外の場合は、証明書のサブジェクト (Subject) フィールドの（最も具体的な）Common Name フィールドを使用しなければなりません (MUST)。Common Name の使用は既存の慣行ですが、非推奨であり、認証局は代わりに dNSName を使用することが推奨されます。

照合は、[PKIX-OLD] で指定された照合ルールを使用して実行されます。特定のタイプの ID が証明書に複数存在する場合（たとえば、複数の dNSName 名）、セット内のいずれかの 1 つでの一致が許容されると見なされます。名前にはワイルドカード文字 * を含めることができ、これは単一のドメイン名コンポーネントまたはコンポーネントフラグメントと一致すると見なされます。たとえば、.a.com は foo.a.com と一致しますが、bar.foo.a.com とは一致しません。f.com は foo.com と一致しますが、bar.com とは一致しません。

場合によっては、URI がホスト名ではなく IP アドレスとして指定されることがあります。この場合、iPAddress subjectAltName が証明書に存在していなければならず、URI の IP と正確に一致しなければなりません。

ホスト名が証明書の ID と一致しない場合、ユーザー向けのクライアントは、ユーザーに通知するか（クライアントは、どのような場合でもユーザーに接続を続行する機会を与えることができます (MAY)）、不正な証明書エラーで接続を終了しなければなりません (MUST)。自動化されたクライアントは、エラーを適切な監査ログ（利用可能な場合）に記録しなければならず (MUST)、接続を終了すべきです (SHOULD)（不正な証明書エラーで）。自動化されたクライアントは、このチェックを無効にする構成設定を提供できます (MAY) が、それを有効にする設定を提供しなければなりません (MUST)。

多くの場合、URI 自体は信頼できないソースからのものであることに注意してください。上記のチェックは、このソースが侵害された攻撃に対する保護を提供しません。たとえば、URI が HTTP/TLS を使用せずに取得された HTML ページをクリックして取得された場合、中間者が URI を置き換えた可能性があります。この形式の攻撃を防ぐために、ユーザーは、サーバーによって提示された証明書を注意深く調べて、それが期待を満たしているかどうかを判断する必要があります。

B.3. LDAP (2000/2006)​

2000 年、[LDAP-TLS] は、LDAP でのアプリケーションサービス ID 検証に関して次のテキストを指定しました。

3.6. サーバー ID チェック (Server Identity Check)

クライアントは、中間者攻撃を防ぐために、サーバーの Certificate メッセージで提示されたサーバーの ID に対して、サーバーのホスト名についての理解を確認しなければなりません (MUST)。

照合は、次のルールに従って実行されます。

  • クライアントは、LDAP 接続を開くために使用したサーバーホスト名を、サーバーの証明書で表現されたサーバー名と比較する値として使用しなければなりません (MUST)。クライアントは、サーバーの正規 DNS 名またはその他の派生形式の名前を使用してはなりません (MUST NOT)。

  • 証明書にタイプ dNSName の subjectAltName 拡張が存在する場合、それをサーバーの ID のソースとして使用すべきです (SHOULD)。

  • 照合は大文字と小文字を区別しません。

  • "*" ワイルドカード文字は許可されます。存在する場合、左端の名前コンポーネントにのみ適用されます。

たとえば、*.bar.com は a.bar.com、b.bar.com などと一致しますが、bar.com とは一致しません。特定のタイプの ID が証明書に複数存在する場合（たとえば、複数の dNSName 名）、セット内のいずれかの 1 つでの一致が許容されると見なされます。

上記のチェックに従ってホスト名が証明書の dNSName ベースの ID と一致しない場合、ユーザー指向のクライアントは、ユーザーに通知するか（クライアントはこの場合、ユーザーに接続を続行する機会を与えることができます (MAY)）、接続を終了してサーバーの ID が疑わしいことを示すべきです (SHOULD)。自動化されたクライアントは、接続を閉じ、サーバーの ID が疑わしいことを示すエラーを返すかログに記録すべきです (SHOULD)。

このセクションで説明されているサーバー ID チェックを超えて、クライアントは、サーバーが提供することが観察されたサービスを提供することを許可されていることを確認するために、さらなるチェックを行う準備をすべきです (SHOULD)。クライアントは、ローカルポリシー情報を利用する必要がある場合があります (MAY)。

2006 年、[LDAP-AUTH] は、LDAP でのアプリケーションサービス ID 検証に関して次のテキストを指定しました。

3.1.3. サーバー ID チェック (Server Identity Check)

中間者攻撃を防ぐために、クライアントは（サーバーの Certificate メッセージに提示された）サーバーの ID を検証しなければなりません (MUST)。このセクションでは、サーバーの ID に対するクライアントの理解（通常、トランスポート接続を確立するために使用される ID）は、「参照 ID」と呼ばれます。

クライアントは、参照 ID のタイプ（たとえば、DNS 名または IP アドレス）を決定し、一致が生成されるまで、参照 ID と対応するタイプの各 subjectAltName 値との比較を実行します。一致が生成されると、サーバーの ID が検証され、サーバー ID チェックが完了します。異なる subjectAltName タイプは異なる方法で照合されます。セクション 3.1.3.1 - 3.1.3.3 では、さまざまな subjectAltName タイプの値を比較する方法について説明します。

クライアントは、比較を実行する前に、参照 ID を別のタイプにマップすることができます。マッピングは、参照 ID をマップできるすべての利用可能な subjectAltName タイプに対して実行できます。ただし、参照 ID は、マッピングが本質的に安全であるタイプ（たとえば、URI から DNS 名を抽出して、タイプ dNSName の subjectAltName と比較する）またはマッピングが安全な方法で実行されるタイプ（たとえば、[DNSSEC] を使用する、またはユーザーまたは管理者が構成したホストからアドレス/アドレスからホストへのルックアップテーブルを使用する）にのみマップする必要があります。

サーバーの ID は、参照 ID をサーバー証明書のサブジェクトフィールドの最後の相対識別名 (RDN) の Common Name (CN) [LDAP-SCHEMA] 値と比較することによっても検証できます（ここで「最後」とは、DER エンコードデータの文字列表現における提示順序ではなく、DER エンコード順序を指します）。この比較は、以下のセクション 3.1.3.1 の DNS 名の比較ルールを使用して実行されますが、ワイルドカード照合が許可されないという例外があります。Common Name 値の使用は既存の慣行ですが、非推奨であり、認証局は代わりに subjectAltName 値を提供することが推奨されます。TLS 実装は、X.500 またはその他の規則に従って証明書内の DN を表す場合があることに注意してください。たとえば、一部の X.500 実装では、LDAP の右から左への規則ではなく、左から右へ（最上位から最下位へ）の規則を使用して DN 内の RDN を順序付けます。

サーバー ID チェックが失敗した場合、ユーザー指向のクライアントは、ユーザーに通知するか（クライアントはこの場合、ユーザーに LDAP セッションを続行する機会を与えることができます）、トランスポート接続を閉じてサーバーの ID が疑わしいことを示すべきです (SHOULD)。自動化されたクライアントは、トランスポート接続を閉じ、サーバーの ID が疑わしいことを示すエラーを返すかログに記録するか、その両方を行うべきです (SHOULD)。

このセクションで説明されているサーバー ID チェックを超えて、クライアントは、サーバーが提供するように要求されたサービスを提供することを許可されていることを確認するために、さらなるチェックを行う準備をする必要があります。クライアントは、この決定を行う際にローカルポリシー情報を利用する必要がある場合があります。

3.1.3.1. DNS 名の比較 (Comparison of DNS Names)

参照 ID が国際化ドメイン名である場合、準拠する実装は、タイプ dNSName の subjectAltName 値と比較する前に、RFC 3490 [IDNA2003] のセクション 4 で指定されている ASCII 互換エンコーディング (ACE) 形式にそれを変換しなければなりません (MUST)。具体的には、準拠する実装は、RFC 3490 のセクション 4 で指定されている変換操作を次のように実行しなければなりません (MUST)。

  • ステップ 1 で、ドメイン名は「保存された文字列」と見なされるものとします (SHALL)。

  • ステップ 3 で、"UseSTD3ASCIIRules" というフラグを設定します。

  • ステップ 4 で、各ラベルを "ToASCII" 操作で処理します。

  • ステップ 5 で、すべてのラベル区切り文字を U+002E（ピリオド）に変更します。

「ToASCII」変換を実行した後、DNS ラベルと名前は、RFC3490 のセクション 3 で指定されているルールに従って、等価性を比較しなければなりません (MUST)。

'*' (ASCII 42) ワイルドカード文字は、タイプ dNSName の subjectAltName 値で許可されており、その値の左端（最下位）の DNS ラベルとしてのみ許可されます。このワイルドカードは、サーバー名の左端の DNS ラベルと一致します。つまり、サブジェクト *.example.com は、サーバー名 a.example.com および b.example.com と一致しますが、example.com または a.b.example.com とは一致しません。

3.1.3.2. IP アドレスの比較 (Comparison of IP Addresses)

参照 ID が IP アドレスの場合、ID は「ネットワークバイトオーダー」のオクテット文字列形式 [IP] [IPv6] に変換されなければなりません (MUST)。RFC 791 で指定されている IP バージョン 4 の場合、オクテット文字列には正確に 4 つのオクテットが含まれます。RFC 2460 で指定されている IP バージョン 6 の場合、オクテット文字列には正確に 16 個のオクテットが含まれます。次に、このオクテット文字列は、タイプ iPAddress の subjectAltName 値と比較されます。参照 ID のオクテット文字列と値のオクテット文字列が同一の場合、一致が発生します。

3.1.3.3. その他の subjectName タイプの比較 (Comparison of Other subjectName Types)

クライアント実装は、他のドキュメントで説明されている他のタイプの subjectAltName 値との照合をサポートすることができます (MAY)。

B.4. SMTP (2002/2007)​

2002 年、[SMTP-TLS] は、SMTP でのアプリケーションサービス ID 検証に関して次のテキストを指定しました。

4.1 STARTTLS コマンド後の処理 (Processing After the STARTTLS Command)

[...]

TLS ネゴシエーションで相手側の信頼性を信じるかどうかの決定は、ローカルの問題です。ただし、決定に関するいくつかの一般的なルールは次のとおりです。

  • SMTP クライアントは、クライアントが接続していると考えているドメイン名であるドメイン名を持つサーバー証明書を持つ SMTP サーバーのみを認証したいと思うでしょう。

[...]

2006 年、[SMTP-AUTH] は、SMTP でのアプリケーションサービス ID 検証に関して次のテキストを指定しました。

  1. TSL 上で SASL PLAIN を使用する場合の追加要件 (Additional Requirements When Using SASL PLAIN over TLS)

[...]

成功した [TLS] ネゴシエーションの後、クライアントは、中間者攻撃を防ぐために、サーバーの Certificate メッセージで提示されたサーバーの ID に対して、サーバーホスト名についての理解を確認しなければなりません (MUST)。一致が失敗した場合、クライアントは SASL PLAIN メカニズムを使用して認証を試みてはなりません (MUST NOT)。照合は、次のルールに従って実行されます。

クライアントは、接続を開くために使用したサーバーホスト名を、サーバー証明書で表現されたサーバー名と比較する値として使用しなければなりません (MUST)。クライアントは、安全でないリモートソース（たとえば、安全でない DNS ルックアップ）から派生したサーバーホスト名のいかなる形式も使用してはなりません (MUST NOT)。CNAME の正規化は行われません。

証明書にタイプ dNSName の subjectAltName 拡張が存在する場合、それをサーバーの ID のソースとして使用すべきです (SHOULD)。

照合は大文字と小文字を区別しません。

"" ワイルドカード文字は、証明書の左端の名前コンポーネントとして使用できます (MAY)。たとえば、.example.com は a.example.com、foo.example.com などと一致しますが、example.com とは一致しません。

証明書に複数の名前（たとえば、複数の dNSName フィールド）が含まれている場合、いずれかのフィールドとの一致が許容されると見なされます。

B.5. XMPP (2004)​

2004 年、[XMPP-OLD] は、XMPP でのアプリケーションサービス ID 検証に関して次のテキストを指定しました。

14.2. 証明書の検証 (Certificate Validation)

XMPP ピアが別のピアと安全に通信する場合、ピアの証明書を検証しなければなりません (MUST)。3 つの可能なケースがあります。

ケース #1 (Case #1): ピアには、トラストアンカーで終わる認証パスによって認証されていると思われるエンドエンティティ証明書が含まれています（[PKIX] のセクション 6.1 で説明されているように）。

ケース #2 (Case #2): ピア証明書は、検証ピアに知られていない認証局によって認証されています。

ケース #3 (Case #3): ピア証明書は自己署名されています。

ケース #1 では、検証ピアは次の 2 つのいずれかを実行しなければなりません (MUST)。

  1. [PKIX] のルールに従ってピア証明書を検証します。次に、証明書は、[HTTP-TLS] で説明されているルールに従ってピアの予想される ID に対してチェックされるべきです (SHOULD)。ただし、タイプ "xmpp" の subjectAltName 拡張が存在する場合は、それを ID として使用しなければならない (MUST) という例外があります。これらのチェックのいずれかが失敗した場合、ユーザー指向のクライアントは、ユーザーに通知するか（クライアントは、どのような場合でもユーザーに接続を続行する機会を与えることができます (MAY)）、不正な証明書エラーで接続を終了しなければなりません (MUST)。自動化されたクライアントは、接続を終了し（不正な証明書エラーで）、エラーを適切な監査ログに記録すべきです (SHOULD)。自動化されたクライアントは、このチェックを無効にする構成設定を提供できます (MAY) が、それを有効にする設定を提供しなければなりません (MUST)。

  2. ピアは、認証パス全体を含め、承認のためにユーザーに証明書を表示すべきです (SHOULD)。ピアは、証明書（またはハッシュなどの偽造不可能な表現）をキャッシュしなければなりません (MUST)。将来の接続では、ピアは同じ証明書が提示されたことを検証しなければならず (MUST)、変更された場合はユーザーに通知しなければなりません (MUST)。

ケース #2 およびケース #3 では、実装は上記の (2) のように動作すべきです (SHOULD)。

[XMPP-OLD] は独自のルールを定義しましたが、[XMPP] は、XMPP でのアプリケーションサービス ID 検証に関するこのドキュメントのルールを再利用しています。

B.6. NNTP (2006)​

2006 年、[NNTP-TLS] は、NNTP でのアプリケーションサービス ID 検証に関して次のテキストを指定しました。

  1. セキュリティに関する考慮事項 (Security Considerations)

[...]

TLS ネゴシエーション中に、クライアントは、中間者攻撃を防ぐために、サーバーの Certificate メッセージで提示されたサーバーの ID に対して、サーバーホスト名についての理解を確認しなければなりません (MUST)。照合は、次のルールに従って実行されます。

  • クライアントは、接続を開くために使用したサーバーホスト名（または TLS "server_name" 拡張 [TLS] で指定されたホスト名）を、サーバー証明書で表現されたサーバー名と比較する値として使用しなければなりません (MUST)。クライアントは、安全でないリモートソース（たとえば、安全でない DNS ルックアップ）から派生したサーバーホスト名のいかなる形式も使用してはなりません (MUST NOT)。CNAME の正規化は行われません。

  • 証明書にタイプ dNSName の subjectAltName 拡張が存在する場合、それをサーバーの ID のソースとして使用すべきです (SHOULD)。

  • 照合は大文字と小文字を区別しません。

  • "" ワイルドカード文字は、証明書の左端の名前コンポーネントとして使用できます (MAY)。たとえば、.example.com は a.example.com、foo.example.com などと一致しますが、example.com とは一致しません。

  • 証明書に複数の名前（たとえば、複数の dNSName フィールド）が含まれている場合、いずれかのフィールドとの一致が許容されると見なされます。

一致が失敗した場合、クライアントは、明示的なユーザー確認を求めるか、QUIT コマンドで接続を終了してサーバーの ID が疑わしいことを示すべきです (SHOULD)。

さらに、クライアントは、接続先のサーバーの ID と、それらのサーバーによって提示された公開鍵との間のバインディングを検証しなければなりません (MUST)。クライアントは、一般的な証明書検証のために [PKIX] のセクション 6 のアルゴリズムを実装すべきです (SHOULD) が、同等のレベルの検証を達成する他の検証方法（サーバー証明書をすでに検証済みの証明書および ID バインディングのローカルストアと比較するなど）でそのアルゴリズムを補足することができます (MAY)。

B.7. NETCONF (2006/2009)​

2006 年、[NETCONF-SSH] は、NETCONF でのアプリケーションサービス ID 検証に関して次のテキストを指定しました。

  1. セキュリティに関する考慮事項 (Security Considerations)

サーバーの ID は、パスワードベースの認証データまたは構成データや状態データがサーバーに送信されたりサーバーから受信されたりする前に、ローカルポリシーに従ってクライアントによって検証および認証されなければなりません (MUST)。クライアントの ID も、構成データや状態データがクライアントに送信されたりクライアントから受信されたりする前に、着信クライアント要求が正当であることを確認するために、ローカルポリシーに従ってサーバーによって検証および認証されなければなりません (MUST)。どちらの側も、反対側の未知の、予期しない、または正しくない ID との NETCONF over SSH 接続を確立すべきではありません。

2009 年、[NETCONF-TLS] は、NETCONF でのアプリケーションサービス ID 検証に関して次のテキストを指定しました。

3.1. サーバー ID (Server Identity)

TLS ネゴシエーション中、クライアントは、サーバーによって提示された証明書を注意深く調べて、それがクライアントの期待を満たしているかどうかを判断しなければなりません (MUST)。特に、クライアントは、中間者攻撃を防ぐために、サーバーの Certificate メッセージで提示されたサーバーの ID に対して、サーバーホスト名についての理解を確認しなければなりません (MUST)。

照合は、以下のルールに従って実行されます（[NNTP-TLS] の例に従います）。

  • クライアントは、接続を開くために使用したサーバーホスト名（または TLS "server_name" 拡張 [TLS] で指定されたホスト名）を、サーバー証明書で表現されたサーバー名と比較する値として使用しなければなりません (MUST)。クライアントは、安全でないリモートソース（たとえば、安全でない DNS ルックアップ）から派生したサーバーホスト名のいかなる形式も使用してはなりません (MUST NOT)。CNAME の正規化は行われません。

  • 証明書にタイプ dNSName の subjectAltName 拡張が存在する場合、それをサーバーの ID のソースとして使用しなければなりません (MUST)。

  • 照合は大文字と小文字を区別しません。

  • "" ワイルドカード文字は、証明書の左端の名前コンポーネントとして使用できます (MAY)。たとえば、.example.com は a.example.com、foo.example.com などと一致しますが、example.com とは一致しません。

  • 証明書に複数の名前（たとえば、複数の dNSName フィールド）が含まれている場合、いずれかのフィールドとの一致が許容されると見なされます。

一致が失敗した場合、クライアントは、明示的なユーザー確認を求めるか、接続を終了してサーバーの ID が疑わしいことを示さなければなりません (MUST)。

さらに、クライアントは、接続先のサーバーの ID と、それらのサーバーによって提示された公開鍵との間のバインディングを検証しなければなりません (MUST)。クライアントは、一般的な証明書検証のために [PKIX] のセクション 6 のアルゴリズムを実装すべきです (SHOULD) が、同等のレベルの検証を達成する他の検証方法（サーバー証明書をすでに検証済みの証明書および ID バインディングのローカルストアと比較するなど）でそのアルゴリズムを補足することができます (MAY)。

クライアントがサーバーの予想される ID に関する外部情報を持っている場合、ホスト名チェックを省略できます (MAY)。

B.8. Syslog (2009)​

2009 年、[SYSLOG-TLS] は、Syslog でのアプリケーションサービス ID 検証に関して次のテキストを指定しました。

5.2. サブジェクト名認可 (Subject Name Authorization)

実装は、認証パス検証 [PKIX] をサポートしなければなりません (MUST)。さらに、ローカルに構成されたホスト名を使用して許可されたピアを指定し、次のように名前を証明書と照合することをサポートしなければなりません (MUST)。

  • 実装は、ローカルに構成されたホスト名を subjectAltName 拡張フィールドの dNSName と照合することをサポートしなければならず (MUST)、名前をサブジェクト識別名の共通名部分と照合することをサポートすべきです (SHOULD)。

  • '*' (ASCII 42) ワイルドカード文字は、subjectAltName 拡張の dNSName（および、ホスト名の格納に使用される場合は共通名）で許可されますが、その値の左端（最下位）の DNS ラベルとしてのみ許可されます。このワイルドカードは、サーバー名の左端の DNS ラベルと一致します。つまり、サブジェクト *.example.com は、サーバー名 a.example.com および b.example.com と一致しますが、example.com または a.b.example.com とは一致しません。実装は、上記のように証明書内のワイルドカードをサポートしなければなりません (MUST) が、それらを無効にする構成オプションを提供することができます (MAY)。

  • ローカルに構成された名前には、値の範囲と一致するようにワイルドカード文字を含めることができます (MAY)。サポートされるワイルドカードのタイプは、サブジェクト名で許可されるものよりも柔軟である場合があり (MAY)、さまざまな環境のさまざまなポリシーをサポートすることが可能になります。たとえば、ポリシーでは、特定の CA トラストルートによって発行されたすべての資格情報が承認されるトラストルートベースの承認を許可できます。

  • ローカルに構成された名前が国際化ドメイン名である場合、準拠する実装は、比較を実行するために、[PKIX] のセクション 7 で指定されているように、ASCII 互換エンコーディング (ACE) 形式にそれを変換しなければなりません (MUST)。

  • 実装は、ローカルに構成された IP アドレスを subjectAltName 拡張に格納された iPAddress と照合することをサポートできます (MAY)。この場合、ローカルに構成された IP アドレスは、[PKIX] のセクション 4.2.1.6 で指定されているようにオクテット文字列に変換されます。このオクテット文字列が subjectAltName 拡張の iPAddress の値と等しい場合、一致が発生します。

B.9. SIP (2010)​

2010 年、[SIP-CERTS] は、SIP でのアプリケーションサービス ID 検証に関して次のテキストを指定しました。

7.2. SIP ID の比較 (Comparing SIP Identities)

実装（クライアントまたはサーバー）が 2 つの値を SIP ドメイン ID として比較する場合：

実装は、各 SIP ドメイン識別子の DNS 名コンポーネントのみを比較しなければなりません (MUST)。実装は比較にスキームまたはパラメータを使用してはなりません (MUST NOT)。

実装は、値を DNS 名として比較しなければなりません (MUST)。つまり、比較は [DNS-CASE] で指定されているように大文字と小文字を区別しません。実装は、[PKIX] のセクション 7.2 に従って国際化ドメイン名 (IDN) を処理しなければなりません (MUST)。

実装は、値を全体として一致させなければなりません (MUST):

 実装は接尾辞と一致させてはなりません (**MUST NOT**)。たとえば、"foo.example.com" は "example.com" と一致しません。

 実装は、他の DNS ラベルまたはラベルのシーケンスを伴う先頭の "." または "*." などの、いかなる形式のワイルドカードとも一致させてはなりません (**MUST NOT**)。たとえば、"*.example.com" は "*.example.com" とのみ一致し、"foo.example.com" とは一致しません。同様に、".example.com" は ".example.com" とのみ一致し、"foo.example.com." とは一致しません。

    [HTTP-TLS] では、dNSName コンポーネントにワイルドカードを含めることができます。たとえば、"DNS:*.example.com" です。[PKIX] は、これを明示的に禁止していませんが、ワイルドカードの解釈を個々の仕様に委ねています。[SIP] は、証明書内のワイルドカードの存在に関するガイドラインを提供していません。上記のルールにより、このドキュメントは SIP ドメインの証明書でのそのようなワイルドカードを禁止しています。

B.10. SNMP (2010)​

2010 年、[SNMP-TLS] は、SNMP でのアプリケーションサービス ID 検証に関して次のテキストを指定しました。

サーバーの提示された証明書が構成されたトラストアンカーへの認証パス検証 [PKIX] に合格し、長さゼロの snmpTlstmAddrServerFingerprint 値を持つアクティブな行が存在する場合、snmpTlstmAddrServerIdentity 列には予想されるホスト名が含まれます。この予想されるホスト名は、次のようにサーバーの証明書と比較されます。

  • 実装は、予想されるホスト名を subjectAltName 拡張フィールドの dNSName と照合することをサポートしなければならず (MUST)、名前をサブジェクト識別名の CommonName 部分と照合することをサポートできます (MAY)。

  • '*' (ASCII 0x2a) ワイルドカード文字は、subjectAltName 拡張の dNSName（および、ホスト名の格納に使用される場合は共通名）で許可されますが、その値の左端（最下位）の DNS ラベルとしてのみ許可されます。このワイルドカードは、サーバー名の左端の DNS ラベルと一致します。つまり、サブジェクト *.example.com は、サーバー名 a.example.com および b.example.com と一致しますが、example.com または a.b.example.com とは一致しません。実装は、上記のように証明書内のワイルドカードをサポートしなければなりません (MUST) が、それらを無効にする構成オプションを提供することができます (MAY)。

  • ローカルに構成された名前が国際化ドメイン名である場合、準拠する実装は、比較を実行するために、[PKIX] のセクション 7 で指定されているように、ASCII 互換エンコーディング (ACE) 形式にそれを変換しなければなりません (MUST)。

予想されるホスト名がこれらの条件を満たさない場合、接続を閉じなければなりません (MUST)。

B.11. GIST (2010)​

2010 年、[GIST] は、General Internet Signalling Transport でのアプリケーションサービス ID 検証に関して次のテキストを指定しました。

5.7.3.1. TLS での ID チェック (Identity Checking in TLS)

TLS 認証後、ノードは、中間者攻撃を回避するためにピアによって提示された ID をチェックし、ピアが GIST 層でのシグナリングに参加することを許可されていることを確認しなければなりません (MUST)。承認チェックは、セクション 4.4.2 で説明されているように、提示された ID を各承認済みピアデータベース (APD) エントリと順番に比較することによって実行されます。このセクションでは、単一の APD エントリの ID 比較アルゴリズムを定義します。

X.509 証明書を使用した TLS 認証の場合、DNS 名前空間からの ID を、証明書に存在するタイプ dNSName の各 subjectAltName 拡張に対してチェックしなければなりません (MUST)。そのような拡張が存在しない場合、ID を証明書のサブジェクトフィールドにある（最も具体的な）Common Name と比較しなければなりません (MUST)。DNS 名を dNSName または Common Name フィールドと照合する場合、照合は大文字と小文字を区別しません。また、"" ワイルドカード文字は、証明書または APD 内の ID の左端の名前コンポーネントとして使用できます (MAY)。たとえば、APD 内の .example.com は a.example.com、foo.example.com、.example.com などの証明書と一致しますが、example.com とは一致しません。同様に、.example.com の証明書は、a.example.com、foo.example.com、*.example.com などの APD ID に対して有効ですが、example.com に対しては無効です。

さらに、ノードは、接続先のピアの ID と、そのピアによって提示された公開鍵との間のバインディングを検証しなければなりません (MUST)。ノードは、一般的な証明書検証のために [PKIX] のセクション 6 のアルゴリズムを実装すべきです (SHOULD) が、同等のレベルの検証を達成する他の検証方法（サーバー証明書をすでに検証済みの証明書および ID バインディングのローカルストアと比較するなど）でそのアルゴリズムを補足することができます (MAY)。

事前共有キーを使用した TLS 認証の場合、psk_identity_hint（サーバー ID、つまり応答ノードの場合）または psk_identity（クライアント ID、つまりクエリノードの場合）内の ID を、APD 内の ID と比較しなければなりません (MUST)。

に最終更新