My claim is if a CA conforms to a particular criterion, and that conformance in fact has no effect on the behavior of Mozilla as experienced by a typical user, then you have to question the value of including that criterion in a policy intended to benefit typical users.
This assertion as stated above is not really correct, and I thought I'd correct it myself before someone else embarrasses me into doing so. Instead of writing "has no effect on the behavior of Mozilla" I should have written "has no effect on the sequence of events".
To restate this, a criterion placed on a CA should make a difference in what actually happens in practice: If the CA conforms to the criterion then as a consequence bad things should be prevented from happening, bad things that would have (or plausibly might have) happened had the CA not conformed to the criterion.
I'll expand on this point with three examples:
First, let's consider the criterion that a CA verify in some way the domain name stored in a SSL server certificate (in the CN or wherever it goes these days), as it might apply to a (fictitious) bill-paying service at www.payyourbills.biz.
Suppose that an attacker is able to spoof DNS to direct www.payyourbills.biz traffic to his own malicious site, and further suppose that the attacker was able to find a CA who would issue him (or anyone else) an SSL server cert with CN=www.payyourbills.biz, no questions asked.
In this case it would make a difference for typical Mozilla users to require that CAs do domain name verification as a criterion for including the CAs' trusted root CA certs in Mozilla. The attacker would either not be able to get a cert referencing www.payyourbills.biz, or would have to get it from a CA whose cert is not included by default in Mozilla. In either case the typical Mozilla user would be presented with some sort of warning dialog, and could be warned away from the malicious site.
Second, let's consider the criterion that a CA issue CRLs on a regular basis and/or maintain an OCSP responder. (I know I'm beating this example to death, but it's a good example.)
Suppose that an attacker is able to get copies of the private key corresponding to the www.payyourbills.biz SSL server cert, and again does the DNS spoofing to redirect traffic to his own malicious version of www.payyourbills.biz. Further suppose that the CA learns of the key compromise and revokes the www.payyourbills.biz cert.
In this case it makes no difference to typical Mozilla users whether we impose CRL- or OCSP-related criteria on CAs as a condition of including their certs, since (as previously noted) CRL or OCSP checks would never be done under the default Mozilla settings. No matter what the criteria are, typical Mozilla users would see no warnings whatsoever when they go to the fake www.payyourbills.biz site.
Finally, a more "in between" example: let's consider the criterion that a CA validate the correctness of every piece of data in the certificate, including in particular the O and OU attributes.
Suppose that an attacker sets up a new site www.payyourtaxes.biz, and represents it as an offshoot site of www.payyourbills.biz, run by PayYourBills Inc., the operator of the original site. Suppose also that the attacker finds a CA who will issue him a cert with CN=www.payyourtaxes.biz and O=PayYourBills Inc. This cert then contains a mix of true information (the attacker does in fact operate the www.payyourtaxes.biz site) and false information (the attacker has no association with PayYourBills Inc.).
Now, would having the above-mentioned criterion make a difference to a typical Mozilla user or not? If the typical user never clicks on a "View Certificate" button in Mozilla then they will never see the O attribute; since the certificate would check out as OK otherwise (including passing the domain name check), the user would have no reason to suspect that anything is amiss.
So the criterion in question fails the test of making a difference from this point of view. However to be fair some users (typical or otherwise) might sometime find occasion to do a "View Certificate" operation, even though most users would not, and imposing the criterion would make a difference for those users. It's also possible that future versions of Mozilla might give greater visibility to the O attribute, perhaps by displaying it in the chrome somewhere; this might make it much more likely that a typical Mozilla user would catch what was happening.. However given the current state of Mozilla imposing this criterion is not as obviously useful as imposing the criterion to verify the domain name.
This example is of course specific to SSL server certificates, and the situation might be different for email certs or developer certs. For example, as I understand it a typical user would always get a warning dialog the first time they downloaded a signed code object (e.g., Java applet or XPI) from a new developer. In that event a typical user might be more likely to click the "View Certificate" button and inspect other fields of the developer's certificate, so there would be more value in a criterion to ensure that CAs validate more of the information placed in such a certificate.
To sum up, my point in these comments is *not* that we should not have criteria regarding how CAs operate, or that we should have very loose criteria. My point is rather to argue that for each and every criterion we decide to adopt, we have to justify why adopting that criterion would actually make a difference in the case of the typical Mozilla user.
(And recall that the criteria in question here are really the criteria we would use for our own evaluation of CAs, in cases where independent evaluations either don't exist or we choose not to rely entirely on them, for whatever reason.)
Frank
-- Frank Hecker [EMAIL PROTECTED] _______________________________________________ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
