And if this company approaches mozilla and says "look, we have a webtrust seal, so add our CA cert to your browser", looks to me like a slam dunk.
The current draft 11 policy is *not* "have WebTrust, can get in". See also my comments below.
Now part of this issue gets at the definition of a CA. Is every company that issues certs and has a root CA cert a CA? Even if the owners of the servers whose DNS names appear in its certs have never heard of it, and have never asked it to issue them a cert? If they approach mozilla to have their CA cert added to the root list, what in mozilla policy excludes it? Let's see ... apparently not webtrust, perhaps not ETSI, hmmm.
It seems to me that a reasonable CA policy would CLEARLY and UNAMBIGUOUSLY keep such issuers of certs, whose existence is unknown to the servers that their certs appear to represent, out of the root CA list. Today Draft 11 does not.
You've implied this several times without actually referencing the parts of the policy that you believe would permit this. Please allow me to first point to clause 4 in draft 11:
"4. We reserve the right to not include a particular CA certificate in our software products ... for any reason. This may include (but is not limited to) cases where we believe that including a CA certificate ... would cause undue risks to users' security ..."
I think this language is pretty clear, in particular that "any reason" part. (Like, say, "we don't want to install CA certs for SSL MITMs"? Sounds like a reason to me.)
Now let's consider clause 7 in draft 11:
"7. We consider verification of certificate signing requests to be acceptable if it meets or exceeds the following requirements: ...
* for a certificate to be used for SSL-enabled servers, the CA takes
reasonable measures to verify that the entity submitting the
certificate signing request has registered the domain(s) referenced
in the certificate or has been authorized by the domain registrant
to act on the registrant's behalf;"In the example we're discussing, where the SSL MITM generates certificates for www.paypal.com, www.etrade.com, etc., is the "entity submitting the [CSR]" the domain registrant for those sites? Is that entity authorized by Paypal, E*Trade, etc., to apply for certs on their behalf? Somehow I don't think so, unless those companies and others have clicked through the fine print of the SSM MITM's license agreement along with the users of the SSL MITM software.
So the hypothetical SSL MITM CA applicant fails the test of clause 7, and even if they didn't we would be free to reject them under clause 4. So what's the problem? That the applicant would then sue the MF and force it to submit?
Well, in the US anybody is free to sue anybody else for any reason whatsoever, so I guess our hypothetical rejected CA applicant could throw armies of lawyers at the MF if they felt like it. Of course, so much for NDAs then, and for having to tiptoe around the question of who's actually running such SSL MITMs; there's nothing like a lawsuit in public court to generate loads of public attention.
Well, hoorah! as the marines say. That's a very big admission by you - that WebTrust by itself may not suffice.
I've been saying that since draft 10 or 11 came out. It's in several of my posts.
Ian, Nelson is exactly right here, he did bring up the concern about WebTrust audits simply auditing compliance to CA policies (e.g., as outlined in the CP, CPS, etc.), and not necessarily evaluating those policies as being good or bad in terms of security. I think that particular concern is perfectly valid, and that's exactly why I added more policy requirements to draft 11.
Forbidding CAs that issue certs without the knowledge of the parties identified in the certs. Objective. Policy protects user security.
This is exactly what clause 7 of draft 11 is intended to do. Now maybe what's confusing is that the language is couched in terms of 'the entity submitting the CSR' and not in terms of the CA. That's because the language also has to cover the case of other entities (i.e., not the CA) falsely applying for certs.
However if you would prefer that I include a new clause with language specifically addressing the behavior of CAs then I'd be glad to consider putting one in draft 12. Your language above is a start, but I'd probably have to modify it somewhat to make sure it covers all three cases (SSL, S/MIME, and object signing); off the top of my head maybe something like the following would suffice as an added requirement for clause 6:
"6. We require that all CAs whose certificates are distributed with our software products:
...
* not issue certificates without the knowledge of the parties whose
identities, domain names, and/or email addresses are referenced
in the certificate
..."
(However note this could lead to ambiguity if the info in the cert could apply to multiple entities, i.e., the "John Smith" problem. Maybe that wouldn't be a problem in practice, I don't know.)
The contractual arrangement doesn't say the user has no right to keep anything private. It merely says that the other party has the right to do what it can to intercept. A mozilla user with a reasonable root CA list is still protected.
Uh, what if the SSL MITM's installation procedure simply overwrites libnssckbi.dll (and the CA cert list embedded in it) with a new version? Wouldn't an SSL MITM implementor think of that?
Frank
-- Frank Hecker [EMAIL PROTECTED] _______________________________________________ mozilla-crypto mailing list [email protected] http://mail.mozilla.org/listinfo/mozilla-crypto
