2. アプリケーションサービスの命名 (Naming of Application Services)

このセクションでは、インターネット上のアプリケーションサービスの命名について説明し、次に PKIX におけるサブジェクトの命名について簡単に説明します。

2.1. アプリケーションサービスの命名 (Naming Application Services)

この仕様では、アプリケーションサービスの名前は DNS ドメイン名（例: "example.com"）に基づいていると想定しています。場合によっては、アプリケーションサービスの種類によって補足されます（例: "example.com の IMAP サーバー"）。

アプリケーションクライアントまたはユーザーの観点から見ると、一部の名前は**直接的 (direct)です。これは、人間のユーザーによって直接提供されるためです（たとえば、実行時の入力、事前設定、またはクライアント通信試行の明示的な受け入れを介して）。一方、他の名前は間接的 (indirect)**です。これは、ユーザー入力に基づいてクライアントによって自動的に解決されるためです（たとえば、DNS SRV または NAPTR レコードを使用したソース名からのターゲット名の解決）。この次元は、証明書の消費、具体的にはこのドキュメントで説明する検証にとって最も重要です。

アプリケーションサービスの観点から見ると、一部の名前は**非制限的 (unrestricted)です。これは、あらゆる種類のサービスに使用できるためです（たとえば、証明書は、example.com 上の HTTP サービスと IMAP サービスの両方に再利用できます）。一方、他の名前は制限的 (restricted)**です。これは、1 種類のサービスにのみ使用できるためです（たとえば、IMAP サービスのみに使用するための専用証明書）。この次元は、証明書の発行にとって最も重要です。

したがって、関心のある識別子タイプを次のように分類できます。

CN-ID は直接的かつ非制限的です。
DNS-ID は直接的かつ非制限的です。
SRV-ID は直接的または（より一般的には）間接的であり、制限的です。
URI-ID は直接的かつ制限的です。

この分類を以下の表にまとめます。

+-----------+-----------+---------------+
|           |  直接     |  制限         |
|           |  (Direct) |  (Restricted) |
+-----------+-----------+---------------+
|  CN-ID    |  はい     |  いいえ       |
+-----------+-----------+---------------+
|  DNS-ID   |  はい     |  いいえ       |
+-----------+-----------+---------------+
|  SRV-ID   |  どちらも |  はい         |
+-----------+-----------+---------------+
|  URI-ID   |  はい     |  はい         |
+-----------+-----------+---------------+

ソフトウェアの実装、サービスの展開、および安全な PKIX ベースの認証のための証明書の発行において、これらの区別を念頭に置くことが重要です。特に、アプリケーションサーバーの実装、アプリケーションクライアントの実装、アプリケーションサービスプロバイダー、および認証局にとってのベストプラクティスは、わずかに異なります。理想的には、このドキュメントを参照するプロトコル仕様は、どの識別子がサーバーおよびクライアントによる実装に必須であるか、どの識別子が証明書発行者によってサポートされるべきか、およびどの識別子がアプリケーションサービスプロバイダーによって要求されるべきかを規定します。これらの要件はアプリケーションごとに異なるため、普遍的なルールを断定的に規定することはできません（たとえば、相互運用性の目的のために、すべてのアプリケーションプロトコルのすべてのソフトウェア実装、サービスプロバイダー、および認証局がベースラインとして DNS-ID を使用またはサポートする必要があるなど）。

ただし、各アプリケーションプロトコルは、その技術を積極的に使用またはサポートするソフトウェア開発者、アプリケーションサービスプロバイダー、および CA のコミュニティ全体に適用されるベースラインを少なくとも 1 つ定義することが望ましいです（そのようなコミュニティの 1 つである CA/Browser Forum は、[EV-CERTS] において「拡張検証証明書」のためにそのようなベースラインをすでに成文化しています）。

2.2. DNS ドメイン名 (DNS Domain Names)

この仕様の目的上、アプリケーションサービスの名前は、次のいずれかの形式に準拠する DNS ドメイン名である（またはそれに基づいている）とします。

「従来のドメイン名 (traditional domain name)」。つまり、[IDNA-DEFS] で記述されている "LDH ラベル" であるラベルのみを持つ完全修飾 DNS ドメイン名または "FQDN"（[DNS-CONCEPTS] を参照）。非公式には、そのようなラベルは [US-ASCII] の文字、数字、およびハイフンに制限されており、ハイフンは最初の文字位置では禁止されています。追加の資格が適用されますが（詳細は上記の引用仕様を参照）、それらはこの仕様には関係ありません。
「国際化ドメイン名 (internationalized domain name)」。つまり、ドメイン名の全体的な形式（非公式には、ドット区切りの英数字ハイフンラベル）に準拠しているが、従来の US-ASCII 範囲外の適切にエンコードされた Unicode コードポイントを含むラベルを少なくとも 1 つ含む DNS ドメイン名。つまり、少なくとも 1 つの U-ラベルまたは A-ラベルが含まれていますが、それ以外の場合は、[IDNA-DEFS] および関連文書に記載されている NR-LDH ラベル、A-ラベル、または U-ラベルの任意の組み合わせを含むことができます。

2.3. PKIX 証明書におけるサブジェクトの命名 (Subject Naming in PKIX Certificates)

理論的には、X.509 [PKIX] を使用するインターネット公開鍵インフラストラクチャは、[X.500] および [X.501] で定義されているグローバルディレクトリサービスモデルを採用しています。そのモデルの下では、情報はディレクトリ情報ベース (DIB) に保持され、その中のエントリはディレクトリ情報ツリー (DIT) と呼ばれる階層に編成されます。その階層内のオブジェクトまたはエイリアスエントリは、属性のコレクション（それぞれが定義されたタイプと 1 つ以上の値を持つ）で構成され、一意の識別名 (Distinguished Name, DN) によって一意に識別されます。エントリの DN は、ツリー内の上位エントリの相対識別名（DIT のルートまで）とエントリ自体の 1 つ以上の特別に指定された属性（これらは集合的にエントリの相対識別名 (Relative Distinguished Name, RDN) を構成します。ツリー内の上位エントリの識別名に対して相対的であるため、そう呼ばれます）を組み合わせることによって構築されます。ルートに最も近いエントリは「最上位 (most significant)」エントリと呼ばれることがあり、ルートから最も遠いエントリは「最下位 (least significant)」エントリと呼ばれることがあります。RDN は、属性タイプと値のペア（[LDAP-DN] も参照）のセット（つまり、順序付けられていないコレクション）であり、それぞれがエントリに関する何らかの属性を主張します。

実際には、[X.509] および [PKIX] で使用される証明書は、エンティティを識別するために X.500 および X.501 の主要な概念（DN や RDN など）を借用していますが、そのような証明書は必ずしもグローバルディレクトリ情報ベースの一部ではありません。具体的には、PKIX 証明書のサブジェクト (subject) フィールドは X.501 タイプの名前であり、「サブジェクト公開鍵フィールドに格納された公開鍵に関連付けられたエンティティを識別」します（[PKIX] のセクション 4.1.2.6 を参照）。ただし、証明書にサブジェクト代替名 ("subjectAltName") 拡張が含まれており、その拡張に少なくとも 1 つの subjectAltName エントリが含まれている限り、サブジェクトフィールドは空であっても完全に許容されます。subjectAltName 拡張により、さまざまなアイデンティティをサブジェクトにバインドできるためです（[PKIX] のセクション 4.2.1.6 を参照）。subjectAltName 拡張自体は、型付きエントリのリストであり、各型は異なる種類の識別子です。

私たちの目的において、アプリケーションサービスは、サブジェクトフィールドに含まれる名前（つまり、CN-ID）および/または subjectAltName エントリの次の識別子タイプの 1 つによって識別できます。

DNS-ID
SRV-ID
URI-ID

既存の証明書は、多くの場合、サブジェクトフィールドで CN-ID を使用して完全修飾 DNS ドメイン名を表します。たとえば、Common Name タイプの属性が完全修飾 DNS ドメイン名の形式と一致する文字列（それぞれ "im.example.org"、"mail.example.net"、および "www.example.com"）を含む次の 3 つのサブジェクト名を検討してください。

CN=im.example.org,O=Example Org,C=GB

C=CA,O=Example Internetworking,CN=mail.example.net

O=Examples-R-Us,CN=www.example.com,C=US

ただし、Common Name は厳密に型付けされていないため、Common Name には完全修飾 DNS ドメイン名の形式と一致する文字列ではなく、サービスのユーザーフレンドリーな文字列が含まれる可能性があります（このような単一の Common Name を持つ証明書には、通常、完全修飾 DNS ドメイン名を含む少なくとも 1 つの subjectAltName エントリがあります）。

CN=A Free Chat Service,O=Example Org,C=GB

または、証明書のサブジェクトには、CN-ID と、ユーザーフレンドリーな文字列を含む別の Common Name 属性の両方が含まれる場合があります。

CN=A Free Chat Service,CN=im.example.org,O=Example Org,C=GB

一般に、この仕様は、以下のセクションでより完全に説明するように、可能であればサブジェクトフィールド (CN-ID) を使用するよりも subjectAltName エントリ（DNS-ID、SRV-ID、URI-ID など）を使用することを推奨し、好みます。ただし、この仕様を再利用する仕様は、展開されたインフラストラクチャとの後方互換性など、そうする正当な理由がある場合（たとえば、[EV-CERTS] を参照）、CN-ID 識別子タイプのサポート継続を合法的に推奨することができます。

2.3.1. 実装上の注意 (Implementation Notes)

混乱は、証明書に含まれる階層情報の異なるレンダリングまたはエンコーディングに起因する場合があります。

証明書はバイナリオブジェクトであり、[X.690] で指定された識別符号化規則 (DER) を使用してエンコードされます。ただし、一部の実装では、証明書発行者、サブジェクトフィールド、および subjectAltName 拡張の表示可能な（つまり、印刷可能な）レンダリングが生成され、これらのレンダリングは、表示する前に DER エンコードされたシーケンスを「文字列表現」に変換します。証明書のサブジェクトフィールド（タイプ Name [X.509]、Distinguished Name (DN) [X.501] と同じ）は順序付けられたシーケンスであるため、サブジェクトの文字列表現では通常順序が保持されますが、サブジェクト（および DN）の 2 つの最も一般的な文字列表現は、左から右への順序付けと右から左への順序付けの採用が異なります。ただし、相対識別名 (RDN) は属性タイプと値のペアの順序付けられていないセットであるため、RDN の文字列表現は正規の DER エンコーディングとは異なる場合があります（また、属性タイプと値のペアの順序は、さまざまな実装によって提供される RDN の文字列表現または表示順序によって異なる場合があります）。さらに、さまざまな仕様では、DN または証明書のサブジェクトフィールド内の RDN の順序を参照するために、情報の階層（実際に存在するかもしれないし、存在しないかもしれない）に暗黙的に関連する用語を使用しています。たとえば、「最も具体的 (most specific)」対「最も具体的でない (least specific)」、「左端 (left-most)」対「右端 (right-most)」、「最初 (first)」対「最後 (last)」、または「最上位 (most significant)」対「最下位 (least significant)」などです（たとえば、[LDAP-DN] を参照）。

混乱を減らすために、この仕様では、そのような用語の使用を避け、代わりにセクション 1.8 で提供されている用語を使用します。特に、[HTTP-TLS] の「サブジェクトフィールド内の（最も具体的な）Common Name フィールド」という用語を使用する代わりに、CN-ID は、Common Name タイプの属性タイプと値のペアを 1 つだけ含む証明書サブジェクト内の相対識別名 (RDN) であると述べています（これにより、RDN にタイプ CN の複数の AVA（属性値アサーション）が含まれ、そのうちの 1 つが「最も具体的」とみなされる可能性が排除されます）。

最後に、理論的にはサブジェクトフィールド内の RDN の順序には意味があると主張する人もいますが、実際には、そのルールは通常守られていません。タイプ CN の AVA は、サブジェクトフィールド内のどこにでも有効であると見なされます。