On 02/28/2011 08:20 AM, Jean-Marc Desperrier wrote: > For context, from a message I wrote in last October : >> Given the number of protocols that include SRP (SSL/TLS, EAP, SAML), >> given that there's already a proposed patch for NSS (bug 405155, bug >> 356855), a proposed patch for openssl ( >> http://rt.openssl.org/Ticket/Display.html?id=1794&user=guest&pass=guest >> ), I still think SRP is the better choice since the effort to implement >> it would be much more widely useful than with J-PAKE. >> >> On the long term, I wouldn't be surprised if at some point you'll add >> another scenario where augmented security would be useful, and you will >> in all likehood stay the only users of J-PAKE, I believe SRP will >> certainly end up being included, and it will be a little stupid to have >> 2 functionally equivalent algorithms. > > So the end result : I see that J-PAKE code got included inside NSS > https://bugzilla.mozilla.org/show_bug.cgi?id=609076 with a layer to > access it from js (bug 601645). This was not announced here, and even > if it looked like Sync Would keep J-PAKE, I did not imagine it would > be included as a new mechanism in NSS, I thought it would stay inside > an external layer. It's a crypto authentication mechanism. It involves keys. I needs to be in NSS if we are to support it at all. (which is why it's there;).
bob > > I really, really regret I gave up on that dead-end discussion about > J-PAKE and did not follow what happened exactly after that. > It would have been just functionally equivalent for Sync to use SRP > instead of J-PAKE in Sync, but so much more useful for everyone else, > especially for all those who would love to be able to use SRP with TLS.
-- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
