<http://www.hecker.org/mozilla/ca-certificate-metapolicy/>:
11. ... We have to deal with the world as it is, not as it might be or as we might wish it to be
I disagree. We're here to *change* the world, aren't we? ;-)
17. The assessment of CAs that have not undergone independent audit should be based only on information that is (or will be) available to the general public
If the Mozilla person assessing the CA gains deep insight into the processes of the CA, e.g. by speaking with the CA people, being physically onsite, being virtually onsite by being allowed to access and check their servers (using a user/guess account over SSH), and he gains confidence in the CA as a result, and documents that publically as far as possible (not all of the above may be possible to publish), and bases his decision partially on that confidence, would that satisfy your rule or conflict with it?
18. ... The policy should not arbitrarily exclude CAs from consideration based on factors such as the CA's size, reputation, business practices not related to certificate issuance, profit or nonprofit status, geographic location, and the like.
Not so sure about that. If a company has proven to be ruthless, I don't want their certs to be in Mozilla by default, no matter how many independent audits they passed. Hypothetical case: If Microsoft was a CA, would you include them, if they formally passed our criteria? If a company has a track record of issuing bad certs or even having their root cert stolen, that's reputation, and IMHO very relevant.
However a CA's certificate should be removed only if there is adequate reason, not just in the form of increased risk
So, if I'm a CA: start nice, or even just pretent to be nice, and when I am included, I can get sloppy or evil?
Yes, the certificate holders of a CA have a reasonable expectation to not have the certificate be draw from under them, and this should be considered when removing CAs.
But I wouldn't state it *that* explicitly in the policy, so it would be perceived as a right to stay in the root. I'd rather word it as "consider", not "should not" or 'increased risk is not a reason'.
<http://www.hecker.org/mozilla/ca-certificate-policy/>:
the actual criteria themselves will be included in another document, most likely the FAQ on policy details, not in the policy itself.
I'd say the actualy criteria *are* the policy, so should be part of it. You already have a meta-policy, with this you make that a meta-meta-policy.
CAs should send an email message to [EMAIL PROTECTED]
It should be mandatory policy to inform interested users of new root CAs after decision, and before decision for people who want to take part in the discussion.
other entities distributing Mozilla and related software are free to adopt their own policies.
Good and necessary.
<http://www.hecker.org/mozilla/ca-certificate-faq/policy-details/>
For example, a given CA might issue relatively few certificates, but those certificates might be issued to particular web sites used by a large number of Mozilla users.
I'd rather add the actual certs, not a root cert. Much smaller risk.
Which risks and threats are you concerned about in connection with certificates and CAs?
The answer doesn't really show the cases we consider problematic. Most controverse is probably: Do we trust governments? I don't. This implies that I don't trust Verisign either. You may argue that I'm paranoid, but many governments (incl. US and Germany, unfortuantely) are snooping on their citizens, even innocent third-parties, so I'd argue that this is some risk even for average users.
It's hard to fight governments, but there are some things which can be done to migitiate that risk (e.g. not blindly accept a *changed* certificate), which could be considered, if we acknoledge that risk.
(This check can be thought of as providing additional security against DNS spoofing beyond what is present in the DNS itself.)
DNS provides security? ;-)
First, recall that we are co... Next, given these assumptions we need to...
I'd strike these paragraphs. Don't fit, and almsot anybody interested in root certs knows that, I'd guess.
Also, does the CA vet the certificate field
typo?
Should there be rules wrt to malware, i.e. abuse of rights when running software signed with the cert? If an extension comes with a signature with mozdev as root CA, I bet almost all users (actually including me) expect that the software doesn't do anything evil.
I know that this would probably be against CA standard policy (we just certify the name, not the holder or content), but runs *totally* against most user expections.
Maybe this is a UI question, though, I don't know.
Criteria:
Given the long documents, the actual concrete criteria are very vage and weak.
Is there a minimum requirement *how* the server name, email address or real name (for person or company) must be determined. In particular, I think (might have misunderstood it) there are several "classes" of certificates you can get for email - Class 1 checks only the email address, but does not have your real name, Class 2 checks your real name using passport?, there's also a Class 3. Even with GPG, it's generally expected that you check the real name against the passport, in person, before you publically sign a key. The policy here doesn't mention *any* of that. If I find a company name in a certificate, signed by any CA, can I rest assured that the CA actually checked the records, in a secure way, to assure that the name in the cert matches the holder name? That the actual person/computer holding the cert is allowed to act on behalf of that company?
What about CA security? How does the CA ensure that the root CA is not stolen, the server rooted (virtually or physically), that no man-in-the-middle attack is taking place during signing up? I'd personally say it's minimum requirement that the server is physically safe from access and guarded, and I would *not* count datacenters of hosting services in that, it should be guarded by people of the CA. I'm pretty sure that my servers at home are safe, but I don't know if anybody accesses my dedicated server at the hosting company. Similarily, securing a server virtually is a very hard task. As a basic rule, I'd say that the CA server should have no other functions (esp. no FTP server, CVS server etc.), no known remote holes etc..
What is the process by which our request will be evaluated and a decision made?
The answer is nice, but as said earlier, that should be part of the actual policy, and should include announcement of positive decisions of inclusion.
The module owner and other interested parties will discuss the request in Bugzilla (/not/ in the newsgroup and mailing list)
Sure? Bugzilla is totally inadequate for longer discussions.
_______________________________________________ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
