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

content/child/webcrypto/openssl/util_openssl.cc

 // Copyright 2014 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
 #include "content/child/webcrypto/openssl/util_openssl.h"
 
 #include <openssl/evp.h>
 #include <openssl/pkcs12.h>
 
 #include "base/stl_util.h"
@@ skipping 162 matching lines @@
   // Serialize the key at creation time so that if structured cloning is
   // requested it can be done synchronously from the Blink thread.
   std::vector<uint8_t> pkcs8_data;
   Status status = ExportPKeyPkcs8(private_key.get(), &pkcs8_data);
   if (status.IsError())
     return status;
 
   *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();
 }
 
 Status ImportUnverifiedPkeyFromSpki(const CryptoData& key_data,
                                     int expected_pkey_id,
                                     crypto::ScopedEVP_PKEY* pkey) {
   if (!key_data.byte_length())
     return Status::ErrorImportEmptyKeyData();
 
   crypto::OpenSSLErrStackTracer err_tracer(FROM_HERE);
@@ skipping 39 matching lines @@
 
 std::vector<uint8_t> BIGNUMToVector(const BIGNUM* n) {
   std::vector<uint8_t> v(BN_num_bytes(n));
   BN_bn2bin(n, vector_as_array(&v));
   return v;
 }
 
 }  // namespace webcrypto
 
 }  // namespace content