- From: Eric Roman <ericroman@google.com>
- Date: Wed, 3 Aug 2016 09:55:28 -0700
- To: "Waitzman, David (Contractor)" <David_Waitzman@comcast.com>
- Cc: "public-webcrypto@w3.org" <public-webcrypto@w3.org>
- Message-ID: <CAFswn4k7eAxvNbpdQvVoOz47WvjtakSRP7SHUOiqq9mp9p4Duw@mail.gmail.com>
I am not sure that I parsed your question or motivation correctly; will try to answer it two different ways: (a) If your environment doesn't have Promises, then necessarily your environment does not provide a native implementation of Web Crypto either (certainly not the version in the latest draft). In that case you would need to provide Web Crypto as a polyfill too, and so the question really is: "are there security risks to using Web Crypto polyfill XXX rather than built in platform support?" Yes -- It depends on your polyfill, but assuming a Javascript-side implementation you should consider: * Implementation quality of the polyfill (is it a mature library that properly implements cryptographic primitives) * Does your security model require unextractable keys (a Javascript polyfill almost surely cannot provide this; there are also subtle challenges like not revealing keying material due to non-constant timing of operations, for which all bets are off in a JS runtime environment). (b) If on the other hand your question is specifically about whether ECMAScript 6 provides important security features needed for Web Crypto, then the answer is No. The use of Promises for instance does not provide any security benefits. In fact earlier versions of the spec did not use Promises. On Tue, Aug 2, 2016 at 6:50 PM, Waitzman, David (Contractor) < David_Waitzman@comcast.com> wrote: > I want to use WebCrypto, Encrypted Media Extensions, and Media Source > Extensions in a context where only ECMAScript 5.1 is required. So I need > to at least use a polyfill for Promise, as it is an ECMAScript 6 feature. > Any other polyfills that I would need? Would any of those polyfill(s) > somehow introduce a security risk that would not be present if ECMAScript 6 > was instead used? > > Thanks, > -- > David Waitzman > Envieta Systems LLC > >
Received on Wednesday, 3 August 2016 16:55:58 UTC