On Wed, 9 Mar 2011, Anders Rundgren wrote:
It is too late introducing TLS-SRP, the market will not use it.
Uh? There's not just one single market that will or won't use a particular
protocol feature. There are plenty of different areas where TLS is used and
some of them will use TLS-SRP,
On 2011-03-10 09:32, Daniel Stenberg wrote:
On Wed, 9 Mar 2011, Anders Rundgren wrote:
It is too late introducing TLS-SRP, the market will not use it.
Uh? There's not just one single market that will or won't use a particular
protocol feature. There are plenty of different areas where TLS
Jean-Marc Desperrier wrote:
I don't see it as a substitute for PKI, only as a substitute for
user/password.
If you want SRP but don't need TLS-SRP then you could implement SRP outside of
NSS and then build the UI support around that non-NSS support as a HTTP
1. The user's username is sent
Brian Smith wrote:
An augmented PAKE user authentication protocol might be very useful
for some things, but TLS-SRP seems very troublesome. IIRC, there are at
least four deal-breaking problems with TLS-SRP as a substitute for PKI:
I don't see it as a substitute for PKI, only as a substitute
It is too late introducing TLS-SRP, the market will not use it.
Why not make NSS more useful for certificates instead?
Anders
On 2011-03-09 09:45, Jean-Marc Desperrier wrote:
Brian Smith wrote:
An augmented PAKE user authentication protocol might be very useful
for some things, but TLS-SRP
Brian Smith wrote:
Jean-Marc Desperrier wrote:
[...] (I'd expect it instead to leave
the AES256 key inside NSS and just get back the handle to it to
encrypt what it needs later. [...]).
The kind of improvement you described above will be made to resolve
Bug 443386 and/or Bug 638966.
I
Jean-Marc Desperrier wrote:
Brian Smith wrote:
The kind of improvement you described above will be made to resolve
Bug 443386 and/or Bug 638966.
I think Bug 638966 is slightly different, it's about permanently
storing the secret keys in the NSS db (I don't know if that's
really possible,
Jean-Marc Desperrier wrote:
But Curl, that supports secret keys from version 7.21.4, with GnuTLS
only at the moment but is pushing hard to get in in Openssl also,
apparently has simply given up about having TSP-SRP support when
compiled with NSS.
I see in an old doc that Johnathan was
On Mon, 7 Mar 2011, Brian Smith wrote:
But Curl, that supports secret keys from version 7.21.4, with GnuTLS only
at the moment but is pushing hard to get in in Openssl also, apparently has
simply given up about having TSP-SRP support when compiled with NSS.
Can I just add that we (in the
Jean-Marc Desperrier wrote:
I notice the committed code extracts the generated shared symmetric
key up to the javascript level, so takes no real advantage from
having generated it inside NSS (I'd expect it instead to leave
the AES256 key inside NSS and just get back the handle to it to
Robert Relyea wrote:
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
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 (
12 matches
Mail list logo
