3. Expect-CT失敗の報告

UAが既知のExpect-CTホストへの接続を試み、接続がCT適格でない場合、UAは既知のExpect-CTホストのExpect-CTメタデータのreport-uri（ある場合）にExpect-CT失敗を報告すべきです。

UAがCT適格でない接続を介してExpect-CT応答ヘッダーフィールドを受信した場合、UAがこの接続のExpect-CTレポートをまだ送信していない場合、UAは設定されたreport-uri（ある場合）にExpect-CT失敗を報告すべきです。

3.1. 違反レポートの生成

違反レポートオブジェクトを生成するために、UAは次のキーと値を持つJSON [RFC8259]オブジェクトを構築します：

"date-time" - UAがCT準拠失敗を観察したUTC時刻。[RFC3339]セクション5.6に従ってフォーマットされた文字列。

"hostname" - CT準拠チェックに失敗した元のリクエストを行ったホスト名。文字列として提供されます。

"port" - CT準拠チェックに失敗した元のリクエストを行ったポート。整数として提供されます。

"scheme" - （オプション）CT準拠チェックに失敗した元のリクエストを行ったスキーム。文字列として提供されます。このキーはオプションであり、存在しない場合は"https"と見なされます。

"effective-expiration-date" - CT準拠チェックに失敗したExpect-CTホストの有効期限日（セクション2.3.2.2を参照）をUTCで示します。[RFC3339]セクション5.6に従ってフォーマットされた文字列として提供されます。

"served-certificate-chain" - TLSセッション設定中にExpect-CTホストによって提供された証明書チェーン。文字列の配列として提供され、証明書が提供された順序で表示しなければなりません。配列内の各文字列は、[RFC7468]で説明されている各X.509証明書のPEM表現です。

"validated-certificate-chain" - 証明書チェーン検証中にUAによって構築された証明書チェーン。（これは"served-certificate-chain"キーの値とは異なる場合があります。）文字列の配列として提供され、UAが検証したチェーンに一致する順序で表示しなければなりません。

"scts" - UAがExpect-CTホストのために受信したSCT（ある場合）とその検証ステータスを表します。JSONオブジェクトの配列として提供されます。各JSONオブジェクトには次のキーがあります：

• "version" キー、整数値を持ちます。SCTが[RFC6962]セクション3.2で定義された形式の場合、UAはこの値を1に設定しなければならず、[RFC9162]セクション4.5で定義された形式の場合は2に設定します。

• "status" キー、文字列値を持ちます。UAは次のいずれかの値に設定しなければなりません："unknown"（UAがSCTが発行されたログの公開鍵を持っていないか信頼していないことを示す）;"valid"（UAが[RFC6962]セクション5.2または[RFC9162]セクション8.1.3で説明されているようにSCTを正常に検証したことを示す）;または"invalid"（署名が不正またはタイムスタンプが無効なためSCT検証が失敗したことを示す）。

• "source" キー、文字列値を持ちます。[RFC6962]セクション3および[RFC9162]セクション6で定義されているように、UAがSCTを取得した場所を示します。UAは値を次のいずれかに設定しなければなりません："tls-extension"、"ocsp"、または"embedded"。

• "serialized_sct" キー、文字列値を持ちます。"version"キーの値が1の場合、UAはこの値を[RFC6962]セクション3.2からのbase64エンコードされた[RFC4648]シリアル化されたSignedCertificateTimestamp構造に設定しなければなりません。"version"キーの値が2の場合、UAはこの値を[RFC9162]セクション4.5で定義されているSCTを表すbase64エンコードされた[RFC4648]シリアル化されたTransItem構造に設定しなければなりません。

"failure-mode" - Expect-CTレポートがenforceモードまたはreport-onlyモードのExpect-CTポリシーによってトリガーされたかどうかを示します。文字列として提供されます。Expect-CTメタデータがenforce設定を示している場合、UAはこの値を"enforce"に設定しなければならず、それ以外の場合は"report-only"に設定します。

"test-report" - （オプション）レポートがレポートサーバーの動作が正しいことを確認するためにテストクライアントによって送信された場合、値はtrueに設定されます。値はブール値として提供され、レポートがサーバーの動作をテストするために役立ち、破棄できる場合はtrueに設定しなければなりません。

3.2. 違反レポートの送信

UAは既知のExpect-CTホストのExpect-CT失敗を報告すべきです：つまり、既知のExpect-CTホストへの接続がUAのCTポリシーに準拠しておらず、ホストのExpect-CTメタデータにreport-uriが含まれている場合。

さらに、UAは保存されたExpect-CTメタデータを持たないホストのExpect-CT失敗を報告すべきです：つまり、UAがホストに接続し、report-uriディレクティブを含むExpect-CTヘッダーフィールドを受信した場合、接続がUAのCTポリシーに準拠していない場合、UAはExpect-CT失敗を報告すべきです。

Expect-CT失敗を報告する手順は次のとおりです。

1. セクション3.1で説明されているように違反レポートオブジェクトを生成した結果である値を持つ単一のキー"expect-ct-report"を持つJSONオブジェクトレポートオブジェクトを準備します。

2. レポート本文をレポートオブジェクトのJSON文字列化とします。

3. report-uriをExpect-CTヘッダーフィールドのreport-uriディレクティブの値とします。

4. Content-Typeヘッダーフィールドがapplication/expect-ct-report+jsonで、レポート本文で構成されるエンティティ本文を持つHTTP POSTリクエストをreport-uriに送信します。

UAは、HTTP POSTリクエストを送信する一環として、[FETCH]の一部としてクロスオリジンリソース共有（CORS）プリフライトを送信するなど、他の操作を実行してもよいです。

3.3. 違反レポートの受信

Expect-CT違反レポートを受信すると、レポートサーバーは、リクエスト本文を有効なJSONとして解析でき、レポートがセクション3.1で説明されている形式に準拠し、レポートの"scheme"、"hostname"、および"port"フィールドのスキーム、ホスト名、およびポートを認識している場合、2xx（成功）ステータスコードで応答しなければなりません。レポート本文を解析できない場合、またはセクション3.1で説明されている形式に準拠していない場合、またはレポートサーバーがレポート内のスキーム、ホスト名、またはポートのレポートを受信することを期待していない場合、レポートサーバーは400 Bad Requestステータスコードで応答しなければなりません。

セクション3.2で説明されているように、この仕様の将来のバージョンは、異なるトップレベルキーで送信される新しいレポート形式を定義する可能性があります。レポートサーバーがレポート形式を認識しない場合、レポートサーバーは501 Not Implementedステータスコードで応答しなければなりません。

レポートの"test-report"キーがtrueに設定されている場合、サーバーはさらに処理せずにレポートを破棄してもよいですが、それでも2xx（成功）ステータスコードを返さなければなりません。"test-report"キーが存在しないか、falseに設定されている場合、サーバーはExpect-CTホストの所有者による処理と分析のためにレポートを保存すべきです。