- From: Jarred Nicholls <jarred@webkit.org>
- Date: Thu, 10 May 2012 10:21:05 -0400
- To: Cullen Jennings <fluffy@cisco.com>
- Cc: Nadim <nadim@nadim.cc>, public-webcrypto@w3.org
- Message-ID: <CANufG2O+jwPg1MyVdkjjoxY9XFda9S=pzH5aw8R7y-7kSXExJA@mail.gmail.com>
On Thu, May 10, 2012 at 9:42 AM, Cullen Jennings <fluffy@cisco.com> wrote: > > One way to deal with the ECC / RSA issues is instead provide the > underlining big math libraries that are needed to implement these and leave > the actually IPR encumbered implementation to an JS library. If done right, > this would could have approximately the same performance as a native > implementation. > Key management, protection and sandboxing is a major concern when you leave most-to-all of the implementation in the JS context. This is a nice thought, but impractical from a security standpoint. It also goes against the goal of having an easy-to-use and ready-to-go API for symmetric, asymmetric, and hash/sign operations. Jarred > > > On May 9, 2012, at 11:33 AM, Nadim wrote: > > > Hi everyone, > > I think we need to have a discussion regarding whether the API will > exclusively implement (and rely on) newer, faster standards (such as ECDH, > ECDSA) or whether there will be a larger dependence on RSA, either for > fallback or stronger compatibility reasons. > > > > If it is eventually decided that not only the best available per-task > algorithm is implemented, but rather, all possible algorithms, where do we > draw the line? Do we implement SHA1 in addition to SHA2? Does that also > warrant an MD5 implementation? > > > > Personally, I believe that focusing only on the newer, more efficient > standards (such as ECC) is a better idea, but I stand very humbly by my > opinion and a much more interested in listening to the group's opinions. > > > > Thank you, > > NK > > >
Received on Thursday, 10 May 2012 14:22:01 UTC