4. サーバー ID の表現 (Representing Server Identity)

このセクションでは、証明書発行者向けのルールとガイダンスを提供します。

4.1. ルール (Rules)

認証局が、アプリケーションサービスプロバイダーが関連するアプリケーションを提供する完全修飾 DNS ドメイン名に基づいて証明書を発行する場合、アプリケーションサービスアイデンティティの表現には次のルールが適用されます。読者は、これらのルールの一部が累積的であり、このドキュメントの後半で説明するように、重要な方法で相互作用する場合があることに注意する必要があります。

証明書には、相互運用性のベースラインとして、可能な限り "DNS-ID" を含めるべきである (SHOULD)。
証明書を使用するサービスが、関連する仕様で証明書に SRV-ID タイプの識別子を含めることになっている (OUGHT TO) 技術を展開している場合（たとえば、[XMPP] の場合）、証明書には SRV-ID を含めるべきである (SHOULD)。
証明書を使用するサービスが、関連する仕様で証明書に URI-ID タイプの識別子を含めることになっている (OUGHT TO) 技術を展開している場合（たとえば、[SIP-CERTS] による [SIP] はこれに該当しますが、[HTTP-TLS] は HTTP サービスによる URI-ID の使用について記述していないため、[HTTP] は該当しません）、証明書には URI-ID を含めるべきである (SHOULD)。スキーム (scheme) は、アプリケーションサービスタイプに関連付けられたスキームでなければならず (SHALL)、「ホスト (host)」コンポーネント（またはその同等物）は、サービスの完全修飾 DNS ドメイン名でなければならない (SHALL)。この仕様を再利用する仕様は、アプリケーションプロトコルの PKIX 証明書に含まれる URI-ID でどの URI スキームが許容されるかを指定しなければならない (MUST)（たとえば、[SIP-SIPS] で説明されている SIP の場合は "sip" であり "sips" や "tel" ではない、または将来の仕様で説明されるかもしれない HTTP の場合は http と https など）。
証明書には、[SRVNAME] の公開前に定義された他のアプリケーション固有の識別子タイプ（たとえば、[XMPP] の XmppAddr）、またはサービス名や URI スキームが存在しない識別子タイプを含めることができる (MAY) 。ただし、そのようなアプリケーション固有の識別子はすべてのアプリケーション技術に適用されるわけではないため、この仕様の範囲外である。
多くのデプロイされたクライアントは依然として証明書のサブジェクトフィールド内の CN-ID をチェックしているが、認証局は、CN-ID でサーバーの完全修飾 DNS ドメイン名を表す証明書の発行をやめることが推奨される。したがって、認証局が、この仕様を再利用し、特定のアプリケーション技術のコンテキストで CN-ID 識別子タイプの継続的なサポートを明示的に推奨している仕様に従って証明書を発行する場合を除き、証明書には CN-ID を含めるべきではない (SHOULD NOT)。
証明書には複数の DNS-ID、SRV-ID、または URI-ID を含めることができる (MAY) が、セクション 7.4 でさらに説明するように、複数の CN-ID を含めるべきではない (SHOULD NOT)。
この仕様を再利用する仕様がワイルドカード文字 '' の継続的なサポートを許可しない限り、識別子内の完全な左端のラベルとして（[DNS-CONCEPTS] のラベルとドメイン名の説明に従い、たとえば ".example.com"）であれ、その断片として（たとえば、oo.example.com、fo.example.com、または fo*.example.com）であれ、提示される識別子の DNS ドメイン名部分には通配符文字を含めるべきではない (SHOULD NOT)。いわゆる「ワイルドカード証明書」に関する詳細な議論は、セクション 7.2 にあります。

4.2. 例 (Examples)

DNS SRV ルックアップでは検出できない "www.example.com" の単純なウェブサイトを考えてみましょう。HTTP はサーバー証明書での URI の使用を指定していないため、サービスの証明書には、"www.example.com" の DNS-ID のみが含まれる可能性があります。デプロイされたインフラストラクチャとの後方互換性のために、"www.example.com" の CN-ID が含まれる場合もあります。

"mail.example.net" ホストにある IMAP アクセス可能な電子メールサーバーを考えてみましょう。これは "[email protected]" 形式の電子メールアドレスにサービスを提供し、"example.net" アプリケーションサービス名の DNS SRV ルックアップを介して検出可能です。サービスの証明書には、"_imap.example.net" および "_imaps.example.net" の SRV-ID（[EMAIL-SRV] を参照）、ならびに "example.net" および "mail.example.net" の DNS-ID が含まれる可能性があります。デプロイされたインフラストラクチャとの後方互換性のために、"example.net" および "mail.example.net" の CN-ID が含まれる場合もあります。

"voice.example.edu" ホストにある SIP アクセス可能な Voice over IP (VoIP) サーバーを考えてみましょう。これは "[email protected]" 形式の SIP アドレスにサービスを提供し、<sip:voice.example.edu> という URI で識別されます。サービスの証明書には、"sip:voice.example.edu" の URI-ID（[SIP-CERTS] を参照）と、"voice.example.edu" の DNS-ID が含まれます。デプロイされたインフラストラクチャとの後方互換性のために、"voice.example.edu" の CN-ID が含まれる場合もあります。

"im.example.org" ホストにある XMPP 互換のインスタントメッセージング (IM) サーバーを考えてみましょう。これは "[email protected]" 形式の IM アドレスにサービスを提供し、"im.example.org" ドメインの DNS SRV ルックアップを介して検出可能です。サービスの証明書には、"_xmpp-client.im.example.org" および "_xmpp-server.im.example.org" の SRV-ID（[XMPP] を参照）、"im.example.org" の DNS-ID、および "im.example.org" の XMPP 固有の "XmppAddr"（[XMPP] を参照）が含まれる可能性があります。デプロイされたインフラストラクチャとの後方互換性のために、"im.example.org" の CN-ID が含まれる場合もあります。