Hi evilbunny, > I've a similar project under development, little more testing to see > if the user has the rights to the domain, and they generate their own > private keys etc... little more effort on the users part, however I've > tried to code it in a sane method, by stopping people being able to > request www.microsoft.com for example... > > www.cacert.org for more info, it's mostly functional, still working on > it however...
These checks are useful, but since the CA operator has the code (we are about to release it as open-source; it is already at SourceForge's CVS), he can easily override it. In our model, anyone can create *entry-level* (EL) certificates with any name -- that's why entry-level certificates shouldn't be widely trusted; at most, locally trusted. The idea is to use the Verified Identity (IV) CA to get credibility to the name. This will become clear when we put the VI CA online in a few days -- then you'll see what it is capable of. I'll let you know when it's online. Meanwhile, its main ideas are described in the paper. But the idea is this: only the VI certs should be widely trusted. The EL certificates should be only a initial jumpstart to get a first certifi- cate. The user's aim should be to "upgrade" it to VI status. I saw your CA site. Quite cool. What's the underlying platform? -K. ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
