- From: Manger, James <James.H.Manger@team.telstra.com>
- Date: Mon, 18 May 2015 13:01:50 +1000
- To: Devdatta Akhawe <dev.akhawe@gmail.com>
- CC: "public-webappsec@w3.org" <public-webappsec@w3.org>
- Message-ID: <255B9BB34FB7D647A506DC292726F6E1285C2C1E1C@WSMSG3153V.srv.dir.telstra.com>
Hi Dev, 4. Example 1 and example 2 should include a full hash, not have part elided with "...". 5. Example 1 and example 2 should have different hash values as they are for different resources. 6. I'm a little surprised to see potentially real domains in examples 1 & 2 (site53.cdn.net<http://site53.cdn.net> and analytics-r-us.com<http://analytics-r-us.com>) instead of, say "cdn.example.net<http://cdn.example.net>" and "analytics-r-us.example.com<http://analytics-r-us.example.com>". 4-5-6 all seem to be editorial nits. I am happy to consider it if others feel strongly, particularly if you or anyone else is willing to write a pull request :) Pull request for these editorial nits: https://github.com/w3c/webappsec/pull/358 “Use domains reserved for examples, complete examples, and consistent examples” 7. Section 3.1 "Integrity metadata" says the format is the same as hash-source from CSP2. This is not quite right. hash-source is defined to start and end with a single quote. Instead, refer to section 3.6 "The integrity attribute" that references hash-algo (not hash-source) from CPS2. you are right. https://github.com/w3c/webappsec/pull/356/ fixes that. hash-algo is only how to identify the algorithm ("sha256" / "sha384" / "sha512"). It doesn't give the syntax for the hash value. A better fix would be: -This metadata MUST be encoded in the same format as the hash-source -in [section 4.2 of the Content Security Policy Level 2 specification][csp2-section42]. +This metadata MUST be encoded as per `hash-with-options` in section 3.6 "The integrity attribute". 10. Options in hash-with-options at first glance look like they use the well known URI query parameter syntax (?name=value&name=value). For instance, you might expect the following to be a valid integrity value: --snip-- 11. The character restrictions on option-value look quite arbitrary. Where did the subset of 16 For this and other reasons, we have decided not to spec that part and updated it to just be VCHAR. https://github.com/w3c/webappsec/commit/a14b345e232108b8187b83fed9a43a1a81898d12 I think this resolves both #10, #11, right? Yes, resolved. Thanks again for the detailed feedback. -- James Manger
Received on Monday, 18 May 2015 03:03:00 UTC