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

Reply via email to