[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:
http://www.w3schools.com/html/html5_webstorage.asp

>
>     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 
> performance.
>
> The data is stored in key/value pairs, and a web page can only access data stored by itself.
>
>

My point was that Javascript on a page could store and later authenticate any kind of certificate, token, key, or similar data in 
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.

For instance, an authentication site could define a secure interface that allows persistent Javascript and Web Storage to be used by 
other web sites completely within the browser.  One way to do this would be through a pseudo-web server in the browser that provided 
a tight interface to that cached Javascript code which would maintain the same security context as the original authentication site.

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.
>
> Greg
>
> 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.
>>
>> You can probably implement what you're thinking with Javascript and
>> client-side storage, perhaps with WebCL for crypto computation (although
>> Javascript is probably good enough now).  Store your authorization
>> 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.
>>>
>>> Greg
>>
>> sdw
sdw



More information about the FoRK mailing list