2.4. Processing Rules (処理規則)

2.4. Processing Rules (処理規則)

このセクションでは, 相互認証されたTLS接続を交渉し, その接続からバックエンドオリジンサーバーにクライアント証明書を伝達するTTRPに適用可能な処理規則の概要を示します。この技術は構成またはデプロイメントオプションとして使用されるものであり, ここで説明する処理規則は, そのオプションが有効になっているサーバーに対するものです。

TTRPは, [TLS]または[TLS1.2]で説明されているように, クライアントとの相互認証されたTLS接続の使用を交渉し, そのポリシーおよび信頼された証明機関に従ってクライアント証明書を検証します。基盤となるTLS接続上の各HTTPリクエストは, 以下の変更を加えてオリジンサーバーにディスパッチされます:

1. クライアント証明書は, セクション2.2で説明されているように, ディスパッチされたリクエストのClient-Certヘッダーフィールドに配置されます。

2. そのように構成されている場合, クライアント証明書の検証チェーンは, セクション2.3で説明されているように, リクエストのClient-Cert-Chainヘッダーフィールドに配置されます。

3. 元の受信リクエストでClient-CertまたはClient-Cert-Chainヘッダーフィールドが出現した場合, リクエストを転送する前に削除または上書きしなければなりません (MUST)。Client-CertまたはClient-Cert-Chainヘッダーフィールドを持つ受信リクエストは, HTTP 400レスポンスで拒否してもよい (MAY)。

クライアント証明書認証の使用が交渉されなかったTLS接続を介してTTRPに行われたリクエストは, バックエンドサーバーにリクエストをディスパッチする前に, Client-CertおよびClient-Cert-Chainヘッダーフィールドのすべての出現を削除することによってサニタイズしなければなりません (MUST)。

その後, バックエンドオリジンサーバーは, リクエストのClient-Certヘッダーフィールドを使用して, クライアントからTTRPへの接続が相互認証されたかどうか, もしそうであれば, それによってクライアントが提示した証明書を判断できます。クライアント証明書 (またはその欠如) に基づくアクセス制御の決定は, 適切にレスポンスコンテンツを選択するか, 証明書が与えられたコンテキストで受け入れられないと見なされる場合はHTTP 403レスポンスで伝達できます。受け入れられない証明書に対してTLS層でのエラー指示に依存するTLSクライアントは, これらの信号を受信しないことに注意してください。

Client-Certリクエストヘッダーフィールドの値がレスポンスを選択するために使用される場合 (例えば, レスポンスコンテンツがアクセス制御されている場合), レスポンスはキャッシュ不可能でなければならない (MUST) (例えば, Cache-Control: no-storeを送信することによって) か, またはVary: Client-Certレスポンスヘッダーを送信することによって, 同じClient-Certヘッダーフィールド値を持つ後続のリクエストに対してのみ選択的に再利用されるよう指定されなければなりません (MUST)。TTRPがVaryヘッダーフィールド ([HTTP]のセクション12.5.5) にClient-CertまたはClient-Cert-Chainを含むレスポンスに遭遇した場合, Varyレスポンスヘッダーフィールドの値を*に変換することによって, ユーザーエージェントがレスポンスをキャッシュすることを防ぐべきです (SHOULD)。

フォワードプロキシおよびその他の仲介者は, リクエストにClient-CertまたはClient-Cert-Chainヘッダーフィールドを追加したり, 既存のClient-CertまたはClient-Cert-Chainヘッダーフィールドを変更したりしてはなりません (MUST NOT)。同様に, クライアントはリクエストでClient-CertまたはClient-Cert-Chainヘッダーフィールドを使用してはなりません (MUST NOT)。