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