I’ve just posted a new draft 12 of the proposed Mozilla CA certificate policy, and absent strong objections plan to submit this to the Mozilla Foundation for approval as a 1.0 policy. The two substantive changes in this draft are as follows:
To address some of the concerns expressed about CAs issuing “duff” certificates (defined loosely as certificates that are dubious from a security or technical point of view) I’ve expanded clause 4 to add examples of certificate-related problems that might cause us to reject a CA’s application for inclusion or to consider removing an already-included CA certificate.
To address a concern about certificates of different “assurance levels” being issued under the same CA root (or intermediate), I’ve added a new clause 13 that recommends CA consider using separate root or intermediate CAs when issuing certificates according to
With regard to the language regarding “duff” certificates, I’ve included this language in clause 4 rather than clause 6 (requirements on CAs) for a couple of reasons.
First, the basic concern as I understand it is that we keep out incompetent or otherwise dubious CAs; clause 4 is all about maintaining our freedom to reject or remove CAs, with the new language basically clarifying exactly why we might do this, so I think that’s the appropriate place to put the new language.
Second, in my opinion at least some of the example reasons to reject/remove CAs could be problematic when interpreted as strict requirements per clause 6. For example, it’s quite possible that a CA might knowingly issue a CA with false information in response to a legitimate request from a law enforcement agency or other government entity. If we happened to find out about this I wouldn’t want the policy (as strictly interpreted) to always force us to remove the CA.
(Ian G raised the point that CAs could try to excuse issuance of fraudulent certificates by claiming that “the government made me do it.” My response was that we should be skeptical of such claims, and should look to the pattern of the CA’s behavior and the overall context.)
As another example, in some cases CAs might issue “confusing” certificates for reasonably legitimate reasons; for example, there might be multiple financial institutions in the U.S. or around the world using variants on names like “First Bank” or “National Bank.” In other cases there might be a pattern of behavior indicating real problems, e.g., with a CA that appears to have been set up as mainly as a way for phishers to get certificates for names like “paypa1.com,” “micr0soft.com,” etc. In my opinion the policy needs to provide us the freedom to make subjective judgements as to what indicates a real problem and what does not. The point of clause 4 is to provide that needed “wiggle room,” which again is why I think the new language should go into clause 4.
Regarding the new clause 13, I’m proposing this as a recommendation (at present) rather than a requirement for reasons I’ve previously stated (though unfortunately I can’t find the references right now): I don’t think we should mandate this until it’s clear how much of a problem this really is, how much it would affect the existing set of CAs already included in the products, and whether we’re going to make UI and other changes that would depend on this. However I do think it’s reasonable to put CAs on notice that we’re thinking about this issue and may take action on it at some point.
Also, note that I sidestepped the tricky issue of defining and determining certificate “assurance levels.” I think a better approach (at least for now) is simply to recommend that all certificates issued under a single CA (whether issued directly by a root CA or by an intermediate CA under a root CA) be issued according to the same policy.
This concludes my comments on the rationale behind the changes in draft 12 of the CA certificate policy. As usual, I welcome your comments on this issue. (You can post comments to the relevant thread in n.p.m.crypto.)
At this point I think that the policy is basically in a state to be submitted to the Mozilla Foundation for approval as a 1.0 policy, and I plan to do do absent any strong objections. I could always mess about with the policy some more, but I don’t believe that at this time there’s a consensus to make additional substantive changes beyond what I’ve already made. (As I’ve said before, we can always revisit the policy later if/when events warrant doing so.)