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.
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
