Evilbunny, > MKC> The idea is to use the Verified Identity (IV) CA to get credibility to > MKC> the name. This will become clear when we put the VI CA online in a few > MKC> days -- then you'll see what it is capable of. I'll let you know when > MKC> it's online. Meanwhile, its main ideas are described in the paper. But > MKC> the idea is this: only the VI certs should be widely trusted. The EL > MKC> certificates should be only a initial jumpstart to get a first certifi- > MKC> cate. The user's aim should be to "upgrade" it to VI status. > > Make sense I guess, however I think it would be too confusing for most > joe public's out there to comprehend beyond the warnings the browsers > spew at them...
Indeed it is. But IMHO this is a problem of the current generation of web browsers. The digital certificate UIs are anything but easy to use. Everyone who has tried knows that the average user thinks that all this certificate mumbo-jumbo is way too complex, too cumbersome. The famous "Why Johnny can't encrypt" paper illustrates this well for PGP; someone's got to write a usability paper of recent https-capable browsers. (We're actually thinking of doing that :)) My guess we'll have to wait for a new generation of browsers that build on this previous experience to fix that up -- and we dare to think that a collaborative certificate infrastructure like the one we are proposing stands a better chance of becoming more widely deployed, widely accepted than the outrageously expensive alternatives offered by commercial CAs that we were alluding at the start of this thread. And, most importantly, contribute to make them more widely understood and, in turn, the software that uses them more user-friendly. As long as certificates are expensive and impopular, they'll continue to be rare, misunderstood, misused. OpenSSL is doing a great job of laying out the middleware to make certificates free. But we still lack a widely accepted PKI and we still lack decent apps. Oh my. Seems like I got carried away again. Sorry for the rant. :) > MKC> I saw your CA site. Quite cool. What's the underlying platform? > > Front end is PHP based, with all operations feeding a MySQL table, > which is then crontab'd to trigger a c programmer to interact with > openssl, hoping to get a 2nd box and pipe data via a serial cable so > that the worst that can happen is fraudulent certificates are issued, > rather then the private key nabbed... (ie only interfaces into the box > are via serial cable and physical console access...) well unless > anyone has a better suggestion? Ours is Perl-based. We prefered Postgres because we wanted transactions (to follow the ideas outlined in Peter Gutmann's ideas about certificate management as transaction processing and because our local DBAs liked it most :)). Just as you, we plan to have a second box to be the "signing engine" (we considered a fancy cryptoprocessor, but we decided to stick with cheaper hardware and open-source software) connected via serial cable. Maybe put it in a tempest-shielded safe and all that. But this is somewhat further away in the future. First we'd like to build a user base that justified all these precautions. Seems to me that we have a lot in common. Maybe we could join forces? -K. ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
