known Pinned Host

既知ピン付きホスト (HTTP)

[3] 既知ピン付きホスト (Known Pinned Host) は、 以前のアクセスで得られたピンの情報を利用者エージェントが保持しているホストです。

仕様書

意味

[2] 既知ピン付きホスト (Known Pinned Host) は、 PKP ヘッダーで得られた情報を一定期間利用者エージェントにおいて保持しておくものです。

[63] PKP-RO ヘッダーの情報をキャッシュしてはなりません >>5

状態

[54] 既知ピン付きホストキャッシュ (Pinning Metadata >>4) は、次の状態を持ちます。

ドメイン名
ピン付きホスト (Pinned Host) ドメイン名です >>5
実効ピン日付 (Effective Pin Date)
利用者エージェントホストに関する妥当なピン付けヘッダー (Valid Pinning Header) を観測した時刻です >>5
実効満期日付 (Effective Expiration Date)
実効ピン日付max-age を足したものです >>5
includeSubDomains
includeSubDomains 指令が指定されたかどうかです >>5
report-uri
report-uri 指令が指定された場合、その値です >>5
ピン
0個以上のピンのリストです。

[12] なお report-uri で指定された URL に送信される JSON では、 effective-expiration-date実効満期日付を記述します。

report-uri を参照。

ドメイン名

[57] 既知ピン付きホストは、ドメイン名により識別します。 IPアドレスは使いません。 >>5

[58] 対象URLホストIPアドレスなら、 利用者エージェントはそのホスト既知ピン付きホストとして記録してはなりません >>5

[59] RFC では Request-URI としています >>5 が、Request-URIホストを指定したとは限りませんから、対象URL (実効要求URL) のものを使うべきと思われます。また RFCRFC 3986 URI を使っているので IP-literal または IPv4address といっています >>5 が、実際の URL はそれ以外の構文で IPアドレスが指定されるかもしれず、その場合でも既知ピン付きホストとするのは不適当と思われます。

[28] 利用者エージェントは、ドメイン名IDNA 正準化を行わなければなりません >>5

[29] RFCHSTSRFC の方法を参照しています。 IDNA 参照。

[60] ドメイン名は、既知HSTSホストドメイン名一致により比較します >>5

[13] 複数一致するものが見つかる場合 (includeSubDomains が使われている場合にあり得ます。) にどう処理するべきかは定かではありません。 すべてにそれぞれ Pin Validation を行う必要があるのでしょうか。

[62] (完全一致ではなく) 超ドメイン一致する既知ピン付きホストのキャッシュを編集してはなりません >>5

満期

[55] 既知ピン付きホスト満期 (expired) であるとは、 実効満期日付過去日付であることをいいます >>5

[61] 利用者エージェントmax-age 値に上限を設けても構いません。 上限を超える値が指定された場合は、上限が指定されたものとして扱って構いません。 >>5

[56] 利用者エージェントは、キャッシュ中の満期既知ピン付きホストを無視しなければなりません >>5

preloaded pin list

[6] 利用者エージェントは、 PKP 仕様に基づき応答から得た既知ピン付きホストの他に、 実装組み込みなどの方法でピン付きホストの情報を得て構いません。 既知ピン付きホストと衝突する場合にどちらを優先するかは実装定義です。 >>5

[15] preload は、不正な方法で発行された証明書を使って攻撃者が PKP利用者エージェントに与えることを防ぐために有用かもしれません >>14

[16] そのような使い方をするなら利用者エージェントの組み込み (preload) の PKP が優先される必要がありそうです。

自己署名証明書の扱い

[8] 利用者エージェントは、 自己署名末端実体証明書による認証を受け入れる場合には、 そのような証明書に関するピンも認めても構いません >>5

fingerprinting

[18] 既知ピン付きホストの情報は fingerprinting vector となります。

[19] 利用者エージェント既知ピン付きホストの情報を消去する仕組み >>17, >>20 や現在の状態を表示する仕組み >>20利用者に提供してもよいかもしれません (advisable)

関連

[24] HSTS既知HSTSホストに相当します。