Comment 136 for bug 232340

It really comes down to whether mozilla.org is willing to assume liability for vetting certificate providers. If so, they need to have a policy and apply it evenly. If not they should probably not include any certificates, or should include anything that anybody sends them.

Personally, I'm not inclined to trust AIPCA to make an assurance that a CA provider is trustworthy. After all, the various standards bodies certified that Verisign knows what it is doing, and yet they issued an MS code signing certificate.

That is a VERY big deal - if they had issued one for anybody other than MS, I doubt that MS would have sent out an update. MS didn't do it out of concern for Verisign, or even for a chunk of change most likely. They did it because they didn't want their name associated with the latest virus, and because they had the power to do it.

In fact, the MS debacle shows just how backwards Verisign actually is. They should just maintain a CRL and require that it be queried routinely (instead of off by default like it is in most apps). Then they could revoke the cert without cooperation from anybody.

As far as CACert goes - it provides an assurance that whoever is using the certificate was able to maintain control of the domain/email it is assuring. I'd probably alter the algorithm to require a 1 week waiting period on certs, during which the domain would be tested several times randomly - this would prevent somebody from hijacking the domain for 5 minutes and getting a cert - holding onto it for a week would be much harder.

Personally I put more stock in something like this rather than somebody who only assures that you were able to write a check for $15-200 and send in some convincing-looking letterhead (which can be generated on a laser printer for 25 cents these days).

If on the other hand we want to take a leave-it-up-to-the-users approach with regard to trust, the only neutral position really is to just not include certs at all.