Hi Kurt,
I think it's more subtle than that, some of the problems in brief: 1) Mozilla/Firefox either trust a CA 100% or not at all.
Correct.
3) It's very difficult even for technical users to find out who exactly signed a certificate. For example a certificate is signed by "valicert", who is that? (Tumbleweed bought Valicert and then Axway bought Tumbleweed, who the heck is Axway and what exactly do they do?). Or a certificate is signed by beTrust, who is that? (which joined up with Baltimore cybertrust to form Cybertrust, and in turn Verizon purchased the whole thing.).
Correct observation.
4) CAs are generally not restricted in whom they can issue certs to, i.e. governmental CA's (Turkey, Holland, Denmark, etc.) are not restricted to issuing certs within .tk, .nl, .dk for example (there are good arguments for and against this, but I think it should at least be discussed, and I'd love to see a bit more user control over this).
We've discussed this previously here and it's a much wanted feature. Unfortunately NSS doesn't supports it at the moment.
5) There is no way for an end user to really verify the CPS/CS stuff, most CAs seem to publish them online, quite a few are out of date by several years
That shouldn't happen. If you know such cases and the CA Policy in not adequate anymore, please let us know.
6) There appears to be no re-evaluation for CA's that are bought out or merge with other CAs
That's also correct. However Kathleen started to track audit reports very recently.
7) There are several suspicious and questionable looking CA's in Mozilla/Firefox, e.g.: Internet Publishing Services from Spain, they have 7 certificates, what possible need is there for 7 certificates?
They are on the way out - as per request of ipsCA.
8) The CA approval protocol appears to be largely fail open, they submit paperwork showing they comply with certain standards/etc at a certain time point and then there is a public comment period (where exactly?) and if no-one objects they are in.
It happens at mozilla.dev.security.policy and we are doing it for several years already. Please join us reviewing CAs at that list.
9) there is no formal process to revoke certificates for a CA that violate the rules. Heck theres no official set of rules for them to break (one signed malware code, on hundred signed malware codes? a provably weak domain authentication process that allows people to buy certificates for domains they don't own reliably, etc.).
I believe this is work in progress at the moment. See https://wiki.mozilla.org/CA:Root_Change_Process
10) I'm not even sure whom exactly to contact about these issues or to report security problems with respect to a CA doing bad things (so I've been lurking on the list for a bit and am now posting).
All the action happens at mozilla.dev.security.policy (and this list is actually the wrong one for this discussion).
I've also seem these topics raised in this forum, Bugzilla, etc. and nothing much come of them which is what I expect to happen here sadly. One simple question I'd love to see answered: who exactly is in charge of this and what exactly do they do (it seems that certificate approval duty floats around between a few people).
Currently Kathleen Wilson is module owner and in charge for CA issues. There are another few Mozilla employees involved from time to time. And a couple of volunteers performing the reviews.
-- Regards Signer: Eddy Nigg, StartCom Ltd. XMPP: start...@startcom.org Blog: http://blog.startcom.org/ Twitter: http://twitter.com/eddy_nigg -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
