[4] 利用者エージェントが Pin Validation の失敗を報告するべきことと、 その報告先 URL を指定するものです >>1。
[6] URL が指定されている場合で Pin Validation に失敗した時は、 報告を指定された URL に送信するべきです >>1, >>22。 利用者エージェントは報告するよう最善の努力を尽くすべきですが、 例外的状況で報告できなくても構いません >>1。
[12] 例えば報告先が Pinning Validation その他の証明書の検証に失敗するなら、 接続を中止しなければなりません >>1。
[18] 任意の他サイトに報告を送って良いのかどうかは謎です。とはいえ同じホストに送ってもおそらく Pin Validation エラーになることは変わらないので、違うホストに送る必要があるのでしょうが...
[43] 利用者エージェントは同じ起源に制限しても構いません >>42。
[5] 利用者エージェントは、指定された URL に報告を POST
します >>1, >>22。
[7] 利用者エージェントは、指定された URL scheme が TLS を使うものなら、ホストが Known Pinned Host であるなら Pinning Validation をしなければなりません >>1。
[8] 利用者エージェントは、指定されたホストが既知HSTSホストなら、 HSTS を適用しなければなりません >>1。
[13] 報告先ホストが Pin Validation に失敗し、元のホストに報告するよう求めるようなループを検出し、報告をやめるべきです >>1。
[15] 報告失敗時には、後から再送を試みても構いません >>1。
[16] 報告送信頻度は制限するべきです >>1。 同じ報告をむやみに繰り返さないよう努力するべきです >>20。
[23] POST するデータは、次のような JSONオブジェクトです >>22。date-timehostnameporteffective-expiration-dateinclude-subdomainsincludeSubDomains 指令が指定されていたかどうかを boolean
で表したものです >>22。noted-hostnameincludeSubDomains が指定されていた時は hostname
と異なる値になるかもしれません。served-certificate-chainvalidated-certificate-chainknown-pins=、引用文字列の形にした文字列です。引用文字列は、
SPKI Fingerprint を base64 符号化したものです。 >>22
[25] 同じ名前と値の組が複数あってはなりません >>22。
[33] (広義の) HTTP の一部であるにも関わらず、HTTPの日時形式ではなく RFC 3339の日時形式が採用されています。
[27] 証明書鎖は、含まれる証明書の順序をそのまま配列内の文字列の順序とするべきと思われます。 (自明と考えられたためか、明記されていません。)
[45] 証明書鎖には、組織内で使う MITM proxy の証明書のような、 外部に晒したくない情報が含まれてしまう場合もあり、注意が必要です >>42。
[28] known-pins の各ピンの値は、 pin-*
指令と同じ構文となっています。
値は引用文字列でなければならず、字句ではいけないようです。
[29] アルゴリズムの名前は、pin-* 指令の名前と同じものとされていることから、
大文字・小文字不区別と思われますが、明記はされていません。
[30] RFC は引用文字列に " が含まれることからその JSON
文字列では \ によりエスケープするか、 '
で括るかのいずれかとしなければならないとしています。例 (>>26)
も ' を使っています。しかし、 JSON では '
で文字列を括ることは認められていませんから、本 RFC と JSON
の両方の規定を満たすためには、 ' は使えませんし、 RFC
の例は正しくありません。RFC正誤表はこれを修正しています >>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 を通すべきかどうかは不明です。
[47] Deprecate 'report-uri'. Drop 'reports'. 'report-to' is the new hotness. · w3c/webappsec-csp@90528dd ( 版) <https://github.com/w3c/webappsec-csp/commit/90528ddb877c8241208f83e752a2f4cf6829e610>
[48] 'report-to' overrides 'report-uri'. Closes #51. · w3c/webappsec-csp@ab03aef ( 版) <https://github.com/w3c/webappsec-csp/commit/ab03aef0560b244f90b310d39db04e29c3cdc29f>
[49] No CSP report-uri|frame-ancestors|sandbox in meta · whatwg/html@3947072 ( 版) <https://github.com/whatwg/html/commit/39470724136a366bab4e893efd889a513d61cc3e>
[50] Pass a base URL to the URL parser for violation reporting. (mikewest著, ) <https://github.com/w3c/webappsec-csp/commit/5e4ef7a41c44a7229db10d33659a980f04494f00>
[51] Exclude fragments from reported URLs. (mikewest著, ) <https://github.com/w3c/webappsec-csp/commit/c60db267c4f295d50652a6ca24d825059f83390e>
[52] Note that violation reports are attacker controlled. (mikewest著, ) <https://github.com/w3c/webappsec-csp/commit/6b9fdc97d9a8acfe00b62f5000d83f55ee13b5e6>