- From: Manger, James <James.H.Manger@team.telstra.com>
- Date: Wed, 7 Jan 2015 11:51:18 +1100
- To: "public-webappsec@w3.org" <public-webappsec@w3.org>
- Message-ID: <255B9BB34FB7D647A506DC292726F6E127D6232AFF@WSMSG3153V.srv.dir.telstra.com>
The ni examples in "Subresource Integrity" (editor's draft 30-Dec-2014) are not quite right. 1. The ni:///sha-512 URI in 3.2.1 "Agility" needs to omit the "=" padding at the end of the base64url encoded value. See RFC6920 section 3 definition of "Digest Value": "The digest value MUST be encoded using the base64url [RFC4648] encoding, with no "=" padding characters." WRONG (twice) ni:///sha-512;rQw3wx1psxXzqB8TyM3nAQlK2RcluhsNwxmcqXE2YbgoDW735o8TPmIR4uWpoxUERddvFwjgRSGw7gNPCwuvJg==?ct=text/plain RIGHT ni:///sha-512;rQw3wx1psxXzqB8TyM3nAQlK2RcluhsNwxmcqXE2YbgoDW735o8TPmIR4uWpoxUERddvFwjgRSGw7gNPCwuvJg?ct=text/plain 2. The example openssl command in "Subresource Integrity" section 3.1 leaves newline characters in the output (including in the middle of the sha-512 output). Suggested change: FROM: | openssl enc -base64 | TO : | openssl base64 -A | 3. The example content is given as "Hello, world!" in the 3.1 text, but as "Hello, world." in the note (! vs .). The ni values are calculated from the "." version. Curiously (unfortunately?) it is close but slightly different from the example content in RFC6920 section 8.1: "Hello World!". -- James Manger
Received on Wednesday, 7 January 2015 00:51:49 UTC