5. TLSAとDANEのユースケースと要件 (TLSA and DANE Use Cases and Requirements)

TLSAで定義されているさまざまなタイプの証明書関連付けは、[RFC6394]のさまざまなセクションと一致しています。[RFC6394]のセクション3のユースケースは、このドキュメントで次のようにカバーされています。

• 3.1 CA制約 -- 証明書用途0を使用して実装されます。

• 3.2 証明書制約 -- 証明書用途1を使用して実装されます。

• 3.3 トラストアンカーアサーションとドメイン発行証明書 -- それぞれ証明書用途2と3を使用して実装されます。

[RFC6394]のセクション4の要件は、このドキュメントで次のようにカバーされています。

複数のポート (Multiple Ports) -- 単一のホストで実行されているさまざまなアプリケーションサービスのTLSAレコードは、ホスト名の前に付けられるサービス名とポート番号を通じて区別できます(セクション3を参照)。

ダウングレードなし (No Downgrade) -- セクション4は、クライアントがTLSAレコードを処理して動作できる条件を指定します。具体的には、TLSAリソースレコードセットのDNSSECステータスが偽造と判断された場合、TLS接続(開始されている場合)は失敗します。

カプセル化 (Encapsulation) -- カプセル化はTLSA応答セマンティクスでカバーされています。

予測可能性 (Predictability) -- この仕様の付録は、アプリケーション開発者が推奨されるクライアント動作の一貫した解釈を形成できるように、運用上の考慮事項と実装ガイダンスを提供します。

機会主義的セキュリティ (Opportunistic Security) -- この仕様に準拠したクライアントがTLSAレコードの存在を確実に判断できる場合、この情報を使用しようとします。逆に、クライアントがTLSAレコードの不在を確実に判断できる場合、通常の方法でTLSを処理することにフォールバックします。これはセクション4で説明されています。

組み合わせ (Combination) -- 特定のホスト名に対して複数のTLSAレコードを公開できるため、クライアントはさまざまなアサーションを反映する複数のTLSA証明書関連付けを構築できます。2つのTLSA証明書関連付けを単一の操作で組み合わせるサポートは提供されていません。

ロールオーバー (Roll-over) -- TLSAレコードは、レコードのTTL有効期限を含む、DNSプロトコルの範囲内で通常の方法で処理されます。これにより、クライアントが期限切れのTLSAレコードによって行われたアサーションにロックオンすることがなくなり、1つの公開鍵または証明書用途の使用から別の用途への移行が可能になります。

シンプルな鍵管理 (Simple Key Management) -- TLSAレコードのSubjectPublicKeyInfoセレクタは、ドメイン保有者が証明書を管理する必要なく、単一の長期公開鍵/秘密鍵ペアのみを維持すればよいモードを提供します。付録Aでは、このモードを使用する有用性と潜在的な欠点について概説しています。

最小限の依存関係 (Minimal Dependencies) -- この仕様は、TLSAリソースレコードセットの起源の真正性と完全性を保護するためにDNSSECに依存しています。さらに、TLSA証明書バインディングを使用したいシステムでDNSSEC検証が実行されない場合、この仕様では「ラストマイル」が安全なトランスポート経由である必要があります。このアプローチには他の展開依存関係はありません。

最小限のオプション (Minimal Options) -- 動作モードは、DANEユースケースと要件に正確にマッピングされます。DNSSEC使用は必須であり、この仕様はアプリケーションが検証されたTLSAレコードのみを使用することを推奨しています。

ワイルドカード (Wildcards) -- ワイルドカードは、TLSAリクエスト構文で限定的な方法でカバーされています。付録Aを参照してください。

リダイレクション (Redirection) -- リダイレクションは、TLSAリクエスト構文でカバーされています。付録Aを参照してください。