Moved some editoral issues that implied work to bugzilla
authorHarry Halpin <hhalpin@w3.org>
Sun, 30 Nov 2014 23:06:31 +0100
changeset 297 2316fdae19b6
parent 296 3a3c76f675a6
child 298 d82b6dc4ca6c
Moved some editoral issues that implied work to bugzilla
spec/Overview-WebCryptoAPI.xml
--- a/spec/Overview-WebCryptoAPI.xml	Sun Nov 30 23:03:57 2014 +0100
+++ b/spec/Overview-WebCryptoAPI.xml	Sun Nov 30 23:06:31 2014 +0100
@@ -1,4 +1,4 @@
-<?xml version='1.0'?>
+h<?xml version='1.0'?>
 
 <!--
 Overview.xml
@@ -1306,18 +1306,6 @@
                          sequence&lt;<a href="#dfn-KeyUsage">KeyUsage</a>&gt; keyUsages );
 };
         </x:codeblock>
-        <div class="ednote">
-          <ul>
-            <li>
-              <a href="https://www.w3.org/2012/webcrypto/track/issues/35">ISSUE-35</a>:
-              The specification for wrapKey/unwrapKey does not specify how authors that do not trust
-              the execution environment may indicate required attributes for keys that are
-              unwrapped. An example is unwrapping a key with a non-extractable key, marking
-              the newly unwrapped key as non extractable, and then further indicating that all
-              keys unwrapped with the newly unwrapped key are also non-extractable.
-            </li>
-          </ul>
-        </div>
         <div id="subtlecrypto-interface-description" class="section">
           <h3>Description</h3>
           <p class="norm">This section is non-normative.</p>
@@ -3762,12 +3750,7 @@
   required <a href="#dfn-HashAlgorithmIdentifier">HashAlgorithmIdentifier</a> <dfn id="dfn-RsaHashedImportParams-hash">hash</dfn>;
 };
           </x:codeblock>
-          <div class="ednote">
-            <p>
-              Should this be folded into RsaHashedKeyGenParams and rely on the optional nature of the
-              dictionary fields?
-            </p>
-          </div>
+         
         </div>
         <div id="rsassa-pkcs1-operations" class="section">
           <h4>Operations</h4>
@@ -4007,12 +3990,6 @@
                   </p>
                 </li>
               </ol>
-              <div class="ednote">
-                <p>
-                  TODO: Specify the mapping between key.algorithm.hash and the appropriate Hash
-                  functions (and back to OID).
-                </p>
-              </div>
             </dd>
 
             <dt>Import Key</dt>
@@ -16848,17 +16825,6 @@
 required BufferSource <dfn id="dfn-HkdfCtrParams-context">context</dfn>;
 };
           </x:codeblock>
-          <div class="ednote">
-            <p>
-              The definition of HKDF allows the caller to supply an optional pseudorandom salt
-              value, which is used as the key during the extract phase. If this value is not
-              supplied, an all zero string is used instead. However, support for an explicit
-              salt value is not widely implemented in existing APIs, nor is it required by
-              existing usages of HKDF. Should this be an optional parameter, and if so, what
-              should the behavior be of a user agent that does not support explicit salt
-              values (is it conforming or non-conforming?)
-            </p>
-          </div>
         </div>
         <div id="hkdf2-ctr-operations" class="section">
           <h4>Operations</h4>
@@ -18383,20 +18349,6 @@
               </tr>
             </tbody>
           </table>
-          <div class="ednote">
-            <p>Should the following be specified.</p>
-            <ul>
-              <li><p>RSASSA-PKCS1-v1_5 with SHA-1</p></li>
-              <li><p>RSA-PSS with SHA-1</p></li>
-              <li><p>ECDSA with SHA-1</p></li>
-              <li>
-                <p>
-                  ECDSA where the curve (P-256, P-384, P-521) is not aligned with the hash (SHA-256,
-                  SHA-384, SHA-512)
-                </p>
-              </li>
-            </ul>
-          </div>
         </div>
         <div id="jwk-mapping-usage" class="section">
           <h3>Usage mapping</h3>