Draft 11 of Mozilla CA certificate policy

I've just posted a new draft 11 of the proposed Mozilla CA certificate policy. The only substantive changes are as follows:

• I strengthened the language in paragraph 4 to cover rejecting CA requests if we believe it's appropriate to do so.

• I modified paragraph 6 to add a requirement relating to verification of certificate signing requests, and added a new paragraph 7 to describe minimum verification requirements for each type of certificate. (See below for more on this.)

• I added a new paragraph 14 noting that the Mozilla Foundation will designate someone to handle CA requests, with mozilla.org staff being the "supreme court" for any disputes.

The major change in this draft was to address an outstanding issue noted in my previous post:

In particular, as noted by Nelson Bolyard among others, [draft 10 of] the proposed Mozilla Foundation policy as written requires that CAs be evaluated to confirm that their practices match their own policies and assertions (e.g., as expressed in the CPS, CP, etc.); the proposed policy does not go beyond that to attempt to put requirements on those CA policies, for example, to require particular assurance levels for CAs issuing particular types of certificates.

In this draft I have tried to provide such a "minimum assurance level" for each of the three types of certificates we're concerned with: email certificates, SSL server certificates, and object signing certificates. I've focused on verification of information relating to CA subscribers (i.e., people applying for and being issued certificates) because that appeared to be the most controversial point, and one that is "underspecified" in some of the criteria we're referencing, which require the CA to conform to its documented policies with regard to vetting of subscribers but don't go beyond that to state which policies are acceptable and which are not.

I believe that in practice other CA operational issues (e.g., protection of CA signing keys) are likely to be adequately addressed by audits and evaluations according to the WebTrust, ETSI, or X9.79 criteria, so at least for now I haven't attempted to craft policy language relating to such issues.

Why did I choose the particular minimal requirements listed in paragraph 7? It's worth exploring this point in depth because this is a topic on which reasonable people can disagree, and I want to make everyone aware why I drafted the policy the way I did. (I've adapted the following material from a thread on CA subscriber vetting that I initiated on n.p.m.crypto.)

Requirements on CA subscriber verification

Any policy language relating to CA subscriber verification needs to take into account and separately address the possible use cases and the relevant threats for those use cases. For this policy we have three overall categories of use cases--for email certs, SSL server certs, and object signing certs--and then subcategories of use cases within those overall categories, e.g., for SSL server certs we have HTTP/SSL for web sites vs. IMAP/SSL for email servers. Within each subcategory we potentially have multiple use cases of interest; for example, with HTTP/SSL one possible use case is protection of credit card information for a site like Amazon.com or eBay, while another is setting up a password-protected personal site with family news and photographs.

Our problem is how to craft policy language that both allows CAs to support all the use cases that we might consider legitimate and is in sync with the nature of the respective threats associated with those use cases. This is an area where I believe that subjectivity is inevitable; let me be absolutely clear on what I mean by this:

Certainly we can come up with some set of specific and "objective" requirements on what CAs should do to vet subscribers: "provide full name, address, date of birth, etc.", "show up in person with passport or other national identity card", "provide evidence of organizational affiliation on organization letterhead", and so on. That is what lots of people have done, including ETSI (i.e., in the documents referenced in the draft policy) and the Electronic Authentication Partnership. But that is not the approach I am taking; the point of our proposed CA cert policy is not to be a "how to prove your identity" checklist.

Rather the point is: how do we decide that a given set of measures to vet CA subscribers--the set of measures that we presumably want to enshrine in our policy--is the minimal set that is "good enough", and that dropping even one minor element from that minimal set makes the vetting "not good enough"? In my opinion we can make that determination only in the context of a specific threat (or set of threats) as applied to particular use cases.

And that is where I think subjectivity is inevitable: you have to make a somewhat subjective assessment on what the threats are, how likely they are, and how serious they are. You also have to make a somewhat subjective assessment of what use cases are legitimate and relevant, and thus should be provided for in the policy, and what use cases are illegitimate and/or irrelevant, and hence can be ignored as far as the policy is concerned. I believe you can't completely apply analytical and deductive processes here, even if you have some hard data regarding threats, etc., because people may be proceeding from different axioms in terms of their values and beliefs regarding the threats and use cases--for example, what one person considers to be an illegitimate or irrelevant use case another person might consider to be a (or even the) major reason to use the product.

If we simply adopt sample vetting criteria (e.g., as outlined in the Lightweight Certificate Policy and Normalized Certificate Policy in ETSI TS 102 042 or elsewhere) then I believe that we are not addressing the true underlying problem: We run the risk of adopting criteria that are out of line with respect to the relevant threats, and by ignoring context we run the risk of negatively impacting legitimate use cases that are relevant to typical users.

With that in mind, let's take each case in turn, starting (out of order) with SSL server certificates, since those play a key role in potential anti-phishing strategies, and phishing is the single biggest threat we're currently concerned about.

SSL server certificate

With regard to SSL server certificates, if CAs and SSL are to protect against phishing at all then at a minimum there must be some assurance that only the owner of a domain can get a cert for that domain. Otherwise having the user compare the domain name in the Firefox address bar and the domain name in the status bar (as recommended by Gervase Markham and others) is of no use, since if someone can spoof the address bar domain name then they can also trivally get an SSL server certificate with a domain name matching the spoofed name.

Why not go further and require definitive proof of identity? Arguably this is

• a secondary consideration
• not necessarily possible in some contexts, and
• overkill for some use cases.

Taking these in turn:

Identity of the domain name owner is arguably a secondary consideration, because our primary consideration is ensuring that the "certificate owner" (i.e., the entity possessing the private key associated with the certificate) is the same as the domain owner, and you don't necessarily need to use identity per se to confirm that. (For example, you could verify that the certificate applicant both possesses the private key for the certificate and also controls the email account listed in the whois registry as being associated with the administrative contact for the domain.)

Second, identity documentation and ways of evaluating it can vary from country to country. It's possible in some cases that trying to prove that "certificate owner" is truly "J. Random User" and that "J. Random User" is the "domain owner" would be less useful and straightforward than trying to prove "certificate owner" = "domain owner" more directly (as in the example above). (Unlike identity, we do have a single global system regulating domain name registration, however poorly people may feel it works sometimes.)

Finally, proof of identity is arguably overkill for some legitimate and relevant use cases. For example, there are use cases involving IMAP/SSL, SMTP/SSL, etc., where the relying parties (i.e., the people with IMAP/SMTP mail clients) would have a prior relationship with the certificate applicant (i.e., the entity running the IMAP or SMTP server) and you wouldn't necessarily need strong identity checking by the CA. If strong identity checking is always required for SSL server certs then it would have to be extended to cover this use case as well (since we have a binary trust model for SSL server certificates--they're either "trusted" or not), and this might negatively impact this use case, by "raising the bar" for operators of IMAP, etc., servers.

Requiring strong identity checks for the IMAP/SSL use case "raises the bar" because it means operators of IMAP/SMTP servers either have to pay more for CA certs to cover the costs of additional identity checking that is arguably not needed for this use case, or they have to operate their own CAs, which is not a trivial task. The net effect is that this discourages the adoption of IMAP/SMTP, etc., over SSL, and thus negatively impacts typical users who might benefit from their email service providers adopting SSL for use with email protocols.

Email certificates

Here again the primary threat of interest is phishing, and if CAs and SSL are to protect against email phishing attacks at all then at a minimum there must be some assurance that only the person controlling an email account can get a cert for that account. Otherwise having the user (or the email client) compare the email address in the "From" field and the email address in the certificate is of no use, since if someone can spoof the From field then they can get a certificate to match the spoofed from address.

Why not go further and require definitive proof of identity of the person or entity associated with the email account? Because as with SSL server certs this is arguably a secondary consideration, not necessarily possible in some contexts, and overkill for some use cases.

In the Internet identity per se has never been tightly coupled with email accounts and email use. I communicate (every day it seems :-) with entities like "Nelson Bolyard", "Ian G", "Gervase Markham", "Duane", etc., without having ever met them or having the least idea if their real-life identities match their online identities. (Well, I did meet Nelson once, but I certainly didn't check his drivers license or passport, so I have no idea if I was meeting the real Nelson or a false one.)

As with the IMAP/SSL use case, in my opinion there are perfectly legitimate and relevant email use cases, like communication among friends, where requiring strong proof of identity would arguably negatively impact typical users in the context of those use cases. (Again, this is because requiring strong identity checks requires potential email cert users to pay more for certs to cover the additional checks, to go outside the CA system--e.g., by using PGP-based systems--or to use unsecured email.)

Object signing certificates

With object signing certs we are also concerned with the possibility of phishing, in the sense of tricking users into installing unwanted and potentially malicious software based on the users' perception that the software is from a known and trusted source. Unfortunately in the object signing case we have no independent mechanism for which the cert is serving as a cross-check (as the domain name in an SSL certificate does for the address bar, and the email address in an email certificate does for the From field). The only thing the user has as information is what's in the certificate itself.

(I've previously proposed that at least for software distributed through mozilla.org we consider providing such an independent mechanism, by tying object signing certificates issued to the Mozilla Foundation to domains controlled by the Mozilla Foundation. Thus, for example, we might have Firefox accept a signed Firefox extension for installation only if it had been downloaded from the updates.mozilla.org site. However this is not applicable to object signing in general, at least as practiced today. See also my comments below regarding related proposals.)

Since the user has to rely solely on information in the object signing certificate, arguably that information needs to be as correct as possible. At a minimum this means providing strong assurances of the identity of the entity distributing the software (who might not necessarily be the developer of the software).

It's also possible to imagine some CAs going beyond that and issuing object signing certs tied to a particular software object being distributed, e.g., as identified by a SHA-1 hash. (Among other things, this would more closely match practices for SSL certs, where each domain requires its own certificates--at least if we ignore "wildcard" certificates.) Alternatively object signing certificates could contain a "authorized download site" list which could be used as an additional check. But this is not general practice today, so our policy can't assume it.

This concludes my comments on the rationale behind the changes in draft 11 of the CA certificate policy. As usual, I welcome your comments on this issue, and in particular your opinions as to whether I should take this draft forward to the Mozilla Foundation for consideration as a 1.0 policy. (You can post comments to the relevant thread in n.p.m.crypto.) If you do have suggestions for changes please submit the actual language you'd like to see in the policy.

2005-02-27