Merge pull request #488 from mozfreddyb/sha256-to-sha384

Francois Marier · Francois Marier · commit de73e7a06b92 · 2015-09-28T09:44:16.000-07:00
Rewrite instance of SHA256 to SHA384, see issue #477
diff --git a/specs/subresourceintegrity/index.html b/specs/subresourceintegrity/index.html
@@ -157,9 +157,9 @@ <h2 id="introduction">Introduction</h2>
 and the <code>fetch()</code> API with an <code>integrity</code> attribute that contains a cryptographic hash
 of the representation of the resource the author expects to load. For instance,
 an author may wish to load some framework from a shared server rather than hosting it
-on their own origin. Specifying that the <em>expected</em> SHA-256 hash of
+on their own origin. Specifying that the <em>expected</em> SHA-384 hash of
 <code>https://example.com/example-framework.js</code>
-is <code>C6CB9UYIS9UJeqinPHWTHVqh/E1uhG5Twh+Y5qFQmYg=</code> means
+is <code>Li9vy3DqF8tnTXuiaAJuML3ky+er10rcgNR/VqsVpcw+ThHmYcwiB1pbOxEbzJr7</code> means
 that the user agent can verify that the data it loads from that URL matches
 that expected hash before executing the JavaScript it contains. This
 integrity verification significantly reduces the risk that an attacker can
@@ -169,11 +169,11 @@ <h2 id="introduction">Introduction</h2>
 <code>script</code> element, like so:</p>
 
   <pre><code>&lt;script src="https://example.com/example-framework.js"
-        integrity="sha256-C6CB9UYIS9UJeqinPHWTHVqh/E1uhG5Twh+Y5qFQmYg="
+        integrity="sha384-Li9vy3DqF8tnTXuiaAJuML3ky+er10rcgNR/VqsVpcw+ThHmYcwiB1pbOxEbzJr7"
         crossorigin="anonymous"&gt;&lt;/script&gt;
 </code></pre>
 
-  <p>Scripts, of course, are not the only response type which would benefit
+  <p class="example">Scripts, of course, are not the only response type which would benefit
 from integrity validation. The scheme specified here also applies to <code>link</code>
 and future versions of the specification are likely to expand this coverage.</p>
 
@@ -214,7 +214,7 @@ <h4 id="resource-integrity">Resource Integrity</h4>
 <a href="#dfn-integrity-metadata">integrity metadata</a> is added to the <code>link</code> element included on the page:</p>
 
           <pre class="example"><code>&lt;link rel="stylesheet" href="https://site53.example.net/style.css"
-      integrity="sha256-vjnUh7+rXHH2lg/5vDY8032ftNVCIEC21vL6szrVw9M="
+      integrity="sha384-+/M6kredJcxdsqkczBUjMLvqyHb1K/JThDXWsBVxMEeZHEaMKEOEct339VItX1zB"
       crossorigin="anonymous"&gt;
 </code></pre>
         </li>
@@ -225,7 +225,7 @@ <h4 id="resource-integrity">Resource Integrity</h4>
 the script, and adds it to the <code>script</code> element:</p>
 
           <pre class="example"><code>&lt;script src="https://analytics-r-us.example.com/v1.0/include.js"
-        integrity="sha256-Rj/9XDU7F6pNSX8yBddiCIIS+XKDTtdq0//No0MH0AE="
+        integrity="sha384-MBO5IDfYaE6c6Aao94oZrIOiC6CGiSN2n4QUbHNPhzk5Xhm0djZLQqTpL0HzTUxk"
         crossorigin="anonymous"&gt;&lt;/script&gt;
 </code></pre>
         </li>
@@ -271,7 +271,7 @@ <h3 id="key-concepts-and-terminology">Key Concepts and Terminology</h3>
 is an origin whose scheme component is <code>HTTPS</code>.</p>
 
     <p>The <dfn>message body</dfn> and the <dfn>transfer encoding</dfn> of a resource
-are defined by <a href="http://tools.ietf.org/html/rfc7230#section-3">RFC7230, section 3</a>. [[!RFC7230]] </p>
+are defined by <a href="http://tools.ietf.org/html/rfc7230#section-3">RFC7230, section 3</a>. [[!RFC7230]]</p>
 
     <p>The <dfn>representation data</dfn> and <dfn>content encoding</dfn> of a resource
 are defined by <a href="http://tools.ietf.org/html/rfc7231#section-3">RFC7231, section 3</a>. [[!RFC7231]]</p>
@@ -331,19 +331,19 @@ <h3 id="integrity-metadata">Integrity metadata</h3>
 in <a href="http://www.w3.org/TR/CSP11/#source-list-syntax">section 4.2 of the Content Security Policy Level 2 specification</a>.</p>
 
     <p>For example, given a script resource containing only the string "alert('Hello, world.');",
-an author might choose <a href="#dfn-sha-2">SHA-256</a> as a hash function.
-<code>qznLcsROx4GACP2dm0UCKCzCG+HiZ1guq6ZZDob/Tng=</code> is the base64-encoded
+an author might choose [SHA-384<a href="#dfn-sha-2">sha2</a> as a hash function.
+<code>H8BRh8j48O9oYatfu5AZzq6A9RINhZO5H16dQZngK7T62em8MUt1FLm52t+eX6xO</code> is the base64-encoded
 digest that results. This can be encoded as follows:</p>
 
-    <pre class="example"><code>sha256-qznLcsROx4GACP2dm0UCKCzCG+HiZ1guq6ZZDob/Tng=
+    <pre class="example"><code>sha384-H8BRh8j48O9oYatfu5AZzq6A9RINhZO5H16dQZngK7T62em8MUt1FLm52t+eX6xO
 </code></pre>
 
     <div class="note">
       <p>Digests may be generated using any number of utilities. <a href="http://www.openssl.org/">OpenSSL</a>, for
 example, is quite commonly available. The example in this section is the
 result of the following command line:</p>
 
-      <pre><code>echo -n "alert('Hello, world.');" | openssl dgst -sha256 -binary | openssl enc -base64 -A
+      <pre><code>echo -n "alert('Hello, world.');" | openssl dgst -sha384 -binary | openssl enc -base64 -A
 </code></pre>
 
     </div>
@@ -366,14 +366,14 @@ <h4 id="agility">Agility</h4>
 For example, the resource described in the previous section may be described
 by either of the following hash expressions:</p>
 
-      <pre><code>sha256-qznLcsROx4GACP2dm0UCKCzCG+HiZ1guq6ZZDob/Tng=
+      <pre><code>sha384-dOTZf16X8p34q2/kYyEFm0jh89uTjikhnzjeLeF0FHsEaYKb1A1cv+Lyv4Hk8vHd
 sha512-Q2bFTOhEALkN8hOms2FKTDLy7eugP2zFZ1T8LCvX42Fp3WoNr3bjZSAHeOsHrbV1Fu9/A0EzCinRE7Af1ofPrw==
 </code></pre>
 
       <p>Authors may choose to specify both, for example:</p>
 
       <pre><code>&lt;script src="hello_world.js"
-   integrity="sha256-qznLcsROx4GACP2dm0UCKCzCG+HiZ1guq6ZZDob/Tng=
+   integrity="sha384-dOTZf16X8p34q2/kYyEFm0jh89uTjikhnzjeLeF0FHsEaYKb1A1cv+Lyv4Hk8vHd
               sha512-Q2bFTOhEALkN8hOms2FKTDLy7eugP2zFZ1T8LCvX42Fp3WoNr3bjZSAHeOsHrbV1Fu9/A0EzCinRE7Af1ofPrw=="
    crossorigin="anonymous"&gt;&lt;/script&gt;
 </code></pre>
@@ -446,7 +446,7 @@ <h4 id="is-response-eligible-for-integrity-validation">Is <var>response</var> el
 checks if they are same-origin or are the result of explicit access granted to
 the loading origin via CORS. [[!CORS]]</p>
 
-      <p class="note">As noted in <a href="http://tools.ietf.org/html/rfc6454#section-4">RFC6454, section 4</a>, some user agents use
+      <p class="note">As noted in <a class="note" href="http://tools.ietf.org/html/rfc6454#section-4">RFC6454, section 4</a>, some user agents use
 globally unique identifiers for each file URI. This means that
 resources accessed over a <code>file</code> scheme URL are unlikely to be
 eligible for integrity checks.</p>
@@ -563,16 +563,16 @@ <h4 id="does-response-match-metadatalist">Does <var>response</var> match <var>me
 functions. For example, a developer might write a <code>script</code> element such as:</p>
 
       <pre><code>&lt;script src="https://example.com/example-framework.js"
-        integrity="sha256-C6CB9UYIS9UJeqinPHWTHVqh/E1uhG5Twh+Y5qFQmYg=
-                   sha256-qznLcsROx4GACP2dm0UCKCzCG+HiZ1guq6ZZDob/Tng="
+        integrity="sha384-Li9vy3DqF8tnTXuiaAJuML3ky+er10rcgNR/VqsVpcw+ThHmYcwiB1pbOxEbzJr7
+                   sha384-+/M6kredJcxdsqkczBUjMLvqyHb1K/JThDXWsBVxMEeZHEaMKEOEct339VItX1zB"
         crossorigin="anonymous"&gt;&lt;/script&gt;
 </code></pre>
 
       <p>which would allow the user agent to accept two different content payloads, one
-of which matches the first SHA256 hash value and the other matches the second
-SHA256 hash value.</p>
+of which matches the first SHA384 hash value and the other matches the second
+SHA384 hash value.</p>
 
-      <p class="note">User agents may allow users to modify the result of this algorithm via user
+      <p class="example note">User agents may allow users to modify the result of this algorithm via user
 preferences, bookmarklets, third-party additions to the user agent, and other
 such mechanisms. For example, redirects generated by an extension like
 <a href="https://www.eff.org/https-everywhere">HTTPSEverywhere</a> could load and execute
@@ -754,7 +754,7 @@ <h5 id="elements">Elements</h5>
     <section>
       <h6 id="the-link-element-for-stylesheets">The <code>link</code> element for stylesheets</h6>
 
-      <p>Whenever a user agent attempts to <a href="http://www.w3.org/TR/html5/document-metadata.html#concept-link-obtain">obtain a resource</a> pointed to by a
+      <p>Whenever a user agent attempts to <a start="4" href="http://www.w3.org/TR/html5/document-metadata.html#concept-link-obtain">obtain a resource</a> pointed to by a
 <code>link</code> element that has a <code>rel</code> attribute with the keyword of <code>stylesheet</code>,
 modify step 4 to read:</p>
 
@@ -770,7 +770,7 @@ <h6 id="the-link-element-for-stylesheets">The <code>link</code> element for styl
     <section>
       <h6 id="the-script-element">The <code>script</code> element</h6>
 
-      <p>Replace step 14.1 of HTML5’s <a href="http://www.w3.org/TR/html5/scripting-1.html#prepare-a-script">“prepare a script” algorithm</a> with:</p>
+      <p>Replace step 14.1 of HTML5’s <a start="6" href="http://www.w3.org/TR/html5/scripting-1.html#prepare-a-script">“prepare a script” algorithm</a> with:</p>
 
       <ol>
         <li>Let <var>src</var> be the value of the element’s <code>src</code> attribute and
@@ -834,7 +834,7 @@ <h3 id="hash-collision-attacks">Hash collision attacks</h3>
     <p>Digests are only as strong as the hash function used to generate them. User
 agents SHOULD refuse to support known-weak hashing functions like MD5 or SHA-1,
 and SHOULD restrict supported hashing functions to those known to be
-collision-resistant. At the time of writing, SHA-256 is a good baseline.
+collision-resistant. At the time of writing, SHA-384 is a good baseline.
 Moreover, user agents SHOULD re-evaluate their supported hash functions
 on a regular basis, and deprecate support for those functions shown to be
 insecure.</p>
diff --git a/specs/subresourceintegrity/spec.markdown b/specs/subresourceintegrity/spec.markdown
@@ -33,9 +33,9 @@ This document specifies such a validation scheme, extending two HTML elements
 with an `integrity` attribute that contains a cryptographic hash
 of the representation of the resource the author expects to load. For instance,
 an author may wish to load some framework from a shared server rather than hosting it
-on their own origin. Specifying that the _expected_ SHA-256 hash of
+on their own origin. Specifying that the _expected_ SHA-384 hash of
 `https://example.com/example-framework.js`
-is `C6CB9UYIS9UJeqinPHWTHVqh/E1uhG5Twh+Y5qFQmYg=` means
+is `Li9vy3DqF8tnTXuiaAJuML3ky+er10rcgNR/VqsVpcw+ThHmYcwiB1pbOxEbzJr7` means
 that the user agent can verify that the data it loads from that URL matches
 that expected hash before executing the JavaScript it contains. This
 integrity verification significantly reduces the risk that an attacker can
@@ -45,7 +45,7 @@ This example can be communicated to a user agent by adding the hash to a
 `script` element, like so:
 
     <script src="https://example.com/example-framework.js"
-            integrity="sha256-C6CB9UYIS9UJeqinPHWTHVqh/E1uhG5Twh+Y5qFQmYg="
+            integrity="sha384-Li9vy3DqF8tnTXuiaAJuML3ky+er10rcgNR/VqsVpcw+ThHmYcwiB1pbOxEbzJr7"
             crossorigin="anonymous"></script>
 
 {:.example}
@@ -86,7 +86,7 @@ and future versions of the specification are likely to expand this coverage.
     [integrity metadata][] is added to the `link` element included on the page:
 
         <link rel="stylesheet" href="https://site53.example.net/style.css"
-              integrity="sha256-vjnUh7+rXHH2lg/5vDY8032ftNVCIEC21vL6szrVw9M="
+              integrity="sha384-+/M6kredJcxdsqkczBUjMLvqyHb1K/JThDXWsBVxMEeZHEaMKEOEct339VItX1zB"
               crossorigin="anonymous">
     {:.example}
 
@@ -96,7 +96,7 @@ and future versions of the specification are likely to expand this coverage.
     the script, and adds it to the `script` element:
 
         <script src="https://analytics-r-us.example.com/v1.0/include.js"
-                integrity="sha256-Rj/9XDU7F6pNSX8yBddiCIIS+XKDTtdq0//No0MH0AE="
+                integrity="sha384-MBO5IDfYaE6c6Aao94oZrIOiC6CGiSN2n4QUbHNPhzk5Xhm0djZLQqTpL0HzTUxk"
                 crossorigin="anonymous"></script>
     {:.example}
 
@@ -210,19 +210,19 @@ This metadata MUST be encoded in the same format as the `hash-source` (without t
 in [section 4.2 of the Content Security Policy Level 2 specification][csp2-section42].
 
 For example, given a script resource containing only the string \"alert(\'Hello, world.\');\",
-an author might choose [SHA-256][sha2] as a hash function.
-`qznLcsROx4GACP2dm0UCKCzCG+HiZ1guq6ZZDob/Tng=` is the base64-encoded
+an author might choose [SHA-384][sha2] as a hash function.
+`H8BRh8j48O9oYatfu5AZzq6A9RINhZO5H16dQZngK7T62em8MUt1FLm52t+eX6xO` is the base64-encoded
 digest that results. This can be encoded as follows:
 
-    sha256-qznLcsROx4GACP2dm0UCKCzCG+HiZ1guq6ZZDob/Tng=
+    sha384-H8BRh8j48O9oYatfu5AZzq6A9RINhZO5H16dQZngK7T62em8MUt1FLm52t+eX6xO
 {:.example}
 
 <div class="note">
 Digests may be generated using any number of utilities. [OpenSSL][], for
 example, is quite commonly available. The example in this section is the
 result of the following command line:
 
-    echo -n "alert('Hello, world.');" | openssl dgst -sha256 -binary | openssl enc -base64 -A
+    echo -n "alert('Hello, world.');" | openssl dgst -sha384 -binary | openssl enc -base64 -A
 
 [request]: https://fetch.spec.whatwg.org/#concept-request-integrity-metadata
 [csp2-section42]: http://www.w3.org/TR/CSP2/#source-list-syntax
@@ -249,13 +249,13 @@ resource in order to provide agility in the face of future cryptographic discove
 For example, the resource described in the previous section may be described
 by either of the following hash expressions:
 
-    sha256-qznLcsROx4GACP2dm0UCKCzCG+HiZ1guq6ZZDob/Tng=
+    sha384-dOTZf16X8p34q2/kYyEFm0jh89uTjikhnzjeLeF0FHsEaYKb1A1cv+Lyv4Hk8vHd
     sha512-Q2bFTOhEALkN8hOms2FKTDLy7eugP2zFZ1T8LCvX42Fp3WoNr3bjZSAHeOsHrbV1Fu9/A0EzCinRE7Af1ofPrw==
 
 Authors may choose to specify both, for example:
 
     <script src="hello_world.js"
-       integrity="sha256-qznLcsROx4GACP2dm0UCKCzCG+HiZ1guq6ZZDob/Tng=
+       integrity="sha384-dOTZf16X8p34q2/kYyEFm0jh89uTjikhnzjeLeF0FHsEaYKb1A1cv+Lyv4Hk8vHd
                   sha512-Q2bFTOhEALkN8hOms2FKTDLy7eugP2zFZ1T8LCvX42Fp3WoNr3bjZSAHeOsHrbV1Fu9/A0EzCinRE7Af1ofPrw=="
        crossorigin="anonymous"></script>
 
@@ -442,13 +442,13 @@ This algorithm allows the user agent to accept multiple, valid strong hash
 functions. For example, a developer might write a `script` element such as:
 
     <script src="https://example.com/example-framework.js"
-            integrity="sha256-C6CB9UYIS9UJeqinPHWTHVqh/E1uhG5Twh+Y5qFQmYg=
-                       sha256-qznLcsROx4GACP2dm0UCKCzCG+HiZ1guq6ZZDob/Tng="
+            integrity="sha384-Li9vy3DqF8tnTXuiaAJuML3ky+er10rcgNR/VqsVpcw+ThHmYcwiB1pbOxEbzJr7
+                       sha384-+/M6kredJcxdsqkczBUjMLvqyHb1K/JThDXWsBVxMEeZHEaMKEOEct339VItX1zB"
             crossorigin="anonymous"></script>
 
 which would allow the user agent to accept two different content payloads, one
-of which matches the first SHA256 hash value and the other matches the second
-SHA256 hash value.
+of which matches the first SHA384 hash value and the other matches the second
+SHA384 hash value.
 
 {:.example}
 
@@ -648,7 +648,7 @@ specification.
 Digests are only as strong as the hash function used to generate them. User
 agents SHOULD refuse to support known-weak hashing functions like MD5 or SHA-1,
 and SHOULD restrict supported hashing functions to those known to be
-collision-resistant. At the time of writing, SHA-256 is a good baseline.
+collision-resistant. At the time of writing, SHA-384 is a good baseline.
 Moreover, user agents SHOULD re-evaluate their supported hash functions
 on a regular basis, and deprecate support for those functions shown to be
 insecure.
