処理

[6] URL が指定されている場合で Pin Validation に失敗した時は、報告を指定された URL に送信するべきです >>1, >>22。利用者エージェントは報告するよう最善の努力を尽くすべきですが、例外的状況で報告できなくても構いません >>1。

[12] 例えば報告先が Pinning Validation その他の証明書の検証に失敗するなら、接続を中止しなければなりません >>1。

[34]

PKP の処理の項も参照。

[18] 任意の他サイトに報告を送って良いのかどうかは謎です。とはいえ同じホストに送ってもおそらく Pin Validation エラーになることは変わらないので、違うホストに送る必要があるのでしょうが...

[19]

DDoS に使えそうですが、 img や script で他のホストに要求を送らせること自体は既にできるので、新たな脅威ではなさそうです。

[39] ただし CORS なしで JSON を異なる起源に POST できるのは初めてと思われます。これを想定していない Webアプリケーションはあるかもしれません。

[43] 利用者エージェントは同じ起源に制限しても構いません >>42。

[44]

PKP-RO の場合は良いとして、 PKP の場合はほぼ確実に送れなくなりますが...

[5] 利用者エージェントは、指定された URL に報告を POST します >>1, >>22。

[24]

RFC では、「POST」と書かれているだけで、その意味はなぜか明記されていません。要求メソッド POST により送信することを意味すると推測されます。

[7] 利用者エージェントは、指定された URL scheme が TLS を使うものなら、ホストが Known Pinned Host であるなら Pinning Validation をしなければなりません >>1。

[8] 利用者エージェントは、指定されたホストが既知HSTSホストなら、 HSTS を適用しなければなりません >>1。

[9]

リダイレクトをどう処理するべきかは不明です。

[10] 趣旨からすると HSTS 適用後に TLS を使うなら Pin Validation を行うべきと思われます (が仕様書にはそうは書いていません)。

[13] 報告先ホストが Pin Validation に失敗し、元のホストに報告するよう求めるようなループを検出し、報告をやめるべきです >>1。

[14] なぜこれが MUST でなくて SHOULD なのかは謎です。無限ループに陥る実装が正当である理由など無いと思うのですが...

[15] 報告失敗時には、後から再送を試みても構いません >>1。

[16] 報告送信頻度は制限するべきです >>1。同じ報告をむやみに繰り返さないよう努力するべきです >>20。

[17] 例えば同じ組の Pin に関して同じ URL に同じ報告を何度も送る必要はありません >>1。

[21]

PKP-RO は当該応答の処理後は検証のために情報を保持しないことになってはいますが、報告の重複チェックのために保持することは禁止されていない (むしろ求められている) ようです。

[23] POST するデータは、次のような JSONオブジェクトです >>22。

JSONオブジェクト

date-time: Pin Validation に失敗した時刻を、 RFC 3339の日時形式で表したものです >>22。
hostname: Pin Validation に失敗した要求のホスト名を表す文字列です >>22。
port: Pin Validation に失敗した要求のポートを表す整数です >>22。
effective-expiration-date: ピンの実効満期日付を、 RFC 3339の日時形式で表したものです >>22。
include-subdomains: includeSubDomains 指令が指定されていたかどうかを boolean で表したものです >>22。
noted-hostname: 既知ピン付きホストとして記録された時のホスト名です >>22。 includeSubDomains が指定されていた時は hostname と異なる値になるかもしれません。
served-certificate-chain: TLSセッションの設定の時点でサーバーから提供された証明書鎖を、各 X.509証明書の .pem 形式の文字列の配列としたものです >>22。
validated-certificate-chain: 証明書鎖の検証verificationの過程で利用者エージェントが構築した証明書鎖を、各 X.509証明書の .pem 形式の文字列の配列としたものです >>22。検証の過程で複数組の証明書鎖を構築した場合は、最後のものとするべきです >>22。
known-pins: 既知ピン付きホストに関して記録されているピンの配列です。各ピンは、ハッシュアルゴリズム名、 =、引用文字列の形にした文字列です。引用文字列は、 SPKI Fingerprint を base64 符号化したものです。 >>22

[25] 同じ名前と値の組が複数あってはなりません >>22。

[33] (広義の) HTTP の一部であるにも関わらず、HTTPの日時形式ではなく RFC 3339の日時形式が採用されています。

JSON ではしばしば RFC 3339の日時形式等 ISO 8601の日時形式のバリエーションが使われるためでしょうか。

[27] 証明書鎖は、含まれる証明書の順序をそのまま配列内の文字列の順序とするべきと思われます。 (自明と考えられたためか、明記されていません。)

[45] 証明書鎖には、組織内で使う MITM proxy の証明書のような、外部に晒したくない情報が含まれてしまう場合もあり、注意が必要です >>42。

[46] どう対処するべきなのかは不明です。

[28] known-pins の各ピンの値は、 pin-* 指令と同じ構文となっています。値は引用文字列でなければならず、字句ではいけないようです。

[29] アルゴリズムの名前は、pin-* 指令の名前と同じものとされていることから、大文字・小文字不区別と思われますが、明記はされていません。

[30] RFC は引用文字列に " が含まれることからその JSON 文字列では \ によりエスケープするか、 ' で括るかのいずれかとしなければならないとしています。例 (>>26) も ' を使っています。しかし、 JSON では ' で文字列を括ることは認められていませんから、本 RFC と JSON の両方の規定を満たすためには、 ' は使えませんし、 RFC の例は正しくありません。RFC正誤表はこれを修正しています >>31。

[32] 本 RFC は提案標準であり、IESG の承認を含め多くの人の目を経て出版されているはずですが、このような初歩的かつ致命的な誤りが含まれたまま RFC として出版されるとは、 IETF の手続きは何とも杜撰なもののようです。

[26] 例えば次のようにします >>22, >>31。

  {
    "date-time": "2014-04-06T13:00:50Z",
    "hostname": "www.example.com",
    "port": 443,
    "effective-expiration-date": "2014-05-01T12:40:50Z"
    "include-subdomains": false,
    "served-certificate-chain": [
      "-----BEGIN CERTIFICATE-----\nMIIEBDCC...kVDNx\n-----END CERTIFICATE-----",
      ...
    ],
    "validated-certificate-chain": [
      "-----BEGIN CERTIFICATE-----\nMIIEBDCI...kVDNx\n-----END CERTIFICATE-----",
      ...
    ],
    "known-pins": [
      "pin-sha256=\"d6qzRu9zOECb90Uez27xWltNsj0e1Md7GkYYkVoZWmM=\"",
      "pin-sha256=\"E9CZ9INDbd+2eRQozYqqbQ2yXLVKB9+xcprMF+44U1g=\""
    ]
  }

[38] 報告は JSON なので、 MIME型 (Content-Type: ヘッダー) を application/json としなければならないものと推測されますが、 RFC には明記されていません。

[40] Referer:, Origin:, Cookie:, Accept-Language: その他のヘッダーをどう扱うべきかは不明です。

[41] Service Worker を通すべきかどうかは不明です。

仕様書

意味

構文

文脈

処理

メモ