[FoRK] DNT: another example of "you can't make this shit up"

Gregory Alan Bolcer greg at bolcer.org
Tue Oct 16 18:21:44 PDT 2012

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.

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.
> 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
> _______________________________________________
> FoRK mailing list
> http://xent.com/mailman/listinfo/fork

greg at bolcer.org, http://bolcer.org, c: +1.714.928.5476

More information about the FoRK mailing list