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

8. User Agent Processing Model (ユーザーエージェント処理モデル)

本セクションでは、UAのHTTP Strict Transport Security処理モデルについて説明する。このモデルにはいくつかの側面があり、以下のサブセクションで列挙される。

この処理モデルは、UAがIDNA2008 [RFC5890]、または場合によってはIDNA2003 [RFC3490] を実装していることを前提としている (セクション13 ("Internationalized Domain Names for Applications (IDNA): Dependency and Migration") を参照)。また、本仕様のコンテキストで動作するすべてのドメイン名が、本セクションで指定された処理の前に、セクション10 ("Domain Name IDNA-Canonicalization") で概説されているようにIDNA正規化されていることを前提としている。

注 (NOTE): [RFC3490] の引用は、予見可能な将来における実際の展開への継続的な関連性のためである。

上記の前提は、この処理モデルが、本セクションで指定された処理の前に、ドメイン名のIDNA正規化プロセスにおいて、ドメイン名に対して適切なIDNAおよびUnicode検証および文字リストテストが実行されていることを特に前提としていることも意味する。根拠および詳細については、セクション14.10 ("Internationalized Domain Names") のIDNA固有のセキュリティ考慮事項を参照。

8.1. Strict-Transport-Security Response Header Field Processing (Strict-Transport-Securityレスポンスヘッダーフィールド処理)

セキュアなトランスポートを介して受信したHTTPレスポンスに、セクション6.1 ("Strict-Transport-Security HTTP Response Header Field") で指定された構文に準拠するSTSヘッダーフィールドが含まれており、基礎となるセキュアトランスポートのエラーまたは警告がない場合 (セクション8.4を参照)、UAは次のことをしなければならない (MUST):

  • まだ記録されていない場合は、ホストを既知のHSTSホストとして記録する (セクション8.1.1 ("Noting an HSTS Host - Storage Model") を参照)、

または

  • max-ageおよびincludeSubDomainsヘッダーフィールド値トークンの1つまたは両方が伝達する情報がUAがすでに維持している情報と異なる場合は、既知のHSTSホストに関するUAのキャッシュ情報を更新する。

    max-age値は、本質的にSTSヘッダーフィールドを受信した時刻に対する"生存時間 (time to live)"値である。

    max-ageヘッダーフィールド値トークンの値がゼロの場合、HSTSホストが既知である場合、UAはキャッシュされたHSTSポリシー情報 (主張されている場合はincludeSubDomainsディレクティブを含む) を削除しなければならず (MUST)、まだ既知でない場合、UAはこのHSTSホストを記録してはならない (MUST NOT)。

    UAがセキュアなトランスポートを介したHTTPレスポンスメッセージで複数のSTSヘッダーフィールドを受信した場合、UAは最初のそのようなヘッダーフィールドのみを処理しなければならない (MUST)。

それ以外の場合:

  • 非セキュアなトランスポートを介してHTTPレスポンスを受信した場合、UAは存在する任意のSTSヘッダーフィールドを無視しなければならない (MUST)。

  • UAは、セクション6.1 ("Strict-Transport-Security HTTP Response Header Field") で指定された構文に準拠しない任意のSTSヘッダーフィールドを無視しなければならない (MUST)。

8.1.1. Noting an HSTS Host - Storage Model (HSTSホストの記録 - ストレージモデル)

Request-URI (ホストがレスポンスしたメッセージ) のhost生成と一致する部分文字列が、構文的に [RFC3986] セクション3.2.2のIP-literalまたはIPv4address生成と一致する場合、UAはこのホストを既知のHSTSホストとして記録してはならない (MUST NOT)。

それ以外の場合、部分文字列がセクション8.2 ("Known HSTS Host Domain Name Matching") で指定された照合プロセスに従って既知のHSTSホストのドメイン名と一致して一致しない場合、UAはこのホストを既知のHSTSホストとして記録し (MUST)、HSTSホストのドメイン名をキャッシュし、それとともに、指定されたmax-age値によって有効に規定されるこの情報の有効期限、およびincludeSubDomainsディレクティブが主張されているかどうかを記録しなければならない (MUST)。セクション11.2 ("HSTS Policy Expiration Time Considerations") も参照。

UAは、親ドメインと一致する既知のHSTSホストの有効期限またはincludeSubDomainsディレクティブを変更してはならない (MUST NOT)。

既知のHSTSホストのキャッシュエントリの有効期限が過去の日付である場合、その既知のHSTSホストは"期限切れ (expired)"である。キャッシュに期限切れの既知のHSTSホストが存在する場合、UAはキャッシュからすべての期限切れの既知のHSTSホストを削除しなければならない (MUST)。

8.2. Known HSTS Host Domain Name Matching (既知のHSTSホストドメイン名マッチング)

特定のドメイン名は、1つまたは両方の方法で既知のHSTSホストのドメイン名と一致する可能性がある: 一致マッチ (congruent match) または親ドメインマッチ (superdomain match)。または、一致しない可能性がある。

以下の手順は、一致があるかどうか、ある場合はどの方法かを判断する:

ASCII不区分大文字小文字比較を使用して、最も右側のラベルから開始し、右から左に続けて、ラベルごと (ラベルのみを比較) に、特定のドメイン名をUAの各未期限切れの既知のHSTSホストのドメイン名と比較する。[RFC5890] セクション2.3.2.4も参照。

  • 親ドメインマッチ (Superdomain Match)

    既知のHSTSホストのドメイン名全体と特定のドメイン名の右側部分との間でラベルごとの一致が見つかった場合、この既知のHSTSホストのドメイン名は特定のドメイン名の親ドメインマッチである。特定のドメイン名には複数の親ドメインマッチがある可能性がある。

  • 一致マッチ (Congruent Match)

    既知のHSTSホストのドメイン名と特定のドメイン名との間でラベルごとの一致が見つかった場合 -- つまり、比較するラベルがもうない場合 -- 特定のドメイン名はこの既知のHSTSホストと一致して一致する。

8.3. URI Loading and Port Mapping (URI読み込みとポートマッピング)

URIの読み込み時に、セクション5.4で概説されているように、HSTSポリシーが適用される場合、UAは次のように動作しなければならない (MUST):

  • URIにportコンポーネントがない場合、またはportコンポーネントがデフォルトの非セキュアポート80と等しい場合、URIに有効リクエストURIのportコンポーネントとしてデフォルトのセキュアトランスポートポート443を割り当てる。

  • URIのschemeコンポーネントを"https"に変更する。

  • 安全でない接続を確立してはならない (MUST NOT)。

  • 構築された有効リクエストURIへのセキュア接続を確立しようとする (MAY)。

8.4. Errors in Secure Transport Establishment (セキュアトランスポート確立のエラー)

既知のHSTSホストへのセキュアな接続を確立しようとしているときにエラーが発生した場合、UAは接続を続行してはならず (MUST NOT)、エラーをユーザーに警告するメッセージを表示してはならない (MUST NOT)。ユーザーがエラーを介して続行することを許可してもならない (MUST NOT)。

これらのエラーには次のものが含まれる (ただし、これらに限定されない):

  • 期限切れの証明書
  • 自己署名証明書
  • 信頼されていない証明書チェーン
  • ホスト名の不一致
  • TLS/SSLプロトコルエラー