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

7.1. 固定された証明書 (Pinned Certificates)

セクション 1.8 で定義されているように、証明書に他の DNS ドメイン名が含まれているにもかかわらず、ユーザーがサービスの証明書をその DNS ドメイン名に関連付けることを明示的に選択した場合（たとえば、ユーザーが "example.com" のソースドメインに関連付けられたドメインとして "apps.example.net" を明示的に承認した場合）、証明書は DNS ドメイン名に「ピン留め」されていると言われます。キャッシュされた名前の関連付けは、提示された証明書と、それが受け入れられたまたは構成されたコンテキストの両方を考慮しなければなりません (MUST)（「コンテキスト」には、提示された証明書からトラストアンカーへの証明書チェーン、ソースドメイン、アプリケーションサービスタイプ、サービスの派生ドメインとポート番号、およびユーザーによって提供された、またはクライアントによって関連付けられたその他の関連情報が含まれます）。

7.2. ワイルドカード証明書 (Wildcard Certificates)

このドキュメントでは、ワイルドカード文字 '*' を提示識別子に含めるべきではない (SHOULD NOT) が、アプリケーションクライアントによってチェックされることは可能である (MAY) と述べています（主にデプロイされたインフラストラクチャとの後方互換性のため）。その結果、このドキュメントで提供されるルールは、多くの既存のアプリケーション技術のルール（付録 B で抜粋したものなど）よりも制限的です。いくつかのセキュリティ上の考慮事項は、ルールの厳格化を正当化します。

ワイルドカード証明書は、そのドメイン内のありとあらゆるホスト名を自動的に保証します。これは管理者にとっては便利かもしれませんが、不正なホストやバグのあるホストを保証するリスクも生じます。たとえば、[Defeating-SSL]（スライド 91 から開始）および [HTTPSbytes]（スライド 38-40）を参照してください。
既存のアプリケーション技術の仕様は、ワイルドカード文字の許容される場所について明確または一貫していません。たとえば、次のいずれになるかが不明です。
- 完全な左端のラベルのみ（たとえば、*.example.com）
- 左端のラベルの断片（たとえば、fo*.example.com、f*o.example.com、または *oo.example.com）
- 左端のラベル以外のラベルの全部または一部（たとえば、www.*.example.com または www.foo*.example.com）
- いわゆる「パブリックサフィックス」を識別するラベルの全部または一部（たとえば、*.co.uk または *.com）
- 特定のラベルに複数回含まれる（たとえば、fbr.example.com）
- 複数のラベルの全部または一部として含まれる（たとえば、..example.com）
これらの曖昧さは、クライアント実装間のアイデンティティチェック動作に悪用可能な違いをもたらし、過度に複雑で非効率的なアイデンティティチェックアルゴリズムを必要とする可能性があります。
ワイルドカード文字を国際化ドメイン名 [IDNA-PROTO] の A-ラベルまたは U-ラベル [IDNA-DEFS] 内にどのように埋め込むことができるかを定義する仕様はありません。その結果、実装は、国際化ドメイン名の A-ラベルまたは U-ラベル内に埋め込まれたワイルドカード文字を含めること、またはチェックしようとすることを強く推奨しません（たとえば、"xn--kcry6tjko*.example.org"）。ただし、提示されたドメイン名識別子は、残りのすべてのラベルが有効な NR-LDH ラベル、A-ラベル、または U-ラベル（たとえば、"*.xn--kcry6tjko.example.org"）である場合、その文字が左端のラベル全体の場所を占めている限り、ワイルドカード文字を含むことができる (MAY) ことに注意してください。

前述のセキュリティ上の考慮事項にもかかわらず、これを再利用する仕様は、展開されたインフラストラクチャとの後方互換性など、そうする正当な理由がある場合、ワイルドカード文字の継続的なサポートを合法的に推奨することができます（たとえば、[EV-CERTS] を参照）。

7.3. 国際化ドメイン名 (Internationalized Domain Names)

国際化ドメイン名を許可すると、証明書に視覚的に類似した（いわゆる「紛らわしい」）文字が含まれる可能性があります。議論については、たとえば [IDNA-DEFS] を参照してください。

7.4. 複数の識別子 (Multiple Identifiers)

特定のアプリケーションサービスは、さまざまな理由で複数の DNS ドメイン名によってアドレス指定される場合があり、特定の展開は複数のドメインにサービスを提供する場合があります（たとえば、いわゆる「バーチャルホスティング」環境）。複数の識別子の使用は次のように対処されます。

デフォルトの TLS ハンドシェイク交換では、クライアントは通信したい DNS ドメイン名を示すことができず、TLS サーバーはそれ自体の証明書を 1 つだけ返します。TLS への拡張機能がない場合、アプリケーションサービスを複数の DNS ドメイン名にマッピングするのを容易にするために使用される一般的な回避策は、すべてのドメイン名を単一の証明書に埋め込むことです。

より最近のアプローチは、[TLS-EXT] で正式に規定されており、クライアントが client_hello メッセージを送信するときに TLS "Server Name Indication" (SNI) 拡張機能を使用して、サービスに希望または期待する DNS ドメイン名を規定することです。その後、サービスは Certificate メッセージで適切な証明書を返すことができ、その証明書は単一の DNS ドメイン名を表すことができます。

SNI 拡張機能の開発前に必要だった回避策に対応するために、この仕様では、証明書内の複数の DNS-ID、SRV-ID、または URI-ID を許可しています。ただし、複数の CN-ID は明示的に推奨していません。複数の CN-ID を完全に禁止することが望ましいですが、この仕様でそれらを含めるべきではない (SHOULD NOT)（禁止 (MUST NOT) ではなく）としている理由は、現時点でいくつかあります。

少なくとも 1 つの重要な技術的利益のコミュニティが、複数の CN-ID を明示的に許可しています [EV-CERTS]。
少なくとも 1 つの重要な認証局が、複数の CN-ID を含む証明書を発行していることが知られています。
多くのサービスプロバイダーは、少なくとも 1 つの広く展開されているオペレーティングシステムがまだ SNI 拡張機能をサポートしていないため、バーチャルホスティング環境で複数の CN-ID を含めることが必要であるとしばしば考えています。

複数の CN-ID に関する推奨事項が将来さらに厳しくなることが期待されています。