[FoRK] DNT: another example of "you can't make this shit up"
Stephen D. Williams
sdw at lig.net
Tue Oct 16 19:54:33 PDT 2012
On 10/16/12 6:21 PM, Gregory Alan Bolcer wrote:
> Yes, perfect except for four things. 0) Browser already have well managed cert stores, 1) I'm not using PKI for security and
> identities, and 2) browsers are broken in how they handle them, and 3) there's no currently implemented automated way to install a
> cert after an SSL negotiation process is initated.
That doesn't hold together. 0 & 2 are contradictory. 3 is by design because the cert store isn't designed to be used that way. 1
seems at odds with A) using certificates B) some of what you said before. It sounds like you are wanting to use public keys
(otherwise, why a cert and not a cookie?) to protect & authenticate (security) a particular transaction (identity). Identity is not
limited to identity of a person, it can be any kind of entity including a transaction / payment.
When I referred to local storage, I wasn't talking about the browser cert store, I was talking about HTML5 Web Storage:
> What is HTML5 Web Storage?
> With HTML5, web pages can store data locally within the user's browser.
> Earlier, this was done with cookies. However, Web Storage is more secure and faster. The data is not included with every server
> request, but used ONLY when asked for. It is also possible to store large amounts of data, without affecting the website's
> The data is stored in key/value pairs, and a web page can only access data stored by itself.
any way you want, with updates as needed. The only limitation is the same-source domain/URL access. This just requires delegation
to an authorization server (similar to OpenID and BrowserID/Persona and a bit like OAuth) unless and until you can get a browser
extension that allows special capabilities that enhance security while relaxing that constraint.
other web sites completely within the browser. One way to do this would be through a pseudo-web server in the browser that provided
There's no reason to abuse the crufty browser client cert storage system, especially since it wouldn't work with hardware cert
storage, breaks the model, etc.
> Back where we started.
> On 10/16/2012 5:29 PM, Stephen D. Williams wrote:
>> Typical security algebra.
>> A client-side certificate is just a cookie that your browser will give
>> to anybody, at least for the public certificate part.
>> client-side storage, perhaps with WebCL for crypto computation (although
>> tokens locally, public key based or not, then allow services to request
>> an authorization check. A modified browser could short cut any need for
>> using an auth server for assistance, but even when one is needed the
>> local storage of tokens could obviate any database or storage on the
>> auth server. That allows easy scaling and even seeding ISP or corporate
>> nodes for fast local traffic.
>> User identity, a la PKI, shouldn't be confused with proof that you are
>> holding an authorization key even if they are both using public key
>> cryptography. I don't like a lot of things about PKI, starting with
>> ASN.1 and OSI-like X.509 based encoding, but it now unless it becomes
>> completely broken.
More information about the FoRK