I'm a co-author of NSSCKBI.DLL. I added the Quo Vadis CA certificate to it (per Frank's request). Thanks to open source, that's an easily verifiable public fact. Look at http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/security/nss/lib/ckfw/builtins/certdata.txt&rev=1.39#10411 Click on my name on that line for more. So I know a thing or two about this subject.
There's a LOT of misinformation being spread and I intend to address much of it in this thread (but not all in this message). People who issue certificates are "cert issuers" or "certification authorities" or just "CAs". CA certs that come from other CAs are called "intermediate" or "subordinate" CA certs. CA certs that come from no-one else, and are their own final authority, are called "root CA" certs, or (rarely) "trust anchors". Point 1: CAs vouch for identity, not for character or reputation. CA's issue certs. Certs are signed documents that say, in effect "I certificate that this public key belongs to the party named herein and is valid for these uses ..." Certs do NOT say "I certify that the party named herein is reputable, honest, loyal, brave, trustworthy, a good businessman, a good developer, will give you your money back if you're unsatisfied" or anything like that. Certs say: "Here's the name of the party who has this key." The implication is: if you have trouble with the party named in this cert, at least you have the party's name and can hold that party responsible for his actions. If a party to whom a cert is issued acts in bad faith, that is not in itself a bad reflection on the CA that issued the cert. If the information in the cert is falsified, and the CA didn't catch that falsification, and issued the cert anyway, that's a bad CA. Think of a CA as being like an issuer of drivers' licenses or other forms of ID. If the party named on the ID does something bad, that's not any reflection on the issuer of the ID. You don't get mad at the Department of Motor Vehicles (or whoever issues drivers' licenses where you live) when someone drives badly and hits you. But you might get mad at the DMV if they issued a driver's license with a false name or false address. That would be a fault of the issuer. So, if someone gets a certificate from a CA, a certificate whose facts are accurate, and then uses it to commit fraud, you have no business wanting to attack the CA for it. Your beef with a CA should be that the CA failed to do what the CA said he would do to verify the info that he signed (the "signed attrbutes") in the cert. Got that? And if you find that an cert holder has falsified information in his cert and it was undetected by the CA, you should first approach the CA with that info. The CA might revoke the cert, if you have a good case. Point 2: Every browser has its own separate default list of CAs. Microsoft's list is kept in Windows' "certificate store", part of which is in the system registry. All the info about the certs is kept in that store. Windows' cert store is updated by a program available from Microsoft that adds new certs to the store. MS updates their list periodically (maybe twice a year). Mozilla products (including FF, TB, SM, ...) keep their default list in NSSCKBI.DLL. It is updated (by replacement) in new product releases. Mozilla products also have a cert data base (cert8.db) that holds new certs that a user might add, and records information about certs that a user has chosen to explicitly trust or distrust. (More on that below). Opera has its own cert store too, but I don't know much about that. Likewise Safari and others. As far as I know, none of these products interfere with each others' cert stores. Mozilla doesn't mess with windows' cert store, and (AFAIK) vice versa. So, if you find a CA cert in your windows registry, it didn't come from mozilla browsers, and it doesn't affect mozilla browsers. If you're looking for the source of that cert in Window's cert store, look elsewhere than mozilla browsers. (This whole issue started over a cert in Windows' registry. So why is this being discussed in a mozilla group?) Point 3. CA certs are not added casually to mozilla's list. Before a CA's cert can be added to mozilla, the CA must go through a multi-step process to prove that they do business the way they say they do. That process is all explained in mozilla's CA cert policy, a document written by Frank Hecker (Executive Director of mozilla foundation, IIRC). Here is a slightly (?) oversimplified explanation of that process. The CA must first have (write) a public statement that explains how they work. It must define their procedures, and explain what things they check before issuing a cert. This is a "Certified Practices Statement" or "CPS". And the CA must have some independent party (usually an auditor or CPA) audit them and check that they really do operate according to the rules they publicly establish for themselves. For MOST CAs, these audits are done by "WebTrust", an outfit that exists to audit CAs (among others). It's operated by the American Institute of Certified Public Accountants" (AICPA) and the Canadian Institute of Chartered Accountants" (CICA). There are others that could do this too. The full requirements are in mozilla's policy, and I won't go into them here. You suggested that SpywareBlaster might do this. Maybe they could if they're into auditing. That's a policy question. When WebTrust does a CA audit, and the CA passes, WebTrust issues a "seal" for them. You can see a list of exemplary CAs with WebTrust seals at http://www.webtrust.org/abtseals.htm The seals listed there each have an "unqualified attestation" (meaning the attestation doesn't have any provisional parts, no if's, and's or but's). You'll find Quo Vadis listed on that page. (go look!) When the audit is done, a request is made to mozilla, asking for inclusion of the root CA cert. If the site meets the criteria of mozilla's policy and has passed its audit, and there is no unresolved public objection to inclusion of the cert during the public comment period, then the cert will be accepted. Not all applicants get approved. That's the process that Quo Vadis went through. There are public records of the application and the discussion about it. See them at https://bugzilla.mozilla.org/show_bug.cgi?id=238381 Perhaps I've misremembered a few details of this process, details that are minor with respect to the point here, which is that there is a public and open process by which CAs are chosen. There's nothing "automatic" about it. It's not easy for bad guys to get in. Point 4: You want users to have control, but you don't want to require them to exercise that control very often. Updates are a good thing. You already know that mozilla has a "certificate manager" window that you can bring up from preferences. And it shows you all the cert's contents in pretty form. So, that lays to rest the accusation that there is no UI for cert management in mozilla, or that you can only see binary. Perhaps you'd like mozilla to say to the user, at each update, for each new cert, something like this: "Here is a new cert that is being added to your browser's list of CAs. Do you want to trust it?" How would users answer that question? 49% would always click yes, and 49% would always click no. 1% would flip a coin, or call their brother in law, and 1% would switch to a different browser. :) Did any of them benefit from that exprience? Can you imagine every browser user in the world having to decide whether or not to trust a new cert that claims to be from Verisign? How many of them would have ANY idea how to decide that? If users had to add new certs to their list of trusted CA certs themselves, and didn't get new certs from their browser makers, then the users would be forced to manage all their root CA certs themselves. That would be a phisher's bonanza! Users would be overrun with email trying to persuade them to download and trust root CA certs from random web sites, certs that have had no webtrust audit (or equivalent), certs that might come directly from the phishers themselves. To be blunt, that would be a disaster. If widely used, audited, vetted public CA certs were not added to mozilla (or IE or other browsers) in updates, then the most likely alternative is that users would experience Many Many web sites with error messages saying their certs come from unknown issuers. And users would respond to that the way most users always respond to that: they'd "click through" it, overriding the error and proceeding anyway. The more times they see that dialog, the more likely they are to always click through it. It's the rareness of that dialog that makes users ever stop and take notice of it. Users in closed environments (e.g. in corporate enterprise settings) may need to add their company's root CA cert to their browser. That's a legitimate case that a user should RARELY have to do. Likewise, if a root CA should go "rogue" and start issuing falsified certs, a user should have a way to STOP honoring that issuer's certs. mozilla provides both of those capabilities. But the use of those should be exceeding rare, or else you have phishers' bonanza! Users should manage their certs when they're setting up their browser, not daily, and certainly not in response to phishing messages! Point 5: You don't stop bad CAs by forgetting them. If a user finds that he no longer wishes to "trust" a CA, and no longer wants his browser to honor certs from that CA, the thing to do is NOT to delete the cert. User's sometimes mistakenly assume that every cert listed in the cert manager is implicitly trusted. So, if the user doesn't want to trust a cert, the user tends to assume that he should delete it. But there's a difference between encountering a cert from an issuer of whom you have no record, and encountering cert from an issuer that you've seen before and have decided NOT to trust. In one case, you might wanna go see if they're trustworthy. In the other case, you appreciate that reminder that you've already decided this is a bad guy, and you're not tricked into trusting them again, or wasting time re-evaluating them. So, it's better to keep a cert from a bad guy, and mark it deliberately untrusted, than to delete it, and lost all record of whether it was ever trusted before, or not. That's why mozilla doesn't let the user delete certs from NSSCKBI.DLL. Instead, mozilla lets the user mark the cert explicitly untrusted. This is done by "editing" the trust on the cert. You can trust or distrust a cert separately for different purposes. For example, you can trust a cert for (say) email, but not for SSL servers. You can trust a cert for SSL, but not for signing code that you download and run. So, don't be alarmed about not deleting root CA certs. You really want to DISTRUST them, not delete them. Point 6: Old root CA certs retain value, even after they expire. (hey, it's way late here. I'll write more about this later in the week, if anyone cares.) One parting remark. (Is this point 8?) In the numerous discussions of this that I've read, especially http://www.wilderssecurity.com/showthread.php?t=140217 I've read that BoClean regards the update program that adds Quo Vadis's cert to the windows cert store as a trojan horse. The accounts I've read don't name the program file. Might it be a copy of Microsoft's own cert update program? You can download a small program that will update the MS Windows cert store with new CA certs including Quo Vadis's directly from Microsoft at http://download.windowsupdate.com/msdownload/update/v3/static/trustedr/en/rootsupd.exe I wonder if perhaps that is the program that started all this misdirected attention towards mozilla. Imagine a Microsoft update program being identified as a "Quovadis trojan"! -- Nelson B _______________________________________________ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
