[1] HSTS や PKP の includeSubDomains 指令は、
当該 HSTSポリシー/Pinning Policyがサブドメインをも含めて適用されることを表します。
[5] HSTS でこの指令があれば、HSTSポリシーがHSTSホストとそのドメインのサブドメインの両方に適用されることを表します >>2。
[6] HSTS でこの指令がなければ、HSTSポリシーはHSTSホストのみに適用されます。
[14] PKP でこの指令があれば、Pinning Policy が当該ホストとそのドメインのサブドメインの両方に適用されることを表します >>13。
[18] サブドメインに当たるドメインが異なる PKP を指定している場合に
includeSubDomains を使うと、クライアントが接続する順序によって動作が異なってくる場合があります。
例えば hoge.example.com の PKP と example.com の
includeSubDomains 付き PKP で異なるピンが指定されていると、
example.com に先に接続すると後から hoge.example.com
に接続できないかもしれません。 >>16
[15] report-uri で指定された URL に送信される JSON
では、 include-subdomains に本指令が指定されていたかどうかを記述します。
[9] STS は当該ホストかそのサブドメインかに適用するHSTSポリシーしか記述できませんから、
Set-Cookie: で Domain=com のような指定ができてしまうような問題は生じません。
[12] でも TLD の管理者が HSTS を有効にできたりしますが、いいのでしょうかね。 Public Suffix List の階層では指定できないべきな気がしますが。
[10] IRC logs: freenode / #whatwg / 20140907 ( ( 版)) <http://krijnhoetmer.nl/irc-logs/whatwg/20140907#l-237>
[11] IRC logs: freenode / #whatwg / 20140916 ( ( 版)) <http://krijnhoetmer.nl/irc-logs/whatwg/20140916>
[19] Strict Transport Security - IEInternals - Site Home - MSDN Blogs ( 版) <http://blogs.msdn.com/b/ieinternals/archive/2014/08/18/hsts-strict-transport-security-attacks-mitigations-deployment-https.aspx>
One exciting possibility is that some of the many new Top-Level-Domains may opt-in for their entire TLD tree, such that every single site under that domain (e.g. anexample1.secure, otherexample2.secure, etc) are all automatically protected.
[20] Drop 'includeSubdomains'. · w3c/webappsec-clear-site-data@19b9eb1 ( 版) <https://github.com/w3c/webappsec-clear-site-data/commit/19b9eb195433b87458f65e31523bb37c48cda649>
report-uriを参照。