W3C home > Mailing lists > Public > public-webcrypto@w3.org > March 2014

Re: JWK import/export as ECMAScript objects, rather than ArrayBuffer

From: Richard Barnes <rlb@ipv.sx>
Date: Fri, 21 Mar 2014 22:23:41 -0400
Message-ID: <CAL02cgRs2ZzPoVQ8=qyN31zdQu4YT-xV30J9_=pawUGL2CgmAA@mail.gmail.com>
To: Ryan Sleevi <sleevi@google.com>
Cc: Mark Watson <watsonm@netflix.com>, "public-webcrypto@w3.org" <public-webcrypto@w3.org>
On Fri, Mar 21, 2014 at 4:04 PM, Ryan Sleevi <sleevi@google.com> wrote:

>
>
>
> On Fri, Mar 21, 2014 at 12:59 PM, Mark Watson <watsonm@netflix.com> wrote:
>
>>
>>
>> Sent from my iPhone
>>
>> On Mar 21, 2014, at 12:41 PM, Richard Barnes <rlb@ipv.sx> wrote:
>>
>> On Fri, Mar 21, 2014 at 1:17 PM, Mark Watson <watsonm@netflix.com> wrote:
>>
>>>
>>>
>>>
>>> On Fri, Mar 21, 2014 at 7:50 AM, Richard Barnes <rlb@ipv.sx> wrote:
>>>
>>>> On Tue, Mar 11, 2014 at 9:08 PM, Mark Watson <watsonm@netflix.com>wrote:
>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Tue, Mar 11, 2014 at 6:00 PM, Ryan Sleevi <sleevi@google.com>wrote:
>>>>>
>>>>>>
>>>>>> On Mar 11, 2014 5:44 PM, "Mark Watson" <watsonm@netflix.com> wrote:
>>>>>> >
>>>>>> > Hi Ryan,
>>>>>> >
>>>>>> > This looks good with the following comments:
>>>>>> >
>>>>>> > (1) Why not add this capability, whilst keeping the existing JWK
>>>>>> import / export ? For example add a new format "jwk-obj". This would keep
>>>>>> things simple for the other use-case where the JWK is just being written to
>>>>>> / read from a wire protocol. Supporting both is hardly arduous since UAs
>>>>>> must support the serialization / de-serialization for wrap / unwrap anyway.
>>>>>> >
>>>>>>
>>>>>> We should prioritize the common case. Dealing with ArrayBuffers for
>>>>>> JSON or JS Objects is not the common case for any other Web API.
>>>>>>
>>>>> We might disagree about which is the common case. Since we already
>>>>> have the actual JWKs (and several browsers have implemented these and they
>>>>> are being used) it seems sensible to add functionality here. There is no
>>>>> additional work to add rather than replace, so there is no need to
>>>>> prioritize.
>>>>>
>>>>
>>>> It seems abundantly silly to have two options here, when there's a
>>>> trivial conversion between them.
>>>>
>>>> Object -> json.stringify() -> TextEncoder -> ABV
>>>> ABV -> TextDecoder -> json.parse() -> Object
>>>>
>>>> Whichever one we choose here, a small JS shim can emulate the other.
>>>>  So we should really just choose one.
>>>>
>>>
>>> This is fine if you have TextEncoder. It doesn't appear on caniuse.com.
>>> Does anyone have information about browser support of this ?
>>>
>>
>> Even if you don't have TextEncoder, it's a small polyfill.  See, e.g.:
>> http://www.onicos.com/staff/iz/amuse/javascript/expert/utf.txt
>> http://polycrypt.net/common/util.js
>>
>> Object -> json.stringify() -> utf16to8() -> somethingLike_str2abv() -->
>> ABV
>>  ABV -> something_like_abv2str() -> utf8to16() -> json.parse() --> Object
>>
>>
>> How efficient is the polyfill for large messages ?
>>
>> ...Mark
>>
>>
> Define 'large messages'. 512 bytes? 40K? 80K? 2MB?
>
>
Out of curiosity, I made a little speed test and made some measurements (on
my admittedly high-end laptop).
Test: http://www.ipv.sx/transcode-test/
Results: http://goo.gl/jAowJh

TL;DR: All browsers tested could process 16KB in <=6ms and 256KB in <50ms.
 20MB took a couple of seconds.

But none of this matters, since we're talking about key packages, which are
never going to be more than ~10KB.  So performance is not an issue.

--Richard
Received on Saturday, 22 March 2014 02:24:08 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:17:22 UTC