メインコンテンツまでスキップ

2. サーバーとクライアントの動作

2.1. 応答ヘッダーフィールド構文​

Expect-CT応答ヘッダーフィールドは、この仕様で定義される新しいフィールドです。サーバーは、UAがヘッダーフィールドを発行するホストへの接続がCT準拠であるかどうかを評価する必要があることを示すためにこれを使用します（セクション2.4）。

Expect-CT           = 1#expect-ct-directive
expect-ct-directive = directive-name [ "=" directive-value ]
directive-name      = token
directive-value     = token / quoted-string

ディレクティブの全体的な要件は次のとおりです：

  1. ディレクティブの出現順序は重要ではありません。
  2. 特定のディレクティブは、特定のヘッダーフィールドに複数回出現してはなりません。
  3. ディレクティブ名は大文字と小文字を区別しません。
  4. UAは、この仕様で定義された構文に準拠しないディレクティブまたはその他のヘッダーフィールド値データを含むヘッダーフィールドを無視しなければなりません。
  5. ヘッダーフィールドにUAが認識しないディレクティブが含まれている場合、UAはそれらのディレクティブを無視しなければなりません。
  6. Expect-CTヘッダーフィールドが上記の要件（1〜5）を満たし、ローカルポリシーの理由でExpect-CTが無効になっていない場合（セクション2.4.1で説明）、UAは認識するディレクティブを処理しなければなりません。

2.1.1. report-uri ディレクティブ​

オプションのreport-uriディレクティブは、UAがExpect-CT失敗を報告すべきURIを示します（セクション2.4）。

2.1.2. enforce ディレクティブ​

オプションのenforceディレクティブは、存在する場合（つまり、「アサート」されている場合）、CTポリシーへの準拠を強制する必要があること（レポートのみではなく）、およびUAがCTポリシーに違反する将来の接続を拒否する必要があることをUAに通知する値のないディレクティブです。

2.1.3. max-age ディレクティブ​

max-ageディレクティブは、Expect-CTヘッダーフィールドの受信後、UAがメッセージを受信したホストを既知のExpect-CTホストと見なすべき秒数を指定します。

max-age-value = delta-seconds
delta-seconds = 1*DIGIT

2.1.4. 例​

Expect-CT: max-age=86400, enforce

Expect-CT: max-age=86400,enforce
Expect-CT: report-uri="https://foo.example/report"

Expect-CT: max-age=86400,report-uri="https://foo.example/report"

2.2. ホスト処理モデル​

このセクションでは、Expect-CTホストが実装する処理モデルについて説明します。

2.2.1. HTTP-over-Secure-Transport リクエストタイプ​

Expect-CTホストは、その応答にExpect-CTヘッダーフィールドを含めます。ヘッダーフィールドは、セクション2.1で指定された文法を満たさなければなりません。

2.2.2. HTTP リクエストタイプ​

Expect-CTホストは、非セキュアトランスポート経由で伝達されるHTTP応答にExpect-CTヘッダーフィールドを含めるべきではありません。

2.3. ユーザーエージェント処理モデル​

UA処理モデルは、ドメイン名の解析に依存しています。国際化ドメイン名は、[RFC6797]のセクション10のスキームに従ってUAによって正規化されるものとします。

UAは、既知のExpect-CTホストとそれに関連付けられたExpect-CTディレクティブを保存します。このデータは総称して、ホストの「Expect-CTメタデータ」と呼ばれます。

2.3.1. 欠落または不正なExpect-CTヘッダーフィールド​

HTTP応答にセクション2.1で指定された文法に準拠するExpect-CTヘッダーフィールドが含まれていない場合、UAはExpect-CTメタデータを更新してはなりません。

2.3.2. Expect-CTヘッダーフィールド処理​

UAがセキュアトランスポート経由でセクション2.1で指定された文法に準拠するExpect-CTヘッダーフィールドを含むHTTP応答を受信した場合、UAはヘッダーフィールドが受信された接続がUAのCTポリシーに準拠しているかどうかを評価しなければならず、次にExpect-CTヘッダーフィールドを次のように処理します。

接続がUAのCTポリシーに準拠していない場合（つまり、接続がCT適格でない場合）、UAはExpect-CTメタデータを更新してはなりません。ヘッダーフィールドにreport-uriディレクティブが含まれている場合、UAは指定されたreport-uriにレポートを送信すべきです（セクション2.3.3）。

接続がUAのCTポリシーに準拠している場合（つまり、接続がCT適格である場合）、UAは次のいずれかをしなければなりません：

  • ホストがまだ記録されていない場合は、ホストを既知のExpect-CTホストとして記録する（セクション2.3.2.1を参照）、または
  • enforce、max-age、またはreport-uriヘッダーフィールド値ディレクティブがUAがすでに維持している情報とは異なる情報を伝達する場合、既知のExpect-CTホストのUAのキャッシュ情報を更新する。

2.3.2.1. Expect-CTの記録​

エラーのないTLS接続（[RFC5280]で説明されているX.509証明書チェーン検証、およびこのドキュメントのセクション2.4で説明されている検証を含む）でExpect-CT応答ヘッダーフィールドを受信すると、UAはホストを既知のExpect-CTホストとして記録しなければならず、ホストのドメイン名とそれに関連付けられたExpect-CTディレクティブを不揮発性ストレージに保存します。

2.3.2.2. ストレージモデル​

Request-URI（ホストが応答したメッセージの）からのホスト生成に一致する部分文字列が既存の既知のExpect-CTホストのドメイン名と完全に一致しない場合（[RFC6797]のセクション8.2で指定された一致する一致の一致手順に従って）、UAはこのホストを既知のExpect-CTホストキャッシュに追加しなければなりません。UAは次をキャッシュします：

  • Expect-CTホストのドメイン名。
  • enforceディレクティブが存在するかどうか。
  • 有効期限日（有効なExpect-CT日付にmax-ageディレクティブの値を加えたもの）。
  • report-uriディレクティブの値（存在する場合）。

2.3.3. 報告​

UAがセキュアトランスポート経由でreport-uriディレクティブを含むExpect-CTヘッダーフィールドを含むHTTP応答を受信し、接続がUAのCTポリシーに準拠していない場合（つまり、接続がCT適格でない場合）、およびUAがこの接続のExpect-CTレポートをまだ送信していない場合、UAはセクション3で指定されているように、指定されたreport-uriにレポートを送信すべきです。

2.4. CT準拠のためのExpect-CT接続の評価​

UAがTLS接続を設定すると、UAは既知のExpect-CTホストキャッシュに従ってホストが既知のExpect-CTホストであるかどうかを判断します。有効期限日が過去の日付を参照している場合、Expect-CTホストは「期限切れ」です。UAはキャッシュ内の期限切れのExpect-CTホストを無視しなければならず、そのようなホストを既知のExpect-CTホストとして扱いません。

UAがTLS接続を使用して既知のExpect-CTホストに接続する場合、TLS接続にエラーがない場合、UAは追加の正確性チェックを適用します：CTポリシーへの準拠。UAは、既知のExpect-CTホストに接続する際には、CTポリシーへの準拠を評価すべきです。

既知のExpect-CTホストへの接続がUAのCTポリシーに違反している場合（つまり、接続がCT適格でない場合）、および既知のExpect-CTホストのExpect-CTメタデータがenforce設定を示している場合、UAはCT準拠失敗をエラーとして扱わなければなりません。

既知のExpect-CTホストへの接続がUAのCTポリシーに違反し、既知のExpect-CTホストのExpect-CTメタデータにreport-uriが含まれている場合、UAはそのreport-uriにExpect-CTレポートを送信すべきです（セクション3）。

2.4.1. CT準拠チェックのスキップ​

UAがローカルポリシーに従って一部のホストのCT準拠チェックをスキップすることは許容されます。たとえば、UAは、検証された証明書チェーンがUAに組み込まれた（または基盤となるプラットフォームに組み込まれた）トラストアンカーではなく、ユーザー定義のトラストアンカーで終了するホストのCT準拠チェックを無効にすることができます。

UAがCT準拠を評価しない場合、たとえば、ユーザーがそれを無効にすることを選択したため、または提示された証明書チェーンがユーザー定義のトラストアンカーにチェーンアップしているため、UAはExpect-CTレポートを送信すべきではありません。

に最終更新