要約

  • 有効な委任クレデンシャルは、基となるエンドエンティティ証明書の範囲内で、互換性のある TLS または DTLS 1.3 接続を認証する限定権限を示す。
  • ドメインの管理権限、CA の証明書発行権限、法人としての同一性、独立して早期失効できる権限を示すものではない。

仮想的なセキュリティ資産管理画面が CDN エッジを監視しているとする。エッジは有効な委任クレデンシャルを提示して TLS 1.3 ハンドシェイクを完了し、システムはそのノードを新たなドメイン管理者として登録する。最初の観測は正しいが、分類は正しくない。

RFC 9345 の仕組みはもっと狭い。証明書保有者は、公開鍵、署名アルゴリズム、短い有効期間を含む構造に署名する。対応フロントエンドは、親証明書の長期秘密鍵を受け取らずに接続を終端できる。署名はクレデンシャルをエンドエンティティ証明書全体と、クライアントまたはサーバー認証の文脈に結び付ける。

親証明書の検証は残る。相手は証明書チェーンを検証し、エンドエンティティ証明書を期待する身元と照合する。親証明書には DelegationUsage があり、デジタル署名が許可されていなければならない。相手はさらに、ネゴシエーションで選ばれたアルゴリズム、クレデンシャルの署名、時間境界を確認する。別のアプリケーションプロファイルがない限り、残存有効期間の上限は七日で、親証明書を超えられない。

これは TLS の範囲における委任秘密鍵の所持を証明する。新しい公開証明書の発行、DNS の変更、企業関係、ドメインの法的管理者を証明しない。有効なハンドシェイクは権利証ではない。

RFC 9345 は委任クレデンシャル専用の早期失効機構も追加しない。期限切れで失効し、委任の根拠となるエンドエンティティ証明書が失効すれば、クレデンシャルも暗黙に無効になる。委任クレデンシャルの署名に使う長期秘密鍵が漏えいまたは廃止された場合、運用者は当該証明書を失効させなければならない。鍵の状態が変わっただけでは、プロトコル上の別個の失効通知にはならない。委任秘密鍵が盗まれれば、期限切れまたは証明書失効まで新しい接続でなりすましに使われ得る。有効期間を短くすれば露出は減るが、保管管理が不要になるわけではない。

TLS 1.3 の再開ハンドシェイクでは、証明書も委任クレデンシャルも再送されない。実装または受け入れ方針が再開時に元の証明書チェーンを保存して再検証する場合は、元の委任クレデンシャルも関連付けて再検証すべきである。これは条件付きの保証措置であり、プロトコル共通の検証手順ではない。

運用上の受領記録には、親のエンドエンティティ証明書の指紋と期限、DelegationUsage、委任公開鍵の指紋、発行者、クライアントまたはサーバーの役割、アルゴリズム、期間、配布先、保管責任者、TLS バージョン、観測したハンドシェイク、再開処理、親証明書の失効状態、廃止結果、各証拠の観測時刻をひも付ける。限定された終端権限を、プロトコルが与えていない一般的なドメイン権限へ変換してはならない。

出典