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: Thu, 27 Mar 2014 13:42:10 -0400
Message-ID: <CAL02cgTEZAeMtriVRzi7ThE+pgzCpMV8+N1vWeP+L6rR5DyYZA@mail.gmail.com>
To: Mark Watson <watsonm@netflix.com>
Cc: Ryan Sleevi <sleevi@google.com>, "public-webcrypto@w3.org" <public-webcrypto@w3.org>
On Thu, Mar 27, 2014 at 12:08 PM, Mark Watson <watsonm@netflix.com> wrote:

>
>
> Sent from my iPhone
>
> On Mar 27, 2014, at 3:20 PM, Richard Barnes <rlb@ipv.sx> wrote:
>
>
>
>
> On Thu, Mar 27, 2014 at 11:10 AM, Mark Watson <watsonm@netflix.com> wrote:
>
>>
>>
>> Sent from my iPhone
>>
>> On Mar 27, 2014, at 1:50 PM, Ryan Sleevi <sleevi@google.com> wrote:
>>
>>
>> On Mar 27, 2014 3:07 AM, "Mark Watson" <watsonm@netflix.com> wrote:
>> >
>> >
>> >
>> > Sent from my iPhone
>> >
>> > On Mar 27, 2014, at 1:19 AM, Ryan Sleevi <sleevi@google.com> wrote:
>> >
>> >>
>> >>
>> >>
>> >> On Fri, Mar 21, 2014 at 7:23 PM, Richard Barnes <rlb@ipv.sx> wrote:
>> >>>
>> >>> 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
>> >>>
>> >>
>> >> Note, recently this issue was brought to the attention of the W3C TAG
>> and there has been some discussion about this at
>> http://lists.w3.org/Archives/Public/www-tag/2014Mar/0026.html
>> >>
>> >> There is still a lot of confusion about the use cases for the
>> ArrayBuffer case, so hopefully Mark can provide the use case / sample code
>> to demonstrate the pattern.
>> >>
>> >> Otherwise, it does seem like there is a general sentiment towards
>> using 'proper' JavaScript objects, especially in light of the general uses
>> of JWK.
>> >>
>> >> I'd like to make some degree of progress on this so we can close it
>> out.
>> >
>> >
>> > As I mentioned before, if support for TextEncoding is widespread or
>> expected to be soon, then (as Richard says) there is no advantage in
>> supporting both options, since conversion is trivial and efficient.
>> >
>> > In that case, I do not have an opinion on which option we should
>> support (because conversion is trivial and efficient).
>> >
>> > So, what is the status of TextEncoding ?
>> >
>> > ...Mark
>>
>> Mark,
>>
>> Conversion is still trivial and efficient - for _your_ use case, without
>> Encoding support.
>>
>> Put simply: Can you agree to live with this without that support, or will
>> you raise a formal objection? If so, the WG *needs* to know why and how to
>> resolve this.
>>
>> Holding this spec 'hostage' for Encoding support is not a viable path.
>>
>> This is certainly not an issue worthy of a formal objection and I've no
>> intention of holding the spec hostage.
>>
>> I would like to know about the status of TextEncoding. Is it something
>> that all browsers are considering implementing or is it something about
>> which there is controversy? It's not listed on caniuse, which usually
>> covers most mainstream stuff.
>>
>> I don't think it's necessary to have TextEncoding supported by browsers
>> in the same timeframe as WebCrypto to go with the object approach, but I
>> would feel more comfortable with the object approach if it was known that
>> TextEncoding was at least 'coming soon to a browser near you.'
>>
>
> I'm confused as to why TextEncoding is still an issue here.  I though I
> had posted some links to polyfills up-thread, and provided some data on
> their efficiency.  Re-encoding strings from UTF-16 to UTF-8 is really not
> hard.
>
>
> I think if you read my mail carefully it says it is not an issue, but I
> would still like to know when / if TextEncoding is likely to be supported
> by browsers.
>

Ok, got it.  FWIW, TextEncoder has been in Firefox for some time.

--Richard




>
> ...Mark
>
>
> --Richard
>
>
>
>
>>
>> ...Mark
>>
>
>
Received on Thursday, 27 March 2014 17:42:38 UTC

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