[webcrypto] Add import of AES-KW key for NSS.

content/renderer/webcrypto/webcrypto_impl_nss.cc

Index: content/renderer/webcrypto/webcrypto_impl_nss.cc
diff --git a/content/renderer/webcrypto/webcrypto_impl_nss.cc b/content/renderer/webcrypto/webcrypto_impl_nss.cc
index 107c27b0cc135023af09961f6af002aff2a05933..1df84289b243df2018f9de3bcf4e1a7d15d523d5 100644
--- a/content/renderer/webcrypto/webcrypto_impl_nss.cc
+++ b/content/renderer/webcrypto/webcrypto_impl_nss.cc
@@ -260,6 +260,7 @@ bool ImportKeyInternalRaw(
   switch (algorithm.id()) {
     case blink::WebCryptoAlgorithmIdHmac:
     case blink::WebCryptoAlgorithmIdAesCbc:
+    case blink::WebCryptoAlgorithmIdAesKw:
       type = blink::WebCryptoKeyTypeSecret;
       break;
     // TODO(bryaneyler): Support more key types.
@@ -267,8 +268,6 @@ bool ImportKeyInternalRaw(
       return false;
   }
 
-  // TODO(bryaneyler): Need to split handling for symmetric and asymmetric keys.
-  // Currently only supporting symmetric.
   CK_MECHANISM_TYPE mechanism = CKM_INVALID_MECHANISM;
   // Flags are verified at the Blink layer; here the flags are set to all
   // possible operations for this key type.
@@ -295,6 +294,11 @@ bool ImportKeyInternalRaw(
       flags |= CKF_ENCRYPT | CKF_DECRYPT;
       break;
     }
+    case blink::WebCryptoAlgorithmIdAesKw: {
+      mechanism = CKM_NSS_AES_KEY_WRAP;

[eroman, 2013/12/18 02:10:30]

I believe this will need to specify the padding version:
  CKM_NSS_AES_KEY_WRAP_PAD

Since it will be able to wrap arbitrary length keys. This will be easier to
verify once we have implemented the wrap/unwrap operation for it.

[padolph, 2013/12/18 03:21:41]

In an earlier email thread "AES Key Wrap as a new Web Crypto algorithm in Blink"
Ryan, Mark, and I reasoned that RFC 3394 (without padding, corresponds to
CKM_NSS_AES_KEY_WRAP) is the better choice, compared to RFC 5649 (with padding).

The main reason is broader support for 3394 vs 5649; e.g. 5649 is not supported
in OpenSSL or Bouncy Castle.

Also, since we are always wrapping keys, the raw data will satisfy the length
requirements. The exception is the JWK format, but we agreed that the JSON can
be padded with whitespace before the encrypt operation.

In another CL I'm working on, I confirmed that using CKM_NSS_AES_KEY_WRAP passes
the RFC 3394 test vectors here http://www.ietf.org/rfc/rfc3394.txt (and _PAD
does not).

+      flags |= CKF_WRAP | CKF_WRAP;
+      break;
+    }
     default:
       return false;
   }