[3] 既知ピン付きホストは、 以前のアクセスで得られたピンの情報を利用者エージェントが保持しているホストです。
[2] 既知ピン付きホストは、 PKP ヘッダーで得られた情報を一定期間利用者エージェントにおいて保持しておくものです。
[54] 既知ピン付きホストのキャッシュ
(Pinning Metadata >>4) は、次の状態を持ちます。max-age を足したものです >>5。includeSubDomainsincludeSubDomains
指令が指定されたかどうかです >>5。report-urireport-uri
指令が指定された場合、その値です >>5。
[12] なお report-uri で指定された URL に送信される JSON
では、 effective-expiration-date に実効満期日付を記述します。
[57] 既知ピン付きホストは、ドメイン名により識別します。 IPアドレスは使いません。 >>5
[58] 対象URLのホストが IPアドレスなら、 利用者エージェントはそのホストを既知ピン付きホストとして記録してはなりません >>5。
IP-literal または IPv4address
といっています >>5 が、実際の URL はそれ以外の構文で
IPアドレスが指定されるかもしれず、その場合でも既知ピン付きホストとするのは不適当と思われます。[28] 利用者エージェントは、ドメイン名の IDNA 正準化を行わなければなりません >>5。
[60] ドメイン名は、既知HSTSホストドメイン名一致により比較します >>5。
includeSubDomains
が使われている場合にあり得ます。) にどう処理するべきかは定かではありません。
すべてにそれぞれ Pin Validation を行う必要があるのでしょうか。[55] 既知ピン付きホストが満期であるとは、 実効満期日付が過去の日付であることをいいます >>5。
[61] 利用者エージェントは max-age 値に上限を設けても構いません。
上限を超える値が指定された場合は、上限が指定されたものとして扱って構いません。 >>5
[6] 利用者エージェントは、 PKP 仕様に基づき応答から得た既知ピン付きホストの他に、 実装組み込みなどの方法でピン付きホストの情報を得て構いません。 既知ピン付きホストと衝突する場合にどちらを優先するかは実装定義です。 >>5
[15] preload は、不正な方法で発行された証明書を使って攻撃者が PKP を利用者エージェントに与えることを防ぐために有用かもしれません >>14。
[8] 利用者エージェントは、 自己署名末端実体証明書による認証を受け入れる場合には、 そのような証明書に関するピンも認めても構いません >>5。
[18] 既知ピン付きホストの情報は fingerprinting vector となります。
[19] 利用者エージェントは既知ピン付きホストの情報を消去する仕組み >>17, >>20 や現在の状態を表示する仕組み >>20 を利用者に提供してもよいかもしれません。
report-uriを参照。