[webcrypto] Require importKey() for JWK to provide data as a Javascript object rather than a JSON a…

[webcrypto] Require importKey() for JWK to provide data as a Javascript object rather than a JSON arraybuffer.

BUG=373917, 245025
Committed: https://src.chromium.org/viewvc/blink?view=rev&revision=176238

[abarth-chromium, 2014-06-16 06:07:46]

That's kind of bizarre, but ok.  LGTM

[eroman, 2014-06-16 15:59:53]

Do you find the implementation bizarre, or the API change?

(I am trying to get this change in because it is coming to next API draft, and
don't want to break compatibility once shipping webcrypto).

[abarth-chromium, 2014-06-16 16:49:37]

On 2014/06/16 at 15:59:53, eroman wrote:
> Do you find the implementation bizarre, or the API change?

Sorry, I shouldn't have been so vague.  It's strange that we take this nice
structured Dictionary object and flatten it to a UTF-8 encoded JSON structure in
order to call through blink::Platform.  Normally we pass structured objects
across the blink::Platform boundary.

This CL is totally fine.  It's just that the code we've ended up with reflects
the history of how we got here.  :)

[eroman, 2014-06-16 17:19:35]

Thanks for the feedback!

I am eager to improve the design. Some of the other solutions I considered were:

(1) Pass a WebCryptoJwkDictionary object across the blink API, which is
structured and already contains a copy of the extracted properties (n, e, d, p,
dq, dq, qi, etc...)

(2) Same as option (1), but rather than copying the properties from the
dictionary, make WebCryptoJwkDictionary be a wrapper that has methods like
"getStringProperty()", "getBooleanProperty()" so the reading of properties is
controlled by platform layer.

Unfortunately both of these strategies have the problem that unwrapKey() using
format='JWK' still has to operate on a raw JSON buffer (it is passed an
encrypted JSON buffer).

Therefore code in the platform layer must still be able to handle importing keys
from pure JSON. Given that the handling of JSON inputs cannot be removed, using
a structured input for importKey()'s platform implementation here means not only
the extra effort of defining a new blink:: interface, but then also adding extra
codepaths on the platform implementation to read from it.

Design (2) generalizes things by letting the platform side extract what it needs
(rather than having Blink know what properties a JWK has). The chromium platform
implementation of WebCrypto is multithreaded. It posts a task to a crypto thread
to perform the import key. So if using design (2) it would end up having to read
all the JWK properties up front (since reading from Dictionary should only be
done from Blink thread) and make a copy anyway. So no real benefit in design (2)
over design (1).

Weighing these options, I don't think designs (1) or (2) are worthwile. But I
will keep thinking about the problem.

[eroman, 2014-06-16 18:03:53]

The CQ bit was checked by eroman@chromium.org

[commit-bot: I haz the power, 2014-06-16 18:04:05]

CQ is trying da patch. Follow status at
 https://chromium-status.appspot.com/cq/eroman@chromium.org/336173002/20001

[commit-bot: I haz the power, 2014-06-16 20:26:41]

Change committed as 176238

[abarth-chromium, 2014-06-16 22:44:14]

On 2014/06/16 at 17:19:35, eroman wrote:
> Unfortunately both of these strategies have the problem that unwrapKey() using
format='JWK' still has to operate on a raw JSON buffer (it is passed an
encrypted JSON buffer).

Ah, that makes sense.  I didn't realize JSON was baked in that deep.