On Tue, Sep 14, 2010 at 03:16:18PM -0500, Marsh Ray wrote:
> On 09/14/2010 09:13 AM, Ben Laurie wrote:
> >Of some interest to me is the approach I saw recently (confusingly named
> >WebID) of a pure Javascript implementation (yes, TLS in JS, apparently),
> >allowing UI to be completely controlled by the issuer.
> First, let's hear it for out of the box thinking. *yay*
> Now, a few questions about this approach:
> How do you deliver Javascript to the browser securely in the first
> place? HTTP?

I'll note that Ben's proposal is in the same category as mine (which
was, to remind you, implement SCRAM in JavaScript and use that, with
channel binding using tls-server-end-point CB type).

It's in the same category because it has the same flaw, which I'd
pointed out earlier: if the JS is delivered by "normal" means (i.e., by
the server), then the script can't be used to authenticate the server.

And if you've authenticated the server vi HTTPS (TLS) then you might as
well just POST the username&password to the server, since the server
could just as well send you a script that does just that.

This approach works only if you deliver the script in some out-of-band
manner, such as via a browser plug-in/add-on (hopefully signed [by a
trustworthy trusted third party]).


The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com

Reply via email to