- From: Richard L. Barnes <rbarnes@bbn.com>
- Date: Thu, 10 May 2012 10:18:44 -0400
- To: Cullen Jennings <fluffy@cisco.com>
- Cc: Nadim <nadim@nadim.cc>, public-webcrypto@w3.org
Note, however, that that approach would require that private keys be exposed to the JS layer. It seems like we have at least some use cases (e.g., the Netflix cases) where maintaining the secrecy of the private key is important. --Richard On May 10, 2012, at 9:42 AM, Cullen Jennings 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. > > > 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:19:18 UTC