On 09/14/2010 09:13 AM, Ben Laurie wrote:
On 14/09/2010 12:29, Ian G wrote:
On 14/09/10 2:26 PM, Marsh Ray wrote:
On 09/13/2010 07:24 PM, Ian G wrote:

1. In your initial account creation / login, trigger a creation of a
client certificate in the browser.

There may be a way to get a browser to generate a cert or CSR, but I
don't know it. But you can simply generate it at the server side.

Just to be frank here, I'm also not sure what the implementation details
are here.  I somewhat avoided implementation until it becomes useful.

FWIW, you can get browsers to generate CSRs and eat the resulting certs.
The actual UIs vary from appalling to terrible.

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?

How do you get the user to save his private key file? Copy and paste?

How does the proper Javascript later access the user's private key securely?

How do they securely wipe memory in Javascript?

How do they resist timing attacks? In practice, an attacker can probably get the browser to repeatedly sign random stuff with the client cert even while he's running his own script in the same process.

Ultimately this
approach seems too risky for real use, but it could be used to prototype
UI, perhaps finally leading to something usable in browsers.

A sad indictment of browser vendor user interface priorities.

Slide deck here: http://payswarm.com/slides/webid/#(1)

(note, videos use flash, I think, so probably won't work for anyone with
their eye on the ball).

Demo here: https://webid.digitalbazaar.com/manage/

"This Connection is Untrusted"

- Marsh

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

Reply via email to