Now, tell us what other good practices you're hiding. :)
To save spamming bugzilla contacts I'll paste your questions here...
1. How do you protect your single most valuable asset, the private key(s)
for your root CA cert(s)?
Currently there is 2 servers, one for webserver, one for root store, with the root store only connected to the webserver via serial cable, with a daemon running as non-root processes on each end of the serial listening/sending requests/info.
If the root store detects a bad request it assumes the webserver is compromised and shuts itself down.
If the root store doesn't receive a "ping" reply over the serial link within a determined amount of time it assumes the webserver is compromised or the root store itself has been stolen and shuts itself down.
Apart from the boot stuff, all data resides on an encrypted partition on the root store server and only manual intervention in the boot up process by entering the password will start it again.
The requests sent to the root store, are stored in a file for another process triggered by cron to parse and sign them, then stored in a reply file to be sent back to the webserver. Causing things to be separated into different users, basic privilege separation stuff. So being actually able to hack the serial daemons will only at the VERY worst cause fraudulent certificates, not the root to be revealed.
Why use serial you ask? Well certificate requests are low bandwidth for starters, then of course simpler systems in security are less prone to exploits, and finally serial code is pretty mature and well tested and hopefully all exploits were found and fixed a long time ago.
With the proposed root certificate changes, there would be a new root, this would sign at least 1 sub-root, then the private key stored offline in a bank vault, with the sub-root doing all the signing, or alternatively 2 sub-roots, 1 for client certificates, one for server, the thinking behind this, if any of the sub-roots are compromised they can be revoked and reissued.
Alternatively as things progress we can add more layers of security with say 4 webservers talking to 2 intermediate servers, talking to the root store, and acting in a token ring fashion, anything happening out of sequence, and the server directly upstream shuts itself down, which if that were in place and there were multiple paths, any down time in this fashion would fall over to the servers not compromised, anyways just some food for thought.
2. What (if any) provision have you made for certificate revocation?
- if the private key associated with a cert issued by your CA is
compromised, (e.g. copied by someone else), is there any way for
the private key's rightful holder to have your CA revoke that
certificate? Or can the wrongful taker of the private keys
victimize the rightful holder from that time forward until the
cert expires?
All certificates can be revoked/issued via the website. In cases of reported misuse/criminal activities we can revoke these certificates ourselves.
- And what is the validity period of new certs?
Basically we run a web of trust model, and those that have become trusted by verifying their identity with multiple other people in the system can get server certificates for up to 2 years, everyone else is limited to 6 months, however as time progresses and the number of people trusted in the system I'd like to see this decrease to 1 month, 3 at the most.
- How can parties who rely on certs issued by your CA obtain
information from your CA about revoked certificates?
Currently we update our CRL with every revoke, however we are currently int he process of deploying an OCSP responder.
- Does Your CA maintain a Certificate Revocation List that is
accessible by ANY MEANS?
I'm not sure what you mean by any means, usually this is via http/https and retrived automatically by SSL clients and servers to verify the recipient is still valid.
- Does Your CA operate an OCSP server, by which relying parties
may obtain up-to-the-minute revocation information?
Almost...
- What authentication method is used to ensure that someone cannot
cause another person's private key to be revoked?
They must log into the system via SSL client certificate or username and password, which is the same method used to issue the certificate in the first place.
3. Will someone keep your CA operating if the principal dies, or is
incapacitated, or divorced, or an earthquake or tsunami occurs?
CAcert is an official non-profit association, which can not "die" be bought out, sold or otherwise without 100% vote from it's current association members.
Or if the power goes out? Or the cable modem? Or liability lawsuit?
Industrial UPS, in a colo facility with multiple links, as for lawsuits, we're also working on association liability insurance.
- Might the equipment with the private key be sold at auction
(an estate sale), or inherited by some teenage nephew?
This would only be an issue if the association fell into debt, we now have 2 issues to include in a revised constitution, and will be discussing the best ways to word these into the constitution shortly.
4. What evidence can you offer of your answers?
Can get a trusted 3rd party person to make inspections/verify claims, and have those claims witnessed by a JP (Notary in the US), such that they become legally binding documents and that any lies are treated purgory I believe.
_______________________________________________
mozilla-crypto mailing list
[EMAIL PROTECTED]
http://mail.mozilla.org/listinfo/mozilla-crypto
