Check that usage isn't empty when generateKey() is called

content/child/webcrypto/openssl/util_openssl.cc

Index: content/child/webcrypto/openssl/util_openssl.cc
diff --git a/content/child/webcrypto/openssl/util_openssl.cc b/content/child/webcrypto/openssl/util_openssl.cc
index 665e1525ff1f267dd024eb8cb4669e840ff1bf01..06a5876d96f6a82354e51fb808818652b69146a8 100644
--- a/content/child/webcrypto/openssl/util_openssl.cc
+++ b/content/child/webcrypto/openssl/util_openssl.cc
@@ -180,6 +180,9 @@ Status CreateWebCryptoPrivateKey(crypto::ScopedEVP_PKEY private_key,
   *key = blink::WebCryptoKey::create(
       new AsymKeyOpenSsl(private_key.Pass(), CryptoData(pkcs8_data)),
       blink::WebCryptoKeyTypePrivate, extractable, algorithm, usages);
+  if (key->usages() == 0) {

[eroman, 2014/11/20 23:40:10]

This test is not possible, as it will prevent import of keys with empty usages.
There is a separate bug to handle import (which is more involved because of
javascript's structured cloning).

[nharper, 2014/11/21 22:12:01]

Is it an issue that this affects behavior of key import as well? My
understanding of the spec is that importKey also must throw a SyntaxError if the
usages of the secret or private key is empty.

[eroman, 2014/11/21 22:55:47]

Correct, importKey() must also throw a SyntaxError. The issue is that structured
cloning relies internally on the ImportKey*() methods, and there may exist
serialized CryptoKeys which have empty usages.

In more detail:

  (1) Structured cloning is a mechanism to serialize Javascript objects (in this
case  CryptoKey). This serialized form can be persisted into databases
(IndexedDB). Because CryptoKeys aren't vanilla Javascript objects (and in fact
they hide the key content from javascript) they implement their own structured
cloning/decloning. Search for "deserializeKeyForClone" for more information.

  (2) Because existing keys may have already been generated/imported with empty
usages, and because those keys may have already been persisted to IndexedDB, and
because we don't want to break deserializing such keys, we need to be prepared
to deal with it.

  ***(3)*** De-serializing structured-cloned keys is currently implemented using
ImportKey*(). You can see this by searching for "::DeserializeKeyForClone".
Hence some more surgery will be required before creating keys with empty usages
can be blocked.


The LayoutTests currently test serializing/deserializing keys with empty usages
(LayoutTests/crypto/clone-*.html). These will need to be refactored to just test
de-serialization of keys with empty usages since it will no longer be possible
to import them once the other bug is addressed.

Hope that helps to clarify!

+    return Status::ErrorCreateKeyBadUsages();
+  }
   return Status::Success();
 }