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

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

BUG=245025
TEST=content_unittests --gtest_filter="WebCryptoImpl*"

Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=241504

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

https://codereview.chromium.org/117013002/diff/10001/content/renderer/webcryp...
File content/renderer/webcrypto/webcrypto_impl_nss.cc (right):

https://codereview.chromium.org/117013002/diff/10001/content/renderer/webcryp...
content/renderer/webcrypto/webcrypto_impl_nss.cc:298: mechanism =
CKM_NSS_AES_KEY_WRAP;
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.

https://codereview.chromium.org/117013002/diff/10001/content/renderer/webcryp...
File content/renderer/webcrypto/webcrypto_impl_unittest.cc (right):

https://codereview.chromium.org/117013002/diff/10001/content/renderer/webcryp...
content/renderer/webcrypto/webcrypto_impl_unittest.cc:1625: 
Can you delete this extra line?

[eroman, 2013-12-18 02:10:45]

(LGTM after addressing comments above)

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

https://codereview.chromium.org/117013002/diff/10001/content/renderer/webcryp...
File content/renderer/webcrypto/webcrypto_impl_nss.cc (right):

https://codereview.chromium.org/117013002/diff/10001/content/renderer/webcryp...
content/renderer/webcrypto/webcrypto_impl_nss.cc:298: mechanism =
CKM_NSS_AES_KEY_WRAP;
On 2013/12/18 02:10:30, eroman wrote:
> 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.

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).

https://codereview.chromium.org/117013002/diff/10001/content/renderer/webcryp...
File content/renderer/webcrypto/webcrypto_impl_unittest.cc (right):

https://codereview.chromium.org/117013002/diff/10001/content/renderer/webcryp...
content/renderer/webcrypto/webcrypto_impl_unittest.cc:1625: 
On 2013/12/18 02:10:30, eroman wrote:
> Can you delete this extra line?

Done.

[padolph, 2013-12-18 03:22:21]

(manual email)


0 minutes ago #4
https://codereview.chromium.org/117013002/diff/10001/content/renderer/webcryp...
File content/renderer/webcrypto/webcrypto_impl_nss.cc (right):

https://codereview.chromium.org/117013002/diff/10001/content/renderer/webcryp...
content/renderer/webcrypto/webcrypto_impl_nss.cc:298: mechanism =
CKM_NSS_AES_KEY_WRAP;
On 2013/12/18 02:10:30, eroman wrote:
> 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.

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).

https://codereview.chromium.org/117013002/diff/10001/content/renderer/webcryp...
File content/renderer/webcrypto/webcrypto_impl_unittest.cc (right):

https://codereview.chromium.org/117013002/diff/10001/content/renderer/webcryp...
content/renderer/webcrypto/webcrypto_impl_unittest.cc:1625:
On 2013/12/18 02:10:30, eroman wrote:
> Can you delete this extra line?

Done.


On Tue, Dec 17, 2013 at 6:10 PM,  <eroman@chromium.org> wrote:
> (LGTM after addressing comments above)
>
> https://codereview.chromium.org/117013002/

To unsubscribe from this group and stop receiving emails from it, send an email
to chromium-reviews+unsubscribe@chromium.org.

[commit-bot: I haz the power, 2013-12-18 03:26:02]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/padolph@netflix.com/117013002/30001

[eroman, 2013-12-18 03:28:43]

Thanks Paul, my mistake!

(I was looking at an old post:

http://lists.w3.org/Archives/Public/public-webcrypto/2012Oct/0142.html

Which mentioned RFC5649 padding.

I see however that Mark has recently added AES-KW to the Web Crypto spec proper,
and this mentions solely rfc3394.)

[commit-bot: I haz the power, 2013-12-18 05:52:41]

Change committed as 241504

[Ryan Sleevi, 2013-12-18 23:23:46]

On 2013/12/18 03:22:21, padolph wrote:
> (manual email)
> 
> 
> 0 minutes ago #4
>
https://codereview.chromium.org/117013002/diff/10001/content/renderer/webcryp...
> File content/renderer/webcrypto/webcrypto_impl_nss.cc (right):
> 
>
https://codereview.chromium.org/117013002/diff/10001/content/renderer/webcryp...
> content/renderer/webcrypto/webcrypto_impl_nss.cc:298: mechanism =
> CKM_NSS_AES_KEY_WRAP;
> On 2013/12/18 02:10:30, eroman wrote:
> > 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.
> 
> 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.

woah woah woah, totally not. Inventing arbitrary padding schemes = no way.

If that's a view shared with Mark, we need to get this on the W3C list so it can
be discussed and shot down as appropriate :)

> 
> 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).
> 
>
https://codereview.chromium.org/117013002/diff/10001/content/renderer/webcryp...
> File content/renderer/webcrypto/webcrypto_impl_unittest.cc (right):
> 
>
https://codereview.chromium.org/117013002/diff/10001/content/renderer/webcryp...
> content/renderer/webcrypto/webcrypto_impl_unittest.cc:1625:
> On 2013/12/18 02:10:30, eroman wrote:
> > Can you delete this extra line?
> 
> Done.
> 
> 
> On Tue, Dec 17, 2013 at 6:10 PM,  <mailto:eroman@chromium.org> wrote:
> > (LGTM after addressing comments above)
> >
> > https://codereview.chromium.org/117013002/
> 
> To unsubscribe from this group and stop receiving emails from it, send an
email
> to mailto:chromium-reviews+unsubscribe@chromium.org.